Some good news this time.
First of all, LaurentS has agreed to provide his high performance sprite compiler system (Beats Of Rage) for rendering BadMood's HUD and weapon overlays. In fact he has built some of the sprites already for me to conduct tests with. I'm not quite in a position to use them just yet (the HUD stuff is disabled until I solve the game performance problems), but a plan for integrating his precompiled sprite code is well underway
The other good news relates to the game performance problems. I was able to confirm that the gametick is 'chasing its tail' trying to keep up with realtime, and not quite managing it. I wasn't able to confirm it before because the tick manager is quite complicated and my early attempts to foil it were ...foiled.
I found the best solution was to do it properly (as ever) and specify a new TICRATE which is much closer to the expected framerate, and an honest timebase based on a 200Hz tick.
The TICRATE-chasing stuff is really there for synchronizing network games, so each tick has a known, identical state on each client and no framerate-scaling is involved in AI movements etc. The client does however need to make sure it can keep up - otherwise a client locks up, or everyone has to slow down.
Having changed the TICRATE, the framerate gets 'capped' at that number and can't rise above it, but the gametick doesn't try to play catchup with more than 1 or 2 ticks per display refresh (instead of a burst - or continuous stream - of them, which was happening previously).
So the Doom2 test (Map11) that was producing about 2.5fps before is now producing between 4.5 and 6fps with the LOS tests and monsters still enabled. It's still a lot faster with LOS completely disabled but this change has reduced the problem a lot. The framerate is a bit erratic in this range because it's alternating between 1 and 2 gameticks per render and one alone is enough to impact the framerate.
I studied the JagDoom source and determined that the biggest optimization made there was reducing TICRATE from 35Hz (aimed at i486 or better) to 15Hz, and making sure the rendering was able to keep up with approx 15FPS plus some margin (GPU spans/columns, reduced resolution). The 'problematic' bits of the game code were optimized into DSP/GPU assembler to make this achievable.
The problem with the current Falcon version is that the balance of costs is roughly inverse to what the game was designed for - to minimize drawing at the expense of some extra calculation. With the Falcon version, the drawing is relatively cheap compared with the cost of the AI, because the drawing is all DSP'd and hand-optimized, whereas the AI is just C code aimed at a 486 CPU...
So I have a strategy now for making this work:
- Specify a sensible TICRATE which is just below the Falcon's 'average framerate', whatever that ends up being. Temporarily it will be 6Hz = 6fps. This may be too low and cause game code bugs to emerge, but the aim is to raise it again later if possible.
- Give up the ability to play back demos recorded at 35Hz, except in slow-motion (i.e. framerate ok, but things move sloooowly in the world)
- Demos recorded by BM will be recorded at the new TICRATE, and so will play back sensibly.
- DSP-ize the most offensive bits of the C code - several varieties of 'which side of line' tests used in line-of-sight and AI sector searches.
- 68k optimize the algorithms using those (LOS test, sector search)
- If the optimizations are effective enough, raise the TICRATE a bit to close the gap.
- Consider removing the realtime-hunting behaviour of the gametick, by giving up network support (which doesn't exist at the moment anyway) and fixing the gametick:render ratio at 1:1. This eliminates the tail-chasing problem completely, but when the framerate drops the 'game time' will slow down proportionally, as you'd expect with simpler games. The benefit here is that the framerate doesn't need capped so low, and can rise a bit in less costly areas of map without the gametick .
I'm a bit concerned that the game code isn't very clean w.r.t TICRATE and some monsters will not be moving at the right speed etc. having modified it. The Jag source is probably a good reference for fixes here. The Boom source does have fixes related to this too, but the TICRATE hasn't been changed from 35Hz which makes me wonder if those fixes are tested/good.
That's all for now. Longwinded post this time but the chances of this happening on a 16MHz Falcon just improved slightly.