calref / cboe

Classic Blades of Exile
http://spiderwebforums.ipbhost.com/index.php?/forum/12-blades-of-exile/
Other
167 stars 41 forks source link

Still using 100% cpu for a turn-based game that needs 0% cpu. #372

Open clort81 opened 1 week ago

clort81 commented 1 week ago

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.

CelticMinstrel commented 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.

NQNStudios commented 1 week ago

While recently going through startup code to fix #366, this part of the code flagged my attention:

https://github.com/calref/cboe/blob/5d7332562195d4a5db5547bb6797c143c506848c/src/game/boe.startup.cpp#L131

    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".

NQNStudios commented 1 week ago

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.

CelticMinstrel commented 1 week ago

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.

NQNStudios commented 1 week ago

Yeah.