Battlescape performance

[Yankes]

i dont get it. every graphic in battlescape use same color set, but for some reason we change palette in some graphic for simulate shading.
next thing we "casting" back this graphic back to original palette.
it would be better to simply handwrite blit function that have shade arg?

[Daiky]

Yankes : that's exactly what I did yesterday. I wrote my own blit function with the shading done on the fly - it simplifies the whole problem a lot.

But there is still a problem with it. When running in debug mode, the handwritten blit function is also compiled with debug info, making the whole thing soooo sloooow
I'm no specialist on compilers and stuff like that, so I don't know how you can have parts of the code normally build while still being able to debug build the rest...

[DaiShiva]

Yankes : that's exactly what I did yesterday. I wrote my own blit function with the shading done on the fly - it simplifies the whole problem a lot.

But there is still a problem with it. When running in debug mode, the handwritten blit function is also compiled with debug info, making the whole thing soooo sloooow
I'm no specialist on compilers and stuff like that, so I don't know how you can have parts of the code normally build while still being able to debug build the rest...

That is what a RelWDebugInfo (Release with debug info) build does for you. Visual Studio at least will tell you if you have any conflicting flags set.

[Yankes]

in my gcc i dont have this problems, debug version and release version run on the same speed. at lest every program i compiled behave this way (openXcom too).

[Daiky]

found an article on the topic:
https://randomascii.wordpress.com/2011/07/22/visual-c-debug-buildsfast-checks-cause-5x-slowdowns/

going to test it at home tonight and see what the results are...