You are not logged in.
I think this is long overdue, but I've come up with a structure rewrite to allow for over 255 pokemon and over 255 moves
https://docs.google.com/spreadsheets/d/ … sp=sharing
This would actually save space as well, but would take a lot of work to code in.
I'd suggest for crystal, removing animations of front pics
Thoughts or ideas?
https://github.com/froggestspirit/pokecrystal20XX
Last edited by FroggestSpirit (2016-09-15 16:43:05)
This isn't easy to say, but…
Music and ASM hacker
Offline
If you're going to add things like the Gen 3 EVs/IVs systems, you should consider making room for natures and abilities in the rewrite.
There are 25 total natures (I'm not sure whether reading them from a list or having it individually check which stat to raise and which stat to lower would be more compact) which could fit within five bits, right?
And abilities, if you include the Hidden Abilities added in Gen 5, have a maximum of three to choose from, so that would be 2 bits for box data (assuming you listed its abilities in its base stats, and just had a number 1-3 in the box structure that corresponded to the three abilities) and 24 bits for base stats (there are 191 abilities in Gen 6, so I'm assuming it stops at 255 here; I guess an argument could be made to raise it to 512 as future-proofing, which would make 27 bits, but I don't know if that's excessive).
You freed up one byte in your rewrite of the box data, and it seems like natures and abilities could fit in that one byte, but if I'm wrong please correct me since I don't know assembly or the Game Boy's hardware that well.
Of course, I also understand if you think that's too great a leap to attempt, since abilities really changed how Pokémon battles felt in Gen 3 and beyond, especially Pokémon defined by their gimmicks like Slaking and Shedinja. I just think, if you're going to attempt completely revamping the data and modernizing it, going the extra mile and adding the necessary framework for natures and abilities would make it "complete." The only other major additions to the data structure that I can think of is Contest stats, and I don't think that would be a priority since they'd take up 5-6 bytes (depending on whether you also port Sheen) and you'd have to port Contests to Gen II in the first place to make any use of them (and even if someone did they could probably just match each Contest stat with a stat EV, like Speed for Cool, Defense for Beauty, etc.).
Offline
The Contest bit especially would be of help to me for my new project.
Offline
Yeah Abilties and Natures should be a must for a new structure, Modern EV/IV has a lower priority imo but should definitelly be done if possible.
How much do you think it would take to rewrite all the functions to use the new structure?
Offline
Personally wouldn't care for abilities and natures but I can see why people would want them. I think it's going to be a stretch to fit in all the Pokemon as it is with the limited space the ROM has. Pokemon animations would definitely not be missed, I don't think the majority of people can really make new ones easily anyway.
I guess it depends on what you want to do, do you want Crystal with all the Pokemon or do you want to update the engine to the modern age. Matter of taste at that point tbh. I personally would rather be able to go past 253 Pokemon over caring whether my Pokemon has Drizzle and is Naughty.
Last edited by Kuroko Aizawa (2016-09-15 14:16:23)
Offline
I'm not too worried about abilities right now, and natures would be something I'd consider. I think it'd be nice to just get the structure rewritten first, and then people could use it as a base and build upon it. I'm not going to code in 100+ abilities. Natures shouldn't be too hard though. (And yes physical special split is a must too).
EDIT: github https://github.com/froggestspirit/pokecrystal20XX
Last edited by FroggestSpirit (2016-09-15 16:43:23)
This isn't easy to say, but…
Music and ASM hacker
Offline
Modern EV/IV has a lower priority imo but should definitelly be done if possible.
I would argue modern EV/IVs would be high priority simply because they save four bytes in Frogg's write-up, which is essential to hold the new bytes; if I remember correctly I was told 32 bytes is the current limit for box data unless you wanted it to take up a lot more space.
I definitely agree that the highest priority would be expanding the Pokémon and move indexes, though.
Offline
I mean I think Abilities and Natures are important from a gameplay standpoint, I'm pretty sure a new player playing a Gen II ROM and seeing Abilities/Natures would impress him more than a IV/EV System.
Increasing the Poke/Move data is indeed the most important part tho, I was gonna suggest items too, but considering all the teru-samas and the useless mail items, i doubt its needed.
Also I was thinking on the Wild and Trainer battle tables, do you have a plan on how and what to rewrite from them to use the new struct?
Lastly, how difficult would be to implement the new structure on G/S once its done in Crystal?
Offline
I'd be willing to help write base stats and update the dex entries, whenever/if you change the formula for those files. I can also provide sprites for every Pokemon except the new generation 7 ones.
I'd also suggest perhaps leaving some capability of formes, as I do not think the current system can do such a thing without a rewrite. Not saying Mega Evolution or anything, but there are less obvious ones such as Castform, Burmy, Aegislash and such that would benefit greatly from that.
Offline
While it is all a good idea in hindsight, there are extreme considerations to make in the long run. ROM space is the most limited resource, especially when it comes to Generation II games... unless the mapper gets transformed into MBC5, which will also make it easier for pirates to sell cartridges online. Also, I don't condone using anything related to newer generations like the upcoming generation since the hack in question will be easier for Nintendo to take down using the DMCA, if they so choose. Kuroko made a wise choice in not providing those sprites since the newer games use a fresh IP.
Natures are a good idea, but are not required as they take up more space. However, it is viable to have the Physical/Special spilt with natures.
Also, taking out animations? This doesn't sound like a genuine Crystal hack at all, but I don't have to play/support the hack.
Offline
Also, taking out animations? This doesn't sound like a genuine Crystal hack at all, but I don't have to play/support the hack.
It's more so to cut space, and also the amount of work it would take to rig animations for 721 Pokemon is immense, even for just 386. I don't see how removing them would kill the experience, they weren't that prominent even in Gen 4.
And as for pirating, people will find a way regardless. Go on etsy or ioffer and there's tons of gameboy/color/advance pokemon hacks for sale. We can't change the format of the rom as it will break a lot more than you would assume, such as the in game clock and such, so that shouldn't be a concern.
And addressing your first point we wouldn't be hacking these game if we were afraid of nintendo taking them down. Yes they are on a spree with killing fangames but hacks have yet to be touched. Not that it would stop us. The fearmongering with that bs needs to stop.
Offline
I agree on not worrying about Nintendo. If they were going to take this down, they'd take down every hack hosted on Skeetendo, and probably on other sites like Pokécommunity and PHO and romhacking.net, and probably the disassemblies as a whole, and we'd have a much bigger issue on our hands than this individual hack.
Offline
I don't see how removing them would kill the experience, they weren't that prominent even in Gen 4.
I get this, and I somewhat agree. Although, it's only a little thing that adds faithfulness to the original game (Crystal) itself.
Would rather not start a debate about this whole ordeal and leave this as is.
We can't change the format of the ROM as it will break a lot more than you would assume, such as the in game clock and such, so that shouldn't be a concern.
Yes, the MBC3(0) is unique piece of hardware, and I know there are unforeseen consequences, but ROM limits using that specific chip are tight since all of the space is accounted for, as I somewhat said from my previous post. I don't want to protest about a limitation from within the MBC itself, because it'll be very silly.
And addressing your first point we wouldn't be hacking these game if we were afraid of Nintendo taking them down. Yes they are on a spree with killing fangames but hacks have yet to be touched. Not that it would stop us. The fear-mongering with that needs to stop.
I'm not scared with what Nintendo is doing, only very disappointed that the company wants to destroy applications that might help more people get into a specific franchise... or they just want free stuff. However, this is getting to be off-topic since I'm not talking about one specific fangame that got ruined over its quick demise.
My apologies if I come off as disruptive, I'm trying to word this as best I can since you made a couple strong points.
Last edited by Faiyz (2016-09-15 22:50:32)
Offline
Oh, this looks promising!
You seem to be retaining the system of calculating gender and shininess based on IVs. If each of those had their own bit, female and shiny Pokémon would be more useful: no handicapped Attack stat for females, and possible perfect-IV shinies.
I agree that reserving five bits for Natures would be useful, since they're relatively simple to implement and have the immediate reward of seeing them on your status screen to give your Pokémon extra personality. EVs are an internal change, but a useful one since it saves space.
Abilities would (a) take up a whole byte, (b) really change how battles play out, like Mmmmmm said, and (c) take quite a while to implement given how diverse their effects are. So I'd understand leaving that out from the default new structure.
Here's the format of the 2-byte CaughtData:
• Time and level
> 2 bits: Time of day (1: morning, 2: day, 3: night)
> 6 bits: Level
• OT gender and location
> 1 bit: OT gender (0: male, 1: female)
> 7 bits: Location
Note that with only six bits for the level, any wild Pokémon above 64 will look incorrect (regular Crystal doesn't have any, even lowering Lugia and Ho-Oh to 60, but some fan games do). I'd suggest expanding it to seven bits, and maybe adding four or five bits for the type of Poké Ball.
Pokérus uses a whole byte for a rather complicated system allowing it to last 1–4 days. This could be replaced with 3 bits (0 = uninfected, 1–4 = days left, 5 = cured).
My projects on GitHub:
• Polished Map 4.5.4 or 2.5.4++
• Tilemap Studio 3.2.2
• Pokémon Polished Crystal 2.2.0 or 3.0.0 beta
• Pokémon Red★/Blue★: Space World Edition 2020-11-01
Offline
Please do 16-bit items. Also, I don't understand how PP can be one byte.
Offline
Please do 16-bit items. Also, I don't understand how PP can be one byte.
When in the box, each move can have 0-3 pp ups applied. The actual PP will be calculated upon withdrawing
I think pokerus can be shortened to 3 bits.
I'm almost thinking of starting the source code over from scratch, and taking a different approach which will be trying to add padding, making sure that still runs flawlessly, then slowly using the new padding data for extending Pokemon, Moves, and yes, items
This isn't easy to say, but…
Music and ASM hacker
Offline
I'd suggest for crystal, removing animations of front pics
Speaking of it...
Does anyone have a dump of non-animated crystal or gold/silver sprites? Like this but in a format compatible to the red/blue disassembly.
Offline
FroggestSpirit wrote:I'd suggest for crystal, removing animations of front pics
Speaking of it...
Does anyone have a dump of non-animated crystal or gold/silver sprites? Like this but in a format compatible to the red/blue disassembly.
https://github.com/dannye/pokered-gen-II That only has sprites for the original 151, but it's a start.
Last edited by Mateo (2016-09-18 15:48:56)
I am not very active on this forum. I only pop in from time to time.
Offline
Some of Crystal's sprites are clear improvements on both Gold and Silver, like Skarmory and Raikou. For others, if you're going with static sprites it's a matter of taste.
My projects on GitHub:
• Polished Map 4.5.4 or 2.5.4++
• Tilemap Studio 3.2.2
• Pokémon Polished Crystal 2.2.0 or 3.0.0 beta
• Pokémon Red★/Blue★: Space World Edition 2020-11-01
Offline
Nic7C5 wrote:FroggestSpirit wrote:I'd suggest for crystal, removing animations of front pics
Speaking of it...
Does anyone have a dump of non-animated crystal or gold/silver sprites? Like this but in a format compatible to the red/blue disassembly.
https://github.com/dannye/pokered-gen-II That only has sprites for the original 151, but it's a start.
That's what I want to "expand" aiming to write a program to insert pokemon (following the instructions of Schattenjäger and Danny).
Offline
How much data do the animations take up in Crystal? Is there a way to measure that? I could see the appeal of removing them even if they didn't take up any space at all, just so porting newer Pokémon is easier, not needing to make animations for them, but I'm just curious at how much room it would open up.
Offline
How much data do the animations take up in Crystal? Is there a way to measure that?
Rough guess, the extra sprite tiles are as large as 50%–100% of the static sprite. Some random samples:
There's also the bitmask and frame data for each one, but that ought to be smaller than graphic data; I doubt it adds up to more than another 50% each. So maybe removing all the animation data would make room for another 200–300 sprites or an equivalent amount of code.
You could go further and remove the functions for animating sprites at all, but that's a fixed cost, not per-Pokémon, and would be more for thoroughness than for freeing significant space.
Last edited by Rangi (2016-09-18 20:59:13)
My projects on GitHub:
• Polished Map 4.5.4 or 2.5.4++
• Tilemap Studio 3.2.2
• Pokémon Polished Crystal 2.2.0 or 3.0.0 beta
• Pokémon Red★/Blue★: Space World Edition 2020-11-01
Offline
Right now I broke the compilation (WRAM0 wont fit the new structures) but I did have the base data all converted to 2 byte index, with it properly loading. I'll try to fix that, but I still have quite a ways to go before it's useable. If anyone wants to prep sprites, that'd be cool
Edit: I reverted a few changes, and the code should now compile. Still not done obviously
Last edited by FroggestSpirit (2016-09-19 04:01:20)
This isn't easy to say, but…
Music and ASM hacker
Offline
I used a script to remove the animation data: for each Pokémon, front.2bpp.lz, anim0.asm, anim1.asm, bitmask.asm, and frames.asm have been trimmed. Sorry I can't make it a pull request, I already forked pret/pokecrystal as my own project so GitHub won't let me fork your pokecrystal20xx, but here's the pics folder. I missed a few Pokémon: Aipom, Cleffa, Delibird, Fearow, Goldeen, Hoppip, Igglybuff, Jumpluff, Lickitung, Natu, Questionmark, Seaking, Shuckle, Skiploom, Smoochum, Spearow, and Stantler. The rest should be okay.
Last edited by Rangi (2016-11-02 01:40:37)
My projects on GitHub:
• Polished Map 4.5.4 or 2.5.4++
• Tilemap Studio 3.2.2
• Pokémon Polished Crystal 2.2.0 or 3.0.0 beta
• Pokémon Red★/Blue★: Space World Edition 2020-11-01
Offline
I used a script to remove the animation data: for each Pokémon, front.2bpp.lz, anim0.asm, anim1.asm, bitmask.asm, and frames.asm have been trimmed. Sorry I can't make it a pull request, I already forked pret/pokecrystal as my own project so GitHub won't let me fork your pokecrystal20xx, but here's the pics folder. I missed a few Pokémon: Aipom, Cleffa, Delibird, Fearow, Goldeen, Hoppip, Igglybuff, Jumpluff, Lickitung, Natu, Questionmark, Seaking, Shuckle, Skiploom, Smoochum, Spearow, and Stantler. The rest should be okay.
You can use cherry-picking or rebasing to for example set up a branch with the initial pokecrystal commit as the first commit and then add some commits during your process on top of that. In that example of 'a' is the initial commit and 'b' would contain dozens of commits that you don't care about, 'c' up to 'f' would be the commits that modify those files you mentioned above, you could use that "git rebase --onto a b f" to set up a state where only commits from b to f are applied onto a.
Here a, b, c, d, e and f are commit ids as Github shows them.
Last edited by Miksy91 (2016-10-03 15:04:47)
Offline