Hacker News Reader

Comment by sprash | Hacker News Reader

The main reason for the success of 3dfx were drivers that let you talk to bare metal hardware registers instead of dozens of GL abstraction layers. The simplicity of it all is very impressive. This is something programmers absoluteley love. Hence many games supported it and it was very easy to write drivers. Maybe it is time to reimplenent the glide interface in an FPGA ang make a super powered Voodoo card.

View on HN

The only success the drivers had were the lock-in they created to the hardware with Glide, which itself was a thin layer on the underlying hardware. Many games used Direct3D or OpenGL without Glide support and worked just fine.

Hell, Quake itself was written on miniGL which was a subset of an abstraction layer built (IIRC) on top of Glide.

And really, OpenGL at the time was simple too. [Check this OpenGL 1.1 reference](http://www.talisman.org/opengl-1.1/Reference.html) which also includes GLU and GLX function and even with those, the number of calls is very small.

I miss software rendering, games with that as an option are the only old games that still run on modern PCs.

OpenGL games should run fine, some old games that used static sized buffers to hold extensions (like all Quake/Quake2 games that dump the available extension string to the console and the console having a hardcoded buffer for each line) will crash it because of how long the extension string is nowadays, but most drivers have an option to limit the string size (AFAIK Nvidia and AMD drivers check the executable name and do it automatically for known faulty games).

For Direct3D games you must use a 32bit color mode otherwise Windows 8.x/10 will force software rendering which is very slow. Even better, use dgVoodoo2 which is a reimplementation of DirectX 1 to 7 (with a some bits of 8) in Direct3D 11 and provides much better compatibility (also gets rid of the Direct3D 7 2048 surface width limitation, making it possible to play games at 2560x1440 and up).

For Glide, dgVoodoo2 is also very good and you can "cheat" the game to force higher resolutions than what the game thinks it is running at.

I have a lot of old games and everything that isn't DRM encumbered works fine in Windows 10 using dgVoodoo2 and/or some game-specific hacks (Tomb Raider 1 for example is normally a DOS game that you can play using a Glide-enabled build of DOSBox but there was also a Windows version made that used an ancient proprietary 3D API by ATI - someone reimplemented that API and placed extra hacks in there for high resolutions and widescreen support).

Software rendering will only be slow until everyone has manycore processors with SIMD. The die area of threadripper isn’t far from a GPU’s die area.

Yeah, actually the other day i was thinking about getting a 2990WX to try writing a software renderer on it and see how it performs. Too bad it is way too expensive (and Zen 2 CPUs are around the corner).

(Hi Larabee)

Whenever i re-read Tom Forsyth's (who worked on it) article about Larrabee [1], i facepalm hard at Intel's decision to drop it. It is one of the few cases where i really wanted to put my hands on that sort of hardware. An essentially standalone manycore CPU on a PCI express form that is running FreeBSD or Linux, with a bit of graphics specific functionality that doubles as a video card and you can fully program like a PC?

I have "I WANT! I WANT! I WANT!" signs blinking in my head as i type this :-P.

(facepalm mainly because i wanted it, i do not know the economical details)

Funny enough, the Forsyth's (and another one from another team member i do not remember now) article sold me more on Larrabee than any PR speak Intel made.

[1] http://tomforsyth1000.github.io/blog.wiki.html#%5B%5BWhy%20d...

Reply on news.ycombinator.com