New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Hex Editor Improperly Displays Cheat Endianess #1025
Comments
As far as I can tell from looking at the code, checking that box has no actual effect. Right now it's just a parameter that follows the cheat without doing anything. The cheats part of Bizhawk has not been updated in quite a while, and as zermous mentioned in the thread, if some aspect of the cheat tools happens to work, then it's really just good luck. |
Ah ok I see now, thanks for the clear demonstration. |
Go ahead, keep telling people cheats work great. When they discover otherwise, itll be your house they storm with pitchforks and torches. |
How about you test your program when you get a bug report instead of assuming you're right? I didn't want to be a dick about this as I really do like Bizhawk, but it's clear you're just assuming you're right and haven't actually tested it because if you tested it you'd see it works fine. All of these were recorded on a fresh install of 2.2 Cheats working on QuickNES: https://narry.land/wJ5bYH.gif Do you need me to make clips from every other core or is this enough for you? |
Yeah, make a clip of game genie cheats working on GPGX or bsnes |
Well as you already know, the ROM domain on BSNES is read only, but that's nothing a few lines of code can't change. Now this is targeting the wrong domain, it's targeting the CARTROM rather than the System Bus so I had to modify the game genie code slightly to work. I'm assuming this was done because the System Bus can't be poked even with the read-only state Bizhawk puts in place disabled (I'm assuming there has to be a second layer of write protection within the core)? This wasn't a discussion about the code converter though, this was about the cheat system as a whole. Manual cheats working on BSNES: https://narry.land/JZTumr.gif |
OK, thanks for admitting it doesn't work until you change the emulator AND change the cheat code. You used some nice walls of text to try to be sneaky and conflate "it works" with "it basically works you just have to fix it, and it's as good as done because it's easy to fix". There's a reason we haven't fixed it -- changing read only things to writeable has bad consequences (the cheating may linger after it's disabled, for instance) I have other reasons for calling the whole cheat system broken. Cheats frequently don't work because our faked ram pulses (they shouldnt even be called cheats) doesn't work as well as the genuine article would. But really it was the two huge regressions in bsnes and gpgx that made me say, in my own words, "Cheats are so broken that I say they're completely broken". |
I wasn't trying to use walls of text to hide the fact that the cheat code converter has issues. My point was that the cheat code converter not working with two cores is not the same as the cheat system as a whole being broken. Maybe you feel that way, but in my opinion it's misleading to say the entire system is broken because a small portion of it is broken. That'd be like saying the entire 32x core is broken because it mis-reports the endianess of the MD Cart domain compared to the actual file (it does by the way, it's byte flipped internally by Picodrive and then it reports it out as Little Endian instead of Big Endian edit: opened #1048). Is that a problem with the 32x core? Yes. Does that mean the entire 32x core is broken? No. It just means anyone who is pulling data from that domain and comparing it to the actual file (which I happened to be doing) will need to add an exception for just that domain. I've never had issues with cheats not working and I use the cheat system a LOT but I'm not going to debate the existence of issues with the pulses as I'm not watching the values every single frame to make sure nothing was dropped. I would still argue that doesn't mean cheats are "completely broken", but we clearly have different opinions on what constitutes completely broken. Anyways, this hex editor bug is 100% unrelated to the cheats themselves working. This has to do with the overlay displaying the wrong values. |
You're not the one who has to deal with people saying "why doesnt this work" over and over. You're responding to some imaginary version of me who's said that it's actually completely broken instead of the actual me who's only said that he's saying it's completely broken for PR purposes--except for the very first time I said anything about it when I did say it was completely broken, (which I said for PR purposes), instead of that I was only saying it was completely broken (which is what I switched to immediately after that) |
And I'm supposed to know you're just saying it for PR purposes so people don't harass you that they don't work? Anyways this discussion is pointless at this point. Cheats aren't completely broken, but for the sake of preventing people from harassing you asking why they don't work you're just saying they're broken. Got it. |
Oops, I uploaded the wrong file, the above commit doesn't do anything. Issue actually resolved by af9c813 |
As I mentioned on the bug reporting thread, the hex editor doesn't properly display the endianess of a cheat.
The value is replicated as intended, but the data will always show up the same way in the hex editor despite the endianess setting.
The text was updated successfully, but these errors were encountered: