Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Functionality suggestion for game-specific Gsdx hacks
#1
This idea came to me recently, and I feel the need to share it.  Whenever there was a new Sly Cooper development build that was discovered, it needed CRC fixes.  Only recently did it occur to me that loading Gsdx hacks based on the disc image's CRC is kind of a flawed system.  Let me explain.

Although "standard" users won't ever run into trouble with this, I've often come across situations where I need to patch a disc image, either to apply mods directly into the filesystem or to enable debug functionality in developer prototypes.  That being said, whenever any change is made to the disc image file, the CRC changes.  This means that the game-specific Gsdx hacks won't apply to it anymore because - even though it's the same game - the CRC has changed.

I have a proposed solution to this - load game-specific Gsdx hacks based on either:

1. The filename of the executable (i.e. look for SLUS_304.64)

2. The game's title (isn't there an internal list of game titles already?)

3.  Some other identifier that I'm not aware of that PS2 games use

This way, the disc image files could be modified without losing the ability to play them smoothly because the game-specific hacks would still load for them.  I'm sure there's some technical reason why CRC is used, but no matter how much I think about it, this makes more sense to me.
Reply

Sponsored links

#2
The Sly bandage has already been ripped. No more CRC hacks for that game.
[Image: HkgHT5k.gif]
もっとちゃんと言ってよ
忘れないようメモにしてよ



Reply
#3
Not the point I was trying to make, I just meant in general. Also yes it still does, if I modify and Sly disc image file then load it with Direct3D11, there's artifacts and slowdowns all over the place as if I was using OpenGL. This is with 1.6.0 by the way, we don't use 1.7.0 builds because of the added memory regions messing up our cheat tables and trainers.
Reply
#4
You can make patches that remove the effects without including the crc, alternatively use HPO special to resolve upscaling artifacts.
CPU: I3-4160 3.6GHZ
Motherboard: Asrock B85M - DGS
RAM: Hyper X Savage 2x8GB 1.6GHZ cl9
GPU: Asus AMD Radeon R7 360 OC 2GB GDDR5
OS: Windows 10 Pro 64bit
Reply
#5
I see I'm not getting my point across clearly. Let me put it in layman's terms:

ISO without changes = Gsdx hacks apply successfully

ISO with any change = Gsdx hacks do not apply

Gsdx hacks load by looking for a matching CRC

Making changes to ISO makes changes to CRC

System is flawed, my suggestions are not.

Does it make sense now? I'm not looking for workarounds for graphical glitches or patches that don't change graphics! Those are completely unrelated to what I'm trying to say.
Reply
#6
(12-18-2020, 05:00 AM)goody_fyre11 Wrote: I see I'm not getting my point across clearly.  Let me put it in layman's terms:

ISO without changes = Gsdx hacks apply successfully

ISO with any change = Gsdx hacks do not apply

Gsdx hacks load by looking for a matching CRC

Making changes to ISO makes changes to CRC

System is flawed, my suggestions are not.

Does it make sense now?  I'm not looking for workarounds for graphical glitches or patches that don't change graphics!  Those are completely unrelated to what I'm trying to say.

No we understood what you wanted, you gave an entirely moot use case for it and so we just pointed that out and gave you what you can do instead moving forward.

You're right, the system is flawed. It's flawed by design. We are trying to remove it not expand on it which is why Sly doesn't have a hack anymore. Pointing that out to you kind of should have been the hint that we aren't too keen on the CRC hack system.

[Image: Did+I+adequately+answer+your+condescending+question.jpg]
[Image: HkgHT5k.gif]
もっとちゃんと言ってよ
忘れないようメモにしてよ



Reply
#7
Debug functionality can't be patched in any differently, so patching it in using a method that doesn't change the CRC isn't possible.

Okay, let me at least ask this: if someone had brought this up when PCSX2's development first started, would it have been used instead of the way it is now?
Reply
#8
I don't think so.
Main objective is still to avoid hacks at all cost, and correct the the source code to make emulation as accurate as possible.
What you're talking about still implies using hacks
CPU : I7 2600K Oc'ed @ 4.2Ghz
Mobo : Intel P67 southbridge
GPU : NVIDIA Geforce GTX 750 Ti
RAM : 6 Go
Reply
#9
(12-18-2020, 12:20 PM)goody_fyre11 Wrote: Debug functionality can't be patched in any differently, so patching it in using a method that doesn't change the CRC isn't possible.

Okay, let me at least ask this: if someone had brought this up when PCSX2's development first started, would it have been used instead of the way it is now?

I'm not really interested in alt history so I'm not going to address that second comment. It's irrelevant anyway.

I'm aware that patching the ELF changes the CRC and that CRC hacks stop working when you do that. But you're patching the game anyway so just patch out the effect that you don't like. It's not really our responsibility to arbitrarily remove effects and the list of games with these CRC hacks is shrinking.

My friend patches Raw Danger which has a CRC hack to remove broken post-processing, he just patched out the broken post-processing while he was at it. We recently removed a CRC hack for SMT Nocturne and the community for that game just wrote patches that did the same thing.

You're asking us to implement something that would get more users reliant on a system that we want less and less users reliant on.
[Image: HkgHT5k.gif]
もっとちゃんと言ってよ
忘れないようメモにしてよ



Reply




Users browsing this thread: 1 Guest(s)