nice, thanks for the heads up!

Can you make the same patch for 3DMark 2001 SE? (3DMark 2000 can already run with dgVoodoo 2).

lowenz wrote:

Can you make the same patch for 3DMark 2001 SE? (3DMark 2000 can already run with dgVoodoo 2).

Will get to it. You just reminded me that I've read some time ago that older 3D Mark programs are based on MAX-FX engine. Just downloaded it and I see that it uses same DLLs as games, though checksums don't match with either fully patched games, so I suppose I gotta do it all over again, since due to the nature of working with disassembled code, you can't just do a copy-paste, even though the patches are identical for both games with exception of minor low-level differences.

Obviously if you got the time! Thanks! (So we can test it with the pure D3D8.dll with the affinity trick, the Crosire D3D9 wrapper and dgVoodoo2 for D3D11).

These are the results with an OC'ed 1050 Ti

Pure D3D8:

Crosire D3D8to9:

It is really interesting, 'cause the wrapper overhead is largely exceeded by the D3D9 advantage givern by today GPUs drivers.

3D Mark 2001 SE patch done: 3D Mark 99 Max & 2001 SE Startup Hang Patch

You actually don't need to change affinity with stock d3d8.dll thanks to this patch. On my weak laptop with AMD Radeon R2, I've noticed, without any FPS counters, that the game is a little smoother when run on all cores. It kinda makes sense since game's main thread isn't the only one that is part of the game's process so it helps if OS can schedule threads on any CPU it desires instead of everything being constricted to 1 core. And even before this patch, one could set affinity back to all cores when the game started up, but I don't think anyone ever thought of that.

Good job and thank you!

The 2 was huge payne on my computer, making the game randomly working when upgrading Windows.

Good job!!!
Is it difficult to make such patches on their own? Can you advise any tutorials?

You're all very welcome! There aren't any specific tutorials. You just somehow put the pieces together. Patching games that don't come with source code is a very specific kind of programming, or more like re-programming and needs the one to get familiar with x86 assembly language and studying disassembled code using tools like OllyDbg. You do find miscellaneous tutorials about certain tasks, but you're mostly on your own I think. I remember watching long time ago the tutorial that demonstrated how to make Notepad show a message box before it starts. The ones for demonstrating how to bypass copy protection in certain programs seem common, but I never found anything that demonstrated how some bugs were found and fixed in certain application/game. And the fact that every problem is unique complicates matters, plus the source code for most games is not available. When it's available, many improvements are possible, look at modern source ports of classic Doom and Quake games.

Generally, what little I've learned about programming, it all seems like some sort of complex puzzle. For example, you have a library with functionality that manipulate images, another for playing sound files and one that contains drawing routines and by combining functionality in all of them, you can make a game. It's really hard to explain and I'm not really good at these things, haven't really put anything particularly useful together from scratch. Improving other people's work is easier. I don't really understand how some people can just sit behind the computer screen and just write and write code, I usually struggle with simple things and like I said, every problem you're trying to solve programmatically is unique. Programming is essentially manipulating data that make the hardware produce the desired result. It probably takes a lot of practice, trial and error before you become proficient at it.

With this particular patch, it came down to understanding basic x86 assembly language, how Portable Executable format works (it's a container for Windows executable files and DLLs) and a couple of details from documentation on MSDN. So I thought, since I knew Max Payne did something in one of the DLLs' DllMain function, which is not supposed to be used for anything or just for really simple initialization, what if I could delay its execution by the time it would be safe to execute its functionality. So I put a variable in its DllMain where I store if the function was already called. If not, it means Windows called it as part of the game request to load its rendering library. When this happens, I bail out, since I know nothing complex (in this case, calls to Direct3D initialization routines) is supposed to be executed until the game's request to load said library is completed (otherwise you can get a deadlock), at which point, its initialization routine in DllMain can be executed without bad consequences. So by this point, I call it again on my own and this time, the check whether the routine was already called once passes and initialization completes instead of not doing anything like the first time. And no bizarre workarounds required.

This is really very special kind of problem and the only reason it came to it is the fact that developers chose to ignore documentation here: https://msdn.microsoft.com/en-us/librar ... s.85).aspx When you choose to ignore the guidelines, unexpected things can happen and since it works on one computer but not other, some people put the blame on the operating system or graphics drivers. Soulbringer had the same problem before I patched it and I've read that someone discovered the "fix" which includes putting older version of one of graphics driver DLLs in its game folder. Then another person tries it and wonders why the game randomly crashes with strange error. And for the third person, the game doesn't work at all.

Thanks a lot for the patch 😄

Could you please share the source code so we can see the trick working?

Regards

There is no source code, I modified the binaries with OllyDbg and Relocation Section Editor.

I run Max Payne 2 (Steam version) with no issues for now.

Thanks for your effort and the explanation

Regards

Excellent patch, so thanks for the hard work. Solved my issue on windows 10 and original CDs.

Oddly enough, Max Payne 2 has stopped starting now with a message saying that Mp2 needs a Microsoft DirectX 9.0 compatible display adaptor.
I have the game on two machines with identical installations - patched to v1.01, widescreen fix and then this startup fix from the OP. No other changes have been made in the intervening months, apart from Windows updates, which I'm beginning to suspect to be the cause.
I even did an uninstall/reinstall of the game on one machine, but still receive the same DirectX message.
I'll try another clean game install and see what happens.

Are you playing on that FX CPU or some different one? Also, do you already update to Win 10 1909 (if you're using Win 10 at all)?

I'll have to update my sig:
Main rig Ryzen 2600X RX580
Secondary FX8350 GTX960
Both are running Windows 10 ver 1903 build 18362.476
What's odd is that I haven't played the game on either rig for a few months.
I did notice that when I go to uninstall the game (for a clean reinstall) the game version is showing 1.0.98, even though I extracted the 1.01 patch to the game directory since the patch is not self-running.
Correction: I found the executable patch 1.01.

Try reinstall GPU drivers.

Hi there and sorry for the late reply. Yes, my GPU drivers are up to date as of today's writing.
In fact, I reinstalled the game, patched it to 1.01 then added this hang patch, but I still get the same DX9 compatible display adaptor message.
This is most unusual.

Edit
Steam has both games on sale at the moment, so I grabbed them for less than $1, applied the startup hang patch to both games and MP 1 worked fine but I had to set MP2 compatibility to Win98 and now it runs.