Added JFDuke3D, Duke Nukem 3D source port for smaller Pis

[protocultor]

Homepage: https://jonof.id.au/jfduke3d/

This old source port is the original base of EDuke32, according to its own wiki, and provides an OpenGL ES 2 renderer which runs extremely fast on a Raspberry Pi 3 B+; it shouldn't run any slower in older models. On the mentioned Pi 3B+, it can be played on 1280x720 with no visible slowdown, and unlike EDuke32, this resolution (and any resolution) is presented in actual fullscreen.
In greater hardware, it supports GL 2 and Polymost.
Uses SDL2 Game Controller for input (among others), so any gamepad can be supported as long as a gamecontrollerdb.txt file is included in $romdir/ports/duke3d.
Downside is: it seems that it doesn't support addons. It does support NAM at least (couldn't test it, I don't have it, or the Duke addons).
Seriously, just give it a go, on any platform. Script was based on the existing EDuke32 one, so it should run on anything supported by RetroPie.

Semi-unrelated note: EDuke32 installer didn't detect DUKE.GRP file if it's all uppercase, so it installed the shareware version of Duke, no matter if you had the full version on $romdir/ports/duke3d. Having both the full and shareware version of the game at the same time (with filenames using different letter cases) may work with EDuke32, but will crash JFDuke3D (actually, it just tries to use the *.CON files of the full version with the shareware one, failing to start because of it). Make sure you have only one version of the game installed.
This jfduke3d script properly detects the existence of DUKE.GRP, no matter if upper or lowercase. The same logic was applied for the eduke32 script (second commit). Replaces PR #3478 .

[protocultor]

From the same author (Jonathon Fowler) there's a Shadow Warrior port, which uses the same Build engine port, obtained in a git submodule. Seeing that its compilation process is not that different from JFDuke3D, I opted to include it here. Its name is JFShadowWarrior, or JFSW for short.
Credits and thanks to @Exarkuniv for the detection and addition of the game's expansions, which is included in RetroPie-Extra.
If you're reading this, I hope you don't mind. The difference with it is that with this one detects more platforms than the Pi 4 alone.
In terms of performance, in a RPi 3B+ you'll have to disable Voxel Sprites to get JFDuke3D's speed. Otherwise, just keep it at 640x480 resolution.
Note that here the "new way" of keeping config directories (/retropie_dir/configs/ports/game_name/port_name/) is followed, something I couldn't do with JFDuke3D, since EDuke32 saves directly to configs/ports/duke3d.

[joolswills]

Thank you. I think we could avoid some duplication as the build logic looks the same. the shadow warrior port could call the build call from the jfduke3d module.

[protocultor]

I think we could avoid some duplication as the build logic looks the same. the shadow warrior port could call the build call from the jfduke3d module.

Done, now JFShadowWarrior is completely dependent on JFDuke3D. I hope you aren't bothered by the parametrization (not a fan of the way it was handled in the eduke32/ionfury pairing).
Note that I removed the specific commit to clone from both projects' repos. They don't update that often, so missing any bug fixing is not worth it.
Also removed forcing the ALSA driver for music on x86.

[joolswills]

I think this should just call the eduke32 game data function (if it's the same)

[protocultor]

It's "mostly" the same, but it can't be used directly. Look at it, and note how at the beginning has an if [[ "$md_id" == "eduke32" ]]; to verify if it has to install it, because game_data() is called by configure(), and configure() is called on both eduke32 and ionfury.
I can do corrections to both if you want.

[joolswills]

Thanks - yeah, changing it to support your modules as well would make sense.

[protocultor]

Did the short version: moved the if sentence to configure() , so game_data() only worries about Duke3D data, and not if it should be called or not. That allows it to be called from the jfduke3d module.

[joolswills]

There isn't a package libgtk3.0-dev - should it be libgtk-3-dev ?

[protocultor]

You're right, thanks for the correction.

[protocultor]

Just in case: I force pushed the fix to this; the script is referencing the correct package now (libgtk-3-dev).

[newhinton]

@protocultor The emulator works great after adding your script. Is this the right place to mention issues for controls specific to this emulator game?

[protocultor]

@newhinton no, I don't think so, this is for the addition of the scripts to RetroPie... unless your problem is so terrible that it makes these scripts not worth adding.
Try the official documentation, or better yet, my post in the official RetroPie forums. I'll try to help you there.

[s1eve-mcdichae1]

This makes configs/ports/jfduke3d right? Should it be configs/ports/duke3d/jfduke3d instead? Puts the jfduke3d inside configs/duke3d (which already exists for eduke32 module), instead of alongside it.

[s1eve-mcdichae1]

Here, the opposite. Should this just use configs/ports/sw like the RP-Extra module (which this would effectively replace, and there is no other SW module to share space with), or why the extra layer deep?

[protocultor]

I though the same, but configs/ports/duke3d points directly to the config to EDuke32, and your idea would force the config of JFDuke3D to go inside the config of EDuke32 as a subdirectory. Imagine how that would appear inside the config directories of RetroPie (/opt/retropie/configs/ports), and most importantly, how the "home" directory would appear:

ports
  |
  |- duke3d (1)
        |
        |- jfduke3d (2)

~
|
|- .config
|     |
|     |- eduke32 (1)
|          |
|          |- jfduke3d (2)
|
|- .jfduke3d (2)

(1) and (2) are to see where the links point.

The "extra layer" you mention was inspired on how is currently treated for Quake 1 and 2, where the first layer is the name of the game, and inside them is every individual port for that game (compare tyrquake.sh and darkplaces-quake.sh to understand). It's just better organized and future-proofed, compared with how Duke 3D does it, which just has "the name of the game" as the destination for the config of just one of the ports. It's just something that didn't age well, because of the need for organization when having more than one port for a game.

I don't find that joining all the configs on the different ports under the "first port made" is a good idea, especially if the user wants to back up a config for a certain port; this user might find every single config for every port of that game included. Or if the players want to "reset the config" by cleaning the directory, they will find that they deleted the configs for all of the ports of that game.

Of course, there may be a better solution, but I dealed with a legacy problem the best I could. I just don't find mixing directories is a good idea, but if the owners of the project want that, it'll be done.

[s1eve-mcdichae1]

So what you're saying is that it should actually be ports/duke3d/eduke32, but that that ship has sailed...

[protocultor]

Yeah, exactly, that's what EDuke32 should have used since the beginning. Although I understand no one would have predicted the use of different ports for the same game, it would have been nice if it was considered in some form. In the ideal world, it would have been great if this change could be done without the user having to do anything on their end.

Still, this had me thinking again. What if JFDuke3D, instead of using configs/ports/jfduke3d, used configs/ports/dukenukem3d/jfduke3d? Even if we have the same game twice, at least there would be a place where the configs of a potential 3rd port of Duke Nukem 3D could be located, without filling more places on the "root" of ports. If you have a better idea, I'm all ears.

[joolswills]

Thanks. The config locations for some things are not ideal, due to later additions. It might be worth me re-organising the configs for eduke32. I will come back to you. Sorry for the delay.