[released] Hexen II: Hammer of Thyrion
 

I present you the Amiga port of uhexen2 aka Hexen II: Hammer of Thyrion. I've been working on and off this for a couple of years, but with the help of the original maintainer sezero I was finally able to finish it. Keep in mind that this is a very demanding game, so the requirements are closer to Quake 2 than Quake 1. If in doubt, just grab one of the two demo versions to see how it runs.

http://uhexen2.sourceforge.net/
http://sourceforge.net/projects/uhexen2/files/
http://sourceforge.net/projects/uhexen2/

@BSZili

This is fantastic stuff indeed!

While suspect it requires an FPU, I will still see if this works on the Vampire V2 (unless mjnurney beats me too it ;))

Nagyon szépen köszönjük!

Nincs mit!
You are right, the software renderer does lots of floating point math. It will be interesting to see how it performs once FPU support comes to Vampire. It also supports Warp3D via MiniGL and StormMesa, so some of the work can be offloaded to 3D cards. I wonder if a 060 + Voodoo3 combo would be enough to run it.

Wow, impressive.
My 1200 (with overclocked) 060 is currently disassembled so I cant try it out, but would you say its playable at all without 3d card?
(Ive seen NovaCoder run Q2 on AGA with decent framerates.)

Skickat från min HTC One via Tapatalk

No 3D card is required. It has a software renderer version, which supports both RTG and native AGA modes (blazewcp or similar recommended for the latter).

I've downloaded hexen2demo_aug1997-amigaos-m68k.lha and I have trouble getting it to work.

Non GL version loads, and displays 320x240x8 screen, and then hangs with suspend/reboot requester. It's much the same for GL versions. Snoop Dos doesn't show anything suspicious. GLQuake, and Hyperions Quake II run fine on my setup.

I Have VoodooIII in Mediator, with 64MB Ram, latest drivers from Elbox, and latest Warp 3d from Cosmos.

Tested yesterday, good JOB!
I am able to run 060 RTG version, it was about 3.6 FPS on 060/50 MHz.

But I am not able to get working Mega or MiniGL version (tested on Permedia2 only). When I launch Mesa or GL it opens the screen in Mesa or GL, during the loading it stops right after Midi with error message popup "Waiting for disk actity SuspedxReboot. When I choose Suspend the Screen of Hexen remains. It is obviously working, because the screen graphics and fonts are smooth and in 16 bit colors, but I am stuck when loading game somehow :(

I will test today on my another Amiga with 060 and Voodoo4.

Would it be possible to make WarpOS port too? I bet this one would be more usable for classic Amigas ;o) Please pleeeeaaaseeee ;oD

Fantastic! :great

Tested demo version on WinUAE and was getting a lot of crashes on startup at first, but then I switched to running it from a shell script (executable bit needs to be set) and it is now running much better. Using 900000 for stack.

Can you compile it without FPU ?

I've tried running from cli and st stack to 900000, and still after opening the game screen I get the suspend/reboot requester after MIDI_DRV.

I have midi disabled, this is my current start script:

stack 900000
glhexen2 -w -nomidi -nocdaudio -nojoy -heapsize 40000 -sndsdl -sndspeed 44100 -lm_4

You will probably want to leave out the -w (windowmode) and -sndspeed settings and set heapsize according to your spare memory. I don't know if -sndsdl makes any difference...

MIDI, CD audio support, and and all of the SDL code is disabled at compile time. Enabling/disabling those has no effect. The only MIDI_DRV messages you see are from the NULL MIDI driver, which does nothing, so that can't be the problem. If the game crashes, then it's more likely that something after that causes the problem. For example lowlevel.library sometimes acts up, I got a few crashes when the ports weren't properly detected. In that case it's a good idea to start with -nojoy. Unfortunately I can't do much with "it crashes" reports so the above is just guesswork based on my personal experience. If you could install SmartCrash, that would be helpful:
http://aminet.net/package/dev/debug/SmartCrash

There's a minimum stack value hardcoded into the executable, so it will always start with at least 1MB unless a larger value is set in the icon/shell. That was enough for me for both the software and GL version, but it's possible that on different configurations it needs more.

A WarpOS port can probably be done, but only if somebody can hook me up with all the necessary files to run it in WinUAE.

OK, I've managed to run the non GL version using -nosound and -nomidi switches. It runs at around 5fps on 060@75 so it's unplayable.

I still cannot get the GL version to run. My script looks like this:

stack 900000
glhexen2 -width 320 -height 240 -nomidi -nocdaudio -nojoy -heapsize 40000 -sndsdl -sndspeed 8000 -lm_4


I can select new game and so on in the menu, but when hexen is loading the files to start the game I get a blinking led and a nice old crash :(

Works here 68060 66mhz and xPert Merlin. No problems at all. Can't say it fast :D if picture is set small enough it is almost playable. Just wondering if I set picture 320x200 RTG it forces it to window? 320x200 AGA is full screen. There is 320x200 RTG screenmode.

I'm not sure if I understood the question correctly. Fullscreen and windowed modes are handled separately. If the game can't open the screen for itself, then the window can land on the public screen.

You did understand righ. Somehow it doesn't open new public screen 320x200 RTG, instead it opens a window to Workbench screen.

By the way, thanks you effort for all amigas.

Switched to the full game now with the three demos enabled - the Warp3D version crashes during the first demo, but the StormMesa and software versions run all three demos nicely. There is a problem with the (lack of) transparency on the magic bolts seen in the third demo though.

Attachment 49468

So the MiniGL version crashes, but StormMesa works. Interesting. The lack of transparency on the magic bolts is the same on all platforms, this is probably some age old bug. I'll add a ticket for it, and look into the issue when I'll have time.

That is a model bug in original hexen2. The mission pack, however, has it fixed.

It is _probable_ that I patched minigl badly and/or built it badly.. I cannot debug this. One should rebuild minigl with debug symbols as well as the client and debug it.