Thread: Development: Pokémon Fire Red Hacked Engine
View Single Post
Old January 24th, 2010 (9:05 PM).
JPAN JPAN is offline
pokemon rom researcher
Join Date: Dec 2008
Posts: 104
Quote originally posted by Deokishisu:
About the graphical berry problem. I'm not exactly sure what you're saying there. Do you mean that their is literally no way to make a reasonably plausible sprite transition between the berry growth stages in Firered? That you wouldn't be able to link each berry to its respective tree sprite? You can't think of a way to show the intermediary sprite stages in berry growth but can only figure a way to show one or two? You can't find the different growth stage sprites so you can insert them? Please elaborate a bit, maybe we'd be able to work something out! Even a cheap workaround, or a skeleton that could be expanded upon later would be better than nothing imo.
Well, let me first explain what would be needed to create a Berry system. Consider this:

1st - Consider berry trees animated OWs:
If we notice, sprout and seed stages are common to all berries, so we can make the OW manager fetch those when the berry isn't ready. For the growing and ripe stages, we can use two sequential OW's. If we have a single table for all those OW's, we can have different berry trees for 127 different berries, which is more than there are berries. So, using a OW table for berries only, we could easily have that many trees, and that many berries available.

2nd - If berries are OWs that can appear anywhere, they are Dynamic OW's
Made it once, could make it again. Adding a new table of Dynamic OW's would be easy. I would propose that byte 0xFE in the OW loader would make it look in a separate set of variables, checking for the variable corresponding to the berry planting location. Berry planting locations are identified by the picture number, making them limited to 256 patches, same way the Dynamic OW's work now.

3rd - Lets consider Berries separate from OWs. Berries have data.
That's what Gamefreak did. It considered normal OWs were different from Berry trees, and that is why berries can't be translated directly from Ruby to Fire Red. And it's a good idea, anyway. We could attribute every berry a number (starting with 0x1 for cheri berry and ending in 0x2b for Enigma berry) and create a data table for each berry. That table could be simply this:
2 bytes item number
2 bytes OW image
1 byte growth time seed-stage 1
1 byte growth time stage1 - stage 2
1 byte growth time stage2 - ripe
1 byte max time ripe-seed
Of course the table could be much more complex, but this would be enough.
So, in that Dynamic OW variables, we could keep data related to the berry itself and not the OW, as the OW function could fetch the real image to display from this table.
Instead, that Variable would keep this
6 bits Table Index
2 bits growth stage
2 bits watered times
6 bits growth time
Where watered only counts once per stage, growth time is the time passed from last renewal (full cycle) and it's count in the minimum time unit for berries (with real time, I think that's 6 hours).
And as such, it would be possible to implement a very simple berry system in Fire Red.

Now, the actual answer to your question. What I was talking about in that post was my own limitations, and not the game's. As you may see (or not) from this post, I've spent a great deal of time trying to figure out how to put the berries in the game, and minimize needed data in Variable count.
The problem is not data handling, or routine creation. The problem is that there is no Image data for me to copy from one game to the other. While I could create a well-oiled system, without sprites to show, it would look bad. As I have no sprites to include, nor am I capable of making my own, I can't complete this project.

So, In a short sentence, as I have no Spriting skills, and there aren't any ready-made sprites to use, I can't complete this.

On a separate sidenote, one of the hacks I started out making relied heavily on this system, but on a more elaborate note. There, the berry tree data had about 32 bytes of data, counting with diferent variations such weather and seasons. But was halted indefinitely as the Images needed weren't arround.

Quote originally posted by Deokishisu:
EDIT: Oh, and another Hoenn related suggestion that I forgot. Emerald made several additions to ability and berry functionality, namely Flame Body and Magma Armor reducing the time it takes for a Pokemon to hatch, the EV reduction berries, and several other abilities receiving overworld effects. I was wondering if this too could be ported to your engine. When it comes to this, I have no idea how much work would be involved, but if you think it could be done, I'd be happy to grab a list of the changes and additions made in Emerald for you.
That falls under the Item and Ability hacking. The berries could be mimicked easily, as We've already came to the conclusion on how to use items in the bag, in the pokemon menu and in the Overworld. As for the abilities, I've started studying how the Battle screen is organized briefly, but other matters appeared, and I dropped it. Both Attack effects and Ability effects are not very studied areas, but Flame body and Magma Armor ability to hatch eggs could be applied as we know how to check for abilities and where the hatching routine is placed, as well as some other effects (don't remember the ability name) that acts as a natural repel and the one that makes lower-leveled pokemon appear. It can be done, but without ever trying to read into abilities in-batle, i can't say how much work it would take.
Here are the links for my work

Currently working on:
Battle Script Documentation
Another large project
Reply With Quote