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.

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

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.

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.

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.

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.

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.

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

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.

And of course the MiniGL driver:

The other is a patch for Unreal for the Banshee.

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.

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.

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.

1Log: Bound to OpenGLDrv.dll
2Init: Using pixel format 1
3Init: glGetString(GL_VENDOR): X.Org
4Init: glGetString(GL_RENDERER): AMD RAVEN (DRM 3.38.0, 5.8.8-arch1-1, LLVM 10.0.1)
5Init: glGetString(GL_VERSION): 4.6 (Compatibility Profile) Mesa 20.1.7
6Init: 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
7Init: Pixel format 1:
8Init:    Flags: PFD_DRAW_TO_WINDOW PFD_SUPPORT_OPENGL PFD_DOUBLEBUFFER
9Init:    Pixel Type: 0
10Init:    Bits: Color=32 R=8 G=8 B=8 A=8
11Init:    Bits: Accum=0 Depth=24 Stencil=8
12Init: Device supports: GL
13Init: Device supports: GL_EXT_bgra
14Init: Device supports: GL_S3_s3tc
15Init: Device supports: GL_EXT_compiled_vertex_array
16Init: Device supports: WGL_EXT_swap_control
17Init: Device supports: GL_ARB_multitexture
18Init: Device supports: EXT_point_parameters
19Init: Using OpenGL settings [Default]