Recent content by Shiny Quagsire

This is less of a hex editing issue and more of a game reverse engineering issue. There's some things where you can identify structures in a ROM and not have to understand what is using it, but for minor things it generally requires being able to reverse engineer the ROM and understanding Thumb...

This is a GBA memory mapping thing, https://problemkaputt.de/gbatek.htm#gbamemorymap

Yeah I started it, but lost time/interest because disassembly unfortunately isn't the most exciting thing. Would probably be easier to redo it anyhow for armips or similar, and also use macros for the script commands as opposed to assembly bits.

In Fire Red, 0824EFC4 contains a table of structures 4 bytes long describing which environments go with a map's Fight Type. The structure is as follows: <byte> Map Type <byte> Battle Background Index <Half-Word> Padding An equivalent structure does not seem to exist in Emerald or Ruby. The...

I've done this once, it requires modifying the routine which assigns the animation to the Pokemon sprite to load them from a table, like trainer animations do. Don't think I have the source to that anywhere though...

Hm, looking at the animations they seem kinda janky to me. I've tried one-size-fits-all animations but they never quite seemed right. Perhaps you could find the routine which accesses the normal Pokemon sprite animation and then force it into a tabled set of animations for each Pokemon, similar...

I think I found the function used to judge the validity of SOS codes, although I'll have to investigate as to how it even checks the things. It has the strings "bad SOS len", "bad DC huff", "bad AC huff", "bad SOS" and "bad SOS component count", just taking a guess, perhaps the SOS codes are...

The codes kinda remind me of base64, wonder if they do something similar to that in terms of getting raw data to inputtable ASCII. I might try to see if I can track down where in the code they actually read those out, since I got my cart dumped and decrypted.

Looks great, it always bothered me with how hacky the palette system was done, especially with respect to reflections and weather. Seems like this actually managed to improve on a lot of things without having to compromise either, which is great.

Er, that kinda defeats the point. Two layers will always be under the player, one will always be on top. That's how the BGs are sorted by default.

There's quite a bit of info over at DataCrystal which helped me while writing MEH. This seems to be somewhat accurate as well.

Blarg, reuploaded the intro template ZIP, for some reason Dropbox likes to keep killing off my files without me looking.

So the other day I found a plugin for IDA which was called patchdiff2, which apparently could find similar and identical functions between code revisions of the same program. So I decided to run it through and do a diff between Emerald and knizz's IDB, and it actually managed to document most if...

Hm, my only concern though is that I have plans to (maybe) convert some routines to C, so unless I can mix and mingle the two I'm not sure how well that will run. Plus I'd probably have to convert my entire firered.asm. I really just wish gcc had something decent for alternate text encodings.

My plans for that (once I get back to working on this instead of 3DS stuff) is to have a sort of pre-preprocessor which lets me add different preprocessing options. So in the main source files, I'll look for something like .poketext "Something" and I'll turn it into .bytes in another .asm file...