Hey, four months ago at this point you asked me in a comment about the Jimmy Neutron PC game and I didn't respond to it because TH-cam didn't notify me about it, I'm so sorry about that. If you still had any questions I'd be happy to answer.
Hehe no worries, I was just curious about how you were able to modify the .dll to get it to work. Though I figured it probably takes a lot of coding experience, which I do not have lol. Thanks for following up
So you downloaded and tried out the DLL and saw that the patch works, but was wondering how I made the patch? Sure, I am willing to share. So the story behind this is that gamemaster468 is a TH-camr I follow that wanted to play the Jimmy Neutron PC games for the anniversary of his channel which was coming up in a few days, but couldn't get it to run. I figured maybe it was something basic like it was THQ so it probably had some DRM on it or something. I told him I'd take a look at it and see if I could fix it. I don't actually own the game but I found another game called Hot Wheels Mechanix using the same library so I downloaded the demo for it and started from that. As it turns out there was no DRM, the problem was something else. The patched DLL is only two bytes modified from the original. I made the patch using IDA and Olly Debugger just because it's what I learned first but you could probably just as easily use the more standard Ghidra and x64dbg. The precise issue with the game is that it would start up (and I could hear it start up) but would not render anything and was just a black screen. I began by simply Googling the issue and found out that the DxWnd developers had also been trying to get the game to work but not much in the way of useful debugging info. Now this type of issue is the worst kind to debug because it's much easier to debug a problem when something _is_ happening that _shouldn't_ (like an error message) rather than when something _isn't_ happening that _should_ (like when you can hear the game working but only see a black screen.) This took me I'd like to say around 11 hours to figure out (not in one session of course - over the course of three days) and most of that time was just throwing random darts. I saw the game had some debug logging, so I spent some time trying to get it enabled. However I didn't get any useful error message out of it. I also learned the OMT2.dll was actually a library called Open Media Toolkit, which was now open source. I tried substituting the latest version into the game but it was too new. The version of Open Media Toolkit the game used was from before it went open source, so the specific version I had to work with was proprietary. However, the repo of the open source version still proved handy as a way to see what certain functions were intended to do, as many of them remained unchanged in the latest version of Open Media Toolkit. The important revelation was when I realized I could make the game work in Software mode if I used dgVoodoo2. However it looked bad and low resolution because... software mode. I wanted it to work in hardware mode. Now however I could compare how both programs executed in Olly and see what one did that the other did not. I noticed OMT exported many functions to do with rendering, so I decided to set a breakpoint on an export called "render" and see if it ever gets called. Surprise surprise, it did get called in software mode where the game worked, but not hardware mode. So now it was just a matter of looking up at the call stack in software mode and see which breakpoint does not get hit in hardware mode. What this lead me to find was that it was not allocating the buffer it used for drawing the render. Why? Because it was trying to allocate a buffer many times larger than the screen. Actually, it was trying to allocate a buffer with a negative number size. As is turns out, this is because the game was failing to get the window position to use. In fact I'm pretty sure it would have never succeeded in getting it, even in XP. It passes the wrong cbSize variable to the GetMonitorInfo WinAPI call - which causes the function to error, and do nothing. Worse, the program assumes it succeeded and never bothers to initialize the x/y variables to zero! This means they are essentially random numbers dictated by whatever happened to be on the stack before at that memory address. I imagine that by sheer coincidence, this would've been zero on XP. On Windows 10 however it is some negative number, so the detected window size is wrong, so the allocated buffer size is wrong and the game never renders anything. Solution to this? The game always renders in fullscreen anyway - initialize the x/y variables to zero. Two bytes modification and the game is fully working. Most old games don't suffer any serious problems running on newer hardware. The vast majority of problems are caused by DRM or simple mistakes like this. This is why you have to be careful when writing native code!
@@tomysshadow Thank you very much for the detailed info!! I appreciate it. I originally tried the new Open Media Toolkit .dll file from the GitHub repo as well but my debugging didn't go any further than that. I play a lot of old PC games so information like this is very interesting to me.
Finally :p nice! Your screen recorder jacked up again though :( Also, is online playable with this?
Thanks! What are you talking about though, recording seems fine lol. I think it's theoretically playable online if everyone has the mod. :)
@@andetstk1237 Hmm strange lol
@@andetstk1237 Maybe it's my big screen
nice
Did Benau say yes?
Haven't asked him yet, sorry. I'll do that now in fact
I'm thinking it might be a question for the website though and not Benau, we'll see
@@andetstk1237 Which website. The freegamedev forums or supertuxkart.net?
Lol it's 2 am where Benau lives so we might have to wait a bit for an answer
@@andetstk1237 Lol. But which website are you talking about?
Hey, four months ago at this point you asked me in a comment about the Jimmy Neutron PC game and I didn't respond to it because TH-cam didn't notify me about it, I'm so sorry about that. If you still had any questions I'd be happy to answer.
Hehe no worries, I was just curious about how you were able to modify the .dll to get it to work. Though I figured it probably takes a lot of coding experience, which I do not have lol. Thanks for following up
So you downloaded and tried out the DLL and saw that the patch works, but was wondering how I made the patch? Sure, I am willing to share.
So the story behind this is that gamemaster468 is a TH-camr I follow that wanted to play the Jimmy Neutron PC games for the anniversary of his channel which was coming up in a few days, but couldn't get it to run. I figured maybe it was something basic like it was THQ so it probably had some DRM on it or something. I told him I'd take a look at it and see if I could fix it.
I don't actually own the game but I found another game called Hot Wheels Mechanix using the same library so I downloaded the demo for it and started from that. As it turns out there was no DRM, the problem was something else. The patched DLL is only two bytes modified from the original. I made the patch using IDA and Olly Debugger just because it's what I learned first but you could probably just as easily use the more standard Ghidra and x64dbg.
The precise issue with the game is that it would start up (and I could hear it start up) but would not render anything and was just a black screen. I began by simply Googling the issue and found out that the DxWnd developers had also been trying to get the game to work but not much in the way of useful debugging info.
Now this type of issue is the worst kind to debug because it's much easier to debug a problem when something _is_ happening that _shouldn't_ (like an error message) rather than when something _isn't_ happening that _should_ (like when you can hear the game working but only see a black screen.) This took me I'd like to say around 11 hours to figure out (not in one session of course - over the course of three days) and most of that time was just throwing random darts.
I saw the game had some debug logging, so I spent some time trying to get it enabled. However I didn't get any useful error message out of it. I also learned the OMT2.dll was actually a library called Open Media Toolkit, which was now open source. I tried substituting the latest version into the game but it was too new.
The version of Open Media Toolkit the game used was from before it went open source, so the specific version I had to work with was proprietary. However, the repo of the open source version still proved handy as a way to see what certain functions were intended to do, as many of them remained unchanged in the latest version of Open Media Toolkit.
The important revelation was when I realized I could make the game work in Software mode if I used dgVoodoo2. However it looked bad and low resolution because... software mode. I wanted it to work in hardware mode. Now however I could compare how both programs executed in Olly and see what one did that the other did not.
I noticed OMT exported many functions to do with rendering, so I decided to set a breakpoint on an export called "render" and see if it ever gets called. Surprise surprise, it did get called in software mode where the game worked, but not hardware mode. So now it was just a matter of looking up at the call stack in software mode and see which breakpoint does not get hit in hardware mode.
What this lead me to find was that it was not allocating the buffer it used for drawing the render. Why? Because it was trying to allocate a buffer many times larger than the screen. Actually, it was trying to allocate a buffer with a negative number size.
As is turns out, this is because the game was failing to get the window position to use. In fact I'm pretty sure it would have never succeeded in getting it, even in XP. It passes the wrong cbSize variable to the GetMonitorInfo WinAPI call - which causes the function to error, and do nothing. Worse, the program assumes it succeeded and never bothers to initialize the x/y variables to zero!
This means they are essentially random numbers dictated by whatever happened to be on the stack before at that memory address. I imagine that by sheer coincidence, this would've been zero on XP. On Windows 10 however it is some negative number, so the detected window size is wrong, so the allocated buffer size is wrong and the game never renders anything.
Solution to this? The game always renders in fullscreen anyway - initialize the x/y variables to zero. Two bytes modification and the game is fully working.
Most old games don't suffer any serious problems running on newer hardware. The vast majority of problems are caused by DRM or simple mistakes like this. This is why you have to be careful when writing native code!
@@tomysshadow Thank you very much for the detailed info!! I appreciate it. I originally tried the new Open Media Toolkit .dll file from the GitHub repo as well but my debugging didn't go any further than that. I play a lot of old PC games so information like this is very interesting to me.