Ma-Shell

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 5th element, you need to call list->first->next->next->next->next. It becomes evident that random access on any member of the list is quite bad. However, if you only iterate over the entire list, handling each element in there, this can be done quite efficient. Of course, lists can be grown and shrinked without problems, since they do not have to be any continous blocks of memory. However, since you need to keep track of all the additional bookkeeping-elements, like references to the first, last, next and previous elements, you need more storage than in an array. Performance wise, the fact that they are not in a continuous block of memory also impacts the caching behaviour (but you probably won't notice unless you are using them quite intensively) Maps are something quite different. They usually work by building a hash value of the corresponding keys and finding the corresponding list of elements that have the same hash-value in an array of buckets. They are usually well suited, if you have a key-value-pair, which you need to track. Both, insert- and lookup- operations require building of a hash-value, as well as an array access and iterating over a (usually very small) list of items in the corresponding bucket, so they have "rather constant" access times.

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.

What does the code for differently coloured letters look like? Do you call CreateText once for every letter and then position them manually or is there a nicer way?

Is it possible to combine more than 2 worlds (possibly by daisy chaining them)?

I see two possible issues with filters: 1. I understand a filter as having some sort of "layer-id" on the objects and a camera only rendering objects with a given layer-id. Suppose, you have two objects A and B. If you want to first render A and B and then from a different camera only B (e.g. you have a vampire in front of a mirror. You would want the entire scenery to include the vampire but when rendering the mirror, you would want to render the scenery from that perspective without the vampire). This would not be easily possible with a layer-id. 2. Performance: You have to run through all objects and see, whether they match the filter in order to decide, whether to cull them or not. If you instead just walk the world's list of entities, this does not happen. Why not using something like this: camWorldA->SetClearMode(ColorBit | DepthBufferBit); camWorldB->SetClearMode(DepthBufferBit); camWorldC->SetClearMode(DepthBufferBit); context->ClearWorlds(); // nothing is being rendered context->AddWorld(worldA); // All cameras of world A are rendered context->AddWorld(worldB); // First all cameras of world A are rendered, then all of world B context->AddWorld(worldC); // First all cameras of world A are rendered, then all of world B, then all of world C This would give the user maximum flexibility and only require the context to hold a list of worlds, which are rendered one after another instead of having a single active world. For compatibility and comfortability reasons, you could additionally define void World::Render(Context* ctx) { ctx->ClearWorlds(); ctx->AddWorld(this); } This way, you could still use the system as before without ever knowing of being able to render multiple worlds. EDIT: I see, my vampire wouldn't work with this system, as well (unless you allow a mesh to be in multiple worlds) but I still think, this is quite a flexible and easy to use system without much of an overhead

Isn't that basically what a world is? Each camera renders only the objects that are in its world, so the world is basically a filter for the camera