Open clort81 opened 1 week ago
I would guess that the chief reason for this may be the animated terrain, which is probably CPU-bound. Logically, that could probably be done on the GPU, though. I am not aware of anyone who has tried this or any other changes that could affect CPU usage, however.
I've attached the "game" label because, if memory serves, the game uses event polling while the editors use event wait, meaning they probably don't have the same issue. Feel free to correct me if that's not the case.
While recently going through startup code to fix #366, this part of the code flagged my attention:
while(sound_going(95)) {
draw_splash(pict_to_draw, mainPtr, logo_from);
handle_splash_events();
}
This code will update/draw as many times per second as the processor and GPU can handle. Which is not good--typically a game will lock its frame rate to a maximum of 60 or 30 by delaying at the end of every frame if less time was used than needed.
I don't know if BoE is running as fast as it can at all times, or just at startup, but if it is, that could definitely be the culprit.
I suspect this is the source of the problem, because boe.main.cpp
doesn't seem to do anything to set up a traditional "game loop".
Ah, this could be limiting the frame rate: https://github.com/calref/cboe/blob/5d7332562195d4a5db5547bb6797c143c506848c/src/game/boe.main.cpp#L340
But with the while
loop in the startup logic I think the limiter call will be ignored at that point.
I think fps_limiter.frame_finished();
should be added to handle_splash_events()
to change that.
I suspect this is the source of the problem
That loop is only during startup, so I'm fairly sure it can't be the source of a general problem.
Yeah.
There's no game logic running between turns / moves, at all. It ran on a 20mhz 16-bit machine, originally.
So, has anyone done a fork that fixes this?
Please link if there is one.