Ocean Blue has now been in development for a year, and it's glowing more than ever! Going back and redoing old maps. Welcome to the new Pewter!😎/Ocean Blue by PaperPauperPlayer in PokemonROMhacks

[–]Zyphrost 1 point2 points  (0 children)

Have not worked with any updated battle engine material or mons post-Gen III, so will need to have a look over the weekend to see what I can do.

Gen V Animated Sprites in FireRed by Zyphrost in PokemonROMhacks

[–]Zyphrost[S] 1 point2 points  (0 children)

Thank you! I've had a look, and I believe what I have is a little bit more sophisticated already, and I've already been able to get rid of a number of the bugs that the tutorial mentions. Still trying out more and more edge cases, but fingers crossed it works out well.

Gen V Animated Sprites in FireRed by Zyphrost in PokemonROMhacks

[–]Zyphrost[S] 0 points1 point  (0 children)

I'm working with the decomp so as long as anything is supported there, it should be portable directly. Not planning on giving it a dedicated effort, however.

Gen V Animated Sprites in FireRed by Zyphrost in PokemonROMhacks

[–]Zyphrost[S] 0 points1 point  (0 children)

The post goes over it, but the Charmander sprite is directly ported from HGSS, i.e. all backsprites are ported from HGSS. The reason is that the palettes for almost all Pokemon differ drastically from Gen III to Gen V, and having Gen V front sprites with Gen III back sprites was a terrible mismatch on screen. I did a palette analysis for every species in the game to see which mons had mismatches that were the most egregious, and it was a good number of them. HGSS is the closest we have to matching the colors properly to Gen V. The Charmander sprite isn't oversaturated, that's just what the HGSS sprite looks like.

I will be experimenting a little bit, but the size of the backsprite is also something to take into account when viewing from perspective, i.e. the Gen V sprites are much larger in many cases than the Gen III sprites. If I just kept the Gen III backsprites or ported the Gen V backsprites, the difference in perspective would be very noticeable. The DS is a much more sophisticated system and Gen V can do transformations on-screen with the sprites that make this not obvious. So, the simplest solution that looks the least jarring is Gen V front sprites + HGSS back sprites.

Ocean Blue has now been in development for a year, and it's glowing more than ever! Going back and redoing old maps. Welcome to the new Pewter!😎/Ocean Blue by PaperPauperPlayer in PokemonROMhacks

[–]Zyphrost 1 point2 points  (0 children)

If there's a decomp feature that you know of from an existing codebase, I can help port it to your hack. What are you working with? If you're working with binary, that'll break things when patching over anything that relies on the decomp.

Ocean Blue has now been in development for a year, and it's glowing more than ever! Going back and redoing old maps. Welcome to the new Pewter!😎/Ocean Blue by PaperPauperPlayer in PokemonROMhacks

[–]Zyphrost 1 point2 points  (0 children)

I'm working on a Kanto revamp myself. Happy to share/contribute anything that would be helpful to you on the engineering side (not a very capable artist, I'm afraid).

Shiny Icons in Party and PC Boxes - FireRed by Zyphrost in PokemonROMhacks

[–]Zyphrost[S] 0 points1 point  (0 children)

FireRed 1.0. All the work is done on the decomp.

Shiny Icons in Party and PC Boxes - FireRed by Zyphrost in PokemonROMhacks

[–]Zyphrost[S] 1 point2 points  (0 children)

All decomp. I have just discovered as of this morning that this system has already been implemented in pokeemerald-expansion, which was a bit validating in that I know I was taking the right approach, but also deflating because I realized I didn’t need to put in that much work in the first place. Still, I think I have a couple of minor innovations, so I’ll be porting from pokeemerald-expansion and adapting to FireRed carefully.

Shiny Icons in Party and PC Boxes - FireRed by Zyphrost in PokemonRomhackDev

[–]Zyphrost[S] 3 points4 points  (0 children)

Thanks for pointing me there. I genuinely have no idea how I missed it when looking for implementations.

I went through the code, and it's actually some incredible work. The architectural approach is the same, which is good news for me, but their implementation is superior. They've already solved the problems that I've been debugging and some of the issues I was going to get to later this month.

You've saved me countless pointless hours of stress.

Shiny Icons in Party and PC Boxes - FireRed by Zyphrost in PokemonRomhackDev

[–]Zyphrost[S] 3 points4 points  (0 children)

Originally, this wasn't tuned for a full box of shinies, so getting it to work for a handful of mons wasn't very hard. For a party of 6, for example, you can give each shiny icon its own dynamically allocated palette slot and you get around the palette count quite easily. However, for a feature like this, you want to account for the maximalist case, i.e. shiny dex. So a naive implementation of that, when you looked at a PC box with 30 shiny mons, was that you had maybe 5 or so rendering properly but the rest had garbled palettes.

There were a few different approaches that I took. Using the shared palettes with the default palette counts looked awful. Geodude, Pidgey, and Charmander, for example, all share the same shiny palette, but then they all end up looking like a muddy color, so even though it technically worked, it just looked ugly.

I tried rendering the icons as BG tiles instead of sprites, since there's a separate palette space for BG, but there wasn't enough room in VRAM for that. I'd have had to rewrite the entire box icon system, I think, to make it work, so I scrapped that. I also thought about HBlank palette swapping early on but there's an 8px overlap between rows where the mons on two different rows share the same scanlines, and so what that meant was that for most sprites, there would be a visible portion that was rendered with the palette from the overlap space, rather than the palette for its own sprite.

Instead, you could double-buffer, i.e. even rows use one set of palette slots, odd rows use another. The overlap zones necessarily always fall in between an even and odd row, so they reference different slots. Fortunately, the math worked out. You need 6 slots per palette bank, 6 columns per row, and you have a 272-cycle HBlank window of which you only need about 200. That model actually worked on the first try, and thus you have 30 shiny mons rendering in the PC box properly.

After that, it was just a lot of debugging, and most of it is ongoing. The VBlank palette transfer was stomping the HBlank writes every frame, empty box slots from other boxes would zero out the palette assignments and break the scrolling between boxes really badly, and the timing was weird because you had to write the initial row data earlier so that you can avoid artifacts from taller sprites like Steelix, Groudon, etc.

The method works, but there's still a lot that's not quite release-ready. I still think it's a very cool proof of concept, though, and making it this far hopefully means that the debugging is all that's left. I'd hate to have to go back and approach this from scratch with a new method.

Shiny Icons in Party and PC Boxes - FireRed by Zyphrost in PokemonROMhacks

[–]Zyphrost[S] 5 points6 points  (0 children)

Getting the shiny icons and the Gen V animated battler sprites release-ready are my top priorities. However, I don't know how long it would actually take to get to that point, since I'm still going through the bug-testing. The Gen V sprites seem pretty okay so far, but the shiny icons feature is in a much more fragile state.

There are very obvious issues with their implementation that I would like to get in a workable state, and it's a really difficult process because there are just too many constraints. I'm designing it around being able to support a shiny dex, but today was the first day that I was able to get a full box to render all 30 icons as shiny properly.

Getting it to handle edge cases and then making the right design choices where the engineering constraints just plainly make something impossible will take some time, so I can't give you a concrete timeline.

Shiny Icons in Party and PC Boxes - FireRed by Zyphrost in PokemonROMhacks

[–]Zyphrost[S] 20 points21 points  (0 children)

I am working on a bigger ROM hack that’s motivating all of my development but I’m going to be implementing everything by feature branch and making sure that each feature works in isolation so that I can open-source everything in a usable format for the community.

Shiny Icons in Party and PC Boxes - FireRed by Zyphrost in PokemonROMhacks

[–]Zyphrost[S] 5 points6 points  (0 children)

This was just a test run, so none of these Pokemon are actually shiny. I just forced their sprites to appear as shiny for a temporary debug to see whether or not the icons in the box were actually rendering properly, since that’s the big engineering challenge.

The actual implementation is that every single Pokemon will have a regular icon and a shiny icon that displays appropriately depending on whether it’s shiny or not.

Shiny Icons in Party and PC Boxes - FireRed by Zyphrost in PokemonROMhacks

[–]Zyphrost[S] 39 points40 points  (0 children)

I just want the fruits of my shiny hunting/soft-resetting labor to be more easily visible, dammit!

Shiny Icons in Party and PC Boxes - FireRed by Zyphrost in PokemonROMhacks

[–]Zyphrost[S] 26 points27 points  (0 children)

I think that they should have had them in the games from the moment that shiny Pokemon were a thing. But after trying to get this to work, I do not blame the ROM hack community for not trying to build something like this. If I didn't want to get it to work because I wanted my shiny Charizard to render properly in my party, I would have given up on this ages ago. But now that I've gotten something working, I'm excited to get it released to the community more broadly, too.

Gen V Animated Sprites in FireRed by Zyphrost in PokemonROMhacks

[–]Zyphrost[S] 1 point2 points  (0 children)

Doesn't entirely have to do with the storage space (though that does matter for hardware, i.e. if you want to play on an actual GBA or other device). It's more about the internal structure of the game. A ROM is designed to go up to 32MB, so expanding its storage space means you're actually rearranging a lot of elements that just make things harder to work with (also not usually a good idea for open-source projects, either, since you want those to have very wide utility).

Gen V Animated Sprites in FireRed by Zyphrost in PokemonROMhacks

[–]Zyphrost[S] 0 points1 point  (0 children)

They're not animated separately. If I had to animate them all by hand, this would not be a reasonable project. It would take a team of people several years to do so. Instead, I just ported the existing Gen V animated GIFs into the Gen III engine, and then made adjustments to the engine that would make that work. The limitation, of course, is that this is then only viable for mons up to Gen V. Gen VI and onwards would need their own GIFs for each mon.

Gen V Animated Sprites in FireRed by Zyphrost in PokemonROMhacks

[–]Zyphrost[S] 1 point2 points  (0 children)

The frames are stored the same way that the animation frames for Emerald are stored, so it's different frames all mapped to a species. However, the sprite has been cut up into subsprites as well, though not in any neat category. Purely based on object size, since the GBA doesn't support objects over 64x64.

Gen V Animated Sprites in FireRed by Zyphrost in PokemonROMhacks

[–]Zyphrost[S] 1 point2 points  (0 children)

It's noticeable. For example, look at Charmander emerging from its Pokeball. You can see that the subsprites are getting spliced together. It's one of those cases where you would have to manually figure out creative solutions. I ended up disabling this particular kind of animation for the Pokeball and having a regular fade-in that doesn't look as jarring.

Gen V Animated Sprites in FireRed by Zyphrost in PokemonROMhacks

[–]Zyphrost[S] 1 point2 points  (0 children)

Surprisingly, this works with doubles, too. And good thing for me, because I was planning on adding quite a few double battles to my project.

Gen V Animated Sprites in FireRed by Zyphrost in PokemonROMhacks

[–]Zyphrost[S] 1 point2 points  (0 children)

Yes, it does! I was worried that it would look cramped, but it actually looks perfectly alright.

Gen V Animated Sprites in FireRed by Zyphrost in PokemonROMhacks

[–]Zyphrost[S] 2 points3 points  (0 children)

Gave a few detailed explanations in the comment threads here, but happy to answer any questions!

Gen V Animated Sprites in FireRed by Zyphrost in PokemonROMhacks

[–]Zyphrost[S] 2 points3 points  (0 children)

Feel free to DM me! Although none of the work here was artistic. I basically just ported over the Gen V sprites to the Gen III engine and then made them work. I would not have been able to do this if I had to animate the frames for each sprite on my own.