Opengl Driver Not Accelerated Gzdoom

[Mica Withington]

No, that means you will have to resort to using one of those mentioned ports that are made for low-end PC players. LZDoom is based on an older build of GZDoom, so you will get to experience the fancy modern lighting stuff.

@Redneckerz mentioned ZDoom32, which is an unofficial continuation of ZDoom, meaning that some advanced graphics options may or may not in there. Same author as LZDoom, so if LZDoom doesn't work for you, try it.

ZDoom32, despite its name, does include a OpenGL renderer. Ill list drfrag's Legacy builds here, can't hurt: He made several ZDoom derivatives: ZDoom Classic (CL), ZDoom Legacy Edition (LE), and ZDoom32. There used to be even more, but these are the actively maintained ones. drfrag added a lot of features to each of them, but given these are for legacy systems, ill list them on GPU support:

Ahh, "good" old Intel HD. It never fails, it never fails. See a thread about somebody having problems with his [insert OpenGL accelerated port here] and 99% of the time it will be the "good" ol' Intel HD. It seems just yesterday that Windows Vista came out....

GZDoom comes with a file entitled lights.pk3, which contains dynamic light definitions for relevant standard Doom, Heretic, Hexen and Strife actors, and a file entitled brightmaps.pk3 which contain brightmaps for many of these games' sprites. Loading these files automatically or not can be toggled from the IWAD selection box.

For some reason, Intel got away with "supporting" advanced renderer features in software (most notably DX10, but that might have to do with some underground deal to get those chips out of the Window -pardon the pun- and getting that coveted "Windows Vista certified" sticker on a few hundred millions of budget laptops and netbooks -but I digress). No other GPU manufacturer that I know of ever went this route, and it would be interesting to see how far a game would go with an emulated or just "supported at the driver level" GPU feature.

Still, it was irritating to see DX10 stuff that would refuse to run at on a proper DX9 video card (e.g. a Radeon 9600XT), to "run"....somewhat on an Intel GMA, which would otherwise be inferior in every conceivable benchmark at the time.

it's interesting how they are honest about the OpenGL 2.1 driver NOT being HW accelerated though. But I don't know if it would be better (and more realistic) saying that it's not supported, period, than forcing software to make the distinction between a real and a fake support. So that means that there are apps that accept non-accelerated drivers as well?

Still, it was irritating to see DX10 stuff that would refuse to run at on a proper DX9 video card (e.g. a Radeon 9600XT), to "run"....somewhat on an Intel GMA, which would otherwise be inferior in every conceivable benchmark at the time.

Around the GMA X3000/X4000 series Intel finally started to take the IGP seriously and these are the first semi decent pieces of junk that actually are runnable. But yes, their weird emulation scheme was bizarre to uphold, realy.

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.

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.

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.

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.

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.

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.

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.

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.

GZ PT is a standalone non-profit GZDOOM based remake of Hideo Kojima's Playable Teaser. While not a 1:1 remake, every sequence has been recreated as close as possible to the original, with low res assets and textures in true retro fashion.

Will you manage to escape the haunted corridor?

Please don't ask about Quest Gzdoom or Delta Touch, this game was made and tested specifically for standard PC GZDoom so while it may work on those specific versions I cannot answer or give tech support to Delta/Quest users.

3a8082e126