Win95 game on Android handheld with 3dfx - 3D is fine but 2D menus are terribly slow

[ldonkaio]

First of all, congrats for the amazing work!

I am trying to run the game Sub Culture (1997) on an entry level Android handheld device (Ayaneo Pocket Air Mini) through RA's dosboxpure core.
The game has an initial 2D menu and also in-game 2D screens when you enter ports (well, whatever you want to call ports for underwater cities).

I started playing the "software rendering" version of the game, and the 3d graphics were quite laggy, as expected from my low power device, so I decided to try 3dfx emulation.

After installing the drivers and playing around with settings (e.g. using hardware OpenGL) I managed to get the 3dfx version working: the performance on the 3D parts of the game is very nice, but the 2D menus became extremely laggy.
The start menu is almost unresponsive, and sometimes it triggers a hard crash of the core when trying to navigate it.
The in-game menus are somehow more responsive but still quite slow and the music stutters quite a lot, which is a pity.

I read in another issue about the fact that 2D screens are hard to render with 3dfx OpenGL emulation, so I was wondering if this is just a hard limit or if there are some things I can try to improve the situation or new features addressing this are planned.
It would be a pity to not be able to play a nice game which runs flawlessly in the 3D parts just because the 2D parts make it unplayable when using 3dfx emulation.

[schellingb]

When it comes to 3dfx emulation via OpenGL the rendering of 1 pixel is about as complex as rendering 1 polygon. So if we estimate a game of the era had maybe up to a few hundred thousand polygon per second at 30 frames per second we maybe 10 or 20 thousand polygon per frame. Compare that to a full screen 640x480 image where every pixel is drawn which results in over 300 thousand draw commands required to fill the screen. So because for the emulation we spend all of our time converting the commands to what the device hardware can use it ends up making 2D slower than 3D.

There is still possible optimization, where a (large) group of pixel draw commands would be emulated via a dynamically generated texture image. But doing that smartly so it is fast is quite complex. Maybe sometime in the future...

[ldonkaio]

I see, thanks a lot for the explanation, it makes perfect sense!
I'll watch out for future updates then :).