Yamagi Quake 2 version 8.50 overhaul

[protocultor]

Changelog: https://github.com/yquake2/yquake2/blob/QUAKE2_8_50/CHANGELOG

Most relevant addition for RetroPie is a new OpenGL ES 1.0 renderer, which provides excellent performance under Buster for basically all Pis that are supported in this OS.
Works on Bullseye, but requires a little fiddling to run the Legacy driver there:
yquake2/yquake2#1128 (comment) (point 2).
Note that, even if you don't use GLES1, its new options for optimization in mobile / embedded GPUs (gl1_discardfb and gl1_lightmapcopies) are also available in GL1, so all SBCs and their OSs are benefitted from it.

This PR includes:

• A patch that enables the "Exit shortcut", RetroArch style, in YQ2. Meaning, Hotkey + Start immediately quits the game and returns to EmulationStation. In terms of SDL buttons, "Guide" is the one used as Hotkey; if that doesn't exist, "Back" ("Select") is used.

• Another patch, which applies a "fake revert" of the SDL3 gamepad buttons PR of YQ2 (Consistent binding between multiple gamepad types + labels by style yquake2/yquake2#1183), so it doesn't conflict with the SDL2 configuration applied by runcommand on RetroPie. The reasoning behind this is detailed in point 3 of this comment:
  Input auto-configuration for SDL2 gamepads #4035 (comment)

• A new default configuration file to install for the game. This includes predefined gamepad buttons (that can be reassigned in options menu), gameplay changes for a smoother experience with controller, and most importantly, enables the mentioned optimization options for embedded GPUs.

• Changed name of the game expansions to properly order them by release date (instead of the second being shown first).

Something that I wanted to do, but it's not my call, is to change the module section from "experimental" to "optional". Please evaluate this after seeing this PR in action, in every platform, including Pi 1.

[cmitu]

@protocultor thank you for the PR and the yquake2 changes. While I don't have a Pi1 to test, I'll run some tests over the week-end to see how the new version works with the new GLES1 renderer.

In general, the PR looks fine, for the moment I have just one question which I'll address inline with a review.

[cmitu]

AFAICT there's no kms but non-gles system in RetroPie, so the kms check would be redundant. Why the new test here ? Is the new renderer not working with r_customwidth/r_customheight or you think the video mode parameters are no longer necessary ?

[protocultor]

My apologies, my cleanup wasn't a as complete as I thought. The mentioned verification and parameters are no longer needed, so they were taken out.
For the record, the new renderer does work with r_customwidth / r_customheight , but it's no longer necessary to put them on the parameters since the r_mode -2 (automatic resolution) included in the new default config is more succint, and achieves the exact same result, with the possibility for the user to change it if it's needed. Vsync is also enabled by default, on all renderers.

[cmitu]

@protocultor no worries, I just wanted to know the reason for the modification.

I think that the r_customwidth/r_customheight might not be needed anymore for KMS, though maybe we can add - globally, for all platforms - the +set r_mode -2 parameter. For new installation, the r_mode is part of the .cfg file, but for existing installation it may not be. For now it's ok, I'll do some tests with how the resolution change from runcommand is affected.

[cmitu]

@protocultor Ok, so I've done a few tests using a Pi4 running both current OS (Buster) and the current RaspiOS (bookworm) and also a Pi3 using the current OS (Buster). It's fullspeed on a Pi3 @720p and it's really fast !

1. The kms params for width/height are no longer necessary, when either native fullscreen or window fullscreen are used in the Video options the fullscreen resolution is always used and any video mode set by runcommand is kept.
2. Forcing the vid_renderer to gles1 from the command line will override any settings set by the user. Now, when the params handling was originally designed it was probably ok since the PI platform(s) could only have one accelerated renderer (i.e. GL1), but now some of them can potentially use either GL1/GLES1 or GLES3. I'll think of something here, since the preferred solution would be to set the preferred/default vid_renderer in yq2.cfg instead of doing it runtime.
3. I noticed that in current RaspiOS (bookworm) the gles1 renderer fails with SDL being unable to create a GLES1 rendering context. This is not specific to Yamagi, the same error message is logged when running the SDL2 test testgles (and it also fails to run). Seems to be related to the Mesa version included in the current RaspiOS, since the GLES1 renderer doesn't have an issue with the older RaspiOS (i.e. buster).
   When the gles1 renderer fails, the software renderer is automatically loaded and it runs ok (since it's forcing a 640x480 resolution), but this might impact the defaults we set at runtime for RPI devices. I'll see if I can trace where this issue occurs and if upstream can offer some insight, but until we have a solution I think the ref_gles3 renderer can be set as default in the .cfg file.

For now, I'll think of something for 2. Regarding 3. - what was/is your testbed for the GLES1 renderer ?

[protocultor]

@cmitu it's funny that you mention GLES3, since it's not new at all but no one added it to the YQ2 script in these years.
Is performance good with GLES3 in a RPi 4? I ask because I worked a lot in many optimizations to GL1/GLES1 and GL3 doesn't include most of them, so I don't know if GLES3 would work better than GL1 in this hardware (for now, at least).

About my testbed, I only have a RPi 3B+, so I've only tested in that. This comment documents my experience on different RPi OSs:
yquake2/yquake2#1128 (comment)
Since this comment, I've increased efficiency by almost 10% by improving gl1_discardfb, and performance of GLES1 in Bullseye is actually faster than GL1 after its installation, but most of the statements remain true.
In summary, only Buster and earlier support GLES1 officially, while in Bullseye can be manually installed and it's even recommended, but Bookworm doesn't ship the kernel part of the legacy driver so it's a no go, you're forced to use GL1, which is not as fast as GLES1 where available unfortunately. Also, the only OS with decent "point parameters" GL extension is Buster. In both Bullseye and Bookworm you have to disable it (gl1_pointparameters 0) to have round particles in the game, that in a RPi 3 at least.

About RetroPie, I've only tested the official image, so I didn't even know that it was possible to install it in newer OSs. I'll do that now (hope it doesn't break anything on any partition).
I fully agree that setting good defaults for every platform in yq2.cfg is the way to go. If you can guide me on how to properly detect each OS in the RetroPie scripts, I'd be thankful, because I'd be able to concatenate the proper settings for each in yq2.cfg. The only thing that baffles me is having to set GL1 in Bullseye, since I don't think many people know that can use GLES1.

[protocultor]

Forcing the vid_renderer to gles1 from the command line will override any settings set by the user. Now, when the params handling was originally designed it was probably ok since the PI platform(s) could only have one accelerated renderer (i.e. GL1), but now some of them can potentially use either GL1/GLES1 or GLES3. I'll think of something here, since the preferred solution would be to set the preferred/default vid_renderer in yq2.cfg instead of doing it runtime.

Done in the new commit, now it sets the renderer in the default config.

I noticed that in current RaspiOS (bookworm) the gles1 renderer fails with SDL being unable to create a GLES1 rendering context. This is not specific to Yamagi, the same error message is logged when running the SDL2 test testgles (and it also fails to run). Seems to be related to the Mesa version included in the current RaspiOS, since the GLES1 renderer doesn't have an issue with the older RaspiOS (i.e. buster).
When the gles1 renderer fails, the software renderer is automatically loaded and it runs ok (since it's forcing a 640x480 resolution), but this might impact the defaults we set at runtime for RPI devices. I'll see if I can trace where this issue occurs and if upstream can offer some insight, but until we have a solution I think the ref_gles3 renderer can be set as default in the .cfg file.

Also solved, the default is the software renderer but in any installation the script should be able to change it. Now it checks if running Buster or earlier to set GLES1 as the renderer (although maybe shouldn't be recognized as a gles platform in the newer OSs, but that's another matter). Can you give it another try?