[Other✓] Are there practical limitations that I'm not aware of, or am I just a beginner who's in over their head?

[chloapsoap]

Apologies in advance for general ignorance on my part. This is my first time posting to this community for help and I recognize that I may be making a fool out of myself. Please bare with me lol

So a few months ago I started working on my first romhack (Emerald). I had some naive ideas of what I wanted to achieve before I even started doing any work, and I'm having trouble finding information for a few things I had in mind. I suspect that there are practical limitations I'm not aware of.

I was hoping someone could help me to better understand the technology I'm working with. The specific questions I have are kind of a mixed bag, but they're really just examples of me not understanding the landscape I'm working in:

1. Regarding memory: I've heard it said that FRLG are superior to RSE in terms of how much free space is available. If this is the case, how does this manifest itself? How much additional space are we talking about here? Elaboration on how memory is managed in these games would be appreciated (if appropriate).

2. Regarding the opening sequence: How much of this can be altered? I was surprised at how little discussion I was able to find about this, and I'd really appreciate some help tracking it down if it exists.

3. Regarding battle scripting: So, I'm pretty tacky. I want to include a couple of scripted trainer battles. To what extent is this possible in Gen 3 (and in other gens if applicable)? Can trainer AI be tweaked, or am I going to have to torture my hack to hell and back to make this happen?

I understand that some of these questions might be complicated to answer. I'm a 5th-year CS undergrad, so I can parse technical jargon decently well if necessary. Insight on anything here (specific or general) would be greatly appreciated

 

[mgriffin]

If you're a CS undergrad, I'd recommend using the decomps, at which point all these things become much easier (probably from "practically impossible" to "pretty straightforward once you understand the systems") because you can simply change the code.

 

[chloapsoap]

If you're a CS undergrad, I'd recommend using the decomps, at which point all these things become much easier (probably from "practically impossible" to "pretty straightforward once you understand the systems") because you can simply change the code.

Oh wow. Yeah, this looks like exactly what I need. I've been browsing this forum since January and in that time it didn't occur to me that source code was even available (and it's been a confusing past few months to say the least). I'll check that stuff out. Thank you so much for pointing me in the right direction.

 

[ThomasWinwood]

mgriffin is correct; there's little to no reason not to use a decomp for a new project at this point. That said, to actually answer your questions...

Regarding memory: I've heard it said that FRLG are superior to RSE in terms of how much free space is available. If this is the case, how does this manifest itself? How much additional space are we talking about here? Elaboration on how memory is managed in these games would be appreciated (if appropriate).

Ruby/Sapphire and Emerald are very different beasts - FireRed/LeafGreen rewrote a fairly substantial chunk of the game engine, and Emerald is Ruby/Sapphire reimplemented on top of that. There's a persistent meme that Emerald is "unstable" dating from the early days of Pokemon ROM hacking - in short, it has unused space on-cartridge filled with both all-zeroes and all-ones, but the naive approach to finding free space in Emerald leads to corrupting instruments because some of those zeroes are meaningful. Using a decomp makes all this irrelevant, because you don't care about free space anymore so long as your final binary stays below 32MB in size.

The GBA has no memory management - everything is mapped into the processor's address space at fixed addresses. FireRed and LeafGreen have a simple linked-list implementation of malloc to make use of EWRAM; Ruby/Sapphire don't.

Regarding the opening sequence: How much of this can be altered? I was surprised at how little discussion I was able to find about this, and I'd really appreciate some help tracking it down if it exists.

What "opening sequence" do you mean? The one before the title screen, or the one where Professor Obligatory asks you your name, gender and social security number? Both are hard-coded, but "hard-coded" is just another way of saying "harder to edit, especially if you're not using a decomp, since it's not a data table".

Regarding battle scripting: So, I'm pretty tacky. I want to include a couple of scripted trainer battles. To what extent is this possible in Gen 3 (and in other gens if applicable)? Can trainer AI be tweaked, or am I going to have to torture my hack to hell and back to make this happen?

Scripting is easy whether you're using a decomp or not. Trainer AI is hard-coded (see above).

 

[chloapsoap]

Ruby/Sapphire and Emerald are very different beasts - FireRed/LeafGreen rewrote a fairly substantial chunk of the game engine, and Emerald is Ruby/Sapphire reimplemented on top of that. There's a persistent meme that Emerald is "unstable" dating from the early days of Pokemon ROM hacking - in short, it has unused space on-cartridge filled with both all-zeroes and all-ones, but the naive approach to finding free space in Emerald leads to corrupting instruments because some of those zeroes are meaningful. Using a decomp makes all this irrelevant, because you don't care about free space anymore so long as your final binary stays below 32MB in size.

The GBA has no memory management - everything is mapped into the processor's address space at fixed addresses. FireRed and LeafGreen have a simple linked-list implementation of malloc to make use of EWRAM; Ruby/Sapphire don't.

Very interesting. I'm glad I won't have to deal with it, but I was pretty curious about what went on between Ruby/Sapphire (I always mis-date Emerald, my bad) and FireRed/LeafGreen in terms of memory management. This makes sense to me.

What "opening sequence" do you mean? The one before the title screen, or the one where Professor Obligatory asks you your name, gender and social security number? Both are hard-coded, but "hard-coded" is just another way of saying "harder to edit, especially if you're not using a decomp, since it's not a data table".

I mean everything between selecting "New Game" and when your sprite is dropped into the game (so, the latter). At the time, I figured that the one before the title screen was more of a cinematic and I didn't want to bother with it. However, I wasn't sure if the conversation with the prof was treated the same. Without the decomps, I couldn't figure out how to change anything during that opening sequence (including the starting location. I had the warp tiles in the moving truck in Emerald drop me in my bedroom, and I said "good enough for now"). None of my web searches came up with any discussion on this either, but I guess it wouldn't if everyone altering it can look at the code for it. I'll give it a second look once I download the repository.

Scripting is easy whether you're using a decomp or not. Trainer AI is hard-coded (see above).

Good to know. Thanks for taking the time to clear these things up for me. They've been bugging me for a while now and it's nice to finally get some closure

 

[Tacobell24]

If by "Opening sequence", you mean the battle with Gengar and Nido, I can offer some assistance there

Since I too found a limited amount of stuff on it, so i worked it out myself