You got a 7900 GTX Skyscraper? Nice! I'm still waiting for mine to arrive.

philscomputerlab wrote:

What game was it and what was the issue?

It wasn't a game, it was my own OpenGL testbed, as I said.
The issue was that if I ran multiple threads with their own OpenGL context, the scheduling of OpenGL commands appeared to be quite erratic, so the framerate of each thread was very jumpy.

philscomputerlab wrote:

Well you can't fix it. People have tried to fix many games and there simply are no solutions.

There's always a solution. The question is just: how much time does it take to find the problem and build a patch?

philscomputerlab wrote:

Exactly my point. You see the problem? There are only drivers so old that you can roll back to.

But your point doesn't make sense. The age of a driver says nothing about how buggy it is. Nor should it matter how many drivers you have to choose from. Ideally you only need one driver, as long as it doesn't have any bugs.
In fact, I would argue that older hardware is only more troublesome, because drivers were far less mature in the old days.

philscomputerlab wrote:

the GeForce 4 Ti being the last card to support Shadow Buffers

Erm, what are you talking about? The GF4 was actually one of the first to support shadow buffers (I assume you mean depth/stencil targets by that).
Shadow mapping has since become the standard shadowing algorithm in games, completely replacing shadow volumes, and nVidia's extensions have become standardized since Direct3D10. Now ALL cards are REQUIRED to support depth/stenciltargets for Direct3D/OpenGL compatibility.

philscomputerlab wrote:

or Nvidia and AMD changing things up with their shaders when the went from GeForce 7 to 8 and X1900 series to HD200 series?

At least with Direct3D, all hardware is required to be completely backward-compatible. So all Direct3D10 hardware is required to completely support the old DIrect3D8/9 shader models as well. And they do. All shader code I've ever written, still works on all DX11-hardware I've tested it on.

philscomputerlab wrote:

Put the GeForce 7 in a Windows 8.1 PC and try getting a GeForce driver older than ForceWare 177.

Why would you want older drivers? You generally want the latest drivers, as they have the most bugfixes.

philscomputerlab wrote:

And I've only played around with a handful of games! And most of them needed some tweaking or couldn't get completely fixed.

Some games are bugged, some drivers are bugged. Some combinations of games and drivers are bugged.
In general, things have only gotten better over the years.
All I can say is that *my* D3D-code still works fine on Windows 8.1 with a modern DX11 card and the latest drivers. There's nothing fundamentally broken with D3D (any version) in newer versions of Windows.
I recently dusted off this old thing, when I was playing around with my PowerVR PCX2 card in Windows 98SE. This is DirectX2 code, the oldest possible D3D code there is: http://bohemiq.scali.eu.org/D3DDonut.zip
Works fine on Windows 8.1 Pro x64 on my GeForce GTX460.
Ironically enough, this is what I get in Windows XP:

Conclusion: Period-correct doesn't mean a thing. Sometimes you get bugs, sometimes you don't.

It wasn't a game, it was my own OpenGL testbed, as I said.
The issue was that if I ran multiple threads with their own OpenGL context, the scheduling of OpenGL commands appeared to be quite erratic, so the framerate of each thread was very jumpy.

Sorry but we don't care about OpenGL testbed but games.

There's always a solution. The question is just: how much time does it take to find the problem and build a patch?

But you provide none:

Tomb Raider II, Far Cry, Pandora Tomorrow.

How much time would you put on fixing this vs. just playing it on an XP machine?

But your point doesn't make sense. The age of a driver says nothing about how buggy it is. Nor should it matter how many drivers you have to choose from. Ideally you only need one driver, as long as it doesn't have any bugs.
In fact, I would argue that older hardware is only more troublesome, because drivers were far less mature in the old days.

I'll explain it to you. Let's say a game breaks after a certain driver. So you want to install a driver before it broke. But because you have a modern graphics card there are no drivers available that go back that far. But according to you modern drivers are less troublesome but the opposite is true.

Erm, what are you talking about? The GF4 was actually one of the first to support shadow buffers (I assume you mean depth/stencil targets by that).
Shadow mapping has since become the standard shadowing algorithm in games, completely replacing shadow volumes, and nVidia's extensions have become standardized since Direct3D10. Now ALL cards are REQUIRED to support depth/stenciltargets for Direct3D/OpenGL compatibility.

This is the issue in Splinter Cell:

https://www.youtube.com/watch?v=nB9BTbtNyDw&l … ZHpq30_nk2HgZ9M

GeForce 3 look at the top left: http://www.nvidia.com/page/geforce3.html

Not supported on GF 6 and later.

At least with Direct3D, all hardware is required to be completely backward-compatible. So all Direct3D10 hardware is required to completely support the old DIrect3D8/9 shader models as well. And they do. All shader code I've ever written, still works on all DX11-hardware I've tested it on.

What you wrote doesn't matter to us. We care about games. Required to be backward compatible? Well clearly that requirement isn't met. And DirectX2? Have you ever tried playing games that old on Windows 8.1?

Why would you want older drivers? You generally want the latest drivers, as they have the most bugfixes.

Because as an example Pandora Tomorrow breaks with 177 and later. You are wrong about bug fixes. Drivers focus on fixing bugs to do with current issues, boost performance in current games. This often causes old games to break.

philscomputerlab wrote:

And I've only played around with a handful of games! And most of them needed some tweaking or couldn't get completely fixed.

Conclusion: Period-correct doesn't mean a thing. Sometimes you get bugs, sometimes you don't.

Conclusion is that on period correct hardware and software you get next to no bugs, whereas on modern hardware you will run into issues all the time.

Also if it doesn't mean anything then can you please get Pandora Tomorrow and Tomb Raider II working?

I have yet to find a game that is from the XP era, that doesn't work. Win9x era is a diferent story, but these games won't run on WinNT/2000/XP either.

I have found a lot of 9X games that work on XP and not on Vista/7. Some games work better yet on 2000

But I can also tell you that my NetBurst chips don't run significantly hotter than the Core chips from their reported temperatures, especially loading temperatures. In other words, TDP is still telling you what's the max dissipation, and that doesn't change meaning just because the processor is able to do a lot more with the same power budget. Idle temperatures may be lower, but that's largely insignificant unless you're right up against the limits of cooling

Not only idle temps. The average running temps while browsing, general computing or even gaming are significantly lower.
Of course when loaded full out with something like prime95 or audio/video encoding, the temps are not much different.
But the high temps and high power consumption is for a much shorter amount of time because it is done sooner.

philscomputerlab wrote:

You got a 7900 GTX Skyscraper? Nice! I'm still waiting for mine to arrive.

Even better! I have two 😀

philscomputerlab wrote:

Sorry but we don't care about OpenGL testbed but games.

Well then I don't care about your game issues either.

philscomputerlab wrote:

How much time would you put on fixing this vs. just playing it on an XP machine?

Well none, given your lack of interest and appreciation.

philscomputerlab wrote:

I'll explain it to you. Let's say a game breaks after a certain driver. So you want to install a driver before it broke.

Different videocards have different drivers, and therefore different bugs.
Things just don't work the way you think they do.

philscomputerlab wrote:

But according to you modern drivers are less troublesome but the opposite is true.

The drivers are, but some games just have broken code. Just because a game works doesn't mean it should.
The real solution is to fix the game, not to break the driver.

philscomputerlab wrote:

Not supported on GF 6 and later.

As I say, depth/stenciltargets are a standard feature on all D3D10+ hardware.
Just because some game may be broken doesn't mean that the hardware doesn't support it.
All modern games use it.

philscomputerlab wrote:

What you wrote doesn't matter to us. We care about games. Required to be backward compatible? Well clearly that requirement isn't met.

You don't know that. You assume the problem is in the drivers/hardware, while it is most probably in the game.
The example you give about shadowmapping is ridiculous anyway, as I already said.
Here's a list of all sorts of things, including the shadow mapping extensions for D3D9: http://aras-p.info/texts/D3D9GPUHacks.html
Says it works on GeForce3+, no exceptions.

philscomputerlab wrote:

You are wrong about bug fixes.

No u!
Seriously though, your logic is severely broken. You are claiming that because they fix issues with newer games, this WILL cause old games to break.
Which is nonsense obviously. Fixing a bug will not break any properly written code. Fixing a bug may only expose code that was already broken anyway.
You know Intel and its bad reputation with drivers? Well, every single time my own code ran into problems on Intel drivers, the drivers were actually 100% correct! The code I had written had just implicitly assumed certain things that were not necessarily supported for a given baseline of D3D or OpenGL. Some code should not have worked on any SM2.0 device, yet it worked fine on my Radeon 9600XT, despite the D3D specs saying otherwise. The feature I used was actually an SM3.0 feature, which apparently was silently supported by the ATi drivers anyway, even on SM2.0.

philscomputerlab wrote:

Conclusion is that on period correct hardware and software you get next to no bugs, whereas on modern hardware you will run into issues all the time.

No, that conclusion is completely false, since Windows XP would be 'period correct', as you claim... yet it was the one with the bugs, where Windows 8.1 was not.
This was the only combination where I saw the bug though. I've tested it on a wide range of hardware and software, and they all worked fine.

philscomputerlab wrote:

Also if it doesn't mean anything then can you please get Pandora Tomorrow and Tomb Raider II working?

What is wrong with Tomb Raider II anyway? I recently bought the whole Tomb Raider collection on Steam, including TRII, and it seems to work.

Well then I don't care about your game issues either.

You're on the wrong website. Look up what VOGONS stands for. You keep applying YOUR situation to everyone else which is very narrow minded, selfish and ignorant.

Well none, given your lack of interest and appreciation.

Not interested in you fixing anything but I want you to put a hourly and dollar figure on the amount of work that would need to be invested to patch an old game or a modern driver. You yourself said that there is a solution for everything and that it's a matter of resources. Well there goes your entire argument of "they should just fix the game" out the windows.

philscomputerlab wrote:

I'll explain it to you. Let's say a game breaks after a certain driver. So you want to install a driver before it broke.

The drivers are, but some games just have broken code. Just because a game works doesn't mean it should. The real solution is to fix the game, not to break the driver.

Again a very naive and totally removed from reality view. Your theory might hold true if your game is watching a triangle spin and nothing more but games push the boundaries, drive progress and take short cuts to optimize.

As I say, depth/stenciltargets are a standard feature on all D3D10+ hardware.
Just because some game may be broken doesn't mean that the hardware doesn't support it.
All modern games use it.

Again an assumption which is proven otherwise by the game not working.

You don't know that. You assume the problem is in the drivers/hardware, while it is most probably in the game.

And you assume it's the game. But you forget to realise that the only variable that changes is the driver. The game and the hardware stay the same. So going up a driver version the game suddenly doesn't work. And you blame the game. Totally makes no sense.

Says it works on GeForce3+, no exceptions.

Again living in fantasy world. Like a child: "Well that's what it says so it must be true".

You are claiming that because they fix issues with newer games, this WILL cause old games to break.

Not just claiming, it's actually true! Remember your point about resources and people working on period relevant issues? Well that's exactly what is happening here. The focus is on fixing issues and improving performance on games such as Battle Field 4 and not Battle Field 2142.

Fixing a bug will not break any properly written code.

A programmers naive and unrealistic view of things. Chasing the perfect code. What you don't get is that the programmer cannot foresee the future.

Y

ou know Intel and its bad reputation with drivers?

Quite the opposite. Intel driver give me less issues than any other vendor.

The code I had written had just implicitly assumed certain things that were not necessarily supported for a given baseline of D3D or OpenGL. Some code should not have worked on any SM2.0 device, yet it worked fine on my Radeon 9600XT, despite the D3D specs saying otherwise. The feature I used was actually an SM3.0 feature, which apparently was silently supported by the ATi drivers anyway, even on SM2.0.

Not sure what you're trying to prove here. That you produced "broken code" or that programs are written by humans that go by the knowledge they have and have access to at a give point in time?

No, that conclusion is completely false, since Windows XP would be 'period correct', as you claim... yet it was the one with the bugs, where Windows 8.1 was not.

So to summarise, the few games with issues I mentioned: Splinter Cell, Pandora Tomorrow, Far Cry, F.E.A.R. all have issues in 8.1 but run flawless on period correct hardware. But you still say that XP is broken? Are you for real?

At risk of takings this already off topic post further off topic:

I recently dusted off this old thing, when I was playing around with my PowerVR PCX2 card in Windows 98SE. This is DirectX2 code, the oldest possible D3D code there is: http://bohemiq.scali.eu.org/D3DDonut.zip
Works fine on Windows 8.1 Pro x64 on my GeForce GTX460.

That program ran surprisingly well on my 486 with Windows 2000 and S3 ViRGE (but no textures)
~14 FPS

I don't have an XP machine handy to test right now

smeezekitty wrote:

That program ran surprisingly well on my 486 with Windows 2000 and S3 ViRGE (but no textures)

It was written for a PowerVR PCX2 card with 4 MB memory (I actually made the donut very highpoly to try and push the PowerVR to the limits. I used a Pentium Pro 200 to drive it. The 486 is probably the bottleneck, because it has to transform, light and send all these quads over the bus).
I tried running it on my Matrox Mystique card with 2 MB, and I think it ran out of memory on the texture and zbuffer.
It might work with a smaller texture size, or perhaps with a different texture format and/or smaller window size.
It also won't run on early Voodoo cards because I use windowed mode.
I could change those two things, to make it more compatible.
Other than that, it should run on anything really, since it's D3D1-code. Windows 95 and up will support that, and nearly all 3d cards will have some form of D3D driver.

philscomputerlab wrote:

You're on the wrong website. Look up what VOGONS stands for. You keep applying YOUR situation to everyone else which is very narrow minded, selfish and ignorant.

Yea whatever. I came here mostly for vintage MS-DOS/DOSBox stuff, since I develop for real IBM PCs, and I've been debugging the DOSBox code a bit here and there.
I don't consider anything Windows/3d-accelerated 'retro/vintage', to stay with the topic here.
However, I was going to share some of my knowledge and experience of having developed for Windows/3d-accelerators with D3D, OpenGL and proprietary APIs for some 20 years.

philscomputerlab wrote:

You yourself said that there is a solution for everything and that it's a matter of resources. Well there goes your entire argument of "they should just fix the game" out the windows.

No, because as I said, drivers are a moving target. Old games are not.
Besides, as I already said, the games are generally easier to fix than the drivers.

philscomputerlab wrote:

Again a very naive and totally removed from reality view. Your theory might hold true if your game is watching a triangle spin and nothing more but games push the boundaries, drive progress and take short cuts to optimize.

I've actually written tons of 3d applications like that. I doubt you have.
So who is calling who naive?

philscomputerlab wrote:

Again an assumption which is proven otherwise by the game not working.

No, just a case of your broken logic. You see two events, and conclude that correllation implies causation. Which is a fallacy: http://en.wikipedia.org/wiki/Correlation_does … imply_causation

philscomputerlab wrote:

What you don't get is that the programmer cannot foresee the future.

What you don't get is that APIs and OSes have very strict specifications, and are not subject to change for a given version.
Which is why even D3D1-code will still run on Windows 8.1 and modern D3D11 cards, even though they were developed almost 20 years after D3D1 first hit the market.
Because D3D1 today is still the same as it was in 1996.
You don't NEED to foresee the future. Don't you get that? Heck, the whole reason why we're still using these crappy x86 CPUs and Windows today is exactly because of this backward-compatibility. People keep using x86 CPUs and Windows because these new machines can still run their old applications. It's the main reason why none of the alternative CPU-architectures and OSes ever gained marketshare on the desktop.
All because programmers did not have to foresee the future. Intel and Microsoft made sure the past was supported.

Scali wrote:

Besides, as I already said, the games are generally easier to fix than the drivers.

How so with companies shutting down, documentation getting lost, programmers passed away or moved on? You might think as a programmer again , in the sense that from a programming point of view it is easier to fix the code of the game than the driver but that is naive because it's not about the code, it's about the people, time, knowledge and resources to get someone to sit down and actually fix it.

No, just a case of your broken logic. You see two events, and conclude that correllation implies causation.

You did actually. With Far Cry you straight away called it PEBKAC and "well I didn't have any issues", conclusion all sorts of assumptions. I bet you didn't even know about the issue until I mentioned it. Well now you know, see if you can find a solution. With Pandora Tomorrow you can change the hardware, the driver and the OS. The OS will break it. The hardware will break it and the driver will break it. All three have to be period correct within a narrow window. So it's a complex issue but YOU are the one that says it's the game that is broken which is clearly wrong.

1What you don't get is that APIs and OSes have very strict specifications, and are not subject to change for a given version.
2Which is why even D3D1-code will still run on Windows 8.1 and modern D3D11 cards, even though they were developed almost 20 years after D3D1 first hit the market.

Firstly old D3D games not working in Windows 8.1 proves all of this nonsense. GOG.com had a lot of trouble with early D3D games even newer version such as 6 and 7. Secondly games use a lot more than D3D. There are issues with copy protection, sound, other libraries, hardware not compatible (noticed that ISA slots have disappeared, programming to spec didn't fix this one). So again please don't apply your limited experiences to the entire catalogue of computer games. The massive number of games that do not work on modern hardware makes mince meat out of your arguments.

philscomputerlab wrote:

How so with companies shutting down, documentation getting lost, programmers passed away or moved on?

It's called 'reverse engineering'. What did you think we were doing to make sure DOSBox works with as many games and demos as possible?
We don't get in touch with the original programmers and we certainly don't get access to the source code.
We just study the programs to see what they do, and how the system responds to that.

philscomputerlab wrote:

You did actually. With Far Cry you straight away called it PEBKAC

No, I asked if you were sure it wasn't PEBKAC, and if the issues are present on different brands of videocards/drivers. Which you still haven't answered.

philscomputerlab wrote:

Firstly old D3D games not working in Windows 8.1 proves all of this nonsense.

No it doesn't. There's tons of apps that do all sorts of things that are outside the specs of Windows/D3D/etc.
Rule #1 for a programmer: working code is not bugfree code.

philscomputerlab wrote:

noticed that ISA slots have disappeared, programming to spec didn't fix this one)

That's because ISA slots have nothing to do with programming. To a program, it doesn't matter whether a VGA card or a Sound Blaster is ISA, PCI, or whatever. As long as it is compatible, software will just work.
With Windows it matters even less, as all hardware is abstracted anyway, and programs do not interact directly with hardware. They only interact with drivers, which have been designed against a well-specified interface specification.

philscomputerlab wrote:

The massive number of games that do now work on modern hardware makes mince meat out of your arguments.

No they don't. You just don't understand cause and effect properly.

Heck, the whole reason why we're still using these crappy x86 CPUs and Windows today is exactly because of this backward-compatibility. People keep using x86 CPUs and Windows because these new machines can still run their old applications.

What is wrong with x86?

Remember Apple moved from PPC TO x86

The massive number of games that do now work on modern hardware makes mince meat out of your arguments.

Massive seems like a stretch. They are a minority really

It's called 'reverse engineering'. What did you think we were doing to make sure DOSBox works with as many games and demos as possible?
We don't get in touch with the original programmers and we certainly don't get access to the source code.
We just study the programs to see what they do, and how the system responds to that.

And that's easier than playing it period correct?

No, I asked if you were sure it wasn't PEBKAC, and if the issues are present on different brands of videocards/drivers. Which you still haven't answered.

Wow splitting hairs. And I did answer. Check the GOG.com and Steam forums for more detail. Or try it on your machine for starters.

No it doesn't. There's tons of apps that do all sorts of things that are outside the specs of Windows/D3D/etc.
Rule #1 for a programmer: working code is not bugfree code.

Yes remember me saying how games push the boundaries, optimise, take shortcuts? This isn't going away. You logic is like talking about drunk driving and saying, well people should be drinking in the first place. Well newsflash that's not how the world and people work. Writing a bug free game isn't going to happen, so let's deal with the realities and not what you think should happen in a perfect programmers world.

That's because ISA slots have nothing to do with programming. To a program, it doesn't matter whether a VGA card or a Sound Blaster is ISA, PCI, or whatever. As long as it is compatible, software will just work.
With Windows it matters even less, as all hardware is abstracted anyway, and programs do not interact directly with hardware. They only interact with drivers, which have been designed against a well-specified interface specification.

We are talking about games. Games run on a computer. Computer = hardware. Hardware changes and period correct means using hardware and software of that period. Simple.

No they don't. You just don't understand cause and effect properly.

Anyone's understanding is not going to make these games run on Windows 8.1 any better. So not sure what your point is. Nothing you say is helping in making more games run. Using period correct hardware and software solves this problem. I don't know what the difficulty is.

smeezekitty wrote:

Massive seems like a stretch. They are a minority really

Remember we are talking about games that "just work". No emulators, no wrappers, no cracks. Moving from DOS to Windows XP made a ton of software inoperable. Now we have emulation to deal with this but asking everyone to rewrite their old programs would have been absurd. In 8.1 I find that with most games I have tried lately I had to fix something. That's where some of us who prefer to use period correct systems are coming from.

leileilol wrote:

Just try Saints Row 2, 2009 PC port of a 2008 console game, on "period correct" 2009 hardware and software and then claim it runs the best.

Well does it run fine on a modern PC? 2009 is fairly recent. If a game runs flawless on Windows 8.1 of course it would be silly to play on an old computer.

leileilol wrote:

(besides you couldn't run my 2d test mod in q3 and i've implemented the correct filter method anyway while trying to wait on you not running quake3.exe +set fs_game test, don't claim to be on a high horse knowitall when you can't start a simple mod)

I wanted to but I'm busy and lots of people ask to do stuff. It's not too much to ask that you at least prepare things on your end so that it's ready to go. I don't even have Quake 3, just the demo. You also never responded and could have said what you're saying now. Also if it means so much to you just get a Voodoo card yourself.

Just try Saints Row 2, 2009 PC port of a 2008 console game, on "period correct" 2009 hardware and software and then claim it runs the best.

do it

(besides you couldn't run my 2d test mod in q3 and i've implemented the correct filter method anyway while trying to wait on you not running quake3.exe +set fs_game test, don't claim to be on a high horse knowitall when you can't start a simple mod)

smeezekitty wrote:

What is wrong with x86?

What isn't? Even back in 1978 it was already quite an outdated architecture. Its direct competitor, the Motorola 68000 was far more modern and powerful (much closer to the 80386).
To make matters worse, the PC used the 8088 instead of the 8086. The 8-bit bus made the CPU completely bottlenecked, making this '16-bit' CPU at 4.77 MHz perform barely any faster than the good old 6502 at 1 MHz.

And over time they just kept extending it and extending it, making the instructionset a complete mess, and all these CPU modes it has to support etc.

smeezekitty wrote:

Remember Apple moved from PPC TO x86

Do you also remember when they first moved to PPC?
At the time the PPC was far superior to any x86.
They only moved to x86 because over time, Intel just caught up with everything through brute force. Motorola was no longer interested in developing the PPC further. So Apple had to move to IBM, but they weren't really interested in making CPUs for the market that Apple wanted to target either. So Apple was basically stuck with the G5 at some point... no more CPU updates.
So, eventually they had to move to x86, because x86 had a huge marketshare, and Intel spends billions of dollars on CPU updates each year, and x86 had already overtaken the PPC anyway.

My understanding (someone please correct me if I'm wrong) is that there was a complete paradigm shift between the DirectX 9 and DirectX 10 generations of GPUs. DirectX 9 GPUs still have the old fixed function graphics pipeline of earlier generations, as well as programmable pixel and vertex shaders. With DirectX 10, someone (Microsoft? Nvidia? Who?) decided that we would get rid of the fixed function pipeline and do everything in shaders. This is why DirectX9 is backwards compatible with earlier versions, but DirectX 10+ stands apart.

In order for DirectX 9 and older games to keep working on DirectX 10+ hardware, the drivers need to emulate the old fixed function pipeline in shaders. As we all know, however, driver development has always been focused on getting the latest games and benchmarks to run well - to hell with everything else. Players of pre-DirectX 10 games are now at the mercy of the driver writers, who have very little incentive to make sure that all the old fixed function code still works.

My experience is that DirectX 9 GPUs can generally be made to work with games from the DirectX 8, 7, 6, and 5 eras, while DirectX 10 GPUs are a complete mess, sometimes even with DirectX 9 games (this has already been pointed out). This would seem to support the conclusions I drew above, and would lend credence to the arguments made by Phil and others.

maximus wrote:

My understanding (someone please correct me if I'm wrong) is that there was a complete paradigm shift between the DirectX 9 and DirectX 10 generations of GPUs. DirectX 9 GPUs still have the old fixed function graphics pipeline of earlier generations, as well as programmable pixel and vertex shaders. With DirectX 10, someone (Microsoft? Nvidia? Who?) decided that we would get rid of the fixed function pipeline and do everything in shaders. This is why DirectX9 is backwards compatible with earlier versions, but DirectX 10+ stands apart.

No. The paradigm shift you mention was actually already in DX9. The Radeon 9700 did not have any fixed-function pipeline, nor did it have a dedicated integer pipeline. It did all shading, fixed-function, DX8.x integer, and DX9 on its floating point pipelines.

The paradigm shift in DX10 would be unified shaders.
Neither paradigm shift really has any effect on compatibility, since D3D is a hardware abstraction layer. The application doesn't 'see' the hardware, so whether there actually is a real fixed function pipeline, or whether the driver just pre-loads some vertex/pixelshaders that are equivalent to the given fixed function pipeline makes absolutely no difference.
Likewise, performing integer operations with a floating point unit, provided the mantissa has enough precision, makes no difference either. In fact, in the Pentium CPU Intel did just that: there is no integer circuitry for division. For a div/idiv instruction, the CPU will forward the operation to the FPU portion.

You're very "textbook correct" scali, but I think you and Phil are talking at cross-purposes.

To summarise: Usually if a visual effect starts to look incorrect between one point in time and another, it's because the driver vendor "fixed" that particular code path, while the game is still written with the "broken" driver in mind. If the change occurs while the game vendor is still around and supporting the game, they'll probably fix their game's code, and all is right in the world.

However sometimes such a driver bug will go un-fixed until well after the game vendor stops supporting the game. This leaves you up shit creek without a paddle until either some third party steps up and offers a patch for the game, or the driver vendor puts a game-specific fix in the driver.

Here's what I see:

What Phil's saying is that in lieu of a patch for the game, the way to get the game looking correct is to use an older driver, and that was pretty common practice in the early noughties. A gotcha to this is that the "working" driver might be so old, that it's not available on the current OS, and/or doesn't work with the latest hardware. So in lieu of a patch, the most practical and immediate way to enjoy the game "as it was intended to be" is on a period-correct system. And he's right.

What scali's saying is that it's not 100% totally impossible to make these games look correct on modern systems with current drivers and hardware, because of how APIs and such are designed to work. Things can be reverse-engineered, and fixes can be made, it's just a matter of finding people with all three of skill, time, and inclination. There's no intrinsic reason that these games "only work correctly" on XP, just a series of unfortunate events. He/she is also right.

So kiss and make up already!

Scali trying to calm things down here again.

I think you are very passionate about programming and pointing out that had programmers followed the specifications closer there wouldn't be issues. But I'm coming from the perspective of a Gamer who just notices that some games don't work properly and that playing it on an old Computer is something that works well for me and others.

I document many of these issues and try to find workarounds, like in F.E.A.R. if you disable input devices the game won't slow down (Some sort of USB polling bug). But this also means that your shortcut buttons and other things don't work any more.