[released] Hexen II: Hammer of Thyrion

[jack-3d]

Using cli (-nojoy -nomidi) I could start mesa version, but the game run less then 1 FPS. It looked nice, but totally slideshow on 060/50. GL version did not load the game, but this time without Susped-Reboot error. It just freezed when first level almost loaded.

Still I think the only possible usage on classics could be WarpOS version, please someone compile it, so we can play it on classics ;o)

Anyway thank you for this nice port, and hoping for WarpOS port ;o)

[BSzili]

Originally Posted by szo

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.

I'm not sure, since it worked fine in WinUAE with Wazp3D.

Originally Posted by jack-3d

Using cli (-nojoy -nomidi) I could start mesa version, but the game run less then 1 FPS. It looked nice, but totally slideshow on 060/50. GL version did not load the game, but this time without Susped-Reboot error. It just freezed when first level almost loaded.

Still I think the only possible usage on classics could be WarpOS version, please someone compile it, so we can play it on classics ;o)

Anyway thank you for this nice port, and hoping for WarpOS port ;o)

How could StormMesa be this slow? I thought it had Warp3D support as well. At least it says so on H&P's website. The WarpOS port is not just a straight recompile. Many functions have to be replaced by ppc.library ones, and interrupt handlers has to be compiled separately, since they need to remain 68k code. This is not something I'd like to do blindly, which is why I need the Blizzard ROMs and a hardfile with WarpOS installed.

Originally Posted by jack-3d

[...] hoping for WarpOS port ;o)

Don't.

[James]

Originally Posted by szo

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

Didn't know that, and I've had a copy of this game for ages.
Don't have the mission pack unfortunately.

Originally Posted by BSzili

How could StormMesa be this slow?

StormMesa has several variables that can prevent hardware rendering, there are also a couple that might speed things up. I would recommend WOSprefs (uses MUI) to check and change these (and Warp3D) variables - StormMesa2010 has it's own prefs program, but it doesn't give detailed info on what each variable does.

http://aminet.net/package/util/misc/WOSprefs

Originally Posted by James

StormMesa has several variables that can prevent hardware rendering, there are also a couple that might speed things up. I would recommend WOSprefs (uses MUI) to check and change these (and Warp3D) variables - StormMesa2010 has it's own prefs program, but it doesn't give detailed info on what each variable does
http://aminet.net/package/util/misc/WOSprefs

When you are able, can you run the stormmesa version with logging (e.g. glhexen2-mesa -devlog ) and post the generated debug_h2.log file, please? A log from a timedemo run would be especially nice.

[thellier]

>How could StormMesa be this slow?
StormMesa can switch back to software rendering for various reasons: so if your system support StormMesa2010 you should better use it in any case (WinUAE or real hardware) as it included lots of fixes

>StormMesa has several variables [...] StormMesa2010 has it's own prefs program, but it doesn't give detailed info on what each variable does.
StormMesa & StormMesa2010 use the same variables : I have added the old documentation from stormmesa to the StormMesa2010's readme
I give it here again

STORMMESA PREFS
===============
Five new options in StormMesa2010 :
"Enable Debugger" "Debug Function" "Step Function" "Change Primitive Funcs" "Use DrawArray"

Enable Debugger:
Enables the output of messages. This is used for debugging of OpenGL programs.
(need to close StormMesa-Prefs to make it works)

Debug Function:
Print all the GL functions names

Step Function:
Step before all GL functions

Change Primitive Funcs:
Usually old StormMesa test (query) all the time the hardware and then choose to use
hardware or software for each Primitive Funcs.
Defaut is Off : So StormMesa2010 just test & choose once for all so can be
faster if the hardware can fully render the given program

Use DrawArray
If a GL program want to draw some GL_TRIANGLES then
we use a fast call to W3D_DrawArray(context,W3D_PRIMITIVE_TRIANGLES,0,count);
So can speed up more when using Warp3D (or Wazp3D in hardware mode)
Badly there is not much existing GL programs that use GL_TRIANGLES
You can try it with starship (the gl one not starshipw3d)
Glexcess use draw GL_TRIANGLES only for the spaceship in the tunnel
This option still got bugs so the default is OFF

Other options were env/vars in the old StorMesa
Their old documentation is given again here

DIRECT:
Forces the application to run in 'direct render' mode,
even if the application attempted to run in the
'indirect render' mode. The use of 3D hardware is only
possible in 'direct render' mode.

NOHW:
Forces the graphics to be drawn by the CPU, the 3D
hardware is not touched.

SYNC:
Enforces synchronized refreshing of the graphics in window
mode. Since StormMesa 3.1 no synchronisation is done
by default in window mode.

TRIPLE:
Enables triple buffering. This leads for fast applications
to better performance in fullscreen mode and to a more
constant animation. The disadvantage is the much bigger
video memory usage.

NOCLAMP:
If this option is activated, then 'texture wrapping' is also used,
if the application wants to use 'texture clamping'. This option
should be used when a Virge 3D processor is used, because the
amount of demos capable of running 3D hardware accelerated grows
a lot.

NICETEX:
Cares, that the graphics quality concerning textures is as good as
possible, even if the overall graphics quality was reduced using
the variables FAST and VERYFAST.

NICEFOG:
Cares, that the graphics quality concerning fogging is as good as
possible, even if the overall graphics quality was reduced using
the variables FAST and VERYFAST.

NOHWLINES:
Forbids the use of 3D hardware rendering for line drawing.

LOCKMODE0:
Default. The graphics isn't drawn directly, an 'indirect context' of the
Warp3D software is used. The drawing operations are collected
in a buffer and drawn later, by enclosing such drawing operations
by an lock/unlock call.
This mode is the most system friendly mode and also works for
applications, that call system functions during OpenGL drawing
which might also cause graphical output.
The disadvantage of this mode is the low performance.

LOCKMODE1:
All objects are drawn directly and every begin-end-block is
enclosed by a lock/unlock call. This mode is right now useless,
since it's performance is very low due to massive lock/unlock
call overhead.

LOCKMODE2:
All objects are drawn directly and the lock is held during the
whole display function. This is the fastest mode, but very
system unfriendly, because it freezes the system very much.

LOCKMODE3:
This mode works very similar to mode 2, but here the lock is
broken in periodic intervals to let the system 'breathe air'.
Practice has shown, that the performance usually isn't
noticeable lower than for the mode 2, but the system
friendliness is much better.

FAST:
If this option is activated, the 3D hardware is also used when some
effects aren't supported completely by the hardware. But StormMesa
still tries to achieve an acceptable graphics quality.

VERYFAST:
If this option is activated, the 3D hardware is mostly used, but
the graphics quality might be unacceptable low.

STATS:
Some information is printed out into the shell after completion
of the application. First, the reasons are displayed, which were
responsible for not using the 3D hardware and second, the amount of
drawn primitives (points, lines, triangles, quads) are printed out.
If there is no statistical output after completion of the application,
then some of the mentioned conditions, which are necessary for 3D
hardware support, are not satisfied.

PROFILE:
Not documented

NORASTER:
Not documented

NODITHER:
Not documented

NOZB:
Not documented

NOZBU:
Not documented

LIN:
Not documented

[jack-3d]

Originally Posted by BSzili

How could StormMesa be this slow? I thought it had Warp3D support as well. At least it says so on H&P's website.

I will check the Mesa settings, truth is I only know I have libraries in the system, but never used Mesa before. So I may have for example NOHW settings enabled. I will check it this evening...

Originally Posted by BSzili

The WarpOS port is not just a straight recompile. Many functions have to be replaced by ppc.library ones, and interrupt handlers has to be compiled separately, since they need to remain 68k code. This is not something I'd like to do blindly, which is why I need the Blizzard ROMs and a hardfile with WarpOS installed.

I think you can get these in WINUAE thread from people running PowerPC in their UAEs. I can be the betatester for you on a real machine then ;o)

[BSzili]

I don't really have time to get WarpOS up and running, or to hunt down people who are willing to upload an image of their system. If there's a ready to use hardfile for me for testing I'll give it a shot, otherwise I'll pass for the time being.
Let me know if you have any luck with getting StormMesa to use hardware acceleration.

[thellier]

Hi

In WinUAE/Wazp3D/StormMesa2010 it start (can select options menus) but stop because it cant find models/spike.mdl
What package contain the models for hexen2 ?


BTW: it is very unclear what is needed to be downloaded for the Amiga version to start ....

Alain

Originally Posted by thellier

Hi

In WinUAE/Wazp3D/StormMesa2010 it start (can select options menus) but stop because it cant find models/spike.mdl
What package contain the models for hexen2 ?


BTW: it is very unclear what is needed to be downloaded for the Amiga version to start ....

Alain

http://uhexen2.sourceforge.net/downl...l#amigaos_m68k The demo version is self-contained. The 'normal' version requires the pak files from the hexen2 cdrom, i.e. copy pak0.pak and pak1.pak from your cdrom into your data1 directory, and you'll most likely need patching them: run h2patch from shell for that.

[utri007]

High quality port. Supports all possible screen and audio modes.

Wish you could spend some time to tinkering Duke 3D for same level.

[Nobby_UK]

Quickly tried the Demo --- but it just sticks at the start screen

[BSzili]

Originally Posted by utri007

High quality port. Supports all possible screen and audio modes.

Wish you could spend some time to tinkering Duke 3D for same level.

Cheers. Maybe I went a bit overboard with adding support for all the different monitor types, but in the end it shed light on some issues that affected non-4:3 modes. Too bad the CPUs are not quite there for the software renderer. Maybe when the Vampire gets FPU support. In the meantime I hope people will have some luck with GL version.

Originally Posted by Nobby_UK

Quickly tried the Demo --- but it just sticks at the start screen

Have you tried running the game with "-nojoy"?

[BSzili]

Those who had lock ups at startup, but had success with "-nojoy", could you try the updated demo if it works without "-nojoy"?
https://sourceforge.net/projects/uhe...Demo-Aug.1997/

[Nobby_UK]

'-nojoy' Works ! --- But No Sound ?

and

The New Version Also Works !

[jack-3d]

Checked the variables and settings, used NOHW (0) VERYFAST (1), but its still absolutely slideshow 0-1 FPS.

If there is anybody who uses WINUAE with PowerPC, please contact BSzili and provide him your hardfile. Anyway this isnt usable with classic Amiga

One more thing. When I switched screen to Workbench, I was surprised it used almost all my Fast RAM (2 MB free out of 128 and 200kb free from ChipRAM which is strange, because I use CVision PPC).

[utri007]

Originally Posted by jack-3d

Checked the variables and settings, used NOHW (0) VERYFAST (1), but its still absolutely slideshow 0-1 FPS.

It wasn't excatly fast but not a slideshow. 320x240 I got about 4-5fps, setting screen smaller it was playable like Quake is with 68040 25mhz.

One more thing. When I switched screen to Workbench, I was surprised it used almost all my Fast RAM (2 MB free out of 128 and 200kb free from ChipRAM which is strange, because I use CVision PPC).

I have only 64mb fast and it was enough, so using 128mb sounds strange.

[James]

Originally Posted by szo

When you are able, can you run the stormmesa version with logging (e.g. glhexen2-mesa -devlog ) and post the generated debug_h2.log file, please? A log from a timedemo run would be especially nice.

debug_h2_logs.zip

Sorry I'm so late posting these, did logs for Quarktex and Wazp3D. Not sure why you needed them from me though?

Originally Posted by BSzili

Those who had lock ups at startup, but had success with "-nojoy", could you try the updated demo if it works without "-nojoy"?
https://sourceforge.net/projects/uhe...Demo-Aug.1997/

Tried starting new version a few times (all varieties) and no lockups so far...

Originally Posted by Nobby_UK

Works ! --- But No Sound ?

Sound should work, I even have mp3 music playing!

Originally Posted by jack-3d

Anyway this isnt usable with classic Amiga

Don't give up too soon, have you tried the Warp3D version from the new demo? The default game config is not suitable for slower machines. Try these:

gl_texturemode "gl_nearest"
gl_keeptjunctions "0"
gl_multitexture "1"

Not sure about the last one - glquake uses gl_fakemultitexture to speed things up. There are probably other settings that can improve speed too...

[BSzili]

I don't know what gl_fakemultitexture does, but enabling multitexturing will give a speed boost on video cards with more than one TMU (it won't do anything on the others). You can enable/disable it in the video menu too, no need to muck around with cvars.

Originally Posted by James

Sorry I'm so late posting these, did logs for Quarktex and Wazp3D. Not sure why you needed them from me though?

Thanks for the logs, very much appreciated. I needed them because they sometimes reveal some gothchas happening behind the scene, (I thought that you ran on original hw, but you are on uae.) Quarktex gives 38 fps but wazp3d gives 1.5?? Ugh..