Have you tried older versions of Unreal?
Tried 16bit vs 32bit?
I remember back in the day running Unreal with UT, instructions are probably around here somewhere.

Default render for UT is Direct3D. So no detailed textures, which can eat a lot of texel performance.

that site said they were using 6.xx drivers, rumor has it the lower driver version the better FPS with old games on old cards. Bugs come with newer games though so thats something to think about.

That too. Unreal is a CPU hungry game.

also win 2000 pro game performance isn't as good as 9X.

DosFreak wrote on 2022-12-07, 02:33:

Have you tried older versions of Unreal?
Tried 16bit vs 32bit?
I remember back in the day running Unreal with UT, instructions are probably around here somewhere.

Haven't tried older than 226. Maybe it's worth a try. Correct, 16bit

Warlord wrote on 2022-12-07, 02:39:

that site said they were using 6.xx drivers, rumor has it the lower driver version the better FPS with old games on old cards. Bugs come with newer games though so thats something to think about.

I can try messing with even more archaic drivers. Judging by readme files it seems like 5.16 is the earliest the Geforce2 GTS shows up. Point taken about potential bugginess. Honestly I should probably stick with something that plays much nicer with XP, or use 98 instead. A few FPS isn't going to kill me but I go down a rabbit hole trying to figure these things out 🤣.

1 GHz Pentium with 100 MHz FSB - is it mobile one?

Putas wrote on 2022-12-07, 11:51:

1 GHz Pentium with 100 MHz FSB - is it mobile one?

No its a desktop CPU

Upping the FSB speed might be of help then.

Putas wrote on 2022-12-07, 14:14:

Upping the FSB speed might be of help then.

Yeah I think it would help, opted for the 100 mhz version because a while back i was trying to get it working in a slocket / 440bx. Not sure i have any 133 sdram either, need to look around. Also the bios is oem locked so not much tweaking can be done.

The FSB comment spurred me to check some other things. It looks like one of these ram sticks is CL3 which the rest are 2. Swapped out and now i get about almost a 10% increase in FPS believe it or not. Unreal is now at about 84 fps. Still not quite as fast as the review sites so the investigation continues!

If they work at 100 MHz CL2 I would try 133 MHz CL3 or whatever you have in between. If that works why not push further...

Putas wrote on 2022-12-08, 14:28:

If they work at 100 MHz CL2 I would try 133 MHz CL3 or whatever you have in between. If that works why not push further...

not sure i can. its an intel 815 board but Gateway OEM bios. dont think there is any way for me to force the FSB.

OK so, I think there are a few factors at play here.

1 - These benchmarks may be performed with no sound. This makes a significant difference in Q3A (30 fps for me). Unreal, less so, maybe 7 FPS.

2 - I've installed Win98 SE on another SD card and tried all manner of older driver versions etc. The best results are very comparable to what I'm getting in XP.

So as others mentioned, it could very well a bottleneck beause of the CPU and/or FSB.

Other benchmarks I've found-- if you watch this guys GF2 Pro repair video https://youtu.be/ygvR_2Jsb84 (check near 25:15), he's using 700 mhz overclocked to 933 (7*133 fsb), I believe (hard to hear what he's saying), and gets ~150 fps in quake3. For comparison, I can barely get 84 with the same settings; w/ sound disabled that bumps up to ~112. I'm not sure if the FSB difference will give me 40 more fps, but who knows. My 3d marks are higher than his too.

I'll go ahead and seek out a cheap 1000/133 etc. to compare.

you're not crazy. 227's the "win98 unofficial service pack by problvmchvld" of patches and didn't exist in 2000.

leileilol wrote on 2022-12-10, 08:33:

you're not crazy. 227's the "win98 unofficial service pack by problvmchvld" of patches and didn't exist in 2000.

I second this, if you want a real benchmark you should use either 224 or 225f.

UTGLR won't really get you much anywhere because a LOT of Unreal's rendering is strictly CPU tied, and also a lot of it thrashes texture memory uploads every single frame ontop of this.

I once had a map I did as a art project of sorts where every single texture used in the map shared one common palette. There were very little if at all any dynamic lights or Fire.dll textures and the performance (including the CPU usage) was surprisingly different than a typical Unreal map. The complexity of the map's BSP tree and how many potentially visible zones there are can also destroy performance as that's all handled in CPU land.

The default OpenGL will only work on very specific drivers and suffers from the infamous GL_EXTENSIONS buffer overflow crash which Unreal itself can't even properly catch. (Using UTGLR is exempt from this but you can only compile it against 224 or 226 public headers)

A lot of things to consider when judging performance:
1: Unreal was heavily designed around 3Dfx Glide, especially on Voodoo 2 cards at the time.
2: Unreal's model format is hilariously inefficient and wasteful, the act of rendering a mesh has quite a CPU hit due to how the format was poorly written.
3: Fire.dll based textures are CONSTANTLY, EVERY FRAME uploaded to VRAM. And these textures are created purely in software prior to upload.
4: Mirrors are additional viewports that effectively double the operations being performed to render anything to begin with. Same goes for any "WarpZone" portals.
5: The more palette objects being used currently in the scene, the performance will ever so slightly worsen.
6: "Volumetric Lighting" can completely destroy performance if it's trying to cover a area with a significantly high res lightmap available to it and if the BSP in the area is terrible.
7: DT_Sprite actors (especially anything DT_Mesh with bParticles set to "true") also destroy performance, as does excessive Canvas operations. (Just try looking at the server browser that UBrowser added and make sure it's set to the "All Servers" tab, watch the CPU usage skyrocket!)

I don't think Unreal, even Unreal Gold and the completely stupid 226f patch that breaks compatibility between it and retail copies ever made use of SSE anywhere. Unreal will say it detects KNI but I have no clue if there's anything in Render.dll that'd try to use KNI. As far as I know there's MMX and 3DNow! optimizations but nothing else.

DracoNihil wrote on 2022-12-10, 12:00:

I second this, if you want a real benchmark you should use either 224 or 225f. […]
Show full quote

leileilol wrote on 2022-12-10, 08:33:

you're not crazy. 227's the "win98 unofficial service pack by problvmchvld" of patches and didn't exist in 2000.

I second this, if you want a real benchmark you should use either 224 or 225f.

UTGLR won't really get you much anywhere because a LOT of Unreal's rendering is strictly CPU tied, and also a lot of it thrashes texture memory uploads every single frame ontop of this.

I once had a map I did as a art project of sorts where every single texture used in the map shared one common palette. There were very little if at all any dynamic lights or Fire.dll textures and the performance (including the CPU usage) was surprisingly different than a typical Unreal map. The complexity of the map's BSP tree and how many potentially visible zones there are can also destroy performance as that's all handled in CPU land.

The default OpenGL will only work on very specific drivers and suffers from the infamous GL_EXTENSIONS buffer overflow crash which Unreal itself can't even properly catch. (Using UTGLR is exempt from this but you can only compile it against 224 or 226 public headers)

A lot of things to consider when judging performance:
1: Unreal was heavily designed around 3Dfx Glide, especially on Voodoo 2 cards at the time.
2: Unreal's model format is hilariously inefficient and wasteful, the act of rendering a mesh has quite a CPU hit due to how the format was poorly written.
3: Fire.dll based textures are CONSTANTLY, EVERY FRAME uploaded to VRAM. And these textures are created purely in software prior to upload.
4: Mirrors are additional viewports that effectively double the operations being performed to render anything to begin with. Same goes for any "WarpZone" portals.
5: The more palette objects being used currently in the scene, the performance will ever so slightly worsen.
6: "Volumetric Lighting" can completely destroy performance if it's trying to cover a area with a significantly high res lightmap available to it and if the BSP in the area is terrible.
7: DT_Sprite actors (especially anything DT_Mesh with bParticles set to "true") also destroy performance, as does excessive Canvas operations. (Just try looking at the server browser that UBrowser added and make sure it's set to the "All Servers" tab, watch the CPU usage skyrocket!)

I don't think Unreal, even Unreal Gold and the completely stupid 226f patch that breaks compatibility between it and retail copies ever made use of SSE anywhere. Unreal will say it detects KNI but I have no clue if there's anything in Render.dll that'd try to use KNI. As far as I know there's MMX and 3DNow! optimizations but nothing else.

OK I appreciate the info. Perhaps a different game would be better to benchmark overall performance then 🤣.

I have a $10 1000/133 CPU on the way so I'll see if anything changes and report back. And also try older versions as recommended.