Reply 60 of 86, by dr.zeissler
It works in software-mode, performace is good.
Retro-Gamer 😀 ...on different machines
It works in software-mode, performace is good.
Retro-Gamer 😀 ...on different machines
Any newer ports for WWIIGI, SWARRIOR, DUKE3D, ROTT known, that work with W98?
Retro-Gamer 😀 ...on different machines
Most of the work being done for ROTT is in ecwolf port, which is still in a very early stage. It'll only load the levels without weapons, enemies or any other interaction and only 1 tile high.
Must not be OpenGL, DIrect3D, DirectDraw would be fine as long as it comes with sound-engine that uses the windows drivers 😀
Retro-Gamer 😀 ...on different machines
WWIIGI - eduke32 only
SWARRIOR - all ports are bad because of the frankensteined codebase release. jfSW might work, ProAsm/SWP has crashing/stuttering issues, ICD is in programmer-fantasy featurecreep hell
DUKE3D - jfduke3d or eduke32, take your pick. for mods it's the latter, but win9x compatibility i'm not sure
ROTT - unfortunately a monopoly of a crappy closed-source illegal port with no others showing up to top it due to the community
glhexen v0.9 works with hexen wad version 1.1 in Win95 (and 3dfx Voodoo without paltex option) as discussed earlier in this thread. It ran slow as compared to the directx ports dxhexen and chocolate hexen 2.0 beta 1.
Edit: chocolate hexen ran fast and depends on SDL libraries, but replaced its SDL.dll with a Win95 compatible SDL.dll. However, it is missing sound/music because of an incompatibility.
The dxhexen port uses a different scaling method at higher resolutions. I prefer it even though it doesn't strive for vanilla authenticity.
Welcome back! Have you tried the new version of ZDoom classic with a GL 1.1 card? It should work and i wonder how the performance would be.
BTW i was wondering why did you chose OpenAL 1.12.854 for ZDoom LE? I guess that would be the last version working in 95? I switched to FMOD Ex for the GL version. Regards.
wrote:WWIIGI - eduke32 only SWARRIOR - all ports are bad because of the frankensteined codebase release. jfSW might work, ProAsm/SWP h […]
WWIIGI - eduke32 only
SWARRIOR - all ports are bad because of the frankensteined codebase release. jfSW might work, ProAsm/SWP has crashing/stuttering issues, ICD is in programmer-fantasy featurecreep hell
DUKE3D - jfduke3d or eduke32, take your pick. for mods it's the latter, but win9x compatibility i'm not sure
ROTT - unfortunately a monopoly of a crappy closed-source illegal port with no others showing up to top it due to the community
WWIIGI/DUKE3D - I have downloaded a very early version of eduke32 and will have a look if it runs on win9x and performs well.
SWARRIOR - You are right, jfSW and SWP both have mostly problems with the stuttering/crackeling sound, the gfx are no so bad and performance is ok.
ROTT - Winrott is playable, but not very good.
Retro-Gamer 😀 ...on different machines
xDuke aka duke3d_w32 has no issues with the sfx, no crackeling, no echos, just OK.
eduke does not start on win98 due to an error that I am currently not able to fix.
Retro-Gamer 😀 ...on different machines
I didn't mention xDuke as that's still software rendered (your thread is adderessing GL ports) and also replaced fast assembly with C and is slower from it.
Nice work on zdoom-CL! It has better performance and many more features than dxhexen. It also supports Win95 with the video acceleration set to none while dxhexen produces an error in that case. I like the culling addition, too.
I did try your client with Voodoo1 in emulation, but I had an error while loading hexen. Only tested with the opengl dll file from the 1st page of this thread. I wish I could test it, if only to see the renderer in action.
I recall that the later OpenAL versions wouldn't work with Win95 because of failing to complete the compiler step or later loss of working audio. Openal also had a later refactor of the multithreading code and its dependencies while the 1.12.x branch was simpler to follow the flow of code from audio input, to processing, to directsound output. There aren't too many lines of essential code there but its error checking seemed useful.
Edit: zdoom-CL now starts with hexen in gl mode. The previous error must have been an emulation issue and not zdoom-CL. Also noted that there are pixel writes with depth. Rarely seen that accessed from other software. Haven't entered a map yet, but that may be from the emulation's lack of handling of pixel writes with depth.
Thanks, you did a pretty good job on that early ZDoom LE versions. I'm interested on performance on real hardware, i've tested it only on GL 1.2 cards so far.
Can it be downgreaded to ogl 1.1 with less effects?
Retro-Gamer 😀 ...on different machines
MesaFx version 051h-5a has opengl 1.2 compatibility with support for 3dfx Voodoo in Win95. Tested in emulation and Zdoom-CL ran Hexen's MAP01, but there are a few opengl rendering problems. Attached the opengl32 library for testing which is dependent on an installation of the latest 3dfx reference driver set for Win9x.
PCem's Voodoo emulation doesn't show the above rendering problems as seen in DOSBox-X. The cause was the latter's opengl mode which likely has an incomplete emulation of the pixel pipeline with depth.
The above MesaFX version corresponds to Mesa 5.1. It should be possible to use a q2dos version of Mesa (but win32 build) and test whether its improvements lead to better performance.
I tried MesaFX with my voodoo3 and ZDoom LE runs mostly fine. ZDoom CL already runs on GL 1.1 hardware but that ancient GZDoom renderer probably already requires 32 bit color depth support, i'm not sure about that. Try the enable GL system menu option as i said before.
wrote:MesaFx version 051h-5a has opengl 1.2 compatibility with support for 3dfx Voodoo in Win95
Does not work on my machine.
Retro-Gamer 😀 ...on different machines
wrote:MesaFx version 051h-5a
Interesting. opengl32.dll matches the one in "mesafx-0.51h5.zip" preserved by The Wrapper Project, but without the other included support files.
"I see a little silhouette-o of a man, Scaramouche, Scaramouche, will you
do the Fandango!" - Queen
Stiletto
MesaFX supports OpenGL for input and 3dfx Voodoo for output. However, there is also a direct3d6 option in Mesa 3.4.2. This may be worth testing whether it reliably sends the opengl instructions of zdoom-CL to a direct3d6 device. I also don't know whether it is possible to port this same direct3d output code to a later version of Mesa.
If the MesaFX option (the above opengl32 dll, for example) performs well with a glide wrapper, such as one that outputs to a direct3d device, then testing a direct3d device is simpler since it doesn't require porting code.
Edit:
Tested the above suggestion of running zdoom-CL (GL mode) with a gl->d3d6 wrapper from the following archive, but without success:
http://www.vogonsdrivers.com/wrappers/files/O … irect3D/AltOGL/
That ancient OGL wrapper was never useful and never could run GZDoom, not even GLDirect 5 could do it properly.
Those old GZDoom renderers are tricky and wouldn't even run with the latest mesa unlike more recent GZDoom versions.
AFAIK MesaFX is a hardware accelerated GL driver so it could never work with a wrapper.
BloodGDX (http://m210.duke4.net) is a great Java port of Blood! (well, maybe not a 'port', the author used what source code he could find, and reverse engineered the rest) that is very good indeed. He's the same bloke who made BloodCM (available from the same site), which is a great, 99% accurate port of Blood! to Eduke32, the enhanced Duke Nukem 3D engine.