Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
wants to merge 5 commits into
base: master
Choose a base branch
from

Conversation

protocultor
Copy link
Contributor

@protocultor protocultor commented Nov 13, 2023

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
Copy link
Contributor Author

protocultor commented Nov 14, 2023

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
Copy link
Member

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
Copy link
Contributor Author

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.

In these ports, alsa is no longer forced on x86
Also, master branch is used in both projects
if [[ "$md_mode" != "install" ]]; then
return
fi
game_data_jfduke3d
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.


isPlatform "x86" && depends+=(nasm)
isPlatform "gl" || isPlatform "mesa" && depends+=(libgl1-mesa-dev libglu1-mesa-dev)
isPlatform "x11" && depends+=(libgtk3.0-dev)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You're right, thanks for the correction.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@newhinton
Copy link

newhinton commented Dec 4, 2023

@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
Copy link
Contributor Author

protocultor commented Dec 4, 2023

@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.


function configure_jfduke3d() {
mkRomDir "ports/duke3d"
moveConfigDir "$home/.jfduke3d" "$md_conf_root/jfduke3d"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

local gamedir="$romdir/ports/shadowwarrior"

mkRomDir "ports/shadowwarrior"
moveConfigDir "$home/.jfsw" "$md_conf_root/sw/jfsw"
Copy link
Contributor

@s1eve-mcdichae1 s1eve-mcdichae1 Dec 6, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

@s1eve-mcdichae1 s1eve-mcdichae1 Dec 6, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

@joolswills joolswills Dec 10, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants