4 ms·

Part of the success of directx over opengl was that very few graphics card companies seemed capable of producing a fully functional opengl driver, for the longe

by rabf 4y ago

Part of the success of directx over opengl was that very few graphics card companies seemed capable of producing a fully functional opengl driver, for the longest time Nvidia was the only option. I recall ATI and Matrox both failing in this regard despite repeated promises.

tanepiper 4y ago
Back in 1999 when the Quake source code came out, I started working on "Quake 2000" which was an improvement on the rendering pipeline of the code. I ended up getting free cards ship to me - one was a GeForce256, one was the Matrox G400 DualHead and I think the other was the ATI Rage 128 Pro. The GeForce blew the other cards performance out the water. The Matrox was particularly bad and the dual screen didn't add much and I remember maybe 2 games that supported it.
avereveard 4y ago
Fully functional opengl was not exactly the issue, or not the only one Opengl was stagnating at the time vendors started a feature wars. On opengl you can have vendor specific extensions, because it was meant for tightly integrated hardware and software. Vendors started leaning heavily on extensions to one up each other. The cronus group took ages to get up and standardize modern features By that time gl_ext checks became nightmarishly complicated and cross compatibility was further damaged by vendors lying about their actual gl_ext support, where drivers started claiming support for things the hardware could do, but using the ext causes the scene to not look right or outright crash Developers looked at that and no wonder they didn't want to take part in any of it This all beautifully exploded a few year later when compiz started taking a foothold which required this or that gl_ext and finally caused enough rage to get cronus working at bringing back under control the mess By that time ms were already at directx 9, you could use xlna to target different architectures, and it brought networking and io libraries with it making it a very convenient development environment *this is all a recollection from the late nineties early 2k and it's by now a bit blurred, it's hard to fill in the details on the specific exts Nvidia was the one producing the most but it's not like the blame is on them, Maxtor and ATI wonky support to play catch up was overall more damaging. Ms didn't need to really do much to win hearts with dx.
- qwertox 4y ago
  Plus MS was also trying to offer more than just graphics by adding audio and networking to the stack which kind of started to make the whole ecosystem attractive, even if it was painful to program against. I had my share of fun with DirectMusic.
  - mrguyorama 4y ago
    DirectInput (and later XInput) had it's faults but it's probably the only reason you can just plug random first and third party controllers into a USB port and expect everything to just work.
- moring 4y ago
  How did Microsoft solve the "extensions problem"? Did they publish standardized APIs in time so vendors wouldn't come up with any extensions? Even then, how did MS prevent them from having the driver lie about the card's features to make it look better than it is?
  - avereveard 4y ago
    Directx api, and driver certification program
  - flohofwoe 4y ago
    MS had a rigorous certification and internal testing process, new D3D versions came out quickly to support new hardware features, and through the Xbox Microsoft had more real world experience for what games actually need than the GPU vendors themselves, which probably helped to rein in some of the more bizarre ideas of the GPU designers. I don't know how the D3D design process worked in detail, but it is obvious that Microsoft had a 'guiding hand' (or maybe rather 'iron fist') to harmonize new hardware features across GPU vendors. Over time there have been a handful of 'sanctioned' extensions that had to be activated with magic fourcc codes, but those were soon integrated into the core API (IIRC hardware instancing started like this). Also, one at the time controversial decision which worked really well in hindsight was that D3D was an entirely new API in each new major version, which allowed to leave historical baggage behind quickly and keep the API clean (while still supporting those 'frozen' old D3D versions in new Windows versions).

by rabf 4y ago

tanepiper 4y ago

Back in 1999 when the Quake source code came out, I started working on "Quake 2000" which was an improvement on the rendering pipeline of the code. I ended up getting free cards ship to me - one was a GeForce256, one was the Matrox G400 DualHead and I think the other was the ATI Rage 128 Pro. The GeForce blew the other cards performance out the water. The Matrox was particularly bad and the dual screen didn't add much and I remember maybe 2 games that supported it.

avereveard 4y ago

Fully functional opengl was not exactly the issue, or not the only one Opengl was stagnating at the time vendors started a feature wars. On opengl you can have vendor specific extensions, because it was meant for tightly integrated hardware and software. Vendors started leaning heavily on extensions to one up each other. The cronus group took ages to get up and standardize modern features By that time gl_ext checks became nightmarishly complicated and cross compatibility was further damaged by vendors lying about their actual gl_ext support, where drivers started claiming support for things the hardware could do, but using the ext causes the scene to not look right or outright crash Developers looked at that and no wonder they didn't want to take part in any of it This all beautifully exploded a few year later when compiz started taking a foothold which required this or that gl_ext and finally caused enough rage to get cronus working at bringing back under control the mess By that time ms were already at directx 9, you could use xlna to target different architectures, and it brought networking and io libraries with it making it a very convenient development environment *this is all a recollection from the late nineties early 2k and it's by now a bit blurred, it's hard to fill in the details on the specific exts Nvidia was the one producing the most but it's not like the blame is on them, Maxtor and ATI wonky support to play catch up was overall more damaging. Ms didn't need to really do much to win hearts with dx.

qwertox 4y ago
Plus MS was also trying to offer more than just graphics by adding audio and networking to the stack which kind of started to make the whole ecosystem attractive, even if it was painful to program against. I had my share of fun with DirectMusic.
- mrguyorama 4y ago
  DirectInput (and later XInput) had it's faults but it's probably the only reason you can just plug random first and third party controllers into a USB port and expect everything to just work.
moring 4y ago
How did Microsoft solve the "extensions problem"? Did they publish standardized APIs in time so vendors wouldn't come up with any extensions? Even then, how did MS prevent them from having the driver lie about the card's features to make it look better than it is?
- avereveard 4y ago
  Directx api, and driver certification program
- flohofwoe 4y ago
  MS had a rigorous certification and internal testing process, new D3D versions came out quickly to support new hardware features, and through the Xbox Microsoft had more real world experience for what games actually need than the GPU vendors themselves, which probably helped to rein in some of the more bizarre ideas of the GPU designers. I don't know how the D3D design process worked in detail, but it is obvious that Microsoft had a 'guiding hand' (or maybe rather 'iron fist') to harmonize new hardware features across GPU vendors. Over time there have been a handful of 'sanctioned' extensions that had to be activated with magic fourcc codes, but those were soon integrated into the core API (IIRC hardware instancing started like this). Also, one at the time controversial decision which worked really well in hindsight was that D3D was an entirely new API in each new major version, which allowed to leave historical baggage behind quickly and keep the API clean (while still supporting those 'frozen' old D3D versions in new Windows versions).