This is an ebuild for Wolf4SDL. Original motivation was to find a reasonably up-to-date engine for Wolfenstein 3D that supports amd64. As the current wolf3d engine in portage (wolfgl) hasn't been updated for >10 years, I had to find something newer. Wolf4SDL, while not perfect, appears to be the best current option. This requires adjusting compile-time variables for the specific version of wolf3d you'd like to play (shareware version, registered Apogee version, etc.). I used USE flags for this, defaulting to the shareware version. Couple notes: 1. Although wolf4sdl itself supports multiple patch levels of each version, my ebuild only supports the latest of each version (1.4). It wouldn't be particularly difficult to extend this to include support for every other variant, but I really don't see the point. 2. Spear of Destiny is also supported by wolf4sdl, but not by this ebuild. The rational is that, since the binary has to be custom tailored to the game data, you can only install and play one game at any given time and this it'd be impossible to play copies of both wolf3d and sod. I think a better approach would be to have a separate ebuild called wolf4sdl-sod that specifically focuses on sod, and allow both to be installed in order to allow playing both games. Aside from the above, the code required some cleanup to compile, which is included in the ebuild. I also included some other enhancements: 1. Patch to support (optionally) auto-grabbing the mouse when launched in window mode (by me) 2. Patch to support quake-style strafing controls (by Matthew - http://diehardwolfers.areyep.com/viewtopic.php?p=63353#63353) 3. Patch to smooth mouse movements (by TexZK - http://diehardwolfers.areyep.com/viewtopic.php?p=63353#63353) The window mouse patch is always applied as it simply provides a new command line option. The latter two are set through USE flags since they affect gameplay. There's one remaining issue that needs to be worked out: wolf3d wrote it's configuration file to the same directory as the binary, and wolf4sdl continues this tradition. This makes use on a multi-user system like Linux rather difficult. I've partially worked around this problem by instructing wolf4sdl to write the config file to /tmp instead of it's own directory. This allows users to actually save preferences across game plays (yay), but obviously it's not a very good solution. I'd really like to get it to save preferences to something like ~/.wolf4sdl/config.wl6, but I'm not a C++ programmer and I just could not for the life of me figure out how to copy and concatenate strings (and the obvious choices of strcp() and strcat() generated compile errors). Anyone with C++ experience is most welcome to give this a shot - look for configname in wl_def.h and wl_main.cpp. Feedback welcome. Reproducible: Always Steps to Reproduce:
Created attachment 237553 [details] games-fps/wolf4sdl-1.6.ebuild
Created attachment 237555 [details, diff] mouse smoothing patch
Created attachment 237557 [details] strafing patch
Created attachment 237559 [details] window mouse patch
Created attachment 237561 [details] desktop icon
Please do not use patch directly (rather use epatch from eutils.eclass); also try not to overuse sed to apply changes. Changes also should happen in src_prepare not src_configure. Finally, hardcoding /tmp is a bad idea.
1. Oops, forgot about epatch. Will get that fixed. 2. I'm not trying to overuse sed, but I think it makes more sense to use that in the places I've used it than to create separate patch files. Other/better suggestions welcome if this is "bad". 3. Will update. 4. Yes, I know it's bad. As I mentioned, though, it's simply the best I could make work, and I figured it's better than not being able to save preferences at all (unless you're playing as root, which is also bad). A proper fix is definitely welcome here; it's just beyond my scripting skills.
Created attachment 237565 [details] games-fps/wolf4sdl-1.6.ebuild Fixed 1 and 3. I looked at the sed usage again and still can't find a better way to handle it. The version.h stuff would require a separate patch file per game version, which seems like overkill. The other fixes, for the GCC and home directory issues, are just one-liners that seem much better to fix with sed than using a patch file. But again, suggestions welcome. Thanks for the feedback.
Hello, The Gentoo Team would like to firstly thank you for your ebuild submission. We also apologize for not being able to accommodate you in a timely manner. There are simply too many new packages. Allow me to use this opportunity to introduce you to Gentoo Sunrise. The sunrise overlay[1] is a overlay for Gentoo which we allow trusted users to commit to and all users can have ebuilds reviewed by Gentoo devs for entry into the overlay. So, the sunrise team is suggesting that you look into this and submit your ebuild to the overlay where even *you* can commit to. =) Thanks, On behalf of the Gentoo Sunrise Team, Markos. [1]: http://www.gentoo.org/proj/en/sunrise/ [2]: http://overlays.gentoo.org/proj/sunrise/wiki/SunriseFaq
Alright, I figured out a proper way to handle the config dir issue. With the new version, configuration will be saved to ~/.wolf4sdl/wolf3d.wl6 or ~/.wolf4sdl/spear.wl6, depending on which game you're playing. W00t. I don't have a retail copy of SoD, but I'll see if I can grab the shareware version and write another ebuild for wolf4sdl-spear. All of the patches should equally apply to it, so hopefully it shouldn't take much time. I'm quite ready to be done with this. :-)
Created attachment 237819 [details] games-fps/wolf4sdl-1.6.ebuild
Created attachment 237821 [details, diff] per-user configuration directory patch
Created attachment 237823 [details, diff] window mouse patch
Created attachment 237825 [details, diff] strafing patch
Created attachment 237833 [details, diff] Alternative configname patch, with error checking (In reply to comment #12) > Created an attachment (id=237821) [details] > per-user configuration directory patch I had seen this bug and was drafting an alternate patch when you posted. Looking at your proposal, we followed a similar path. However, your approach lacks error checking. Although uncommon, it is legal for HOME to be unset, in which case getenv will return NULL. If not checked, this will cause a crash when your strcpy reads the returned value. Also, you use strcpy without any check that the value of HOME will fit within the declared buffer. I have attached my proposed change. I opted to mkdir the required directory inside the new subroutine, and so did not create separate variables for configdir and configname.
OK, I'm officially ready to call this sucker done. The new ebuild includes support for SoD as well. It can be used like this: USE="wolf3d_apogee -wolf3d_shareware spear_full" emerge ... This will build and install support for both wolf3d and spear, with binaries being named wolf3d and spear accordingly, and data being saved to GAMES_DATA_DIR/wolf4sdl/(wolf3d,spear). Alternatively, USE="-wolf3d_shareware spear_demo" will only build and install support for the SoD demo. Ditto if you only want wolf3d installed. I also rolled the GCC fix into one of the patches and added new icons. I like this approach quite a bit - should make things really easy for users, and avoids the need for split ebuilds like I was originally thinking. (In reply to comment #15) > Created an attachment (id=237833) [details] > Alternative configname patch, with error checking Kevin, thanks so much for this. I just wish the timing was better. :-) I like the idea of extra validation, so I tried swapping out my patch for yours, but unfortunately I had some trouble with yours. It kept aborting with "Your $HOME is too long". I spent a while troubleshooting it and rewrote some of the code to get this part to work, but then it gave me a completely separate error when launching the game, something about "No protocol specified". That shouldn't have anything at all to do with this, but I guess it wasn't happy with the changes I made to your code. So, I reverted back to my own patch and basically incorporated your ideas. The same validation is there, just done in a different manner. The added benefit here is that I understand the syntax and was able to make it work. :-) Thanks, though; I very much appreciate your help, even through I wasn't able to use your patch directly.
Created attachment 237849 [details] games-fps/wolf4sdl-1.6.ebuild
Created attachment 237851 [details, diff] per-user configuration directory patch (and GCC fix)
Created attachment 237853 [details, diff] window mouse patch
Created attachment 237855 [details, diff] strafing patch
Created attachment 237857 [details] desktop icon (wolf3d)
Created attachment 237859 [details] desktop icon (spear)
(In reply to comment #16) > (In reply to comment #15) > > Created an attachment (id=237833) [details] [details] > > Alternative configname patch, with error checking > > Kevin, thanks so much for this. I just wish the timing was better. :-) I finished it the day before, but was not able to test it until after you had posted your first iteration. No matter, I am glad that I was able to help. Looking at your final patch, I notice you do not cache the return value of getenv("HOME"). It looks like getenv is not declared as pure/const (see /usr/include/stdlib.h), so each occurrence of getenv in the code will translate to a separate call to getenv at runtime. For a single-threaded program, this is not racy, but it is slightly wasteful, which is why my proposed patch stored the result and then tested/used the pointer initialized from the call to getenv. I neglected to mention that I tried my proposed function in a test program, but did not build a patched wolf4sdl with my proposed change. In the test program it worked fine, and I expected it would work in the normal program as well.
I have a problem with your wolf4sdl ebuild, at least on x86. When I try to save a game, I get a segmentation fault. This problem does not show up when I'm building manually wolf4sdl from source (without the ebuild).
Thanks for the report. It probably has to do with the new code to save games to your home directory, and now that I think about it, I don't believe I actually tried saving a game. I verified the config files were created and persisted, but didn't think to test saving because I thought they were all the same. Oops. I'll try to fix this tonight.
Created attachment 241169 [details] linux multi-user support and GCC fix Huh. That was far less painful to fix than I had anticipated... which probably means I did something wrong. ;-) Please give the new linuxfix.patch a try. I can't say that this is the most elegant solution, but it works (at least for me). Please let me know if you have any trouble.
Great work Jared... saving and loading works just fine now. I found a little other glitch recently, concerning the keyboard layout: I can't manage to type numbers (for copy protection in Spear of Destiny, or a save game). I'm using a laptop with french keyboard, but even with the numeric keypad, I can't insert anything. It's particularly blocking for Spear of Destiny, as I can only answer to questions not requesting numbers. I'm also wondering if, as the game engine is free, we couldn't somehow bypass this protection (through the source code, of course). It's really annoying looking back at the old game documentation each time we start the game :)
Huh, that's odd. I don't think keypads will work (it doesn't for me, at least), but the normal number keys should work fine. Maybe your keyboard is uses different codes for the numbers? Seems kind of odd, though, I really don't have an answer for that. To your second point, though, you actually can bypass the copy protection - just use the --goodtimes argument.
Well, on french keyboards, the keys associated to numbers on the upper side of the keyboard must be shifted in order to get numbers (otherwise we get accents and other special characters). Maybe that's why it doesn't work for me. But I'm glad you gave me the --goodtimes argument... with that, it becomes a non-blocking issue.
Created attachment 288299 [details] linux multi-user support and GCC (4.5) fix Updated linuxfix.patch to compile properly with GCC 4.5.
Is there a reason this was never put into portage?
I'd suspect the usual: no dev has taken any personal interest in it. Same applies to many, many other ebuilds in bugzilla. Technically, though, it should work fine, at least on stable systems. I haven't tested on unstable.