L B

Odds are that I'll make a C# wrapper for Leadwerks 3, whether Josh or Mika like it or not (provided Leadwerks 3 still works with a main DLL). In all likelihood, it won't work for Xamarin and thus portable devices. It'll just be a wrapper for Windows, which is fine for a lot of people who still target this massive audience and don't want to waste hours on the intricacies of low-level development or on the volatility of scripting. That being said, if I can reconcile with C++ (the ex-girlfriend analogy truly was good), I'll probably use C++ myself for Leadwerks.

Haha, I agree with Josh. Don't use your own custom, globally unknown and confusing type defs. If you feel like "float", "int", "unsigned char", etc. are not specific enough and platform variant, use stdint.h (which is, you know, explicit, standardized and known by most C/++ programmers). int => int32_t unsigned short => uint16_t unsigned char => uint8_t etc. http://stackoverflow...e-or-not-stdint

These command names are like the recognizably-shaped gift you see wrapped under the Christmas tree.

I for one prefer a single monitor. After using duals for about 2 years, I came to the conclusion that I was wasting time managing a second screen.

While I agree that the "command" "pattern" (both in quotations intentionally) is ridiculous, the simple approach of saving every state of the program for each action is lazy (but that's not bad per se) and extremely memory consuming. What I'd do is have a reverse action for each action, push the action to a stack, and pop the reverse on undo. Tadah.

We can testify. -Every Leadwerks 2 user, ever.

"Windows supports binary files, so use them." "For what?" "For everything."

Smart pointers really do seem interesting. I wouldn't want to have to manage my ref count either. Think of the Lua scripters, who use this language to avoid the complexity of C++. If they don't want to deal with pointers, they certainly wouldn't want to deal with reference count either. They'd want it to "Just work".

I just got the title's pun!

Josh mentioned wanting to use states. However, I can see how that can grow to a high RAM usage fast. I use something similar to the command pattern too usually.

So close! Keep it up!

That's not a fatality. Yes, with people who do not understand how memory management works and do not call delete, this will happen. If you code properly, it won't. In the same spirit, using your newly proposed system will lead to invalid reference count crashes or objects that stay in memory indefinitely when they shouldn't, because people forget to call "IncRefCount" or "Release" or call them too often. Constructors are not passable through a DLL for other languages, I think this was the reason. Also, in languages that require class wrapping (Java, C#, etc.), using static classes allowed to have 'Entity::Create' instead of 'Engine::CreateEntity', which is a nice syntactic sugar.

I agree with Rick. It seems counter-intuitive to me to have to call IncRefCount. After all, why would I? I have a texture object, I want to use it, why should I do anything to it first? Similarly, using Release() instead of delete seems just as counter intuitive. Normal C++ would do exactly as in your first example. I understand you're removing internal classes this way, but for the end user, it's not prettier, not more intuitive, and will actually be a bother in the long run if we have to type this for every object. In the "source purity" aspect, this has the adverse effect of making me think this wasn't designed for C++, but just patched to work with it.

D'oh, missed it. Guess I should have done more game development in the past year.

I think you may underestimate the amount of work in an undo system for an editor as complex as Leadwerks 3's. But hey, it's almost over, so cheers.

I think Mirror's Edge is baked, not real-time. Unreal Engine 4 seems to do it as well. ParaToxic, I sent you a PM with the video.

It sure is possible, Unreal Engine 4 has it. I would link to a video, but Mr. doesn't seem to like that (understandably). Perhaps you could lookup their implementation details? What algorithms have you found on the web? Some theses might cover it.

Do it well, but don't release it months after the release -- it's a critical feature. I also go by the philosophy of doing from scratch, yourself, but sometimes you have to admit that some libraries exist that already do it well. Weigh the possibilities. People will start coding crappy GUI alternatives from scratch and redo them later.

I like the "Add Component..." approach better.

Yay! And thus, Leadwerks died to profit.

Procedural content generation truly is the future of indie game development. Not having to worry about artists for your props, level or even characters would give developers a huge boost in base assets, and perhaps help unlock funds with the added credibility for future specific assets in their game or software. I have a tree generator side project that I develop when I get time off school and other work. Here's a screenshot for the curious:

Expected behaviour for a fade would obviously be RGB, not HSV. I can only see this being used for unicorns, gay pride, or nyan cat.

FatCow includes the 32x32 version, y'know.

Oh but Josh didn't you hear? DX11, tesselation and PhysX just make your game instantly sexy. You only have to press one button, and voilà!