VOGONS


First post, by DracoNihil

User metadata
Rank Oldbie
Rank
Oldbie

I'm going to hope this is the board to post this in, because I mean... this is about versions 224 and 225 of Unreal. I don't know which version originally introduced OpenGlDrv.dll but it's obvious that it's a experimental render device.

If you look in Unreal.ini this is typically what you see for it:

[OpenGLDrv.OpenGLRenderDevice]
Translucency=True
VolumetricLighting=True
ShinySurfaces=True
Coronas=True
HighDetailActors=True

Note that there's no support for DetailTextures, the option doesn't even exist in Advanced Options either!

Now here's where things get even weirder with it, there is a INI file with the same exact name as the DLL file and this is what's contained in it:

[Default]
MinLogTextureSize=3
MaxLogTextureSize=10
MaxLogUOverV=10
MaxLogVOverU=10
UseZTrick=1
UseMultiTexture=1
UsePalette=1
DoPrecache=1
ShareLists=1
AlwaysMipmap=1

[NVIDIA Corporation/RIVA TNT (PCI)]
MinLogTextureSize=0
MaxLogTextureSize=10
MaxLogUOverV=10
MaxLogVOverU=10
UseZTrick=0
UseMultiTexture=1
UsePalette=0
DoPrecache=1
ShareLists=1
AlwaysMipmap=1

[NVIDIA Corporation/RIVA TNT (AGP)]
MinLogTextureSize=0
MaxLogTextureSize=10
MaxLogUOverV=10
MaxLogVOverU=10
UseZTrick=1
UseMultiTexture=1
UsePalette=0
DoPrecache=1
ShareLists=1
AlwaysMipmap=1

[Intel/Intel740]
MinLogTextureSize=0
MaxLogTextureSize=10
MaxLogUOverV=10
MaxLogVOverU=10
UseZTrick=1
UseMultiTexture=0
UsePalette=1
DoPrecache=1
ShareLists=1
AlwaysMipmap=1

[3Dfx Interactive Inc./3Dfx]
MinLogTextureSize=0
MaxLogTextureSize=8
MaxLogUOverV=2
MaxLogVOverU=2
UseZTrick=1
UseMultiTexture=1
UsePalette=0
DoPrecache=0
ShareLists=0
AlwaysMipmap=0

Show last 12 lines
[ATI/RAGE 128]
MinLogTextureSize=3
MaxLogTextureSize=10
MaxLogUOverV=10
MaxLogVOverU=10
UseZTrick=1
UseMultiTexture=1
UsePalette=0
DoPrecache=1
ShareLists=1
AlwaysMipmap=0

If we look at the output of "strings -e l OpenGlDrv.dll" you can spot the following in the output:

_SGI_cull_vertex
_EXT_point_parameters
_GL_EXT_clip_volume_hint
_GL_ARB_multitexture
_GL_WIN_swap_hint
_WGL_EXT_swap_control
_GL_EXT_compiled_vertex_array
_GL_S3_s3tc
_GL_EXT_paletted_texture
_GL_EXT_bgra
L_GL

S3TC is mentioned, but none of the S3 cards are given a special preset under OpenGldrv.ini
The [Default] in OpenGlDrv.ini I assume is used if it can't find a section in the INI with the exact Vendor/Renderer string in it.

So here's my question: Has anyone ever successfully gotten this to run with any number of late 90's GPU's that have OpenGL support? The only time I've ever ran this successfully is on the Intel Iris Pro 580 on my new tiny PC after exporting the necessary Mesa environment variables to avoid a buffer overflow. I've never gotten this ancient OpenGlDrv to run at all on the various GPU's I've grown up using, either Unreal would crash and catch the crash or the whole thing just silently exits or triggers a BSOD. (or in the case of Windows XP a "has stopped working" message)

If anyone has a Savage 4, can it run Unreal with OpenGL? Will it report GL_S3_s3tc in that case? I'd really love to know.

Steam Profile
YouTube Channel
Seal of Nehahra

Reply 1 of 12, by kolderman

User metadata
Rank Oldbie
Rank
Oldbie

I was playing Unreal on a savage4 last night, but using Metal API instead. Before it was running using something other than Metal, I remember because I had to hack some config files to make Metal work. So it must have either been ogl or d3d - does it support d3d? If not, then I guess it was ogl after all.

Reply 2 of 12, by DracoNihil

User metadata
Rank Oldbie
Rank
Oldbie

I can't find anything in the D3DDrv.dll that would suggest DXT1 / S3TC support in it, it seems to be hinted in OpenGlDrv but the only video I've found on S3TC was using MetalDrv.

Unreal defaults to D3DDrv, and flags OpenGlDrv as "experimental".

Steam Profile
YouTube Channel
Seal of Nehahra

Reply 3 of 12, by kolderman

User metadata
Rank Oldbie
Rank
Oldbie
DracoNihil wrote on 2020-09-01, 19:49:

I can't find anything in the D3DDrv.dll that would suggest DXT1 / S3TC support in it, it seems to be hinted in OpenGlDrv but the only video I've found on S3TC was using MetalDrv.

Unreal defaults to D3DDrv, and flags OpenGlDrv as "experimental".

I always thought that S3TC was only enabled for Metal, which is why I switched to that in the first place, and yes it worked just fine. I could try again tonight to see if ogl work at all, and if so if S3TC seems to be enabled.

Reply 4 of 12, by DosFreak

User metadata
Rank l33t++
Rank
l33t++

Any reason you want to use the original opengl and not the newer versions either from Dohnal or oldunreal? Does the S3 not work with those?

Somewhere around Dec 2000 Nvidia and ATI added support in their drivers for S3TC so guess that wouldn't match with your late 90's requirement if you are just worried about S3TC, so likely only S3 videos cards would qualify. Possibly any Nvidia card equal or below a Geforce 256 if the newer drivers work with those cards.

Once that support was added in the drivers I was using OpenGL w/ S3TC both in U1 and UT in Dec 2000 on a Hercules 3D Prophet 2 GTS 64M on Dec 2000 with the OpenGL file provided by Loki.

I haven't kept track of which renderers work with which versions of Unreal but the attached should worked, note that these files are very old and that there may be newer versions and procedures that may work better from oldunreal.

Above is assuming you are running Unreal 1 and not Unreal using UT.

Attachments

  • Filename
    S3TCforUnreal.zip
    File size
    432.67 KiB
    Downloads
    2 downloads
    File license
    Fair use/fair dealing exception

DOSBox Compilation Guides
DosBox Feature Request Thread
PC Game Compatibility List
How To Ask Questions The Smart Way
Running DRM games offline

Reply 5 of 12, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie

I patched Unreal 1 to the last official Epic released patch 226f and OpenGLDrv was doing great with QEMU MESAGL pass-through. The fly-by demo FPS was slightly lower than Glide for the same version on QEMU Glide pass-through but still achieved comfortably smooth game play within the realm of 60FPS.

Reply 6 of 12, by DracoNihil

User metadata
Rank Oldbie
Rank
Oldbie
DosFreak wrote on 2020-09-01, 20:09:

Any reason you want to use the original opengl and not the newer versions either from Dohnal or oldunreal? Does the S3 not work with those?

225f has no public headers so you can't simply compile UTGLR against version 225f of Unreal. There's headers for 224v but 224v lacks several critical internals that 225f and above introduce, so I can't play online with it. I only use 224v to compile mods and make maps with.

I'm just looking to avoid Unreal Gold because it has bugs that 225f doesn't have, and there are some mods that the UMenu console doesn't work with.

The primary reason I started the thread is I'm curious how many old GPU's can successfully run the render device without crashing, really.

Steam Profile
YouTube Channel
Seal of Nehahra

Reply 7 of 12, by kolderman

User metadata
Rank Oldbie
Rank
Oldbie
DracoNihil wrote on 2020-09-01, 22:56:

I'm just looking to avoid Unreal Gold because it has bugs that 225f doesn't have, and there are some mods that the UMenu console doesn't work with.

Oh is this not using an official patch? I didn't realize. I am just playing Unreal Gold with latest official patch only (whatever that is). I have not noticed so many bugs yet.

Last edited by kolderman on 2020-09-02, 01:17. Edited 1 time in total.

Reply 8 of 12, by leileilol

User metadata
Rank l33t++
Rank
l33t++

not Unreal, but the OpenGL driver in the original Deus Ex was super buggy on my Geforce2. Like, it would reveal the ugly truth that EVERYBODY HAS GOGGLES

(this was fixed in a later patch when Loki Games got involved)

The OpenGL driver started appearing around version 208 I think? Definitely new in the TNT era and wasn't intended for anything older than that (though, it's somewhat possible to throw Techland's S3D wrapper at it, as well as various 3dfx GL ICDs for even worse visual quality/performance). But considering that OpenGL's texture management and Unreal's need to keep writing/uploading textures per frame (for fractals, lightmaps, fog ball calcs, etc) it's surely going to be thrashy on hardware that old.
Fortunately much was learned by UnrealEngine2...

apsosig.png

Reply 9 of 12, by cyclone3d

User metadata
Rank l33t
Rank
l33t

I was digging through some Gateway restore ISO files the other night and I am pretty sure I saw an OpenGL patch for 3dfx cards for Unreal... maybe it was another game. I'll have to see if I can find it again when I am home.

Edit:
Ok, so I was sort of mistaken.
The Installs on the Gateway CDs are for the Voodoo Banshee and possibly other 3dfx cards.

One is an OpenGL driver.

Filename
OGLINST.zip
File size
396.29 KiB
Downloads
3 downloads
File license
Fair use/fair dealing exception

And of course the MiniGL driver:

Filename
mgl_inst.zip
File size
97.54 KiB
Downloads
4 downloads
File license
Fair use/fair dealing exception

The other is a patch for Unreal for the Banshee.

Filename
UNREALFX.zip
File size
1.27 MiB
Downloads
4 downloads
File license
Fair use/fair dealing exception

Yamaha YMF modified setupds and drivers
Yamaha XG resource repository - updated November 27, 2018
Yamaha YMF7x4 Guide
AW744L II - YMF744 - AOpen Cobra Sound Card - Install SB-Link Header
Epstein didn't kill himself

Reply 10 of 12, by DracoNihil

User metadata
Rank Oldbie
Rank
Oldbie
leileilol wrote on 2020-09-02, 01:13:

not Unreal, but the OpenGL driver in the original Deus Ex was super buggy on my Geforce2. Like, it would reveal the ugly truth that EVERYBODY HAS GOGGLES

I'm guessing it's the "masked texture" bug where Poly's flagged as STY_Masked aren't obeyed? (ditto for textures being applied to meshes that have bMasked set)

Because, that's indeed a rather critical bug with the original Unreal 1 OpenGLDrv.

kolderman wrote on 2020-09-01, 23:20:

Oh is this not using an official patch? I didn't realize. I am just playing Unreal Gold with latest official patch only (whatever that is). I have not noticed so many bugs yet.

Nooooo, Unreal Gold is indeed a official patch, as is 224v and 225f but like 226f: 226b (UGold) has issues with reconnecting to servers and mods that expect you to beable to use "ShowMenu" wont work properly because UPakConsole forces you to invoke the UMenu style Console from UT99. Also, because of a name table incompatibility, the two versions cannot join a server of the other without a stupid "Assertion Failed".

I primarily want to go back to using 225f as a client (I already use it to host a dedicated server) just to avoid the reconnect problems and also beable to enjoy the pre-226 GalaxyDrv doppler effect behaviour. 225f was originally going to be the actual final patch to Unreal 1, but then something happened and 226 ended up being created using partially backported code from UT99's builds.

On topic though: I'm intrigued by the anecdotes of trying to run this terrible thing on the hardware at the time. I kinda figured OpenGL's "overhead" would really tank Unreal considering how Unreal tries to implement fractal textures among other things.

Steam Profile
YouTube Channel
Seal of Nehahra

Reply 11 of 12, by pixel_workbench

User metadata
Rank Newbie
Rank
Newbie

I mainly use Unreal Gold, but it has an updated D3D renderer that refuses to work on Riva128. I just get an error at launch. Switching to OpenGL renderer enables the game to run on that card.

My Youtube Channel
P2 400 unlocked / Asus P3B-F / Voodoo3 3k / MX300 + YMF718

Reply 12 of 12, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie

I looked at why Unreal1 226f OpenGLDrv crashed. It suffers 2 very common programming errors at the time, buffer overflows due to huge number of pixel formats returned by WIN32 API and large number of GL extensions from glGetString().

Since QEMU MESAGL on Linux has to emulate Windows OpenGL behavior in querying pixel formats, it always returns the only pixel format that was currently preset from QEMU context. This solved the first buffer overflow by coincidence. This was not the case on Windows because on Windows it was easier just to pass-through WIN32 calls as-is, but I could have planned to do the same as what Linux did.

Yes, the OpenGLDrv driver has indeed supported S3TC, but it was marked as an extension in 1999. Existing Linux MESA returns too many GL extensions up to year 1999 and it crashed the OpenGLDrv due to the 2nd buffer overflow. So I tweaked the extensions table to mark S3TC as 1998 and limit the extensions up to 1998.

The default OpenGLDrv wasn't that bad at all after all. The community addons versions seem to suffer from audio crackling from QEMU.

Log: Bound to OpenGLDrv.dll
Init: Using pixel format 1
Init: glGetString(GL_VENDOR): X.Org
Init: glGetString(GL_RENDERER): AMD RAVEN (DRM 3.38.0, 5.8.8-arch1-1, LLVM 10.0.1)
Init: glGetString(GL_VERSION): 4.6 (Compatibility Profile) Mesa 20.1.7
Init: glGetString(GL_EXTENSIONS): GL_ARB_multisample GL_EXT_abgr GL_EXT_bgra GL_EXT_blend_color GL_EXT_blend_minmax GL_EXT_blend_subtract GL_EXT_copy_texture GL_EXT_subtexture GL_EXT_texture_object GL_EXT_vertex_array GL_EXT_compiled_vertex_array GL_EXT_texture GL_EXT_texture GL_EXT_texture GL_EXT_texture GL_EXT_texture3D GL_IBM_rasterpos_clip GL_ARB_point_parameters GL_EXT_draw_range_elements GL_EXT_packed_pixels GL_EXT_point_parameters GL_EXT_rescale_normal GL_EXT_separate_specular_color GL_EXT_texture_edge_clamp GL_SGIS_generate_mipmap GL_SGIS_texture_border_clamp GL_SGIS_texture_edge_clamp GL_SGIS_texture_lod GL_ARB_framebuffer_sRGB GL_ARB_multitexture GL_EXT_framebuffer_sRGB GL_IBM_multimode_draw_arrays GL_IBM_texture_mirrored_repeat GL_S3_s3tc WGL_EXT_swap_control
Init: Pixel format 1:
Init: Flags: PFD_DRAW_TO_WINDOW PFD_SUPPORT_OPENGL PFD_DOUBLEBUFFER
Init: Pixel Type: 0
Init: Bits: Color=32 R=8 G=8 B=8 A=8
Init: Bits: Accum=0 Depth=24 Stencil=8
Init: Device supports: GL
Init: Device supports: GL_EXT_bgra
Init: Device supports: GL_S3_s3tc
Init: Device supports: GL_EXT_compiled_vertex_array
Init: Device supports: WGL_EXT_swap_control
Init: Device supports: GL_ARB_multitexture
Init: Device supports: EXT_point_parameters
Init: Using OpenGL settings [Default]