Ma-Shell

Please don't use Window::MoveMouse! You will have users constantly asking themselves, whether that's absolute (i.e. move mouse to x, y) or relative (i.e. move mouse by dx, dy). Even if you can easily look it up I think, it is more helpful when scrolling through the autocompletion-options to just see on the first look what the function does without ambiguities.

Pretty sure "appstores" is wrong, though^^

I don't even know what the f*** is going on with all the appstores?^^

This is looking great. I've always been bothered by the available options for a lightweight GUI. I also think that cross platform support for a GUI framework is quite a big deal and can only second the opinion that this is the most important bonus goal. From the material you have posted, there is one thing I am quite curious about: In your code example you are placing the button and panel using fixed coordinates and sizes. Moreover, the widget is only created once and does not run through a loop, where the user would constantly recalculate the coordinates. When looking at the video, howev

You might want to look at the return code: in your batch-file add echo %errorlevel% directly after the game and before the pause

Is there a log in %LOCALAPPDATA%/Leadwerks ?

Have you tried temporarily turning off windows firewall?

Arrays use a single continuous memory block. If you want to enlarge your array you need to copy all data to the new location. However, when you want to randomly index the array, this can be done in constant time, so accessing x[5] is just as fast as accessing the first element or the last one. Vectors are basically a sort of managed arrays. They take care for reserving more space than you actually requested, so they can dynamically be increased and decreased in a limited manner without a performance hit. Lists are usually linked one element to the next. This means, for accessing the

I suppose, that would be the case. There might be some other optimizations for brushes (e.g. if you want to have a sphere, you can simply transfer the center and the radius to the GPU instead of multiple vertices and again save some bandwidth and RAM real estate) but I believe that these differences would be only minor. I should say though, that I have never done any comparison nor do I have any specific knowledge of how this is implemented. Everything I'm saying about that topic is just derived from things I gathered in different forum posts here over the years and using my own logic

The difference comes from the fact that the entire thing is collapsed to just a single model. This means that every piece of code, which iterates over all instances only walks over this object once instead of 1000 times. Also there is only one transformation matrix which is getting updated and pushed back and forth from CPU to GPU and which takes much less space (which can be used for caching again)

What happened to where you claimed 200 fps for 10000 characters? Was that all shared skeletons?

This is certainly a pretty cool feature! Whenever physics is involved, however, the programmer needs to keep in mind that there might be slower systems out there and things might break when executed on slower systems. The programmer might e.g. be tempted to give an option to reduce the particle effects on lower end hardware but then the entire physics might break.

I suppose, texcam will be rendered every frame, just like the normal camera. Would there be an option to render the camera only on demand? Like some sort of photograph? Or with a lower frequency for performance optimization?

Are you using some fancy new technology like MVR or one of its predecessors for the single pass point-lights? If so, have you also evaluated, what happens on older GPUs?

There is but that isn't trivial to implement: Basically you create a grid where each cell lists all the enemies within the region. This requires that when an enemy changes position, it also removes itself from the old cell's list and inserts itself into the new one. Then the player only has to search through the lists of the nearby cells. Of course the additional bookkeeping might have a different performance impact but especially, if the entities also sometimes react to one another or if you're checking the distance more often, this will certainly pay off.