That's a "nevermind" if I've ever seen one. Half the time, the system won't boot properly with the card installed, and Windows refuses to work with it. The times that the system just sort of crashes are usually right before Windows gets to the desktop. There's also artifacting on the System BIOS screen in the form of small white dots, while there is none present on the actual video card BIOS screen. I will try cleaning the AGP contacts on the card with some rubbing alcohol, but if it continues to crash or otherwise malfunction, I will have to diagnose this one as chipset incompatibility.

It's odd though, because I could boot up the PC and install drivers and use Windows normally just fine on the Tabor III. That's why I think this has something to do with the AGP contacts having dirt on them or something like that.

[EDIT]

This isn't going to work. After removing the card, and cleaning the contacts, and checking it for any signs of issues, it still has the same issue. It will artifact small white dots above and below characters in BIOS, and some in DOS mode, and Windows 98 will refuse to load the video drivers, with this error:

"There is a problem with your display settings. The adapter type is incorrect, or the current settings do not work with your hardware."

This has nothing to do with the drivers themselves, or even Windows, as it's artifacting in BIOS. I'm going to say motherboard incompatibility, as the video BIOS itself is free of any artifacting. The system will hard-lock up when I click "ok" on the message, and it will respond to nothing but the reset button. The BIOS is fully updated on the motherboard.

Half-Life's from before the time of hardware T&L and what you're suggesting hasn't been a thing until after 2000. Offloading vertex processing to the GPU was a constant struggle (Voodoo2's much lauded "triangle setup", DX7's HWT&L, OpenGL2's vertex shaders and VBOs, and Vulkan) and that was only applicable to games that used the modern and newer APIs and took advantage of them for appropriate hardware.

tl;dr there is no miracle Half-Life low-end stutter solving video card.

I'm thinking that the stutter itself is from the game loading while doing things. I'm honestly not even looking into low-end anymore, either. I just had the GeForce 2 MX400 lying around, and that's why I tried it.

I read somewhere that the GeForce 256 actually does something like that. Checking it right now, it does mention that the GeForce 256 is T&L capable, but the game has to support it. Unless there's an update to Half-Life WON that was made that specifically allows for T&L. I'd have to do some research into that. Of course, that's assuming that I ever get the ungodly amount of money required to get a GeForce 256, which unless something unexpected happens, I'd doubt.

So I'm probably going to be stuck here for a while. To be fair, it does run alright, but it's very inconsistent, running for, I'd say 55% of the time at 37FPS, and going to 50+ FPS. But in that other video thread, it was discussed that the game just runs poorly, at least, the original WON version does. I'm not sure why it ran so well on that FX5200 if it wasn't for T&L, however.

[EDIT]

Looking around a little bit, I found this site which seems to have a HL update version up to 1.1.1.2. I'm not 100% sure of the legitimacy of this, but this seems to be made by the makers of WON2. I'm wondering if T&L support was thrown in there somewhere.

https://v5.steamlessproject.nl/index.php?page=hl1112

I think Geforce 256 was the first GPU with hardware t&l, but like leileilol said, the game engine itself had to specifically use a version of OpenGL / DX that supported such a feature. That said, it may be possible that modern versions of HL through steam may have been updated, but I doubt it.

My 800mhz coppermine doesn't have 'problems' running Half-Life per say, it just has dips into the 30s when certain AI are rendering. This was absolutely normal back then, nobody had a PC good enough to get a solid 60FPS in brand new AAA first person titles. I knew a few crazies who ran dual pentium 3 coppermine setups just to play Quake 3 and Unreal Tournament, but besides them, must humans accepted 30FPS as a very good baseline.

I'm afraid the only way you're going to lock in Half-Life to 60+ FPS rock solid is going to be by using a Pentium 4 or Athlon XP though I expect the experience would be very smooth using a 133mhz bus top end Coppermine or Tualatin. Unfortunately my slot 1 board with 133mhz bus doesn't work anymore to test this out. I would try to get somebody running a 1ghz coppermine @ 133 to bench the game and then maybe a 1.4ghz Tualatin to see how far ahead of my system they get.

FWIW I've tested half-life all the way up to a GeForce FX5600 and the frame rate remains the same, even at 640x480, it's totally CPU bound.

I don't exactly want a solid 60FPS, I just wish I'd get it to at least 45FPS or so, and stay somewhat consistent with that.

Though, the mention of a dual processor configuration does strike me as plausible, if I managed to get the funds for a dual slot 1 motherboard. Other Katmai's @500MHz are fairly cheap, or I could replace the 500MHz entirely and just get two of the fastest PIII's released in my system's timeframe, the Pentium III Katmai 600MHz model.

That is probably extremely expensive, however. I've looked up dual Slot 1's on eBay before, and they never dip below US$100. Usually, they range in above US$130.

athlon-power wrote:

I don't exactly want a solid 60FPS, I just wish I'd get it to at least 45FPS or so, and stay somewhat consistent with that.

Though, the mention of a dual processor configuration does strike me as plausible, if I managed to get the funds for a dual slot 1 motherboard. Other Katmai's @500MHz are fairly cheap, or I could replace the 500MHz entirely and just get two of the fastest PIII's released in my system's timeframe, the Pentium III Katmai 600MHz model.

That is probably extremely expensive, however. I've looked up dual Slot 1's on eBay before, and they never dip below US$100. Usually, they range in above US$130.

I should add that I don't believe Half-Life can use SMT (Multithreading / multi cores). Such being the case, you would see no improvement at all.

It's too bad we can't overclock the SE440BX-2 for a bit more testing, though you may be able to get away with buying a coppermine capable slotket and a 1000mhz socket 370 coppermine at a reasonable price. 1000mhz slot 1 Coppermines are very expensive and it seems anything above 800mhz doesn't show up often on ebay. Or if you were looking into a whole new board, Pentium III Tualatin boards can run 1.4ghz CPUs, that's almost twice the clock speed of mine, so I would imagine the frame rate would be much better overall.

I have a feeling this chip would blow mine away at 1400mhz + 133mhz bus.
https://www.ebay.com/itm/COMPAQ-G2-PENTIUM-3- … &frcectupt=true [I don't know or endorse the seller, just an example]

If you run Half-Life at 400x300, it's quite smooth. I am still using OpenGL, but it looks like you'd expect it to. I'll try a couple of other display modes (DirectX, Software.. ew.) and see how my mileage varies.

I was joking about 400x300 50% of the way, and the other half, I may fall back on 512x384 in OpenGL or something similar. I did try 1024x768 earlier on, and the FPS was awful, but it never approached single-digits, always staying above 15fps, so I guess that's got to count for something.

My motherboard supports a maximum of a Pentium III 800, so that's as far as I could take it. I don't know how well a faster CPU on a slocket adapter would work, or even if it would work at all.

athlon-power wrote:

Looking around a little bit, I found this site which seems to have a HL update version up to 1.1.1.2. I'm not 100% sure of the legitimacy of this, but this seems to be made by the makers of WON2. I'm wondering if T&L support was thrown in there somewhere.

it isn't and they haven't. It's also not trivial to add (Especially for a 'patch' which just switches some IPs around)

If not the Geforce 256/Quadro, I do remember the Savage 2000's only claim to fame was that for a brief period it was known to be the fastest card for Quake 3 Arena in 32 bit color; might be worth a look. Aside from that maybe a TNT2 Ultra, Power VR Kyro, or something along those lines.

Did you try turning V-Sync Off like I suggested in that thread? I'm fairly certain it will fix performance for the most part. Half-Life probably uses double buffered V-Sync, unless the TNT2M64 drivers allow you to use Triple Buffered VSync.

The M64 is an absolutely horrible card and will be the source of your problems for sure. For the 1999 period get yourself a Voodoo 3 3000/3500 or a matrox g400/g400 max. They would suit your machine very well.

Also since you mentioned loading stutters, check that your HDD is running in DMA mode and not PIO mode. This used to be a common issue for me back in the day.

Even a regular TNT2 would be a big improvement. The 64-bit memory bus on the M64 is a major limitation.

mzry wrote:

The M64 is an absolutely horrible card and will be the source of your problems for sure. For the 1999 period get yourself a Voodoo 3 3000/3500 or a matrox g400/g400 max. They would suit your machine very well.

Also since you mentioned loading stutters, check that your HDD is running in DMA mode and not PIO mode. This used to be a common issue for me back in the day.

I'll have to disagree with your statement about the TNT2 M64 being an absolute horrible card.
It simply is not.

It's biggest gripe may be its limited speed, but only compared to faster/newer cards.

TNT2 M64 is quite a good card actually, it's one of those cards that simply "just works", but isn't the fastest solution you can easily find (any MX2/MX4 card is most likely going to be much faster and as easy to find I suppose).

The speed of the TNT2 M64 is roughly comparable to TNT1 (for instance Diamond Viper 550) and there are PCI versions of this card.

Half-Life's OpenGL interfacing is anachronistic, to say the least.
There are a couple of things John Carmack and Brian Hook addressed since the release of GLQuake that the Valve engineers did not. For example, Half-Life is still using the immediate mode with an API call for every vertex or strip. Quake 2 has some variables for enabling the usage of the superior OpenGL 1.1 calls. Another thing that is especially relevant for Half-Life's flashlight is the lack of a dedicated dynamic lightmap atlas. It is not unusual for the flashlight to manifest itself on three different 128x128 lightmaps that are to be updated every frame, which is a performance killer on PCI cards.
Generally, 3dfx chips had the least driver overhead at the time, so I guess a Voodoo 2 is the most appropriate card for a CPU intensive game like this (or the Banshee for that nice multipass overbrightening).

BeginnerGuy wrote:

I think Geforce 256 was the first GPU with hardware t&l, but like leileilol said, the game engine itself had to specifically use a version of OpenGL / DX that supported such a feature.

For DirectX that certainly is true. Namely, in order for hardware T&L to work, you need to have the vertex data in VRAM beforehand (otherwise the T&L units would get bottlenecked by the PCI/AGP bus, and there would be little or no gain).
Since DirectX is quite low-level, the vertex data was very explicitly in system memory in early versions of DirectX. DirectX 7 was the first to introduce the concept of vertex buffers, and allowed the user to specify whether they be stored in system ram or VRAM.

OpenGL is different however. There are various ways to send vertex data to the OpenGL API, and they don't really specify where and how the OpenGL layer should store that data. To the user, the API is just 'fire and forget'. This high-level abstraction makes it relatively easy for the driver to buffer vertex data, and render the data in batches (which was already a relevant optimization even before hardware T&L). This also means that adding support for hardware T&L is quite trivial (although the PowerVR cards proved that a buffered approach can also be implemented for DirectX, but afaik no other manufacturer ever tried such an approach).

Of course, this is all driven by heuristics, so in practice it still depends on how draw calls can be grouped together. Changing certain attributes would force the driver to flush the buffers and start a new batch. Worst-case, this happens at every individual triangle.
That is the biggest downside of the usage of a classic BSP, as in the original Quake engine (also used by Half-Life): the triangles arrive in more or less 'random' order, one by one. Very efficient for software renderers, not so good for batching calls.
This led to the development of 'leafy' BSP trees, where the BSP would not return one triangle at a time, but rather groups of triangles, to improve GPU efficiency. Half-Life is too old for that though.

TL;DR: OpenGL games not specifically designed for it *can* benefit from hardware T&L, but not necessarily. GLQuake and Half-Life are quite poor cases for hardware T&L.

I'd like to use GF2-gen T&L in OA some day and even I haven't figured where to start, especially since Id Tech 3 by nature is a unified brute-force software processed approach to go through the same strip functions it'd need a complete rewrite to even have it all reproduced in vertex shaders. Losing the CPU overhead from that would be super nice though, and I know Harekiet (yes) did an ARB'd q3 renderer at one point.

leileilol wrote:

I'd like to use GF2-gen T&L in OA some day and even I haven't figured where to start, especially since Id Tech 3 by nature is a unified brute-force software processed approach to go through the same strip functions it'd need a complete rewrite to even have it all reproduced in vertex shaders.

Heh, when I first read that, I thought it applied to DOOM 3, but that's Id Tech 4. Same thing though: they did a LOT of stuff on the CPU there, didn't leverage shaders for the stencil shadows.
I never quite understood that decision: now you needed a 3+ GHz Pentium 4 or a 3000+ equivalent Athlon to process the shadows quickly enough, where most shader cards available at the time would have been able to do that easily, with a much slower CPU.
A great example of that is the Battle of Proxycon test in 3DMark03: https://www.youtube.com/watch?v=Uw2XLhjihKc

They do make full use of shaders, and it scales much better with newer hardware than DOOM 3 did.
I also took that approach for my own engine's stencil shadows back in the day (obviously with a CPU-based fallback for older hardware, but still making use of T&L where possible: I stored the stencil shadows in object space in VRAM and updated only the required data on-the-fly with the CPU, then let the GPU handle T&L).