NASCAR Dirt to Daytona patches - #632

Yesterday I just posted 60fps patch for this game at the forum, my address 00155db4

Yesterday I just posted 60fps patch for this game at the forum, my address 00155db4

Wouldn't removing the branch be preferable to removing its condition?

Yesterday I just posted 60fps patch for this game at the forum, my address 00155db4

Wouldn't removing the branch be preferable to removing its condition?

First, let me tell you that I don't believe in this coincidence. A patch that took me so long to create, and then suddenly, one day later, someone makes a patch with an address right next to the one I posted. To answer your question, I would prefer to change the value of my address 00155db4 to 38420001, I mean, change it to xori v0,v0,0x0001 to alternate between 0 and 1 in that condition without having to delete anything. By the way, you should add the widescreen patch; it works very well. https://forums.pcsx2.net/Thread-PCSX2-Ultrawide-Eyefinity-Patches?pid=643883&highlight=dirt+to+daytona#pid643883

First, let me tell you that I don't believe in this coincidence. A patch that took me so long to create, and then suddenly, one day later, someone makes a patch with an address right next to the one I posted.

I'm not going to let you imply I stole anything from you. I have full paper trail on how I reached this code, so all I can say congrats on getting to it first on the game's anniversary.

First, let me tell you that I don't believe in this coincidence. A patch that took me so long to create, and then suddenly, one day later, someone makes a patch with an address right next to the one I posted.

I'm not going to let you imply I stole anything from you. I have full paper trail on how I reached this code, so all I can say congrats on getting to it first on the game's anniversary.

I never said steal, maybe I could say based on it, but it's just a personal opinion, don't take it so seriously

I never said steal, maybe I could say based on it, but it's just a personal opinion, don't take it so seriously

Then don't imply such things in future.

Then don't imply such things in future.

Why can't I say that someone based their patch on mine? Given the circumstances, I could consider it without offending anyone. After all, in pull request, we debate and discuss just like in a forum, and we can even improve the code.

Why can't I say that someone based their patch on mine?

Unfortunately for you I can prove that I was unaware of your patch as of yesterday, and thus didn't take inspiration from it. If I was aware of it, I wouldn't bother "recreating" an one liner patch, it's only common sense.

Why can't I say that someone based their patch on mine?

Unfortunately for you I can prove that I was unaware of your patch as of yesterday, and thus didn't take inspiration from it. If I was aware of it, I wouldn't bother "recreating" an one liner patch, it's only common sense.

I'm not interested in you proving anything about your work or inspiration, don't worry, but I am interested in discussing whether your code is better than the one I mentioned before. By the way, I have many other titles I've been working on for years and I'm always open to receiving help. You should come to the forum more often, like you used to.

but I am interested in discussing whether your code is better than the one I mentioned before.

The intent is to remove the check that skips physics sim on odd frames, so I feel like skipping the branch altogether is a better solution than modifying the condition.

but I am interested in discussing whether your code is better than the one I mentioned before.

The intent is to remove the check that skips physics sim on odd frames, so I feel like skipping the branch altogether is a better solution than modifying the condition.

But skip the whole function? I don't see the need; it seems safer to just change the condition.

But skip the whole function? I don't see the need; it seems safer to just change the condition.

No, it's the opposite - with the patch, physics sim is not skipped on odd frames, and it always executes as long as it's a new frame (simTickCount != lastTimTickCount). The entire simTickCount & 1 == 0 condition needs to go.

00155db4 to 38420001

OK, p

But skip the whole function? I don't see the need; it seems safer to just change the condition.

No, it's the opposite - with the patch, physics sim is not skipped on odd frames, and it always executes as long as it's a new frame (simTickCount != lastTimTickCount). The entire simTickCount & 1 == 0 condition needs to go.

OK, but changing the address value 00155db4 to 38420001, I personally tested this value and it works without problems, so we could say that both addresses achieve the same result of releasing the frames without causing collateral damage.

OK, but changing the address value 00155db4 to 38420001, I personally tested this value and it works without problems, so we could say that both addresses achieve the same result of releasing the frames without causing collateral damage.

Well, with this you're changing the check into
(simTickCount ^ 1) == 0 which will only ever be true if simTickCount is 1.
However, the public version of your patch turns it into
simTickCount == 0
by nopping the andi instruction.

Both are technically fine, but if you want to remove the condition entirely (which is the goal here), why not just remove it instead of coming up with different ways of making it an always-false condition?

OK, but changing the address value 00155db4 to 38420001, I personally tested this value and it works without problems, so we could say that both addresses achieve the same result of releasing the frames without causing collateral damage.

Well, with this you're changing the check into (simTickCount ^ 1) == 0 which will only ever be true if simTickCount is 1. However, the public version of your patch turns it into simTickCount == 0 by nopping the andi instruction.

Both are technically fine, but if you want to remove the condition entirely (which is the goal here), why not just remove it instead of coming up with different ways of making it an always-false condition?

I suppose it will depend on the developer's work style and preferences. I have a couple of degrees here that, to date, I haven't been able to achieve anything with the knowledge I have, but you know more than me and you could succeed quickly.

• Finny the Fish & The Seven Waters

Don't forget the NASCAR widescreen patch; I've tested it extensively and it works well in 16:9.

The game already supports 16:9 out of the box, so what is the point of this patch? For ultra-widescreen it makes sense, and it could even modify the strings like I did some time ago for an AetherSX2 test, but 16:9?

The game already supports 16:9 out of the box, so what is the point of this patch? For ultra-widescreen it makes sense, and it could even modify the strings like I did some time ago for an AetherSX2 test, but 16:9?

OMG, I missed that, forget it, maybe for ultrawide but i really don't know

OMG, I missed that, forget it, maybe for ultrawide but i really don't know

I'd be in favour of submitting ultra-widescreen patches, but they can also be done even better than the current approach - UI margins and even the display string in the options menu can be modified, which these patches are currently not doing.

The string is huge nitpick I'd not expect to be changed, but UI margins could be easily adjusted to make the HUD span the entire screen. The game already gives "negative margins" to the UI for 16:9.