OS2 World Community Forum
WebSite Information => Article Discussions => Topic started by: Martin Iturbide on June 23, 2025, 05:08:53 pm
-
Hello Again
I've been updating my OHFOWG (https://www.os2world.com/wiki/index.php?title=One_Huge_File_Of_Warp_Games) project and I found some SDL games that does not work directly on ArcaOS.
They use an old SDL.DLL library (that is SDL 1.x) and some require "SDDHELP$".
Games that require SDL.DLL
G:\WARP\A\Abe's Amazing Adventure
* Done - G:\WARP\A\Alizarin Tetris
* Issues - G:\WARP\E\Enigma
* Done - G:\WARP\F\Formido
G:\WARP\H\UHexen
G:\WARP\K\KoboDeluxe
G:\WARP\L\Lopan
G:\WARP\L\Luola
G:\WARP\M\Marryampic2
* Done - G:\WARP\R\Rock Dodger
G:\WARP\S\sdlinvaders
G:\WARP\S\sdlroids
G:\WARP\S\sdlzombies
G:\WARP\S\snakeme
G:\WARP\S\still yet another sokoban
G:\WARP\T\Tiles World
G:\WARP\X\XRick
Games that Requires FSLIB.DLL
G:\WARP\A\Abe's Amazing Adventure
* Done - G:\WARP\A\Alizarin Tetris
G:\WARP\A\Amoebax
* Done - G:\WARP\C\Cuyo\bin
* Issue - G:\WARP\E\Enigma
* Done - G:\WARP\F\Formido
G:\WARP\H\UHexen
G:\WARP\I\InfinityCat
G:\WARP\K\KoboDeluxe
G:\WARP\K\Kuklomenos
G:\WARP\L\Lopan
G:\WARP\L\Luola
G:\WARP\M\Marryampic2
G:\WARP\P\Pingus
* Done - G:\WARP\R\Rock Dodger
G:\WARP\S\sdlinvaders
G:\WARP\S\sdlroids
G:\WARP\S\sdlzombies
G:\WARP\S\snakeme
G:\WARP\S\still yet another sokoban
G:\WARP\T\Tiles World
G:\WARP\X\XRick
But FSLIB.DLL also shows in some of the games. For what I know FSLIB (https://hobbesarchive.com/?detail=/pub/os2/dev/libraries/graphics/FSLib_r5_2009-11-04.zip) is a library to allow the game to run in Full Screen, it also says that "SDDHELP$" is required.
My questions are:
1) Does it makes sense today to use FSLIB, or if there is a better alternative with SDL? I had seen games that with Alt+Tab I can get full screen in games like Tower Toppler without using FSLIB.
2) Does it makes sense to try to recompile this games to avoid FSLIB and "SDDHELP$", or it can backfire?
Regards
-
Hi Martin
If you can recompile any of the games without the need for SDDHELP$ it would make those games playable on systems using panorama driver. I suspect it would need a lot of work though...
Regards
Pete
-
In theory, recompiling should be easy. In practice, I randomly chose rockdodger. The compile died at,
H:\tmp\rockdodger>make
cc -c -g sound.c `sdl-config --cflags` -DVERSION=\"0.6\" -DCOMPILEDATE=\"28/7/02
\"
sound.c:5:10: fatal error: SDL/SDL_mixer.h: No such file or directory
5 | #include <SDL/SDL_mixer.h>
| ^~~~~~~~~~~~~~~~~
compilation terminated.
make.exe: *** [Makefile:35: sound.o] Error 1
We don't have an RPM SDL_mixer and rockdodger uses mods for music.
I can build SDL_mixer, possible dependencies include, timidity for midi support, mikmod for mod support, smpeg or libmad-gpl for MP3 support, as well as flac and ogg which we have RPM's. Actually we also have libmikmod.
Seems there are SDL_mixer ports already floating around as well the other dependencies which can lead to DLL hell.
I also saw a SDL2 port, the repository was gone.
-
Found a newer rockdodger, its build dies due to no SDL-image. Readme also says SDL_mixer is a requirement.
https://bitbucket.org/rpkrawczyk/rockdodger/src/master/ (https://bitbucket.org/rpkrawczyk/rockdodger/src/master/)
-
Thanks for the feedback and for giving it a try.
We don't have an RPM SDL_mixer and rockdodger uses mods for music.
I guess we need to use Andrey Vasilkin SDL 1 port for the missing SDL libs.
- https://hobbesarchive.com/Home/Download?path=/Hobbes/pub/os2/dev/libraries/graphics/SDL_1-2-15_2020-10-05.zip
Regards
-
Curious if they would work with GCC/LIBC as they're compiled with OpenWatcom. So did a quick hack to test. The original rockdodger failed to compile with an incomplete struct error and a lot of warnings, so I tested the newer one I referenced. It is a quick hack so the only changes I made to rockdodger was,
--- Makefile.orig 2025-06-23 21:18:06.000000000 -0700
+++ Makefile 2025-06-23 21:25:26.000000000 -0700
@@ -41,13 +41,13 @@
NEWD=$(PACKAGENAME)-$(VERSION)
COMPILEDATE=$(shell date --date=@$${SOURCE_DATE_EPOCH:-$$(date +%s)} '+%Y-%m-%d')
TARPKGNAME=$(NEWD).pkg.tgz
-OPTIONS=-DVERSION=\"$(VERSION)\" -DCOMPILEDATE=\"$(COMPILEDATE)\" -Wall `$(SDL_CONFIG) --cflags`
-EXENAME=rockdodger
+OPTIONS=-DVERSION=\"$(VERSION)\" -DCOMPILEDATE=\"$(COMPILEDATE)\" -Wall -I../SDL/h
+EXENAME=rockdodger.exe
SOUNDLIBRARIES=-lSDL_mixer
SDL_CONFIG=sdl-config
-LIBRARIES=`$(SDL_CONFIG) --libs` -lSDL_image $(SOUNDLIBRARIES) -lm
+LIBRARIES=-L../SDL/lib -lSDL_image -lsdl12 $(SOUNDLIBRARIES) -lm
OBJECTS=SFont.o guru_meditation.o signal_handling.o random_gen.o datafun.o sound.o input_functions.o scroller.o display_subsystem.o \
game_state.o highscore_io.o sprite.o \
blubats.o greeblies.o powerup.o rocks.o spacedots.o ship.o engine_exhaust.o laser.o \
@@ -78,7 +78,7 @@
ifeq ($(profile),1)
$(CC) -pg -o $(EXENAME) $(OBJECTS) $(LIBRARIES)
else
- $(CC) $(LDFLAGS) -o $(EXENAME) $(OBJECTS) $(LIBRARIES)
+ $(CC) $(LDFLAGS) -Zomf -o $(EXENAME) $(OBJECTS) $(LIBRARIES)
endif
clean:
More work should be done on it, including install, uninstall and pkg.
Actually some of my changes can be reverted if Andrey's SDL package is adapted for GCC. Need sdl-config and renaming the lib names. eg sdlimage.lib --> SDL_image.lib. sdl-config would take care of setting -I and -L so the includes and libs can be found.
Anyways, here's the result, only tested to see if it runs and it needed sdl.ini, included in the package. Please test.
-
Here's sdl-config, I put in h:\tmp\SDL\bin and did "set PATH=h:\tmp\SDL\bin;%PATH%
You need to adjust the prefix to reflect where you installed Valerie's SDL package, rename some of the libs as mentioned, and I had to patch h/SDL/SDL_config_os2.h like so,
H:\tmp\SDL\h\SDL>diff -u SDL_config_os2.h.orig SDL_config_os2.h
--- SDL_config_os2.h.orig 2025-06-23 22:24:50.000000000 -0700
+++ SDL_config_os2.h 2025-06-23 22:17:58.000000000 -0700
@@ -34,7 +34,9 @@
typedef signed int int32_t;
typedef unsigned int uint32_t;
typedef unsigned int size_t;
+#if !defined (__EMX__)
typedef unsigned long uintptr_t;
+#endif
typedef signed long long int64_t;
typedef unsigned long long uint64_t;
Perhaps all the typedef's should be wrapped in the #if defined (__EMX__).
With these changes to the SDL package, rockdodger compiles fine with the original makefile. Changes could still be made, EXENAME=rockdodger.exe so make clean cleans it and trying make pkg failed looking for /usr/bin/install, should be /@unixroot/usr/bin/install, like similar changes can be made.
Many a SDL game should compile for you with these.
sdl-config
#!/bin/sh
# Edit the prefix below to reflect your environment
prefix=h:/tmp/SDL
exec_prefix=$prefix
exec_prefix_set=no
libdir=$prefix/lib
usage="\
Usage: sdl-config [--prefix[=DIR]] [--exec-prefix[=DIR]] [--version] [--cflags] [--libs]"
#usage="\
#Usage: sdl-config [--prefix[=DIR]] [--exec-prefix[=DIR]] [--version] [--cflags] [--libs] [--static-libs]"
if test $# -eq 0; then
echo "${usage}" 1>&2
exit 1
fi
while test $# -gt 0; do
case "$1" in
-*=*) optarg=`echo "$1" | LC_ALL="C" sed 's/[-_a-zA-Z0-9]*=//'` ;;
*) optarg= ;;
esac
case $1 in
--prefix=*)
prefix=$optarg
if test $exec_prefix_set = no ; then
exec_prefix=$optarg
fi
;;
--prefix)
echo $prefix
;;
--exec-prefix=*)
exec_prefix=$optarg
exec_prefix_set=yes
;;
--exec-prefix)
echo $exec_prefix
;;
--version)
echo 1.2.15
;;
--cflags)
echo -I$prefix/h
;;
--libs)
echo -L$prefix/lib -Zomf -lsdl12
;;
# --static-libs)
## --libs|--static-libs)
# echo -L/@unixroot/usr/lib -lSDL -lm
# ;;
*)
echo "${usage}" 1>&2
exit 1
;;
esac
shift
done
-
So tried Abes Amazing Adventure, https://github.com/OSSGames/AbesAmazingAdventure (https://github.com/OSSGames/AbesAmazingAdventure).
It uses configure so need to run "sh autogen.sh". Configure failed looking for SDL.h, patched the macro to look for SDL/SDL.h (source will need the same), reran autogen.sh and it dies here,
checking for sdl-config... h:/tmp/sdl/bin/sdl-config
checking for SDL - version >= 1.0.1... yes
checking for SDL_JoystickOpen... no
*** This version of SDL doesn't have joystick support.
*** Configuring without joystick support.
checking for Mix_OpenAudio in -lSDL_mixer... no
*** SDL_mixer not found. Configuring without audio support.
I don't think any SDL1 has joystick support and the SDL_mixer error is,
configure:7448: checking for Mix_OpenAudio in -lSDL_mixer
configure:7477: eval gcc -o conftest.exe conftest.c -lSDL_mixer -ldl -lm -Lh:/tmp/SDL/lib -Zomf -lsdl12 &5
Error! E2028: _Mix_OpenAudio is an undefined reference
Of course the OW build has Mix_OpenAudio as a symbol, wrong calling convention.
-
Thanks a lot Dave.
Let me know if it is fine how I packed Rock Dodger.
I hope I uploaded the source code correctly on Github:
- https://github.com/OS2World/GAME-SDL-ACTION-RocksnDiamonds
Regards
Update: Corrected version on the file.
-
Hello Dave
Please, if you got the time check also Alizarin Tetris.
- https://github.com/OSSGames/GAME-SDL-PUZZLE-Alizarin_Tetris
Regards
-
Thanks a lot Dave.
Let me know if it is fine how I packed Rock Dodger.
I had the sdl DLLs in the source for testing, they should be removed and also do a make clean to shrink the size.
Edit: Otherwise fine
I hope I uploaded the source code correctly on Github:
- https://github.com/OS2World/GAME-SDL-ACTION-RocksnDiamonds
Regards
Update: Corrected version on the file.
It is rockdodger, not RocksnDiamonds which is a completely different game.
-
It is rockdodger, not RocksnDiamonds which is a completely different game.
Oops... I think I'm falling sleep.
It is fixed now: https://github.com/OS2World/GAME-SDL-ACTION-RockDodger
Regards
-
Hello Dave
Please, if you got the time check also Alizarin Tetris.
- https://github.com/OSSGames/GAME-SDL-PUZZLE-Alizarin_Tetris
Regards
Seems to be missing some pieces,
config.status: error: cannot find input file: '.protos/Makefile.in'
Edit:
Removing the reference from configure.in results in,
Makefile.am:50: error: required directory ./.protos does not exist
make: *** [Makefile:120: Makefile.in] Error 1
-
Found the missing files. Built fine, keys seem jerky, perhaps needs sdl.ini.
I committed some changes including the missing .protos/
-
Thanks Dave
I found some missing files like sounds from the old compile binaries.
In my case it runs too fast when selecting the menus and even the fire shows too fast, but the game is playable.
I added your source code here:
- https://github.com/OS2World/GAME-SDL-PUZZLE-Alizarin_Tetris
I'm attaching the binary release for the public.
Regards
-
Reminds me, while looking for the missing files, I found https://wkiri.com/projects/atris/atris-sounds-1.0.1.tar.gz (https://wkiri.com/projects/atris/atris-sounds-1.0.1.tar.gz), probably the same as you found.
-
Found a FAQ too, this may be relevant,
Q: Why am I having so much trouble controlling the pieces?
A: Atris version 1.0.5 introduced the ability to change the keyboard repeat rate. If you find that the pieces move or rotate too quickly for you, consider changing the setting from within the "Special Options" menu. Let us know if you have any other playability problems.
-
Found a FAQ too, this may be relevant,
Q: Why am I having so much trouble controlling the pieces?
A: Atris version 1.0.5 introduced the ability to change the keyboard repeat rate. If you find that the pieces move or rotate too quickly for you, consider changing the setting from within the "Special Options" menu. Let us know if you have any other playability problems.
Thanks Dave
I changed on "Special Options" on the Key speed and now it plays perfect for me.
Regards
-
FAQ is at https://wkiri.com/projects/atris/Docs/faq.html (https://wkiri.com/projects/atris/Docs/faq.html)
-
Hello
I contacted the Alizarin Tetris author, because the page says that latest version is 1.0.7 and the source code there is for version 1.0.6.
She replied:
Martin,
Thanks for letting me know. It seems this page wasn't updated correctly, and enough time has passed that I'm having trouble finding the files locally. I recommend working with version 1.0.6. The main change for 1.0.7 (which you can duplicate) was to avoid buffer overruns by changing calls to sprintf() to instead use this macro, added to atris.h:
atris.h:#define SPRINTF(buf, fmt, args...) snprintf(buf, sizeof(buf), fmt, ## args)
I hope this is helpful!
Kiri
It is not a big change, I guess.
Regards
-
Guess if someone is experiencing crashes, it is a big enough change.
H:\tmp\GAME-SDL-PUZZLE-Alizarin_Tetris>git diff
diff --git a/atris.h b/atris.h
index 624e611..c48f46c 100644
--- a/atris.h
+++ b/atris.h
@@ -127,6 +127,9 @@ extern Uint16 FastRandom(Uint16 range);
#define ADJUST_SAME 1
#define ADJUST_DOWN 2
+/* Avoid a buffer overflow */
+#define SPRINTF(buf, fmt, args...) snprintf(buf, sizeof(buf), fmt, ## args)
+
#include "atris.pro"
#endif /* __ATRIS_H */
Updated exe attached.
-
Thanks Dave
Seems to be working fine here.
Do you see that "Amoebax" is also compilable? It uses also zlib , libpng, Ogg, Vorbis
https://github.com/OSSGames/GAME-SDL-PUZZLE-Amoebax
Do you use automake for the ones that have "Makefile.am" ?
Regards
-
Thanks Dave
Seems to be working fine here.
Do you see that "Amoebax" is also compilable? It uses also zlib , libpng, Ogg, Vorbis
https://github.com/OSSGames/GAME-SDL-PUZZLE-Amoebax
I'll try later.
Do you use automake for the ones that have "Makefile.am" ?
For OS/2, best to rebuild all the auto stuff. Often there is an autogen.sh that takes care of the rebuilding, otherwise autoreconf -sfi usually takes care of running the tools, aclocal, autoconf, automake, libtool, all with the right parameters.
autogen.sh for atris for example of a simple one,
#!/bin/sh
#
aclocal
automake --foreign
autoconf
./configure $*
Which actually failed due to missing compile file or such, so I ran autoreconf -sfi to install the scripts and afterwards if needed, ran autogen.sh. Reason for needing to fix was, IIRC, a macro that used #include <SDL.h> while newer SDL such as ours needs #include <SDL/SDL.h>. Source needed adjusting the same way.
Edit: add bottom section.
-
Do you see that "Amoebax" is also compilable? It uses also zlib , libpng, Ogg, Vorbis
https://github.com/OSSGames/GAME-SDL-PUZZLE-Amoebax
Do you use automake for the ones that have "Makefile.am" ?
Regards
I played with this quite a bit, the build system seems really screwed up and I give up.
-
Do you see that "Amoebax" is also compilable? It uses also zlib , libpng, Ogg, Vorbis
https://github.com/OSSGames/GAME-SDL-PUZZLE-Amoebax
I played with this quite a bit, the build system seems really screwed up and I give up.
So said fsck it and tried building with the original configure etc. With the correct config.site and configure arguments I got the attached which seems to work on a quick test. Needs further testing, and I installed to /amoebax, I think it will work install to amoebax, untested.
To do, write an INSTALL.OS/2 and clean up the config.site and include it. There's currently no source changes.
-
Hello Dave
Thanks for giving it a try.
In my case I have a problem that can not found the menu.ogg file. (error attached) I tried located the files in different paths and I can not make the .exe find the files. Is there something I'm missing?
Regards
-
I got that error before I installed it. You are running amoebax.exe from amoebax\bin?
BTW, I tested installing in a non-root spot and it worked here retested by unzipping to tmp\amoebax, cd to bin and ran amoebax and it worked here.
-
Hmm, tried on a different drive, only worked when unzipped to \amoebax and ran from \amoebax\bin
-
Here's a binary that will work if ran from /usr/local/bin if you copy the contents of the previous package's share/ directory to /usr/local/share.
Tomorrow I'll try to figure out how it sets things up for looking for the data and see about changing it
-
Hello Dave.
Thanks, it worked here putting the /share folder in "/usr/local/". It is working fine, windowed and full screen, sounds work and I think that controls and speed are fine.
Just wonder if it can be more easy to the user like having the .exe and the directories on the same folder to ship it in a simple way in the package. I'm attaching the picture of the older build for an idea.
Regards
-
Hi Martin, I've screwed around trying to get it to work from amoebax/ with no luck. Looking it likely needs the source patched which I don't have the knowledge to do.
-
Thanks a lot Dave for your time !!!
Abusing again of it ;D Can you please check Cuyo to see if it compiles?
- https://download.savannah.gnu.org/releases/cuyo/cuyo-2.1.0.tar.gz
Regard
-
Thanks a lot Dave for your time !!!
Abusing again of it ;D Can you please check Cuyo to see if it compiles?
- https://download.savannah.gnu.org/releases/cuyo/cuyo-2.1.0.tar.gz
Regard
Hi Martin, ran into problems with getopt()
make[2]: Entering directory 'H:/tmp/cuyo-2.1.0/src'
g++ -DHAVE_CONFIG_H -I. -I.. -Ih:/tmp/SDL/h -Ih:/tmp/SDL/h/SDL -DPKGDATADIR=\"/usr/local/share/cuyo\" -DLOCALEDIR=\"/usr/local/share/locale\" -Wall -W -ansi -MT main.o -MD -MP -MF .deps/main.Tpo -c -o main.o main.cpp
main.cpp: In function 'void scanOptionen(int, char**)':
main.cpp:183:47: error: too many arguments to function 'int getopt()'
183 | while ((opt_chr = getopt(argc, argv, "dhg:f")) != -1) {
| ^
In file included from main.cpp:32:
W:/usr/include/getopt.h:166:12: note: declared here
166 | extern int getopt ();
| ^~~~~~
make[2]: *** [Makefile:524: main.o] Error 1
For the hell of it I tried removing the "dhg:f" and it didn't get much further,
make[2]: Entering directory 'H:/tmp/cuyo-2.1.0/src'
g++ -DHAVE_CONFIG_H -I. -I.. -Ih:/tmp/SDL/h -Ih:/tmp/SDL/h/SDL -DPKGDATADIR=\"/usr/local/share/cuyo\" -DLOCALEDIR=\"/usr/local/share/locale\" -Wall -W -ansi -MT main.o -MD -MP -MF .deps/main.Tpo -c -o main.o main.cpp
main.cpp: In function 'void scanOptionen(int, char**)':
main.cpp:183:38: error: too many arguments to function 'int getopt()'
183 | while ((opt_chr = getopt(argc, argv)) != -1) {
| ^
In file included from main.cpp:32:
W:/usr/include/getopt.h:166:12: note: declared here
166 | extern int getopt ();
| ^~~~~~
make[2]: *** [Makefile:524: main.o] Error 1
Unluckily I'm not knowledgeable enough to get past this.
-
see https://github.com/bitwiseworks/libc/issues/44 for a possible explanation and solution
-
Hi Martin, ran into problems with getopt()
In file included from main.cpp:32:
W:/usr/include/getopt.h:166:12: note: declared here
166 | extern int getopt ();
Unluckily I'm not knowledgeable enough to get past this.
But you are (or will be)...
In cases like this it's a good idea to look at the header to see if there are any notes or #defines that might explain the problem. In this case, there are two different prototypes: one taking 3 args that you want, and one taking no args which is what you're getting. It depends on whether __GNU_LIBRARY__ is #defined (which it should be, AFAIK).
However... looking at the header reminded me of the _real_ problem. 'getopt()' used to be a standalone library with its own header. Nowadays it's part of the standard C library and is declared in 'unistd.h'. So, I think the solution here is to delete any '#include <getopt.h>' so the compiler finds the correct prototype.
-
Ok, if I knew more German, the comment might have clued me in :) I uncommented the #include <unistd.h>, commented the #include <getopt.h> added a couple of LIBS and the compile finished.
Have to test later as have to go out.
There's still the problem of it wanting to be installed to an absolute location, /usr/local by default, to find its data.
German comment,
#if HAVE_GETOPT
/* Laut man-page muss man <unistd.h> includen, wenn man getopt() verwenden
will. Laut gcc <getopt.h>. gcc sitzt am lõngeren Hebel... */
#include <unistd.h>
//#include <getopt.h>
#endif
I should have looked at the headers too, it's how I fixed the ngettext() problem I also had.
-
Here's the game installed to \usr\local. Still not sure how to install it so that it looks relatively for its data.
Edit: Removed zip
-
Ok, if I knew more German, the comment might have clued me in :)
I too am working on a project where all the comments are in German, so I added this to my Favorites:
https://translate.google.com/?sl=de&tl=en&op=translate
-
Ok, if I knew more German, the comment might have clued me in :)
I too am working on a project where all the comments are in German, so I added this to my Favorites:
https://translate.google.com/?sl=de&tl=en&op=translate
That helped, along with using qe to load the files as codepage 1208.
Problem is that configure no longer allows relative paths for PREFIX etc.
Simple fix was to build with
make pkgdatadir=./data
and manually package it.
Seems to work here.
-
Here's the game installed to \usr\local. Still not sure how to install it so that it looks relatively for its data.
Edit: Removed zip
This is one of the biggest problems I encountered with installing unix ported programs. Either you install them in /usr/local or /usr/something, or they are configured to install in a modifiable PREFIX, otherwise you are on your own figuring out a way to install it in a generic path.
I seem to remember I found something interesting via the OS/2 toolkit, but can't remember right now - I'm in the middle of an INCREDIBLY TOUGH moving from a house to another, and I can't really describe how hard and taxing this is becoming day after day.
Hope I'll get back on working on ArcaOS translation and software development ASAP.
Mentore
-
Hello Dave
That helped, along with using qe to load the files as codepage 1208.
Problem is that configure no longer allows relative paths for PREFIX etc.
Simple fix was to build with
make pkgdatadir=./data
and manually package it.
Seems to work here.
Thanks Dave. It also run here.
Just one thing. This port is incompatible with SDL12.dll from netlabs (6-30-16 6:46a 10,527 ).
Once I put on the folder the SDL12.dll (and SDLMIXER) from SDL_1-2-15_2020-10-05.zip worked great.
Just a another thing. Can you please upload your code changes to this repo fork?
- https://github.com/OS2World/GAME-SDL-PUZZLE-Cuyo
Regards
-
Dave.
I had included a readme to package the game to Hobbes. Let me know if you want to add something else or any correction.
Regards
-
Hello Dave
Thanks Dave. It also run here.
Just one thing. This port is incompatible with SDL12.dll from netlabs (6-30-16 6:46a 10,527 ).
Once I put on the folder the SDL12.dll (and SDLMIXER) from SDL_1-2-15_2020-10-05.zip worked great.
Yes I linked against SDL_1-2-15_2020-10-05. Perhaps I should build a SDL_Mixer with GCC and linking against the SDL that YUM installed. This would simplify things as it is a hassle getting configure to recognize SDLMIXER which is built with OW and uses a different calling convention
Just a another thing. Can you please upload your code changes to this repo fork?
- https://github.com/OS2World/GAME-SDL-PUZZLE-Cuyo
Regards
I shall try and see if my app password works with the OS2World organization. Seems that previously it didn't.
If not I'll give you the patches to push.
We should first decide about SDL_mixer as I had to hack configure to get it to use the OW version.
Edit:fix a typo
-
Dave,
Do you mean token? Github switched over to token based passwords several years ago.
https://github.com/settings/tokens
-
Yes, tokens is the right word. Looks like a password and expires
-
Hi Martin, pushed my changes. The package looks fine except I've updated the executable to use -Zhigh-mem, attached.
-
Hello Dave
The older one is working fine, this new one gives me an error that can not find data/sounds.
Regards
-
Hello Dave
The older one is working fine, this new one gives me an error that can not find data/sounds.
Regards
Guess I should have tested :)
It's weird as the error is,
H:\cuyo-2.1.0>cuyo.exe
Error: Could not find "sounds/leftright.wav".
Tried the following places:
./data/sounds/leftright.wav
And
H:\cuyo-2.1.0>ls ./data/sounds/leftright.wav
./data/sounds/leftright.wav
So it is there and should work.
Hmm, rebuilding without -Zhigh-mem and it works. Just use the original binary as it seems the -Zhigh-mem is breaking something, perhaps the combination of a GCC binary and OW DLL.
Edit: updated compile.os2 removing the -Zhigh-mem
-
Thanks Dave
I uploaded the package to Hobbes (the version that was working fine).
Just for my own learning, how do you run the automake script for this case? In case I want to have a compile.cmd command, what would you include there?
Regards
-
In this case and many others, simply
sh autogen.sh
Sometimes autogen.sh runs configure at the end so you can pass the configure arguments to autogen.sh.
If you look at Cuyo's autogen.sh, you see the usual minimal autotools series of commands. Some also have libtool.
Once it has been run to use our autotools port, it usually doesn't need to be run again and configure takes care of creating the makefile's from the makefile.in's, which were created by automake from the makefile.am's
So basically configure --arguments, then make for Cuyo and most autotools projects.
for GAME-SDL-PUZZLE-Cuyo, see compile.os2,
sh ./configure --disable-nls --with-sdl-prefix=H:/tmp/SDL 'LDFLAGS=-Zomf' 'LIBS=-lz -lintl'
make pkgdatadir=./data
Of course SDL needs to be setup for GCC as explained earlier in the thread and the above adjusted for your environment.
-
Thanks Dave
I tried this:
[E:\DEV\5TRYING\GAME-SDL-PUZZLE-CUYO]sh ./configure --disable-nls --with-sdl-pre
fix=C:/usr/include/SDL1 'LDFLAGS=-Zomf' 'LIBS=-lz -lintl'
checking for a BSD-compatible install... /@unixroot/usr/bin/install.exe -c
checking whether build environment is sane... yes
./configure: 1: eval: /bin/sh: not found
configure: WARNING: 'missing' script is too old or missing
checking for a race-free mkdir -p... /@unixroot/usr/bin/mkdir.exe -p
checking for gawk... gawk
checking whether make sets $(MAKE)... no
checking whether make supports nested variables... yes
checking whether to enable maintainer-specific portions of Makefiles... no
checking for g++... g++
checking whether the C++ compiler works... no
configure: error: in 'E:/DEV/5TRYING/GAME-SDL-PUZZLE-CUYO':
configure: error: C++ compiler cannot create executables
See 'config.log' for more details
[E:\DEV\5TRYING\GAME-SDL-PUZZLE-CUYO]make pkgdatadir=./data
make: *** No targets specified and no makefile found. Stop.
I'm not sure what can be wrong. I have a different SDL1 path just in case.
Regards
-
Hi Martin, here is the error,
configure:3256: checking whether the C++ compiler works
configure:3278: eval g++ -Wall -W -ansi -Zomf conftest.cpp -lz -lintl >&5
weakld: cannot open library file 'C:\usr\lib\intl_s.a'.
emxomfld: weak prelinker failed. (rc=8)
configure:3282: $? = 1
configure:3323: result: no
No -lintl, or rather intl_dll.a. Libintl is part of gettext so you need to install the gettext-devel package. You will also need the zlib-devel package for libz (libz_dll.a)
Missing libraries on our system usually result in weakld looking for the static version in /usr/lib.
-
Thanks Dave
I tried this:
[E:\DEV\5TRYING\GAME-SDL-PUZZLE-CUYO]sh ./configure --disable-nls --with-sdl-pre
fix=C:/usr/include/SDL1 'LDFLAGS=-Zomf' 'LIBS=-lz -lintl'
BTW, did you really install SDL_1-2-15_2020-10-05.zip to /usr/include?
I have,
Directory of H:\tmp\SDL
7-14-25 3:00p <DIR> 124 ---- .
7-21-25 8:53a <DIR> 441 ---- ..
6-23-25 9:52p <DIR> 0 a--- bin
7-14-25 3:00p <DIR> 124 ---- dll
7-14-25 3:00p <DIR> 124 ---- h
7-14-25 3:00p <DIR> 124 ---- lib
2-09-16 2:08a 1,944 124 a--- readme.os2
3-03-16 3:10p 844 124 a--- SDL-1.2.15-20160303.txt
3-03-16 3:12p 928 124 a--- SDL-1.2.15-src-20160303.txt
2-09-16 1:35a 2,615 124 a--- sdl.ini
4-27-21 8:44p 31,320,734 124 a--- SDL_1-2-15-src-20201005.zip
11 file(s) 31,327,065 bytes used
Directory of H:\tmp\SDL\bin
6-23-25 9:52p <DIR> 0 a--- .
7-14-25 3:00p <DIR> 124 ---- ..
6-29-25 5:27p 1,278 124 a--- sdl-config
3 file(s) 1,278 bytes used
...
Directory of H:\tmp\SDL\lib
7-14-25 3:00p <DIR> 124 ---- .
7-14-25 3:00p <DIR> 124 ---- ..
10-05-20 9:07a 108,544 124 a--- sdl12.lib
10-05-20 9:07a 21,504 124 a--- sdlimage.lib
10-05-20 9:07a 41,984 124 a--- sdlmixer.lib
10-05-20 9:07a 22,016 124 a--- sdlnet.lib
10-05-20 9:07a 10,240 124 a--- sdlsound.lib
10-05-20 9:07a 25,600 124 a--- sdlttf.lib
6-23-25 9:23p 21,504 124 a--- SDL_image.lib
6-23-25 9:23p 41,984 124 a--- SDL_mixer.lib
6-24-25 8:31p 25,600 124 a--- SDL_ttf.lib
11 file(s) 318,976 bytes used
...
and my current sdl-config
#!/bin/sh
# Edit the prefix below to reflect your environment
prefix=h:/tmp/SDL
exec_prefix=$prefix
exec_prefix_set=no
libdir=$prefix/lib
usage="\
Usage: sdl-config [--prefix[=DIR]] [--exec-prefix[=DIR]] [--version] [--cflags] [--libs]"
#usage="\
#Usage: sdl-config [--prefix[=DIR]] [--exec-prefix[=DIR]] [--version] [--cflags] [--libs] [--static-libs]"
if test $# -eq 0; then
echo "${usage}" 1>&2
exit 1
fi
while test $# -gt 0; do
case "$1" in
-*=*) optarg=`echo "$1" | LC_ALL="C" sed 's/[-_a-zA-Z0-9]*=//'` ;;
*) optarg= ;;
esac
case $1 in
--prefix=*)
prefix=$optarg
if test $exec_prefix_set = no ; then
exec_prefix=$optarg
fi
;;
--prefix)
echo $prefix
;;
--exec-prefix=*)
exec_prefix=$optarg
exec_prefix_set=yes
;;
--exec-prefix)
echo $exec_prefix
;;
--version)
echo 1.2.15
;;
--cflags)
echo -I$prefix/h -I$prefix/h/SDL
;;
--libs)
echo -L$prefix/lib -Zomf -lsdl12
;;
# --static-libs)
## --libs|--static-libs)
# echo -L/@unixroot/usr/lib -lSDL -lm
# ;;
*)
echo "${usage}" 1>&2
exit 1
;;
esac
shift
done
I changed the --cflags section as some projects look for SDL.h and others for SDL/SDL.h
-
Thanks for the info Dave.
It seems that my SDL into configured right. I will try it your way and see if I can learn something ;D
If you have the time can you please check the next in line Enigma, to see if it compiles?
- https://github.com/Enigma-Game/Enigma
Regards
-
If you have the time can you please check the next in line Enigma, to see if it compiles?
- https://github.com/Enigma-Game/Enigma
Hmm, first try,
H:\tmp\Enigma>bash autogen.sh
Bootstrapping ./lib-src/enet autogen.sh: 2: set: Illegal option -o pipefail
ERROR
H:\tmp\Enigma>sh
# autoreconf -sfi
configure.ac:5: installing './compile'
configure.ac:3: installing './install-sh'
configure.ac:3: installing './missing'
Makefile.am: error: required file './AUTHORS' not found
Makefile.am: error: required file './ChangeLog' not found
Makefile.am: installing './INSTALL'
Makefile.am: error: required file './NEWS' not found
Makefile.am: installing './COPYING' using GNU General Public License v3 file
Makefile.am: Consider adding the COPYING file to the version control system
Makefile.am: for your code, to avoid questions about which license your project uses
Makefile.am: installing './depcomp'
autoreconf: error: failed to run automake: SYS0003=0x3: The system cannot find the path specified
#
Might have to use the original configure script.
-
Anyways, created the missing files, put them in both directories that had a configure script, autoreconf worked.
Running configure dies at,
checking for current Xerces release 3.0... not found
checking for old Xerces release >=2.4... configure: error: Xerces >= 2.4 not found.
Building Xerces 3.3.0 (from https://xerces.apache.org/xerces-c/download.cgi (https://xerces.apache.org/xerces-c/download.cgi)) things went very smooth until the linking stage where I seem to have run into a bug or deficiency in our build system.
I'll attach the build.log, def file and map file.
Using fc/2 to search for one of the symbols copied from the map file also fails though it is there. They're huge symbols.
-
So continuing to work on Xerces-c. I built a static lib, which succeeded. Enigma's configure wasn't happy with it, no main or was it mainl, I lost the log.
Tried using ilink v5. Got similar weakld errors and 2936 errors, all undefined exports.
Then I tried the cmake build. I've had a recurring problem where after running cmake, the makefile seems to recurse at the beginning and locks the system hard. So I tried using ninja instead of make.
This actually built an xerces33.dll. The import lib unluckily was empty, well 8 bytes containing !<arch>. Trying
"emximp -o xerces-c_dll.a xerces33.dll" resulted in the same import lib. Looking at the def file, we have,
LIBRARY "xerces33" INITINSTANCE TERMINSTANCE
DESCRIPTION "@#cmake build system:3.3#@##1## 24 Jul 2025 17:19:23 ARCAOS-44454C4::::0::@@xerces-c"
DATA MULTIPLE NONSHARED
No exports. Frustrating as the dll seems to have exports. It's 5.2 MB's and I wonder if the build system tried to use declspec(export) or whatever the command is.
Failures were all trying to link executables.
Not sure where the object files are either, they don't seem to be in build/
-
did you adjust
else()
if(WIN32)
set(XERCES_PLATFORM_EXPORT "__declspec(dllexport)")
set(XERCES_PLATFORM_IMPORT "__declspec(dllimport)")
if (MSVC)
set(XERCES_TEMPLATE_EXTERN)
endif()
set(XERCES_DLL_EXPORT 1)
endif()
in xerces-c-3.3.0\cmake\XercesDLL.cmake
If not it can't work of course
-
Hi all,
Silvan ported xerces-c 3.3.0 to OS2.
This will be available on monday as RPM
Kind regards, Tellie
-
did you adjust
else()
if(WIN32)
set(XERCES_PLATFORM_EXPORT "__declspec(dllexport)")
set(XERCES_PLATFORM_IMPORT "__declspec(dllimport)")
if (MSVC)
set(XERCES_TEMPLATE_EXTERN)
endif()
set(XERCES_DLL_EXPORT 1)
endif()
in xerces-c-3.3.0\cmake\XercesDLL.cmake
If not it can't work of course
I thought there would be a declspec involved. Unluckily I'm obviously missing something as even simplifiing as much as possible and points in between still not working.
if(NOT BUILD_SHARED_LIBS)
set(XERCES_STATIC_LIBRARY 1)
else()
set(XERCES_PLATFORM_EXPORT "__declspec(dllexport)")
set(XERCES_DLL_EXPORT 1)
endif()
Anyways as Tellie says you've built an RPM, it doesn't matter much.
Thanks for the RPM
-
Hello Dave
Tellie made a port and shared the source code:
- https://rpm.netlabs.org/test/Martin/
There is still an issue that the compile exe gives you an issue the second time you run it because some path problems. But I think you can give it a try to see if it compiles in your environment.
It requires "yum install xerces-c libincov libcurl". But Tellie also includes XERCES33.DLL , LIBCURL.DLL and ICONV2.DLL on his test package. (I don't know where LIBCURL.DLL comes from)
Regards
-
My build is now failing,
make[3]: Entering directory 'H:/tmp/Enigma/doc/reference/images'
convert -density 112x112 -units PixelsPerCentimeter -crop 60x60+0+0 H:/tmp/Enigma/doc/reference/images/../../../data/gfx48/ac_bug.png ac_bug.png
sh.exe: 0: Can't open convert
convert -density 112x112 -units PixelsPerCentimeter -crop 60x60+0+0 H:/tmp/Enigma/doc/reference/images/../../../data/gfx48/ac_horse.png ac_horse.png
sh.exe: 0: Can't open convert
make[3]: *** [Makefile:936: ac_bug.png] Error 127
IIRC, convert is part of Imagemagick. While poking around Paul's site for imagemagick, I notice that he already has a build of Enigma 1.3.0, https://os2ports.smedley.id.au/?page_id=79 (https://os2ports.smedley.id.au/?page_id=79) to compare against.
With 2 ports already, I may not go any further.
BTW, libcurl comes from the libcurl RPM package and is just a DLL containing curl basically.
-
Hi Dave
With 2 ports already, I may not go any further.
But if you make it compile that will be great. ;D Paul's version is older and dependent on FSLIB and Tellies port has this issue that does not loads from the second time.
The next in the list is Formido: https://www.mhgames.org/oldies/formido/
-- https://github.com/OSSGames/GAME-SDL-ACTION-Formido
Regards
-
The next in the list is Formido: https://www.mhgames.org/oldies/formido/
-- https://github.com/OSSGames/GAME-SDL-ACTION-Formido
Regards
Hi Martin, built formido.exe, seems to work though it did lock up my system at one point, perhaps due to SM limiting memory. On a freshly booted system it was fine.
Trying to push my changes results in,
H:\tmp\GAME-SDL-ACTION-Formido>git push
Username for 'https://github.com':
Password for 'https://dryeo@github.com':
remote: Permission to OSSGames/GAME-SDL-ACTION-Formido.git denied to dryeo.
fatal: unable to access 'https://github.com/OSSGames/GAME-SDL-ACTION-Formido/':
The requested URL returned error: 403
Here's the exe, need the data directory from https://www.mhgames.org/download.php?formido-1.0.1.tar.gz (https://www.mhgames.org/download.php?formido-1.0.1.tar.gz) for it to run
-
Thanks A lot Dave.
I forked the project into the OS2World github org so you can upload the code changes:
- https://github.com/OS2World/GAME-SDL-ACTION-Formido
I will try out the game and let you know.
Regards
-
Must have been tired as I thought it was your fork :) I'll push soon.
-
Hello
I had tried it and works fine here. It lags a little bit when too many bugs shows on screen, but I guess we need to live with that limitation.
Here it is attached the release version that I plan to upload to hobbes.
Regards
-
Here it is attached the release version that I plan to upload to hobbes.
Looks good. Did you use the SDL RPM? I only tested with the SDL from SDL_1-2-15_2020-10-05.zip. Perhaps test to see if it is as laggy using that SDL DLL.
-
Hi Dave
You are right, with the SDL12.DLL from "SDL_1-2-15_2020-10-05.zip" it works better.
Regards
-
Seems your readme should then be updated.
-
Thanks Dave. I already uploaded, but tomorrow I will change it at hobbes.
Abusing of your time again, (if possiblr) the next one is:
- https://github.com/OSSGames/GAME-SDL-ACTION-UHexen
- https://uhexen.sourceforge.net/
The shareware wad is here: https://hobbesarchive.com/Home/Download?path=/Hobbes/pub/os2/games/action/UHexen_0-601.zip
Regards
-
Hi Martin
Did you checked http://github.com/sezero/uhexen2
As this is even for os2.
This can be compiled with watcom.
-
Abusing of your time again, (if possiblr) the next one is:
- https://github.com/OSSGames/GAME-SDL-ACTION-UHexen
- https://uhexen.sourceforge.net/
The shareware wad is here: https://hobbesarchive.com/Home/Download?path=/Hobbes/pub/os2/games/action/UHexen_0-601.zip
Regards
Hi Martin, I compiled UHexen, dropping the binary and DLL's into UHexen_0-601 I get,
H:\tmp\hexen>uhexen.exe
Starting Hexen!
V_Init: allocate screens.
M_LoadDefaults: Load system defaults.
W_Init: Init WADfiles.
DEMO IWAD detected!
Z_Init: Init zone memory allocation daemon.
MN_Init: Init menu system.
CT_Init: Init chat mode data.
S_InitScript
SN_InitSequenceScript: Registering sound sequences.
I_Init: Setting up machine state.
SDL Audio opened successfully.
ST_Init: Init startup screen.
Executable: U-Hexen 0.5 build Aug 2 2025.
R_Init: Init Hexen refresh daemonTextures Flats Sprites Colormaps Done.
P_Init: Init Playloop state.
Numsprites:300
D_CheckNetGame: Checking network game status.
SB_Init: Loading patches.
SDL: Using video driver:OS2
Killed by SIGSEGV
pid=0x5188 ppid=0x0062 tid=0x0001 slot=0x00ac pri=0x0200 mc=0x0001 ps=0x0010
H:\TMP\HEXEN\UHEXEN.EXE
cs:eip=04b0:00000000 ss:esp=1f38bb5a:001efb78 ebp=00000053
ds=1f38c045 es=0000 fs=0002 gs=0000 efl=1b35a301
eax=001efc28 ebx=1ffc9d7c ecx=001efc3c edx=001efc60 edi=001efb20 esi=001eff8c
Creating 5188_01.TRP
Moved 5188_01.TRP to W:\var\log\app\688e5e16-5188_01-UHEXEN-exceptq.txt
And looking at the trp file, the call stack has _VSDL_InitGraphics as the culprit.
I'll play more, there are a lot of warnings in the compile, but not hopeful.
After I'll look at the source that Tellie pointed to and see about compiling that to use our current environment.
-
Gave up on UHexen. Tried UHexen2. Downloaded https://archive.org/details/hexen-2 (https://archive.org/details/hexen-2) which I first tried running with Odin. Didn't work with memory allocation errors.
Compiled all the binaries I could find in http://github.com/sezero/uhexen2 (http://github.com/sezero/uhexen2). Really needs better instructions and a batch file or such to compile with OW. Copied all binaries and the included SDL dll to the root of hexen 2 and I get,
H:\tmp\Hexen 2>h2.exe
Hammer of Thyrion, release 1.5.10 (2025-06-20)
running on Hexen2 engine 1.29 (OS/2)
More info / sending bug reports: http://uhexen2.sourceforge.net
basedir is: H:\tmp\Hexen 2
Detected byte order: LE
Found SDL version 1.2.16
Host_Init
Server using protocol 19 (Raven/MP/1.12)
Added packfile H:\tmp\Hexen 2\data1\pak0.pak (696 files, 34289 crc)
Added packfile H:\tmp\Hexen 2\data1\pak1.pak (523 files, 2995 crc)
Playing the registered version.
UDP_Init: WARNING: gethostbyname failed (Unknown host)
UDP, Local address: 192.168.0.105 (lan0)
UDP Initialized
Exe: 09:09:44 Aug 4 2025
32.0 megabyte heap
Console initialized.
No fullscreen video modes available
FATAL ERROR: No fullscreen modes available at this color depth
Promising but obviously doesn't like 32 bit colours. Be interesting to know how it runs on Windows
-
Hello
Tellie, uhexen2 was completely under the radar to me. I didn't even know they had a 2018 port to OS/2. Maybe I confused it with the older Hexen/2.
Thanks Dave for trying to compile those.
Regards
-
Tried with 16 bit colour, same output. Guess it is old enough that 256 colour was common and that is what it wants. It's a shame as it compiles nicely with OW, besides having to compile every binary separately.
-
Hello Dave
I don't know how they compile it on 2018. Here it is working (http://sourceforge.net/project/downloading.php?group_id=124987&filename=hexen2-1.5.9-os2.zip).
Like I said before I didn't noticed that UHexen2 (h2.exe) existed. (thanks Tellie for letting me know that)
Regards
-
Interesting. The only one that runs here is the version on Hobbes, where the executable is hexos2.exe and includes HEXEN.WAD.
Trying the h2.exe from 1.59 that you referenced gives me the same error about no full screen modes available when copied to Hexen 2 (the Windows full program I think)
-
Here's the h2.exe I compiled, perhaps your environment is different then mine.
-
Hello Dave
It seems that your compiled version is not compatible with the data files of the 2018 compile ( h2.exe from 1.59 )
[C:\DESKTOP\UHEXEN2]h2
Hammer of Thyrion, release 1.5.10 (2025-06-20)
running on Hexen2 engine 1.29 (OS/2)
More info / sending bug reports: http://uhexen2.sourceforge.net
basedir is: C:\DESKTOP\UHEXEN2
Detected byte order: LE
Found SDL version 1.2.15
Host_Init
Server using protocol 19 (Raven/MP/1.12)
Added packfile C:\DESKTOP\UHEXEN2\data1\pak0.pak (701 files, 20870 crc)
FATAL ERROR: Old version of Hexen II demo isn't supported
I'm trying to find some other data files for Hexen II.
Regards
-
Perhaps this will update the pak files. The documentation is severely lacking. There were probably forums or such covering this stuff.
-
No, it seems it is not compatible with the pak0.pak demo that I have.
-
OK, got it running.
Download the zip at https://archive.org/details/hexen-2 (https://archive.org/details/hexen-2) and unzip. Replace h2.exe with the binary I attached up thread. Start as h2.exe -window -width 640 -height 480
H:\tmp\Hexen 2>h2.exe -window -width 640 -height 480
Hammer of Thyrion, release 1.5.9 (2018-05-31)
running on Hexen2 engine 1.29 (OS/2)
More info / sending bug reports: http://uhexen2.sourceforge.net
basedir is: H:\tmp\Hexen 2
Detected byte order: LE
Found SDL version 1.2.15
Host_Init
Server using protocol 19 (Raven/MP/1.12)
Added packfile H:\tmp\Hexen 2\data1\pak0.pak (696 files)
Added packfile H:\tmp\Hexen 2\data1\pak1.pak (523 files)
Playing the registered version.
UDP_Init: WARNING: gethostbyname failed (Unknown host)
UDP, Local address: 192.168.0.105 (lan0)
UDP Initialized
Exe: 21:47:04 May 31 2018
32.0 megabyte heap
Console initialized.
No fullscreen video modes available
1480k surface cache
Video Mode: 640x480x8
Sound Initialization
SDL audio spec : 22050 Hz, 512 samples, 2 channels
SDL audio driver: OS/2 DART, 32768 bytes buffer
Audio: 16 bit, stereo, 22050 Hz, using SDLAudio
Could not initialize Timidity
SDL detected 2 CD-ROM drives
CDAudio_Init: Unable to open CD-ROM drive CDaudio01 ()
MIDI_DRV: disabled at compile time.
No joystick devices found
======== Hexen II Initialized =========
execing hexen.rc
execing default.cfg
execing config.cfg
couldn't exec autoexec.cfg
Shutting down SDL sound
Couldn't capture a screen shot, it was blank (black).
It does capture the mouse until closed, ctrl-esc brings up the window list but no mouse.
-
Just in case it take more, here's all the binaries and the SDL I installed in Hexen 2.
-
Just in case it take more, here's all the binaries and the SDL I installed in Hexen 2.
It's not running
E:\uhexen2\Hexen 2>h2.exe
Hammer of Thyrion, release 1.5.10 (2025-06-20)
running on Hexen2 engine 1.29 (OS/2)
More info / sending bug reports: http://uhexen2.sourceforge.net
basedir is: E:\uhexen2\Hexen 2
Detected byte order: LE
Found SDL version 1.2.16
Host_Init
Server using protocol 19 (Raven/MP/1.12)
Added packfile E:\uhexen2\Hexen 2\data1\pak0.pak (696 files, 34289 crc)
Added packfile E:\uhexen2\Hexen 2\data1\pak1.pak (523 files, 2995 crc)
Added packfile E:\uhexen2\Hexen 2\data1\pak3.pak (245 files, 1478 crc)
Added packfile E:\uhexen2\Hexen 2\data1\pak4.pak (102 files, 41062 crc)
Playing the registered version.
UDP, Local address: 192.168.1.204
UDP Initialized
Exe: 09:09:44 Aug 4 2025
32.0 megabyte heap
Console initialized.
No fullscreen video modes available
FATAL ERROR: No fullscreen modes available at this color depth