# Skeetendo

’Cause all games were better on the GBC

You are not logged in.

## #1 2013-12-09 15:35:40

erik19borgnia
Member
Registered: 2013-12-08
Post 2/32

### Calculating sprites offsets problems in R/B/Y

Well, I'm having a weird problem while calculating the sprites offsets (I think I'm doing something wrong or something is missing):

Let's simulate I'm going to modify Bulbasaur Sprites in Pokemon Red:
As the Bulbapedia says, the pokemon base stats is like:
PokedexNum BaseHP BaseAttack BaseDefense BaseSpeed BaseSpecial, etc (http://bulbapedia.bulbagarden.net/wiki/ … neration_I)

So, Bulbasaur should be like:
01 2D 31 31 2D 41 and so on (I supposed that those values would be enough to only fin one result)

Now on Hexecute, searching those values, I found at offset 000383DE:
012D 3131 2D41 1603 2D40 5500 40E5 4021 2D00 0003 A403 38C0 0308 0600

According with bulbapedia, there should be 4 bytes more after those I've searched (1603 2D40, type 1, type 2, Catch rate, base exp yield), then the front sprite size (55), and then the front and back sprites pointers (00 40 and E5 40)
Now I calculate the sprite offset by looking at the bulbapedia formula:

The bank in which the sprite is located is based on the internal id of the Pokémon:
id --------------- bank
0x15 ----------- 0x01
0xB6 ----------- 0x0B
0x00 to 0x1E -- 0x09
0x1F to 0x49 -- 0x0A
0x4A to 0x73 -- 0x0B
0x74 to 0x98 -- 0x0C
0x99 to 0xFF -- 0x0D

(Note: these values may not be correct for Yellow.)

The full offset to a sprite is then (bank << 14) + (pointer & 0x3fff).

Bulbasaur index number is 153, 0x99, so it's in bank 0x0D, that's 13 or 1101, then the formula would be:
(1101 << 14) + (0x0040 &  0x3fff) = 110100000000000000 + 000000000001000000 = 110100000001000000 = 0x34040

SO, 0x34040 should be the offset of the Bulbasaur sprite, but if I go there I see:
"C785 37A2 F58C etc", I feel confused, because the sprite starts with the sprite size!
So I look just a bit back in the hex (because Bulbasaur should be the first sprite in that bank, right?), and see that in 0x34000 is a 55, the Bulbasaur sprite size!
I wanted to do this way to learn, I know that there's a disassembly of Pokemon Red, so I looked at it, and yes, Bulbasaur front sprite offset is at 0x34000! So, what about that 0x40 error? Not only with Bulbasaur, but with Rhydon I got that 0x40 error too, but I can't understand why.

Also if I use that formula to get the backsprite of Bulbasaur, there's something weird:
E540 is the Bulbasaur backsprite pointer, a bit too high.
(1101 << 14) + (0xE540 &  0x3fff) = 110100000000000000 + 001110010101000000 = 1000010010101000000 (note that it has one more bit) = 0x42540, and I'm like WTF it should be right next to the front sprite, right?
(also, at that offset there are other things, starting with some 00)
Looking at the disassembly, Bulbasaur back sprite is at 0x340e5, after finishing the front sprite, and starting with 44 (like it should be, the backsprite size).

I think it possibly be something that I'm missing about the LSB and MSB, but if I use 40 00 and 40 E5 as the pointers, the formula gives totally weird numbers: 0x38000 and 0x380E5, both are 0x4000 away from the real offsets.

Ok, I think I've explained all, sorry for being so long.

Thank you!

Erik

PS: ALSO, I tried doing this on Yellow, and also got weird offsets...

Last edited by erik19borgnia (2013-12-09 15:37:17)

Offline

## #2 2013-12-09 20:56:23

comet
Member
Registered: 2012-04-09
Post 324/679

### Re: Calculating sprites offsets problems in R/B/Y

erik19borgnia wrote:

I think it possibly be something that I'm missing about the LSB and MSB, but if I use 40 00 and 40 E5 as the pointers, the formula gives totally weird numbers: 0x38000 and 0x380E5, both are 0x4000 away from the real offsets.

0x40e5 & 0x3fff is 0x00e5. you should be using windows calculator (view -> programmer) instead of trying to add stuff in binary

if youre wondering why it works this way, a pointer is actually a straight memory address. addresses 0x4000-0x7fff are mapped to a switchable 0x4000-byte rom bank. so memory address 0x4000 is actually the first byte of the bank

http://nocash.emubase.de/pandocs.htm#memorymap

Offline

## #3 2013-12-09 22:02:14

erik19borgnia
Member
Registered: 2013-12-08
Post 5/32

### Re: Calculating sprites offsets problems in R/B/Y

comet wrote:
erik19borgnia wrote:

I think it possibly be something that I'm missing about the LSB and MSB, but if I use 40 00 and 40 E5 as the pointers, the formula gives totally weird numbers: 0x38000 and 0x380E5, both are 0x4000 away from the real offsets.

0x40e5 & 0x3fff is 0x00e5. you should be using windows calculator (view -> programmer) instead of trying to add stuff in binary

if youre wondering why it works this way, a pointer is actually a straight memory address. addresses 0x4000-0x7fff are mapped to a switchable 0x4000-byte rom bank. so memory address 0x4000 is actually the first byte of the bank

http://nocash.emubase.de/pandocs.htm#memorymap

FFFFFFFFFFFFUUUUUUUUUUUUUUUUUUUUUUUUUUUU

You're totally right!!!
My god, why I fail in such a stupid calculation -.-!! That's why you shouldn't be doing this at 3 AM... I was reading one less 0 on the 0x040e5... Now that I see both numbers togheter, it's obvious that the 4 will vanish with the &...
Sorry for that! And thank you A LOT!!

Erik

PS: Also, thank you for that aclaration, I was wondering why the "& 0x3fff" :P!

PS2: And here is, my first modified sprite! :D

Yep, I forgot about the "white on the left" thing :P.

Last edited by erik19borgnia (2013-12-09 23:44:30)

Offline