SpaceCadetPinball icon indicating copy to clipboard operation
SpaceCadetPinball copied to clipboard

Graphics could use a performance improvement

Open grepwood opened this issue 3 years ago • 2 comments

While making the big endian port, I've decided a good QA thing to do would be to let the ball run from start to finish, just to see if there are any collision errors or if the gameplay is free from errors. This took a very, very long time. Easily 20 minutes or so. This was performed on PS3 Linux, so the graphics backend was most likely software rendering. Turning off music and sound playback has not helped it. Moving the game from NFS home directory to a local filesystem has also not helped.

In contrast, OpenTTD and Quake 2 run just fine in software rendering.

This area could use improvement.

grepwood avatar Nov 05 '21 11:11 grepwood

To change anything about rendering, you need to first find the bottleneck. On desktop, both in SW and HW SDL, it is in zdrv::paint. On PS3 – who knows.

In my opinion, retained render model of original game is about as performant as it could be. SDL port adds one full frame blit on top of it, and GUI.

Try running the game: • Without GUI – don’t call ImGuiSDL::Render • With frame skip – skip render::PresentVScreen on some frames

k4zmu2a avatar Nov 05 '21 12:11 k4zmu2a

I did some testing with your branch under QEMU s390x. Standalone QEMU ppc was a bust for me, it could not configure the project. An unlikely combination of docker + qemu-user-static saved the day.

So, out of the box, using SW SDL, 3DBP data, with default window size I got ~20fps. With linear filter disabled, I got ~40fps. Disabling GUI had minor impact of +1-2 fps. Adding frame skip allowed the game to reach target UPS. Resizing the window had big impact on FPS, smaller window had more FPS. Things I did not explore: finding ‘native’ RGBA order, some might be faster. My conclusion: SW SDL is fill rate bound, game engine can prepare more FPS than SDL is able to present.

k4zmu2a avatar Nov 07 '21 15:11 k4zmu2a

Software SDL backend is slow; this is a known SDL issue. HW SDL backends are plenty fast. In my opinion, slow SW backend is better than nothing for HW deprived users. Potential solution: I wonder if SDL HW + Mesa SW OpenGL is faster than SDL SW.

k4zmu2a avatar Oct 16 '23 08:10 k4zmu2a