RBY trouble with sprite: Y-flip

[Sawakita]

I created a "side-routine" that allows my game (pokemon blue) to load both compressed and un-compressed sprite.
As you can see:
[un-compressed sprite]


it works fine when the sprite is displayed in the intro (non-flipped).
But when you display a "non compressed" sprite for example in the dex, where the image is flipped, there's this trouble: the order of the columns(8bit wide) of the image is flipped, while the columns themselves aren't flipped so that the image results in this:
[un-compressed sprite]

Obviously compressed sprite still work perfectly, both flipped and un-flipped ones.
[compressed sprites]

Any idea on what could be the problem?

[Tauwasser]

You didn't implement the flipping? You will have to find the original flip mode and implement an if branch.

However, the RBGY compression is actually guaranteed to be the smallest possible size when you implement it right, so I think you should give it a try... Basically split color layers and look for most continuous whitespace (zeroes).

cYa,

Tauwasser

[Sawakita]

Sept 8, 2010 12:54:54 GMT -5 Tauwasser said:

You didn't implement the flipping? You will have to find the original flip mode and implement an if branch.

However, the RBGY compression is actually guaranteed to be the smallest possible size when you implement it right, so I think you should give it a try... Basically split color layers and look for most continuous whitespace (zeroes).

cYa,

Tauwasser

There is a flag that is set (1) when the program loads the image in the dex and reset (0) when it does not. If this flag is set it activates a routine located right before the print-on-screen routine. this routine swaps the nybbles of each byte in the sprite:

ROM0:170F FA AA D0 ld a,(d0aa) ;FlipFlag
ROM0:1712 A7 and a
ROM0:1713 28 0E jr z,1723

ROM0:1715 01 10 03 ld bc,0310
ROM0:1718 21 88 A1 ld hl,a188
ROM0:171B CB 36 swap (hl)
ROM0:171D 23 inc hl
ROM0:171E 0B dec bc
ROM0:171F 78 ld a,b
ROM0:1720 B1 or c
ROM0:1721 20 F8 jr nz,171b


I'm pretty sure that that flag is related to the flip-thingy, but if i implement that routine here's what i get:

(non flipped image is not affected, since flag remains reset)

Regarding your second advice, you know, i still go back reading your document, every now and then, but I still can't handle that algorithm. Maybe someday..

[Tauwasser]

I understood the problem the first time. The decompression routine swaps the buffer data when mirroring is selected, so you will have to do the same for your uncompressed data by hand. This is all I'm saying.

I also mentioned that you can learn a thing or two by trying to use the compression and build tools that implement it, because it is not as bad as the GSC compression once you have the color planes down.

cYa,

Tauwasser

[Mateo]

Would it be easier to make it so the Pokedex doesn't swap them? I never really saw the real point in them being swapped anyways. I guess it's so its like they are facing you either way or something, but still. Just a thought if it proves too annoying to fix the right way.

[Miksy91]

I'd also go with Mateo's idea.
But you could also check how the pokedex system works in Brown.

[Sawakita]

I rewrote the "flip" routine from scratch, now it all works fine!

[Mateo]

Good deal!