tile pattern ordering in ROM

Discussion of hardware and software development for Super NES and Super Famicom.

Moderator: Moderators

Forum rules
  • For making cartridges of your Super NES games, see Reproduction.
Post Reply
psycopathicteen
Posts: 2937
Joined: Wed May 19, 2010 6:12 pm

tile pattern ordering in ROM

Post by psycopathicteen » Sun Apr 03, 2016 2:23 pm

Alisha upper kick.gif
Alisha upper kick.gif (9.77 KiB) Viewed 3313 times
As you can see, this animation takes up a large amount of empty space. All of my animations so far in my game are arranged in boxes with the 8x8 tiles stored going left to right, up to down. My metasprite format allows only one metasprite shape/size per animation, even though a character can have multiple animations that have different sizes. Usually it doesn't waste too much space, but in this case it does.

Because this takes up 96x96 pixels, it uses up 4.5 kB, which goes past the 4 kB DMA limit in my game. Thankfully, I can stuff this animation in a 128 x 64 box by taking out a couple never-used sprites from the top, and moving them to the side, without changing any animation code.

It still wastes a lot of space.
Alisha flipping.png
So should I keep the tiles arranged in a box, and just change the metasprite format to allow size changes in the middle of the animation, or should I ditch the box format as well?

thenewguy
Posts: 32
Joined: Wed Feb 03, 2016 10:39 pm

Re: tile pattern ordering in ROM

Post by thenewguy » Sun Apr 03, 2016 2:30 pm

Personally, I would suggest having your metasprite data allow for arbitrary positions and arbitrary numbers of sprites within the metasprite, so that you can use the absolute minimum amount of sprites needed to cover the actual non-empty area.

tepples
Posts: 22017
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: tile pattern ordering in ROM

Post by tepples » Sun Apr 03, 2016 2:31 pm

Metasprites in Haunted: Halloween '85 are organized as horizontal strips. Each strip is 4 bytes: a starting (x, y) and tile ID, and a fourth byte containing attribute bits (V flip, H flip, palette) for the strip as well as its width in tiles. The sprite plotting subroutine incrases the tile ID by an appropriate amount after each tile. Bit 0 of the starting tile ID tells whether the sprite uses different tiles when the sprite is flipped horizontally, such as the sprite containing the eyes and the 'p' on Donny's hat (which should become a 'q' when flipped).

psycopathicteen
Posts: 2937
Joined: Wed May 19, 2010 6:12 pm

Re: tile pattern ordering in ROM

Post by psycopathicteen » Sun Apr 03, 2016 5:43 pm

Does the tile ID point to where the pattern is stored in the ROM?

tepples
Posts: 22017
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: tile pattern ordering in ROM

Post by tepples » Sun Apr 03, 2016 6:19 pm

It's an OAM ID. In general terms, it points to an offset in tiles relative to the address of the frame's first tile.

User avatar
Drew Sebastino
Formerly Espozo
Posts: 3503
Joined: Mon Sep 15, 2014 4:35 pm
Location: Richmond, Virginia

Re: tile pattern ordering in ROM

Post by Drew Sebastino » Sun Apr 03, 2016 6:21 pm

psycopathicteen wrote: My metasprite format allows only one metasprite shape/size per animation
How did you go about even having this limitation?

psycopathicteen
Posts: 2937
Joined: Wed May 19, 2010 6:12 pm

Re: tile pattern ordering in ROM

Post by psycopathicteen » Sun Apr 03, 2016 6:39 pm

Espozo wrote:
psycopathicteen wrote: My metasprite format allows only one metasprite shape/size per animation
How did you go about even having this limitation?
The metasprite format contains the animation information, and the only thing different between frames is the ROM address.

tepples wrote:It's an OAM ID. In general terms, it points to an offset in tiles relative to the address of the frame's first tile.
Oh yeah, I forgot the NES's sprite patterns aren't set up in columns and rows like the SNES are.

TOUKO
Posts: 293
Joined: Mon Mar 30, 2015 10:14 am

Re: tile pattern ordering in ROM

Post by TOUKO » Tue Apr 05, 2016 6:29 am

It's strange to wasting that amount of VRAM(i know it's in ROM, but i think you load all that frame chunks in VRAM ) with 8x8 tiles . :shock:

I suppose it's for DMAing always the same amount of datas for each animation's frame ??,or simplify the metasprite datas ??

psycopathicteen
Posts: 2937
Joined: Wed May 19, 2010 6:12 pm

Re: tile pattern ordering in ROM

Post by psycopathicteen » Tue Apr 05, 2016 7:39 am

TOUKO wrote:It's strange to wasting that amount of VRAM with 8x8 tiles . :shock:

I suppose it's for DMAing the same amount of datas for each animation's frame ??
It's because optimizing every sprite is very time consuming.

Edit: I think I know a quick fix to my metasprite format. If the size word of the first sprite is greater than $8000, (as oppose to $0001 for 16x16 and $0002 for 32x32) then it's an array of metasprites, instead of a single metasprite.
Last edited by psycopathicteen on Tue Apr 05, 2016 8:18 am, edited 1 time in total.

TOUKO
Posts: 293
Joined: Mon Mar 30, 2015 10:14 am

Re: tile pattern ordering in ROM

Post by TOUKO » Tue Apr 05, 2016 7:51 am

I know, but if you don't want to waste ROM/VRAM like that, you have no choice .
Also the fact you are out of VRAM bandwidth, you must use a double buffer and eat more VRAM,IMO is not really efficient, even if it simplify your metasprite datas .

d4s
Posts: 92
Joined: Mon Jul 14, 2008 4:02 pm

Re: tile pattern ordering in ROM

Post by d4s » Tue Apr 05, 2016 3:57 pm

psycopathicteen wrote: So should I keep the tiles arranged in a box, and just change the metasprite format to allow size changes in the middle of the animation, or should I ditch the box format as well?
Your description of your animation data format is a bit vague, so I can not really comment on that.
I find it hard to believe, but it sounds to me like you're actually transferring tile data and reserving sprite tiles just to display all that empty green space.
That'd be a gigantic waste of vram space and vblank bandwidth.

Generally speaking, I think the sprite data format is mostly a trade-off between artist flexibility(arbitrarily shaped sprites or fixed size boxes?), code complexity(a complex animation engine can turn into a maintenance nightmare very quickly), vram size(how much space is wasted on empty areas?) and performance (number of sprite tiles that need to be processed for a given frame).
There's no single answer to that, it's a matter of preference and project constraints mostly.

Personally, I'm using a flexible approach with simultaneous arbitrary small(8x8) and big(32x32) tile numbers for each animation frame in combination with a converter tool that tries to find a good balance between tile data size and number of sprite tiles used.

Example: (not optimal, though. Ideally, you'd want to keep the number of tiles allocated for an animation to be equal across frames for each tile size)
Image

This approach yields ~0x500 bytes worth of sprite tile data per frame versus your original 0x1200.
However, I wouldn't readily recommend this, unless you absolutely have to use animations with wildly differing dimensions.
Simplicity is king.
psycopathicteen wrote:It's because optimizing every sprite is very time consuming.
That's why you write tools to automate the process.
Of course, there'll always be a corner case here and there that needs manual tweaking
but in general, build automation really goes a long way.

psycopathicteen
Posts: 2937
Joined: Wed May 19, 2010 6:12 pm

Re: tile pattern ordering in ROM

Post by psycopathicteen » Tue Apr 05, 2016 8:44 pm

Okay, I was able to sort them into 4 groups. Each of them 96x64, but with the tiles in a slightly different order. The arrows on the side explain how they fit.
Alisha flipping optimized.png

psycopathicteen
Posts: 2937
Joined: Wed May 19, 2010 6:12 pm

Re: tile pattern ordering in ROM

Post by psycopathicteen » Sat Apr 30, 2016 12:34 pm

I was able to optimize them down to a 64x64 area. I also tried to fit them in as less sprites as possible. I might as well optimize every animation to be under 64x64.

Another thing, I think I'll change my metasprite format slightly to be more human friendly. I have the individual sprites themselves stored with center-based coordinates. I find it confusing that if I'm using 16x16 and 32x32 I have to manually subtract 8 to be aligned with the 32x32 sprites. I'll keep objects themselves use center based coordinates, but I'll make the individual sprites top-left based in the metasprite data.
Alisha flipping optimized.png

Post Reply