That bug also exists in Max Payne, which uses the same engine.
https://www.pcgamingwiki.com/wiki/Max_Payne

Here's a fix based on the one that luigoalma made for that game.

Yeeesss, it works! Thank you so much, I can finally watch that demo again without having to resort to YouTube. 😀

Funny part: The 6900 XT's fans didn't even bother spinning at all until the "Matrix" parts of the demo started. 😉

Love it!

Edit: And that was with 8xEQ MSAA+SSTAA and 16xAF in 2048×1536 (for the correct aspect ratio).

I can run 99 and 2000 in 1920x1080 without problem but not 2001 SE. No errors or anything, I simply don't get resolutions higher than 1280x1024. Different compatibility modes (or none at all) don't make a difference. What am I missing?

Sorry if I write on this old thread but I'd like to understand how some things doesn't work just like in Win 7 used to. I'm using a WDDM1.1 GMA3600 Dx9.0c gpu on Win 8.1 and the 3DMark2000 different cases are these:

1) No compatibility options- of course memory check problem doesn't start
2) Windows Compatibility Tool - I enabled the GlobalMemory flag and it start but the frame rate is very low (like 20fps in the first scene low quality)
3) Without compatibility flags if I use a ddraw wrapper like ddrawcompat I get a decent speed of 2400 points but still lower than running it on Win 7 (it should be around 3300 points). Also another problem is that T&L seems to have problem cause the original Win 7 polygon test was around 11Mt/s while getting a 2Mt/s with the wrapper probably causing the lower speed, D3D-sw mode is even lower, Pentium III (SSE) mode is a bit higher (3,5Mt/s) but graphical problems, missing water etc and still much slower than it should be.

3DMark2000 in Win 7 wasn't running probably also as it could considering 3DMark2001SE results in 4200 points with 20Mt/s polygons test with Pure T&L (while in Win 8.1 around 400 points less but this at least similar to the Win 7 original score).
I tried the directdraw and maxwindow flag in Compatibility Tool but it can't get close to the wrapper results, like isolating the rendering from the GUI I suppose with a real fullscreen mode. Any hints for the Compatibility tool?
The 3DMark2001SE as said seems like more working in Win8.1, the final 20Mt/s polygons score is more what to be expected as I suppose the T&L here is working while in 3DMark2000 feel like it's not.

Update: some new results, using the DxPrimaryEmulation flag into the Compatibility Tool the 20fps limit seems to get surpassed and it get the almost same polygons/s value of the Win 7 32bit test. The final frame rate anyway is still quite low almost 2/3 of the one I get with ddrawcompat (that seems to get higher fps but slower polygons/s). I try adding other compatibility fix.

386SX wrote on 2022-03-25, 11:16:

Sorry if I write on this old thread but I'd like to understand how some things doesn't work just like in Win 7 used to. I'm usin […]
Show full quote

Sorry if I write on this old thread but I'd like to understand how some things doesn't work just like in Win 7 used to. I'm using a WDDM1.1 GMA3600 Dx9.0c gpu on Win 8.1 and the 3DMark2000 different cases are these:

1) No compatibility options- of course memory check problem doesn't start
2) Windows Compatibility Tool - I enabled the GlobalMemory flag and it start but the frame rate is very low (like 20fps in the first scene low quality)
3) Without compatibility flags if I use a ddraw wrapper like ddrawcompat I get a decent speed of 2400 points but still lower than running it on Win 7 (it should be around 3300 points). Also another problem is that T&L seems to have problem cause the original Win 7 polygon test was around 11Mt/s while getting a 2Mt/s with the wrapper probably causing the lower speed, D3D-sw mode is even lower, Pentium III (SSE) mode is a bit higher (3,5Mt/s) but graphical problems, missing water etc and still much slower than it should be.

3DMark2000 in Win 7 wasn't running probably also as it could considering 3DMark2001SE results in 4200 points with 20Mt/s polygons test with Pure T&L (while in Win 8.1 around 400 points less but this at least similar to the Win 7 original score).
I tried the directdraw and maxwindow flag in Compatibility Tool but it can't get close to the wrapper results, like isolating the rendering from the GUI I suppose with a real fullscreen mode. Any hints for the Compatibility tool?
The 3DMark2001SE as said seems like more working in Win8.1, the final 20Mt/s polygons score is more what to be expected as I suppose the T&L here is working while in 3DMark2000 feel like it's not.

Update: some new results, using the DxPrimaryEmulation flag into the Compatibility Tool the 20fps limit seems to get surpassed and it get the almost same polygons/s value of the Win 7 32bit test. The final frame rate anyway is still quite low almost 2/3 of the one I get with ddrawcompat (that seems to get higher fps but slower polygons/s). I try adding other compatibility fix.

I am not sure if that can be the case, but the WDDM version can be an issue. For instance using WDDM 2 in Windows 11 gave bsods which were mostly fixed with WDDM 3.0. Also it's just not drivers, Windows 8.1 legacy DirectX is poor as what I have heard in forums. How about trying DxWnd?

BEEN_Nath_58 wrote on 2022-03-25, 14:24:

386SX wrote on 2022-03-25, 11:16:

Sorry if I write on this old thread but I'd like to understand how some things doesn't work just like in Win 7 used to. I'm usin […]
Show full quote

Sorry if I write on this old thread but I'd like to understand how some things doesn't work just like in Win 7 used to. I'm using a WDDM1.1 GMA3600 Dx9.0c gpu on Win 8.1 and the 3DMark2000 different cases are these:

1) No compatibility options- of course memory check problem doesn't start
2) Windows Compatibility Tool - I enabled the GlobalMemory flag and it start but the frame rate is very low (like 20fps in the first scene low quality)
3) Without compatibility flags if I use a ddraw wrapper like ddrawcompat I get a decent speed of 2400 points but still lower than running it on Win 7 (it should be around 3300 points). Also another problem is that T&L seems to have problem cause the original Win 7 polygon test was around 11Mt/s while getting a 2Mt/s with the wrapper probably causing the lower speed, D3D-sw mode is even lower, Pentium III (SSE) mode is a bit higher (3,5Mt/s) but graphical problems, missing water etc and still much slower than it should be.

3DMark2000 in Win 7 wasn't running probably also as it could considering 3DMark2001SE results in 4200 points with 20Mt/s polygons test with Pure T&L (while in Win 8.1 around 400 points less but this at least similar to the Win 7 original score).
I tried the directdraw and maxwindow flag in Compatibility Tool but it can't get close to the wrapper results, like isolating the rendering from the GUI I suppose with a real fullscreen mode. Any hints for the Compatibility tool?
The 3DMark2001SE as said seems like more working in Win8.1, the final 20Mt/s polygons score is more what to be expected as I suppose the T&L here is working while in 3DMark2000 feel like it's not.

Update: some new results, using the DxPrimaryEmulation flag into the Compatibility Tool the 20fps limit seems to get surpassed and it get the almost same polygons/s value of the Win 7 32bit test. The final frame rate anyway is still quite low almost 2/3 of the one I get with ddrawcompat (that seems to get higher fps but slower polygons/s). I try adding other compatibility fix.

I am not sure if that can be the case, but the WDDM version can be an issue. For instance using WDDM 2 in Windows 11 gave bsods which were mostly fixed with WDDM 3.0. Also it's just not drivers, Windows 8.1 legacy DirectX is poor as what I have heard in forums. How about trying DxWnd?

I have to try that. But the Win 10 compatibility tool that's compatible with Win 8.1 seems to have quite a lot of fix and I suppose Win 7 (that indeed use the same WDDM 1.1 gpu driver) must probably use itself some compatibilty tricks but I'm not sure which exactly or how it decide to run old games beside the usual o.s. flag option. It's interesting anyway that Directx8.1 and above games seem to run more or less similar, just a bit slower on Win 8.x but looking at the synthetic benchmarks the values are similar while Directx7 games requires more work. I'm trying to find a flag to force fullscreen native only rendering or something like it.

386SX wrote on 2022-03-25, 15:10:

BEEN_Nath_58 wrote on 2022-03-25, 14:24:

386SX wrote on 2022-03-25, 11:16:

Sorry if I write on this old thread but I'd like to understand how some things doesn't work just like in Win 7 used to. I'm usin […]
Show full quote

Sorry if I write on this old thread but I'd like to understand how some things doesn't work just like in Win 7 used to. I'm using a WDDM1.1 GMA3600 Dx9.0c gpu on Win 8.1 and the 3DMark2000 different cases are these:

1) No compatibility options- of course memory check problem doesn't start
2) Windows Compatibility Tool - I enabled the GlobalMemory flag and it start but the frame rate is very low (like 20fps in the first scene low quality)
3) Without compatibility flags if I use a ddraw wrapper like ddrawcompat I get a decent speed of 2400 points but still lower than running it on Win 7 (it should be around 3300 points). Also another problem is that T&L seems to have problem cause the original Win 7 polygon test was around 11Mt/s while getting a 2Mt/s with the wrapper probably causing the lower speed, D3D-sw mode is even lower, Pentium III (SSE) mode is a bit higher (3,5Mt/s) but graphical problems, missing water etc and still much slower than it should be.

3DMark2000 in Win 7 wasn't running probably also as it could considering 3DMark2001SE results in 4200 points with 20Mt/s polygons test with Pure T&L (while in Win 8.1 around 400 points less but this at least similar to the Win 7 original score).
I tried the directdraw and maxwindow flag in Compatibility Tool but it can't get close to the wrapper results, like isolating the rendering from the GUI I suppose with a real fullscreen mode. Any hints for the Compatibility tool?
The 3DMark2001SE as said seems like more working in Win8.1, the final 20Mt/s polygons score is more what to be expected as I suppose the T&L here is working while in 3DMark2000 feel like it's not.

Update: some new results, using the DxPrimaryEmulation flag into the Compatibility Tool the 20fps limit seems to get surpassed and it get the almost same polygons/s value of the Win 7 32bit test. The final frame rate anyway is still quite low almost 2/3 of the one I get with ddrawcompat (that seems to get higher fps but slower polygons/s). I try adding other compatibility fix.

I am not sure if that can be the case, but the WDDM version can be an issue. For instance using WDDM 2 in Windows 11 gave bsods which were mostly fixed with WDDM 3.0. Also it's just not drivers, Windows 8.1 legacy DirectX is poor as what I have heard in forums. How about trying DxWnd?

I have to try that. But the Win 10 compatibility tool that's compatible with Win 8.1 seems to have quite a lot of fix and I suppose Win 7 (that indeed use the same WDDM 1.1 gpu driver) must probably use itself some compatibilty tricks but I'm not sure which exactly or how it decide to run old games beside the usual o.s. flag option. It's interesting anyway that Directx8.1 and above games seem to run more or less similar, just a bit slower on Win 8.x but looking at the synthetic benchmarks the values are similar while Directx7 games requires more work. I'm trying to find a flag to force fullscreen native only rendering or something like it.

On the nvidia side of things, each game has a separate profile. Otherwise no game would work. Intel would also have it, albeit a smaller list this inhibiting more issues.

The important thing about DxWnd is that most of its exclusive features and most tweaks/fixes are in windowed mode. Keeping that in mind, I recommend you start the journey of fixing issues.

I don't think WDDM has anything to do with anything.
If any it can just happen that older drivers are unlucky with forward compatibility.

The problem here is probably that the GMA3600 is in fact a rebranded SGX545, which is in turn has the most vile driver that has ever seen the x86 world.

mirh wrote on 2022-03-28, 01:07:

I don't think WDDM has anything to do with anything.
If any it can just happen that older drivers are unlucky with forward compatibility.

The problem here is probably that the GMA3600 is in fact a rebranded SGX545, which is in turn has the most vile driver that has ever seen the x86 world.

And that is what make it interesting. Like the old early video chip accelerators that became interesting only lately to test but they were almost no usable anywhere in their times. The driver of this iGPU was developed only for Win 7 32bit in mind (probably Win 7 Starter lighter version) and I suppose the effort of writing newer or more optimized drivers for longer time I imagine required more efforts than benefits.

From my tests it seems like Win 8.1 32bit while it works suffer from the lack of the WDDM1.3 drivers required to be fully compatible with the GUI but is also the o.s. that after Win 7 imho was not really retro gaming oriented.
But even in Win 7 the GPU can't do miracles and the Directx9 benchmarks show its speed (in the best case 800 points in 3DMark05, 4200 points in 3DMark2001SE, 3200 points in 3DMark2000 but this cause the o.s. wasn't imho designed for a perfect Directx7 games performance not even Win 7).
The iGPU watts usage explain a lot imho. From a idle scenario to a full 3D stressed one there're only few watts of difference. The GPU is really integrated internally in the SoC and probably much less power demanding than the already light CPU for a total system demand of 14W to 18W at the wall plug when using a DC-DC PicoPSU and without dvd reader and using a SSD. Also the SGX545 variant I've got is the 400Mhz version when there was also the 600Mhz one that would be interesting to test.

mirh wrote on 2022-03-28, 01:07:

I don't think WDDM has anything to do with anything.
If any it can just happen that older drivers are unlucky with forward compatibility.

The problem here is probably that the GMA3600 is in fact a rebranded SGX545, which is in turn has the most vile driver that has ever seen the x86 world.

Regarding WDDM what I assume is certain functions aren't being performed on the new architecture drivers. The drivers WDDM won't mean much, but I have cases where a WDDM 1 driver would not work properly on Win8.1 but working on WinXP.

Regarding Intel, it's true they are bad with forward compatibility. I didn't know the GPU was a rebranded PowerGL card. How good it would have been if SGL was still there, the card would be respected more..

SGL stopped being supported by Kyro, GMA wouldn't want do anything more for it.

leileilol wrote on 2022-03-28, 09:34:

SGL stopped being supported by Kyro, GMA wouldn't want do anything more for it.

I mean it would have been cool if SGL support was still there. A probability of getting a wrapper could have been there.

Regarding the PowerVR part I suppose the original idea was to have a new generation type of GPU without using the old GMA XP oriented cores of the early Atom SoC/chipsets but still keeping power demand as low as possible to integrate it @32nm into a single SoC and at that time I imagine the idea of using the smartphone theorically quite capable designs/specs wasn't bad. I had different smartphones using ARM based SoC using the SGX535 GPU I can imagine much similar to this one even if I think much higher clocked and probably adapted to the Win environment.

But on low resolution droid o.s. not usually much upgraded mobile linux system that used not often many OpenGL ES features, that design translated on a desktop/netbook scenario IMHO might not have been simple also cause the WDDM changing feature models, the much different Win 8.x GUIs, the x86/x64 support problem. The CPU was a 64bit one while the GPU was mostly used in 32bit ARMv7 SoC and it seems to have a sense that only 32bit Win 7 drivers were released forcing also the CPU to use a 32bit o.s. to make use of the GPU itself.
And if GPU-Z see it correctly it might have sense that with 4 unified shaders and probably much complex driver/dependencies (as some FAQ pages I think explained) expectations were probably higher than the possible ones. So the gpu would totally be capable of running retrogames but the o.s. supported wasn't already much retrogaming oriented and at the same time the gpu isn't fast enough to run "modern" Directx9 games like Far Cry or GTA IV beside around the low res 15-20fps average values. There was I think a XP beta driver but I never tested it.

Your point can also include DirectDraw, the thing causing all this because it'll behave based on HW and drivers.

BEEN_Nath_58 wrote on 2022-03-28, 12:33:

Your point can also include DirectDraw, the thing causing all this because it'll behave based on HW and drivers.

Indeed on Win 8.x using a sort of mini ddraw dll can improve some of the speed problems of older games (usually up to Directx7) but still there's the feeling the whole o.s. demand both a more powerful cpu and a more powerful/compatible gpu to even run the GUI as supposed to. I remember having even tested the FX 5200 (PCI) on this o.s. and with the only latest WDDM 1.0 driver (forced to install) it worked and quite well but the GUI was quite slow and slower than the WDDM 1.1 driver of this iGPU while both Directx9 GPU. But the OpenGL part of the FX 5200 was faster in games where they ran compared to the on board one. So I think the desktop applications/GUI might need at least a WDDM 1.2 (better 1.3) driver beside even older are compatible but demand more cpu work I think to mantain a good frame rate since Metro Win 8 GUI introduced this sort of logic.

The best way to test this iGPU anyway would be using Win 7 Starter 32bit with its limitations was lighter and would permit the GPU to have less things running in background. DXVA acceleration instead was good with latest drivers, 1080p H264 even 60fps test videos can run without problems and @ 20-30% CPU usage more or less.

A good thing that Microsoft did was include a better class driver basicdisplay.sys with Windows 10. This driver can even run your DirectX title without a manufacturer driver. The one used earlier VGA.SYS while the MBDA had a larger common denominator set, but I am not sure how that works out on very old HW. Your HW could be a good test on it, like testing a DX11 application, you'll need Windows 10 though. And on my personal experience, Microsoft went downhill with compatibility with Windows 8/8.1, as they did from Windows XP to Vista/7, and then lower from 8/8.1 to 10, but then there came a sudden uprise in the compatibility of Windows 10, even surpassing Windows XP/7 in many cases. DirectDraw was controlled well, while some manufacturers like new Intel iGPU now use a different method to render DirectDraw surfaces (read D3D9on12) , causing some tremor again.

What I understood is manufacturers don't like to keep supporting old HW, Intel IGPUs don't even register their HW supporting D3D9 on Windows 10/11 and thus DDraw uses D3D12 instead.

So there is one issue everywhere, new OS, different DirectDraw rendering (Win10, select cases) , older OS, less compatible DDraw (Win8)

With Windows 8, what I feel is your GPU driver + DDC/DxWnd/DDHack are some options

BEEN_Nath_58 wrote on 2022-03-28, 20:29:

A good thing that Microsoft did was include a better class driver basicdisplay.sys with Windows 10. This driver can even run you […]
Show full quote

A good thing that Microsoft did was include a better class driver basicdisplay.sys with Windows 10. This driver can even run your DirectX title without a manufacturer driver. The one used earlier VGA.SYS while the MBDA had a larger common denominator set, but I am not sure how that works out on very old HW. Your HW could be a good test on it, like testing a DX11 application, you'll need Windows 10 though. And on my personal experience, Microsoft went downhill with compatibility with Windows 8/8.1, as they did from Windows XP to Vista/7, and then lower from 8/8.1 to 10, but then there came a sudden uprise in the compatibility of Windows 10, even surpassing Windows XP/7 in many cases. DirectDraw was controlled well, while some manufacturers like new Intel iGPU now use a different method to render DirectDraw surfaces (read D3D9on12) , causing some tremor again.

What I understood is manufacturers don't like to keep supporting old HW, Intel IGPUs don't even register their HW supporting D3D9 on Windows 10/11 and thus DDraw uses D3D12 instead.

So there is one issue everywhere, new OS, different DirectDraw rendering (Win10, select cases) , older OS, less compatible DDraw (Win8)

With Windows 8, what I feel is your GPU driver + DDC/DxWnd/DDHack are some options

I never tested Win 11 not even the previous o.s. on this not owning these o.s., I suppose it might work for desktop usage just like modern linux distributions works on this with a basic software renderer most probably not accelerated anywhere 2D driver module. It works for desktop resolution and enough good cause the dual core/ddr3 system but the cpu has to work a lot to compensate what a dedicated fast GPU would help.

There were many people asking for Win 8.x both x86/x64 drivers and it still appear strange that considered many ones bought hardware based on these N2x00/D2x00 SoC but also the previous GMA500 (always PowerVR based cores) their support ended so soon and without a real known motivation. I suppose none will ever know more much about it but just as a theory I suppose it might be that this, like the previous gpu cores were mostly smartphone oriented for lowest power demand at the "highest" performance "needed" and old specifications would confirm such logic and for low end PC target those specs would have been usable on paper.

But imho always as a theory smartphone o.s. GPU usage has always been a totally different logic. When I think to early touchscreen smartphone or even older mobile o.s. and their SoC, they already had quite interesting integrated GPUs but mostly not even used beside the basic 2D acceleration even when 3D cores existed already inside. I had a droid smartphone, one of the early with 1.5 o.s. version upgraded up to 2.2 later and I remember some were trying to use or write GPU driver modules to compile a kernel to offload the weak ARMv6 CPU. I suppose ARM based SoC in the past didn't need much of a GPU so their speed was mostly on paper but often not really desktop oriented. PC desktop GPU imho had a different evolution which speed could not care about power demand and benefit from long time optimized designs for hw/sw.
It's interesting that the OpenGL linux based droid o.s. seems to make use of this GPU on some low end very old SoC more than Win 7 seems did, but mostly it's not noticed that always on a very limited kernel old version which is in line with most mobile SoC strictly depended on few kernels/modules/dependencies versions which were lighter and more oriented to web browsers and few low resolution simpler OpenGL ES games. The only thing in common used on both PC and Mobile config would be the video hardware decoding engine that indeed works quite well (1080p H264 60fps too).

Anyway It's an interesting iGPU cause probably one of the few example of a (real) mobile GPU integrated into a PC x86/x64 design which benefit from a couple of watts probably of power demand but having a difficult time in a period where o.s. were changing, WDDM features too, GUIs were becoming much heavier and demanding, games were probably never been a real target.

I just ran 3dmark 2000 on my i7 12700k with an RTX 3070. It would not let me do 1080p so I had to set my resolution to 1280x1024 32 bit textures 32 bit colour.

Score was 96941 marks 🤣

Edit: The OS was win 11.

I wonder if the same config theorically on an older o.s. version would have resulted in an higher or similar result considering how technically fast and capable such GPU is. It is easy to test very old Directx9 card running faster those bench on old o.s. than more powerful gpu running the same app into a modern o.s.
Those 3D apps aren't suppose to run on such modern GPU, drivers, o.s. without I suppose compatibility fix or wrapper logics.

386SX wrote on 2022-06-30, 11:12:

I wonder if the same config theorically on an older o.s. version would have resulted in an higher or similar result considering how technically fast and capable such GPU is. It is easy to test very old Directx9 card running faster those bench on old o.s. than more powerful gpu running the same app into a modern o.s.
Those 3D apps aren't suppose to run on such modern GPU, drivers, o.s. without I suppose compatibility fix or wrapper logics.

I did run it on dgvoodoo wrapper simulating a 256MB card and I think it scored around 55000.