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)

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.

Quote:

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.

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.

Quote:

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.

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 doeshttp://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.

>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

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.

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

Quote:

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)

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.

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.

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.

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.

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