Lag vs. recalculation in Clones (2011 thread)

[Simon]

Hi,

Icho was visiting me at my office, and I wanted to show him the thread on clonesgame.com about lag. I didn't find the thread in the private beta testers forum. It turned out to be in a public board. :-]

So, it's linked above. It's for cultural reference mainly. Maybe ideas from there will be interesting for the D/A5 port of Lix.

-- Simon

[ccexplore]

From the thread, it sounded like the backtracking method (ie. recalculation) to deal with lag was for the most part working fine for current versions of Lix, is there any reason to expect changes for the D/A5 port?

[Simon]

I'll try it with backtracking, because that's the obvious thing from the current design, and it should work.

The challenge is performance. On an idle map, performance of video bitmaps is already miles beyond the memory bitmaps in C++/A4 Lix. I ran the C++/A4 game at 16-bit colors, 640x480, anything else would make noticeable dents in the performance on my 9-year-old machine.

The D port hits 60 FPS on small maps, but bashing/digging is taxing on performance during the terrain-removing frame. Drawing to lookup map (for physics) and to the land (for visuals) is passed through an extra class that collects and dispatches outstanding drawings. The idea is that it's easier to profile, and to allow geoo/anyone to easily try some wizardry later.

Profiling is a little tough. geoo and I believe the graphics card caches lots of outstanding jobs, acting like a side thread, allowing the main program to continue. Measuring a block from beginning to end therefore doesn't profile the graphics card's total work.

The plan is to optimize in case we have immediate good ideas, but not concentrate 100 % on performance. It's more important to get working singleplayer out for people to test.

-- Simon

[ccexplore]

Interesting.  Sounds like the perf issue might also impact things like replays and loading of savestates (though less of a problem since singleplayer playability is not as timing-sensitive)?

I know nothing about profiling when it comes to graphics, perhaps forums on A5/SDL or whatever graphics library is being used in the D port could help in that regard.  It sounds correct to me that generally speaking, batches of GPU commands gets offloaded to the GPU to handle, freeing the CPU to go on doing other stuff in parallel (that's kind of the point of having the GPU to accelerate graphics after all).  It may well be that the only thing you can meaningfully measure is the resulting overall frame rate, but perhaps the experts can offer more informed advice on whether more fine-grained profiling is possible and how.  Normal profiling can still be helpful of course to catch any cases where the bottleneck turns out to be CPU-bound by accident.