Research: Battle Redesign Project: 80x80 sprites and more

Hello! As the title of the thread suggests, I'm looking into the possibility of revamping the battle look in 3rd Gen roms (read: Emerald) and implementing 80x80 sprites - the DPP standard - through tilemaps, as well as more minimalist HP boxes (instead of the ugly current ones that cover opposing Pokémon) and more. Essentially, this is the "look" I'd like to achieve:


As you can see, it is possible to have double battles on a 240x160 screen with 80x80 sprites, with a translucent, one-line text area at the bottom (marked in pink) and non-intrusive HP boxes. The HP Boxes are designed to accommodate up to 12-letter nicknames along with a gender sign and Mega symbol. To implement such a look I think would be worthwhile due to the much greater detail provided by larger sprites - a 59% increase in pixel count - as well as to simply use more of the screen space for the actual battle, as opposed to text and HP boxes.

Now, I don't know if the GBA can even support four tilemaps at once, but this is something I'm investigating and looking into implementing myself. I've been an on-and-off romhacker for a few years, and while my coding skills are strong, the structure of the game remains something of a mystery to me. I don't intend to bring people in here just to demand that they do the work for me, and in fact I expect the response to this thread to be lukewarm at best due to the effort people have already put into making excellent 64x64 sprites of all 807 Pokémon. I'm happy to pursue this myself, but I hope that this thread will allow anyone who is interested in the redesign to pool their knowledge and expertise here. Once I've collated what I know into a readable format, I'll be posting it here soon.

You will run out of tile space. You only have 0x7FFF VRAM space for the sprite image data, that computes to approximately 1024 4BPP tiles (a bit less). One 64x64 4BPP sprite takes up 8x8 tiles, which computes to 64 of these 1024 tiles. To make One 80x80 sprite, you need 4, thus each of these sprites take up 256 tiles.

With exactly 4 on the screen (double battle), you use up all the tiles, and lose out on the possibility for HP Box/HP Bar as well as battle animations unfortunately.

Obviously BGs are out of the question, hardware rotation and scaling for a BG applies to the entire BG, and thus you won't be able to control the battle entities on a case by case basis. It's also much slower, and a rotscale 256 color mode must be used costing a large amount of memory expenditure and probably removing the possibility to run BG battle animations.

In my opinion, you should wait or help with FBI's engine so it can be ported for Emerald.

FBI said:

You will run out of tile space. You only have 0x7FFF VRAM space for the sprite image data, that computes to approximately 1024 4BPP tiles (a bit less). One 64x64 4BPP sprite takes up 8x8 tiles, which computes to 64 of these 1024 tiles. To make One 80x80 sprite, you need 4, thus each of these sprites take up 256 tiles.

With exactly 4 on the screen (double battle), you use up all the tiles, and lose out on the possibility for HP Box/HP Bar as well as battle animations unfortunately.

Obviously BGs are out of the question, hardware rotation and scaling for a BG applies to the entire BG, and thus you won't be able to control the battle entities on a case by case basis. It's also much slower, and a rotscale 256 color mode must be used costing a large amount of memory expenditure and probably removing the possibility to run BG battle animations.

Click to expand...

Ah, sugar, I suspected that I'd be struck by limited memory space. Forgive my ignorance, but why is it not possible to have 10x10 tilemaps?

Delta231 said:

In my opinion, you should wait or help with FBI's engine so it can be ported for Emerald.

Click to expand...

I most certainly would contribute if I were not already working with a rombase built on the Emerald Battle Engine. And I have to say, FBI's engine does look very promising, but it's not quite the same as what I was hoping for.

Bozster said:

Ah, sugar, I suspected that I'd be struck by limited memory space. Forgive my ignorance, but why is it not possible to have 10x10 tilemaps?

Click to expand...

What are you referring to as tilemaps?

FBI said:

What are you referring to as tilemaps?

Click to expand...

Forgive me if my choice of vocabulary is improper; my understanding of tilemaps are, like OW maps and the World Map, an assignment of tiles from a tileset like the following:


to create a larger image called a tilemap:

Bozster said:

Forgive me if my choice of vocabulary is improper; my understanding of tilemaps are, like OW maps and the World Map, an assignment of tiles from a tileset like the following:

to create a larger image called a tilemap:

Click to expand...

Right, it specifies the arrangement and palette for a tile. However, sprites don't have tilemaps, this only applies to BGs. A sprite will always be restricted to it's 64x64px original sprite limit.

You're right in that you can merge multiple tilemaps into one BG, so displaying what you want dynamically is possible. It would be fine if you were on Mode 0 with no battle animations. You can merge the textbox tilemap during runtime with some BG and make it work (in my engine I'm merging the Textbox map so I can use multiple BGs for animation effects).

This completely falls on it's head though because of battle animations. For one, you cannot perform rotation/scaling effects on only an individual actor. It would apply the animation to everything on that BG. Second Rotscale modes enforce 8BPP BGs and all of them limit usable BGs to 2 or 3 (depending on the mode), so not only are your Pokemon Sprites heavy on the ROM, but usable BGs are restricted, and certain operations require more computation time to do. All in all, it's not feasible to use BGs for this.

I think the OAM system is the only way, for which the 64x64 limit you'll just have to live with. It's unfortunate, but it's the reality of hacking a GBA game. I also gave this sort of idea a lot of thought when I was designing/making my own engine.

I've seen a similar idea using BGs by Bugmania here: https://www.youtube.com/watch?v=dkUYplAqZOg
Big takeaways would be the large FPS drop/clunkyness and that it's single battles :P

FBI said:

Right, it specifies the arrangement and palette for a tile. However, sprites don't have tilemaps, this only applies to BGs. A sprite will always be restricted to it's 64x64px original sprite limit.

You're right in that you can merge multiple tilemaps into one BG, so displaying what you want dynamically is possible. It would be fine if you were on Mode 0 with no battle animations. You can merge the textbox tilemap during runtime with some BG and make it work (in my engine I'm merging the Textbox map so I can use multiple BGs for animation effects).

This completely falls on it's head though because of battle animations. For one, you cannot perform rotation/scaling effects on only an individual actor. It would apply the animation to everything on that BG. Second Rotscale modes enforce 8BPP BGs and all of them limit usable BGs to 2 or 3 (depending on the mode), so not only are your Pokemon Sprites heavy on the ROM, but usable BGs are restricted, and certain operations require more computation time to do. All in all, it's not feasible to use BGs for this.

I think the OAM system is the only way, for which the 64x64 limit you'll just have to live with. It's unfortunate, but it's the reality of hacking a GBA game. I also gave this sort of idea a lot of thought when I was designing/making my own engine.

I've seen a similar idea using BGs by Bugmania here: https://www.youtube.com/watch?v=dkUYplAqZOg
Big takeaways would be the large FPS drop/clunkyness and that it's single battles :P

Click to expand...

I see, thanks very much for the detailed response! Boy, I really should have looked more into the hardware before just trying to code it. (Then again, hardware limitations have never been anything I've ever had to consider for coding projects.)

I may just be barking up the wrong tree here now, but... are 40x40 sprites a possibility? After all, the game has 24x24, 40x40 and 64x64 sprites. If so, one could split each 80x80 sprite into four - and with sixteen for four mons in a double battle, this would take up a total of 400 tiles. To save a bit of VRAM after, it would be possible to have HP boxes disappear while a move animation is displayed (as occurs in 4th gen games anyway).

Bozster said:

I see, thanks very much for the detailed response! Boy, I really should have looked more into the hardware before just trying to code it. (Then again, hardware limitations have never been anything I've ever had to consider for coding projects.)

I may just be barking up the wrong tree here now, but... are 40x40 sprites a possibility? After all, the game has 24x24, 40x40 and 64x64 sprites. If so, one could split each 80x80 sprite into four - and with sixteen for four mons in a double battle, this would take up a total of 400 tiles. To save a bit of VRAM after, it would be possible to have HP boxes disappear while a move animation is displayed (as occurs in 4th gen games anyway).

Click to expand...

http://problemkaputt.de/gbatek.htm#lcdobjoamattributes

Specifically:

14-15 OBJ Size (0..3, depends on OBJ Shape, see Attr 0)
Size Square Horizontal Vertical
0 8x8 16x8 8x16
1 16x16 32x8 8x32
2 32x32 32x16 16x32
3 64x64 64x32 32x64

Click to expand...

These are the dimension restrictions on OAMs. Remember if you cut up a sprite into multiple OAMs you'll need to link them manually.

FBI said:

http://problemkaputt.de/gbatek.htm#lcdobjoamattributes

Specifically:

These are the dimension restrictions on OAMs. Remember if you cut up a sprite into multiple OAMs you'll need to link them manually.

Click to expand...

Ah, sugar, that is annoying - thanks for linking that page, I hadn't been able to find it before! It looks like I'd have to stitch twenty-five 16x16 sprites together to make one 80x80 sprite! (Or alternatively, nine 32x32 sprites). Maybe this isn't worth it.

Thanks very much for your patient and eloquent responses, I reckon it would make more sense to help finish the remaining moves for your battle system after all - and maybe see if I can help port it over to Emerald!

Bozster said:

I most certainly would contribute if I were not already working with a rombase built on the Emerald Battle Engine. And I have to say, FBI's engine does look very promising, but it's not quite the same as what I was hoping for.

Click to expand...

You really think that? :thonk:

Delta231 said:

You really think that? :thonk:

Click to expand...

By "not what I was hoping for", I'm referring of course to 80x80 sprites. Please don't write posts that add nothing to the discussion. :thonk:

FBI said:

http://problemkaputt.de/gbatek.htm#lcdobjoamattributes

Specifically:

These are the dimension restrictions on OAMs. Remember if you cut up a sprite into multiple OAMs you'll need to link them manually.

Click to expand...

Thanks again for your helpful responses so far! I may be foolhardy now but...

I think I know it would be implemented now but the question is whether or not it would be worth it. Since it is possible to display 128 OBJ at a time, one could have, in a double battle, four 80x80 sprites represented by matrices of five-by-five 16x16 "sub-sprites", using 100 total OBJ and 400 tiles (thus leaving plenty of space for HP boxes and so on). I'm not sure whether or not transformations can be applied to a matrix of OBJ such that they behave as one sprite (for example, if rotated, each OBJ would rotate about its own axis as opposed to one coordinated axis), which would make Emerald-type Pokémon animations and some move animations impossible. However, simple translation and palette swapping should be possible so they wouldn't be completely lifeless. I feel it's worth giving it a go.

My last question for now then, is this: if I really wanted to include Emerald-style animations (expansion and contraction) as well as some move animations like Minimise, would the GBA even be able to handle this for a 25-sprite matrix?

Bozster said:

Thanks again for your helpful responses so far! I may be foolhardy now but...

I think I know it would be implemented now but the question is whether or not it would be worth it. Since it is possible to display 128 OBJ at a time, one could have, in a double battle, four 80x80 sprites represented by matrices of five-by-five 16x16 "sub-sprites", using 100 total OBJ and 400 tiles (thus leaving plenty of space for HP boxes and so on). I'm not sure whether or not transformations can be applied to a matrix of OBJ such that they behave as one sprite (for example, if rotated, each OBJ would rotate about its own axis as opposed to one coordinated axis), which would make Emerald-type Pokémon animations and some move animations impossible. However, simple translation and palette swapping should be possible so they wouldn't be completely lifeless. I feel it's worth giving it a go.

My last question for now then, is this: if I really wanted to include Emerald-style animations (expansion and contraction) as well as some move animations like Minimise, would the GBA even be able to handle this for a 25-sprite matrix?

Click to expand...

This is something I haven't tested. There should be only 31 OAMs available for affine transformations (the matrix ID must be 5 bits). However, I *think* you may be able to point X OAMs to the same transformation matrix. If I were you, I'd test that theory before pursuing it further. A lot of this is riding on that technical feature working out.

It should be also noted that of these 128 displayable objects, GameFreak's Object system is only capable of handling 64 objects, so you'll end up having to do this by hand. In addition, if you wish to recycle the default engine animations, those also use the GF object system, so you'd be in a delicate situation.

As for whether or not its worth it, I think it's worthwhile if you want it for you hack. Just be careful of burning yourself out.
imo this is quite tedious and the GBA isn't the right platform for it. The hardware is old, slow, and only maintains a 60fps because of its measly 240x160 pixel resolution.