Optimization

[Twinklebear]

The engine is really slow. I'm not sure if this is a result of poor drawing optimization, slow physics/collision checking or the way entites are being handled.

If it's physics then it's just more motivation to work faster on getting in Box2d, if it's one of the other two it should be worked on.

The engine should in the end be able to handle very large maps with loads of entities running on them, but at the moment it's quite slow.

[btstevens89]

First area of focus should be on mMap->Draw(). It's taking about .07 seconds to run. FPS wise that's what is killing us. I'll take a deeper look into.

There's also an issue after several collisions the game freezes and takes over a second to render a draw. Not sure what that is either. I'll be actively looking to optimize both these issues.

Fun Fact
The program runs between 40-53 frames before the initial slowdown. It's happening in the Window::DrawTexture() function in mMap->Draw().

Even Funner Fact
This issue isn't happening when running LPCGame.exe outside of Visual Studio.

Best Fact
This is SUPER easy to do with the Performance Analysis in Visual Studio. Just goto Build -> Start Performance Analysis. It tells you all the parts of the program that are running slow.

[btstevens89]

Before/after some optimization.
42% to 30% in Map::CalculateIndex
21% to 26% in TileSet::Texture

63% to 56%, 7% so far.
More to come

Those percentages are the total execution time spent in those functions.

[Twinklebear]

Cool stuff! I've taken a look at the VS profiling before but never spent much time fixing what it said was wrong heh

[btstevens89]

Map::CalculateIndex now will only do something if the camera changes.
TileSet::Texture doesn't have to go through any map lookups if the texture was recently accessed.

These two combined took up over 50% of the program time, and now they're pretty much constant time. Leave this open though because there's more that can be done.

Right now TileSet::Texture never has to use map lookups besides getting the texture the initial time. As more tile images are added though this will change. In order to futher reduce this in the future we could have a queue of recently accessed Textures (rather than the current system that only holds one texture). With this we could have it hold the five (or however many is suitable) most recent textures that were queried. We'd look through that before searching the map.
I still think maps are the best way to hold that information, but they are such a burden.

[Twinklebear]

As a very minor side-note to optimizing memory/speed there are a lot of places in the code that use

std::string blah
//or
const std::string blah

as a param, should be changed to pass by reference. This used to be necessary because I was using a lot of temporaries, but with the migration to luabind this is no longer necessary as the string we pop off the lua_stack is allocated as a string already. Other big class params should also be migrated.

It's important to note that an rvalue reference would be nice but unfortunately luabind doesn't seem to understand them, as I got errors when trying expose a function with an rvalue reference param.

This is really minor though. Wanted to get it marked down so i wouldn't forget heh.