Any chance to support Windows NT4 for retro gaming, its limited to DirectX3/5, OpenGL is working fine?

[MicahMoo11]

This is proof that GLSL shaders 1.20 is passable but should not as it is unstable or worse unplayable.

If people see's this test with NVEDIA. even than of how it performs might be bad for some games.

[William]

I validated that DXGL works with NT 4, but it is slow in software rendering. Still, if you have NVIDIA graphics you might have a better experience. Yes, DXGL Works, however, I did not test GLSL shaders 1.20 due to unplayable with under-powered FPS., only game that was tested was Scooby Case File #2 stone dragon with super debug mode, by removing visual quality and effects. Which from my perspective can't be done without hacks from the TLC engine. It does work with GLSL shaders 1.20. Still just use 1.10 if you really want to test. Even then you're better off with FunkyFr3sh / cnc-ddraw.
Due to Williams' credit the developer of DXGL, it does work with sample games.

As mentioned both in my correspondence in this thread and in the Downloads page, this build is experimental. The changes however have been merged into master in order to allow them to be incorporated into a future release.

I never really thought of supporting Windows NT 4.0 but this thread kind of pushed me to do so.

About that OpenGL32.dll you included in your logs, is that a version of Mesa by any chance?

[MicahMoo11]

That OpenGL32.dll is indeed from MESA the only one I found with GLSL shaders 1.20 support that might be broken. again, I only advised the 7.3 release.

I mostly TEST 200+ educational games. I've seen a performance hit of 20 fps in 70% or odd crashes in the 7.5 release it is really not advised.

[ruthan]

Hello. If you manage to get OpenGL 2.0 working on your system, try the following release:
https://dxgl.org/download/DXGL-0.5.24-win32-msvc7_1.exe

Great news thanks, how complicated is test all common DirectX Ok to OpeGL calls properly?

I mean, do you have some recommended applications / games to test, some proven, maybe some which are using some complicated calls, or maybe even something slightly outside of specs.

By the way has DXGL some inbuild FPS counter possibility? So far i only find out that Fraps up to 1.9 working on NT4, but better to use Fraps 1.8, because version 1.8 keep complaning about DirectX input, which is probably using for its hotkeys implementation.
I you find out any other FPS counter let me know, because Fraps on NT4, not even work with same games.

---
Otherwise i have checked readme, there are is:
"Many functions are stubbed out and return an error"
It would be nice to add some list and explain in 1 line what which stubbed call actually do

- Otherwise its quite typical programmers readme, in wrong way - comiling part its in the front of basic usage description for normal users, the majority of users will not compile it, im sure of that. And so part of them will read changelog, only after thay will make it run for some games / apps and the start, after would be willing to actually monitor project progress. Not underestimate peoples born-in laziness and lack of patience and time in case of trying new things:)

And Compiling part is described in detail and basic usage a is actually more vague:
"Run the installer. When the installer completes, open DXGL Config and add your program files to the config program."
Whole installing and usage, is just 1 liner Its enough to include there main game exe, or if game has multiple of them, like main.exe - some launcher / frontend and some core engine exe files? Is not needed to copy some DXGL files into games folder etc?
Some basic trouble shooting, how to create some debug report etc, would be nice too.

Maybe its better to put compiling and changelog info in separate files.

[ruthan]

I've seen a performance hit of 20 fps in 70% or odd crashes in the 7.5 release it is really not advised.

20 fps hit, does not mean much, if games are runing at lests say 100 FPS, but if they are with 7.3 running 40 FPS and 20 FPS is barely usable.
But it still depends on Which HW and setup, this message a bit cryptic.

[William]

Hello. If you manage to get OpenGL 2.0 working on your system, try the following release:
https://dxgl.org/download/DXGL-0.5.24-win32-msvc7_1.exe

Great news thanks, how complicated is test all common DirectX Ok to OpeGL calls properly?

I mean, do you have some recommended applications / games to test, some proven, maybe some which are using some complicated calls, or maybe even something slightly outside of specs.

By the way has DXGL some inbuild FPS counter possibility? So far i only find out that Fraps up to 1.9 working on NT4, but better to use Fraps 1.8, because version 1.8 keep complaning about DirectX input, which is probably using for its hotkeys implementation.
I you find out any other FPS counter let me know, because Fraps on NT4, not even work with same games.

---
Otherwise i have checked readme, there are is:
"Many functions are stubbed out and return an error"
It would be nice to add some list and explain in 1 line what which stubbed call actually do

- Otherwise its quite typical programmers readme, in wrong way - comiling part its in the front of basic usage description for normal users, the majority of users will not compile it, im sure of that. And so part of them will read changelog, only after thay will make it run for some games / apps and the start, after would be willing to actually monitor project progress. Not underestimate peoples born-in laziness and lack of patience and time in case of trying new things:)

And Compiling part is described in detail and basic usage a is actually more vague:
"Run the installer. When the installer completes, open DXGL Config and add your program files to the config program."
Whole installing and usage, is just 1 liner Its enough to include there main game exe, or if game has multiple of them, like main.exe - some launcher / frontend and some core engine exe files? Is not needed to copy some DXGL files into games folder etc?
Some basic trouble shooting, how to create some debug report etc, would be nice too.

Maybe its better to put compiling and changelog info in separate files.

The part of the Readme that says functions are stubbed out is because API emulation is still not 100%.

At this point I am trying to break free from the 0.5.x branch and focus more on the 0.6.0 rewrite. At first the same set of functions will be stubbed out, and it will at first be more unstable but work back towards feature parity.

[MicahMoo11]

I've seen a performance hit of 20 fps in 70% or odd crashes in the 7.5 release it is really not advised.

20 fps hit, does not mean much, if games are runing at lests say 100 FPS, but if they are with 7.3 running 40 FPS and 20 FPS is barely usable.
But it still depends on Which HW and setup, this message a bit cryptic.

Look, Ruthan, we have only one user in our group with an Nvidia 6 series and an FX 5 series. That user had no issues with the FX 5 series, despite what Williams claims. However, the user did admit she used hacks with the FX series for software rendering to work with DXGL. Williams, if you see this, you should reconsider adding basic support or find a way to force the Nvidia FX series to software rendering. Like I did with Mesa 7.3, I strongly advise. Version 7.5 GLSL shaders 1.20 has problems with software rendering; hardware rendering has no issues. Our community only cares about remaking educational games. My focus is on Wright Micah. It is TLC Games that you found the info here: https://github.com/FunkyFr3sh/cnc-ddraw/issues/316.

I have been working with NT 4 for over four years. I am offended that you went out of your way to say it still depends on which hardware and setup; this message is a bit cryptic. I personally only test Wine (software) and four different virtualizations. VirtualBox is my least favorite. I have to rework TLC games to accommodate those visual environments; you cannot expect people to be running AMD, NVIDIA, or pass-through graphics. Ninety percent of people only have Intel graphics or expect the game to work without any issues. If they encounter an issue, they are cryptic with me, and I need to figure out what the problem is.

This leads back to FunkyFr3sh / cnc-ddraw. Some of our members are experiencing this issue with games from the early DirectX 2 era. https://github.com/FunkyFr3sh/cnc-ddraw/issues/333. Jecub R is asserting that our lead programmer claims this is a ddraw.dll bug, which Windows 9x or ME is not recognized by NT. However, according to https://github.com/FunkyFr3sh/cnc-ddraw ... 2156176878, Jecub R has demonstrated that the developer is mistaken with this post. https://github.com/FunkyFr3sh/cnc-ddraw ... 2654854892. Even now, Jecub R does not comprehend why all 18 Barbie games encounter issues with Windows NT-based systems, including NT 4, which was created in 1996. This is causing confusion in our community, as we developed an ME extended kernel for dxwrapper, hoping that Barbie could function with ME, but discovered that this is not the case. https://github.com/FunkyFr3sh/cnc-ddraw ... 2527306699 indicates that the notorious maze bug in Detective Barbie 2: The Vacation Mystery affects dxwrapper, unlike cnc-ddraw. While this may be off-topic, our community desires for games from 9x to continue functioning with the NT architecture.

Even more concerning, Direct3D developers have ceased support for Pentium 2 & 3 processors until we tested https://dxgl.org/download/DXGL-0.5.24-win32-msvc7_1.exe. It worked with Williams. This means that aside from FunkyFr3sh / cnc-ddraw wrapper, we now have a second alternative. Yes, with Williams' 0.6.0 rewrite, it could fail at any moment. Nevertheless, our community is pleased to see that it worked, and with Direct3D 2 support on the horizon, we hope Williams will investigate the issues with Detective Barbie 2: The Vacation Mystery and the other 17 games. Even if Williams does nothing to resolve the issue and it remains unresolved, it still aligns with FunkyFr3sh's perspective, and even the developer is confused. This situation might encourage others to explore what is happening with the 18 Barbie games. I hope that if this occurs, the Pentium 2 and 3 processors will remain intact. Does this happen with dxwrapper with version 1.2.7300.25?

I apologize if I come across as upset. But Ruthan, you don't understand how hard our community works to preserve very old '90s games. They are on hold, not forgotten. The most extreme case is the 18 Barbie games, which our community is familiar with; unfortunately, we have to prioritize other games given our limited resources.

Once again, hardware and software are vastly different. I, as Wright Micah, would love to test with a GPU, but I lack the resources to do so. I am already quite busy debugging and testing 10 different operating systems, mostly Vista. Do you think it is reasonable to test GPUs?

[William]

I've seen a performance hit of 20 fps in 70% or odd crashes in the 7.5 release it is really not advised.

20 fps hit, does not mean much, if games are runing at lests say 100 FPS, but if they are with 7.3 running 40 FPS and 20 FPS is barely usable.
But it still depends on Which HW and setup, this message a bit cryptic.

Look, Ruthan, we have only one user in our group with an Nvidia 6 series and an FX 5 series. That user had no issues with the FX 5 series, despite what Williams claims. However, the user did admit she used hacks with the FX series for software rendering to work with DXGL. Williams, if you see this, you should reconsider adding basic support or find a way to force the Nvidia FX series to software rendering. Like I did with Mesa 7.3, I strongly advise. Version 7.5 GLSL shaders 1.20 has problems with software rendering; hardware rendering has no issues. Our community only cares about remaking educational games. My focus is on Wright Micah. It is TLC Games that you found the info here: https://github.com/FunkyFr3sh/cnc-ddraw/issues/316.

I have been working with NT 4 for over four years. I am offended that you went out of your way to say it still depends on which hardware and setup; this message is a bit cryptic. I personally only test Wine (software) and four different virtualizations. VirtualBox is my least favorite. I have to rework TLC games to accommodate those visual environments; you cannot expect people to be running AMD, NVIDIA, or pass-through graphics. Ninety percent of people only have Intel graphics or expect the game to work without any issues. If they encounter an issue, they are cryptic with me, and I need to figure out what the problem is.

This leads back to FunkyFr3sh / cnc-ddraw. Some of our members are experiencing this issue with games from the early DirectX 2 era. https://github.com/FunkyFr3sh/cnc-ddraw/issues/333. Jecub R is asserting that our lead programmer claims this is a ddraw.dll bug, which Windows 9x or ME is not recognized by NT. However, according to https://github.com/FunkyFr3sh/cnc-ddraw ... 2156176878, Jecub R has demonstrated that the developer is mistaken with this post. https://github.com/FunkyFr3sh/cnc-ddraw ... 2654854892. Even now, Jecub R does not comprehend why all 18 Barbie games encounter issues with Windows NT-based systems, including NT 4, which was created in 1996. This is causing confusion in our community, as we developed an ME extended kernel for dxwrapper, hoping that Barbie could function with ME, but discovered that this is not the case. https://github.com/FunkyFr3sh/cnc-ddraw ... 2527306699 indicates that the notorious maze bug in Detective Barbie 2: The Vacation Mystery affects dxwrapper, unlike cnc-ddraw. While this may be off-topic, our community desires for games from 9x to continue functioning with the NT architecture.

Even more concerning, Direct3D developers have ceased support for Pentium 2 & 3 processors until we tested https://dxgl.org/download/DXGL-0.5.24-win32-msvc7_1.exe. It worked with Williams. This means that aside from FunkyFr3sh / cnc-ddraw wrapper, we now have a second alternative. Yes, with Williams' 0.6.0 rewrite, it could fail at any moment. Nevertheless, our community is pleased to see that it worked, and with Direct3D 2 support on the horizon, we hope Williams will investigate the issues with Detective Barbie 2: The Vacation Mystery and the other 17 games. Even if Williams does nothing to resolve the issue and it remains unresolved, it still aligns with FunkyFr3sh's perspective, and even the developer is confused. This situation might encourage others to explore what is happening with the 18 Barbie games. I hope that if this occurs, the Pentium 2 and 3 processors will remain intact. Does this happen with dxwrapper with version 1.2.7300.25?

I apologize if I come across as upset. But Ruthan, you don't understand how hard our community works to preserve very old '90s games. They are on hold, not forgotten. The most extreme case is the 18 Barbie games, which our community is familiar with; unfortunately, we have to prioritize other games given our limited resources.

Once again, hardware and software are vastly different. I, as Wright Micah, would love to test with a GPU, but I lack the resources to do so. I am already quite busy debugging and testing 10 different operating systems, mostly Vista. Do you think it is reasonable to test GPUs?

As a clarification, I never said any particular GPU was incompatible with software rendering, because as the name implies it is software rendering and thus doesn't use the GPU chip. As for CPU support, the 0.6.0 rewrite is likely to retain the same degree of compatibility because the Visual C++ .NET 2003 compiler generates code compatible with all families of IA-32 processors.