Skeetendo

’Cause all games were better on the GBC

You are not logged in.

#1 2012-07-03 06:35:42

Danny-E 33
Administrator
Registered: 2012-06-09
Post 27/1,025

Pokemon Red: Palettes

Hi,
I was wondering if there was someone who knows a bit about the palettes that each Pokemon use. The palettes for the Pokemon sprites start at 0x726E0 and go to 0x7272F. With each palette 8 bytes long, that means every Pokemon shares 10 unique palettes. I was wondering if there is a table somewhere that matches each Pokemon id with a palette number? Perhaps palette numbers 0xF-0x18, since there are palettes before the sprite palettes that are used for the towns, routes, Town Map, and titlescreen. Perhaps these palettes are referenced to by the towns, routes, Town Map, and titlescreen as palettes 0x0-0xE? Also, is there maybe a pointer to this table that I can change for the purpose of moving the table where there is plenty of room and add many more palettes and change which palette number is associated with each Pokemon id so each Pokemon (or at least most) can have their own palette rather than sharing just a few of them?

Most of these ideas are just theories by me that seem to make sense as far structure and how it is decided which palette to use for each Pokemon. The only thing that I really know about all of this is where the palettes are located. If Pokemon palette assignments are actually chosen completely differently, perhaps someone can correct me :)

Thanks
~Danny-E 33


Red Hack: Pokémon Prototype

Total number of registered users: 7000+
Total number of active users: ~12

Offline

#3 2012-07-03 15:17:09

Danny-E 33
Administrator
Registered: 2012-06-09
Post 28/1,025

Re: Pokemon Red: Palettes

IIMarckus wrote:

0x725c8, one byte per Pokémon, Pokédex order. Valid palettes can be any of the overworld route palettes or Pokémon palettes, so palette 03 is Viridian City, …, 16 is Bulbasaur/Ivysaur/Venusaur, etc.

Oh wow. Thank you :) I'm sorry for not finding this on my own.
So the end of palette data seems to be at 0x7278F and if I added 8 bytes for 141 more Pokemon, that would make the end of the table at 0x72BF7. Is any of the data between 0x7278F and 0x72BF7 used for a valid purpose or can that data be overwritten? If that data is important, is there a pointer that I can change so I can move the start of that table from 0x72660 (route palette) to somewhere where every palette will fit?
And are you saying there is no palette number 0? So the towns, routes, Town Map, and titlescreen actually use palette numbers 0x1-0xF and the current 10 Pokemon palettes are palettes 0x10-0x19? Thanks for your help :)


~Danny-E 33


Red Hack: Pokémon Prototype

Total number of registered users: 7000+
Total number of active users: ~12

Offline

#4 2012-07-04 00:57:23

476/700

Re: Pokemon Red: Palettes

Danny-E 33 wrote:

So the end of palette data seems to be at 0x7278F

No, that’s not the end of the data.

Where does the data start? How much space does each entry take, and how many entries are there? Use that reasoning to find the end, then check to see if it makes sense (e.g., change the last byte and make sure Mew’s palette changes).

Danny-E 33 wrote:

and if I added 8 bytes for 141 more Pokemon

That’s not right. Where did you get 8 bytes from? Each Pokémon’s palette ID is one byte. Each palette’s colors take up two bytes. Neither of those equals 8.

Danny-E 33 wrote:

Is any of the data between 0x7278F and 0x72BF7 used for a valid purpose or can that data be overwritten?

Always assume data is important unless you specifically know otherwise.

Danny-E 33 wrote:

If that data is important, is there a pointer that I can change so I can move the start of that table from 0x72660 (route palette) to somewhere where every palette will fit?

Yes, there is a pointer. Do you know how to calculate a two‐byte pointer from an offset? Do that, then search for the pointer within that bank and change it.

Danny-E 33 wrote:

And are you saying there is no palette number 0?

No, I never said that. There is a palette 0; it’s used for routes.

The format of all this is described in the disassembly, main.asm, under “MonsterPalettes”. It will probably slow down your browser, so I would download the zip from that link and open the file in a text editor.

#5 2012-07-04 02:29:52

Danny-E 33
Administrator
Registered: 2012-06-09
Post 29/1,025

Re: Pokemon Red: Palettes

I'm sorry, I think we have a few misunderstandings...

IIMarckus wrote:
Danny-E 33 wrote:

So the end of palette data seems to be at 0x7278F

No, that’s not the end of the data.

Where does the data start? How much space does each entry take, and how many entries are there? Use that reasoning to find the end, then check to see if it makes sense (e.g., change the last byte and make sure Mew’s palette changes).

Ok. Palette data starts at 0x72660 with the route palette. It continues with the several town palettes. Then at 0x726C0 there is the Town Map palette which is not documented in the Red/Blue Rom Map. Then the titlscreen palettes, then the ten sprite palettes followed by misc. palettes ending with the border palette which ends at 0x7278F (according to the Red/Blue Rom Map). Where am I wrong?

However, the Red/Blue Rom Map states that the border palette is in fact at 0x72788-0x7278F. But when I look for myself, it appears that the border palette is actually at 0x72780-0x72787 - a location that does not have a documented palette in the Red/Blue Rom map. It seems that the original location I stated for the border palette as ending at 0x7278F is not a palette at all and is full of unrelated data. I believe this is a simple mistake in the Rom Map, and the border palette is actually 8 bytes earlier than documented. (the size of one palette)

IIMarckus wrote:
Danny-E 33 wrote:

and if I added 8 bytes for 141 more Pokemon

That’s not right. Where did you get 8 bytes from? Each Pokémon’s palette ID is one byte. Each palette’s colors take up two bytes. Neither of those equals 8.

Each palette's colors take up two bytes and there are four colors in a palette that is used by a Pokemon Sprite. White, light shade, dark shade, black. So each palette entry is 8 bytes long. There are already 10 palettes that can be used for Pokemon, so I would add 141 more entries at the end of this palette list after the border palette. Again, I do not understand why I am wrong...

IIMarckus wrote:
Danny-E 33 wrote:

Is any of the data between 0x7278F and 0x72BF7 used for a valid purpose or can that data be overwritten?

Always assume data is important unless you specifically know otherwise.

I'm fine with that, I was only wondering if anyone already new it wasn't actually used for anything.

IIMarckus wrote:
Danny-E 33 wrote:

If that data is important, is there a pointer that I can change so I can move the start of that table from 0x72660 (route palette) to somewhere where every palette will fit?

Yes, there is a pointer. Do you know how to calculate a two‐byte pointer from an offset? Do that, then search for the pointer within that bank and change it.

Yes, I have a full understanding of pointers. I'm sure I can figure this out.

IIMarckus wrote:
Danny-E 33 wrote:

And are you saying there is no palette number 0?

No, I never said that. There is a palette 0; it’s used for routes.

IIMarckus wrote:

Valid palettes can be any of the overworld route palettes or Pokémon palettes, so palette 03 is Viridian City, …, 16 is Bulbasaur/Ivysaur/Venusaur, etc.

You say that the route palette is palette 0. But you say that the Viridian City palette is palette 3. The only palette inbetween those is the Pallet Town palette, so one of those statements is false.

Also, going by one order, the green palette used for Bulbasaur/Ivysaur/Venusaur could be palette 0x15 or it could be palette 0x16 according to the two different ways you have described...

IIMarckus wrote:

The format of all this is described in the disassembly, main.asm, under “MonsterPalettes”. It will probably slow down your browser, so I would download the zip from that link and open the file in a text editor.

Yes, I have had this downloaded for a long time, but I have trouble with knowing what I'm looking at due to my lack of asm knowledge, which I am diligently working on by the way.

EDIT: Also, I have had a horrible day. I was in a car accident earlier and today has been very sressful. I tired to make sure I didn't say anything too offending, but if I still came off as rude and ignorant I sincerely apologize...

EDIT2: Seeing as the first three bytes in the palette assignment table at 0x725C8 are 16 16 16 for Bulbasaur/Ivysaur/Venusaur, this suggests that "palette 0" is not a used palette and the route palette simply starts off as palette 1. So I believe your statement in the old thread was correct.

Last edited by Danny-E 33 (2012-07-04 04:15:03)


Red Hack: Pokémon Prototype

Total number of registered users: 7000+
Total number of active users: ~12

Offline

#6 2012-07-04 04:20:54

477/700

Re: Pokemon Red: Palettes

Danny-E 33 wrote:

I'm sorry, I think we have a few misunderstandings...

Yes, mostly on my end. I thought you were talking about the data at 0x725c8, not 0x72660. And somehow I came up with the idea that palettes are only one color… obviously I need more sleep.

Danny-E 33 wrote:

Ok. Palette data starts at 0x72660 with the route palette. It continues with the several town palettes. Then at 0x726C0 there is the Town Map palette which is not documented in the Red/Blue Rom Map. Then the titlscreen palettes, then the ten sprite palettes followed by misc. palettes ending with the border palette which ends at 0x7278F (according to the Red/Blue Rom Map). Where am I wrong?

There are $25 palettes total. The palettes end at 0x72787. I assumed you made a math error, but it looks like the Datacrystal ROM map leaves the last palette out.

Danny-E 33 wrote:

However, the Red/Blue Rom Map states that the border palette is in fact at 0x72788-0x7278F.

No, that’s a case of bad naming in the ROM map. The “border palette” is really a list of palette IDs that make up the border; the data ranges from 0x72788–72E88.

Danny-E 33 wrote:
IIMarckus wrote:
Danny-E 33 wrote:

Is any of the data between 0x7278F and 0x72BF7 used for a valid purpose or can that data be overwritten?

Always assume data is important unless you specifically know otherwise.

I'm fine with that, I was only wondering if anyone already new it wasn't actually used for anything.

It is used for something: the border palettes (among other things). Until you know what you’re doing, the only space you should overwrite is the set of 00s at the end of a bank.

Danny-E 33 wrote:

You say that the route palette is palette 0. But you say that the Viridian City palette is palette 3. The only palette inbetween those is the Pallet Town palette, so one of those statements is false.

Correct. The old post made by me should list Viridian City as palette 2.

This is one of the current problems with hacking: existing documentation (like ROM maps or forum posts) are often subtly wrong. That’s why it’s important to confirm the data yourself through testing. It also gives you a more intuitive understanding of the format.

Danny-E 33 wrote:
IIMarckus wrote:

The format of all this is described in the disassembly, main.asm, under “MonsterPalettes”. It will probably slow down your browser, so I would download the zip from that link and open the file in a text editor.

Yes, I have had this downloaded for a long time, but I have trouble with knowing what I'm looking at due to my lack of asm knowledge, which I am diligently working on by the way.

Crash course of MonsterPalettes:

db PAL_GREENMON ; BULBASAUR

Anything to the right of a semicolon ; is a comment.

db means “define byte”, and puts a literal byte in the file.

Constants for palette names are defined in constants.asm, under “super game boy palettes”. PAL_GREENMON is equivalent to writing $16.

So this block:

db PAL_MEWMON    ; MISSINGNO
db PAL_GREENMON  ; BULBASAUR
db PAL_GREENMON  ; IVYSAUR
db PAL_GREENMON  ; VENUSAUR
db PAL_REDMON    ; CHARMANDER
db PAL_REDMON    ; CHARMELEON
db PAL_REDMON    ; CHARIZARD
db PAL_CYANMON   ; SQUIRTLE
db PAL_CYANMON   ; WARTORTLE
db PAL_CYANMON   ; BLASTOISE

Is equivalent to these bytes:

10 16 16 16 12 12 12 13 13 13

Further down are the actual palette definitions. As you may know, computers usually represent colors as a collection of red, green, and blue intensity. In the case of the Super Game Boy, a color is a 16‐bit integer with 5 bits per color plus one unused bit.

RGB 31,29,31 ; PAL_ROUTE
RGB 21,28,11
RGB 20,26,31
RGB 3,2,2

RGB is a macro (defined in constants.asm) that converts its three arguments into a single 16‐bit integer and places it into the ROM, so we don’t have to do the conversion manually. If you do the math, you’ll see that the above is equivalent to the bytes:

bf 7f 95 2f 54 7f 43 08

#7 2012-07-04 06:21:41

Danny-E 33
Administrator
Registered: 2012-06-09
Post 31/1,025

Re: Pokemon Red: Palettes

IIMarckus wrote:
Danny-E 33 wrote:

I'm sorry, I think we have a few misunderstandings...

Yes, mostly on my end. I thought you were talking about the data at 0x725c8, not 0x72660. And somehow I came up with the idea that palettes are only one color… obviously I need more sleep.

That's alright. No biggie

IIMarckus wrote:
Danny-E 33 wrote:

Ok. Palette data starts at 0x72660 with the route palette. It continues with the several town palettes. Then at 0x726C0 there is the Town Map palette which is not documented in the Red/Blue Rom Map. Then the titlscreen palettes, then the ten sprite palettes followed by misc. palettes ending with the border palette which ends at 0x7278F (according to the Red/Blue Rom Map). Where am I wrong?

There are $25 palettes total. The palettes end at 0x72787. I assumed you made a math error, but it looks like the Datacrystal ROM map leaves the last palette out.

So if I were to repoint the palette table, I should copy from 0x72660 to 0x72787, right? And I should leave 0x72788 and onward right where it is?
And when I do this, palette id's 0x25, 0x26 and so on will all read accurately from a table that's longer than it originally was? Of course as long as I use less than 256 palettes but that won't be a problem.

IIMarckus wrote:
Danny-E 33 wrote:

However, the Red/Blue Rom Map states that the border palette is in fact at 0x72788-0x7278F.

No, that’s a case of bad naming in the ROM map. The “border palette” is really a list of palette IDs that make up the border; the data ranges from 0x72788–72E88.

Danny-E 33 wrote:
IIMarckus wrote:

Always assume data is important unless you specifically know otherwise.

I'm fine with that, I was only wondering if anyone already new it wasn't actually used for anything.

It is used for something: the border palettes (among other things). Until you know what you’re doing, the only space you should overwrite is the set of 00s at the end of a bank.

Oh! Okay, thanks for clearing that all up :)

IIMarckus wrote:
Danny-E 33 wrote:

You say that the route palette is palette 0. But you say that the Viridian City palette is palette 3. The only palette inbetween those is the Pallet Town palette, so one of those statements is false.

Correct. The old post made by me should list Viridian City as palette 2.

This is one of the current problems with hacking: existing documentation (like ROM maps or forum posts) are often subtly wrong. That’s why it’s important to confirm the data yourself through testing. It also gives you a more intuitive understanding of the format.

Right. That's unfortunate, but it makes sense.
Alot like what I did for the evolution data section of Giegue's Master Guide ;)

IIMarckus wrote:

Crash course of MonsterPalettes:

db PAL_GREENMON ; BULBASAUR

Anything to the right of a semicolon ; is a comment.

db means “define byte”, and puts a literal byte in the file.

Constants for palette names are defined in constants.asm, under “super game boy palettes”. PAL_GREENMON is equivalent to writing $16.

So this block:

db PAL_MEWMON    ; MISSINGNO
db PAL_GREENMON  ; BULBASAUR
db PAL_GREENMON  ; IVYSAUR
db PAL_GREENMON  ; VENUSAUR
db PAL_REDMON    ; CHARMANDER
db PAL_REDMON    ; CHARMELEON
db PAL_REDMON    ; CHARIZARD
db PAL_CYANMON   ; SQUIRTLE
db PAL_CYANMON   ; WARTORTLE
db PAL_CYANMON   ; BLASTOISE

Is equivalent to these bytes:

10 16 16 16 12 12 12 13 13 13

Further down are the actual palette definitions. As you may know, computers usually represent colors as a collection of red, green, and blue intensity. In the case of the Super Game Boy, a color is a 16‐bit integer with 5 bits per color plus one unused bit.

RGB 31,29,31 ; PAL_ROUTE
RGB 21,28,11
RGB 20,26,31
RGB 3,2,2

RGB is a macro (defined in constants.asm) that converts its three arguments into a single 16‐bit integer and places it into the ROM, so we don’t have to do the conversion manually. If you do the math, you’ll see that the above is equivalent to the bytes:

bf 7f 95 2f 54 7f 43 08

Hmm, I was following you until right about the end there :P

Danny-E 33 wrote:

EDIT2: Seeing as the first three bytes in the palette assignment table at 0x725C8 are 16 16 16 for Bulbasaur/Ivysaur/Venusaur, this suggests that "palette 0" is not a used palette and the route palette simply starts off as palette 1. So I believe your statement in the old thread was correct.

Ok, thiiis time I can't count. Being 16 16 16 suggests that palette 0 is a real palette. There are 3 undocumented palettes in the Rom Map: 0x726C0; 0x726D8; 0x72780. I was only counting the first and last. I did not notice the middle one, so I was off by one. :)

The palette at 0x726C0 is definetely for the Town Map but do you have any guesses what the other two undocumented palettes are used for? Only out of curiosity.
Perhaps the one at 0x72780 is a badge palette?

EDIT: Also! The pointer to the table of palettes at 0x72660 is at 0x72067 :) Changing the two-byte pointer from  "60 66" to "D0 6F" points to 0x72FD0 which has just the right amount of blank space to add enough palettes for every pokemon individually with a couple dozen bytes left over :) I found that this was also useful for splitting the "Human/Mews" palette. This way, all human characters have one palette, while Mew and Mewtwo can each have their own palette :) Thanks so much IIMarckus for helping sort all of this out! :)

EDIT2: Derp! 0x72FD0 is right before the SGB border data, I just didn't know because I cleared the SGB border data with all zeros a long time ago for until I decided to redo it... XD Well... The next best thing is the block of zeros that runs til the end of the bank which starts at 0x73BA0. But if I did my calculations correctly, that block of zeros seems to be about 48 pokemon too short. In other words, you'll need to have around 48 Pokemon share a palette with another Pokemon in order to scrunch all the palettes in... It is inconvenient, but I think it's do-able. Do you have any other suggestions?

Last edited by Danny-E 33 (2012-07-04 08:23:30)


Red Hack: Pokémon Prototype

Total number of registered users: 7000+
Total number of active users: ~12

Offline

#8 2012-07-06 10:25:28

Danny-E 33
Administrator
Registered: 2012-06-09
Post 38/1,025

Re: Pokemon Red: Palettes

IIMarckus wrote:
RGB 31,29,31 ; PAL_ROUTE
RGB 21,28,11
RGB 20,26,31
RGB 3,2,2

RGB is a macro (defined in constants.asm) that converts its three arguments into a single 16‐bit integer and places it into the ROM, so we don’t have to do the conversion manually. If you do the math, you’ll see that the above is equivalent to the bytes:

bf 7f 95 2f 54 7f 43 08

Ah! I spent more time trying to understand what you meant here. Are you saying take the three values of RBG and convert them each to binary, put them side by side, and convert that number to hex which gives you the 2 byte value for the color?
EX: 31,29,31
31=11111
29=11101
31=11111
11111 11101 11111 = 7F BF
Hmm.. you had BF 7F. So are palettes stored in little endian then?
And am I correct in assuming that the extra 0 bit is the first bit of every two bytes? So the example I just did is teeechnically:
0 11111 11101 11111
Right?

Thanks alot :)
~Danny-E 33

EDIT: Hold on. Your second example says "21,28,11" So:
21=10101
28=11100
11=01011
10101 11100 01011 = 57 8B ?
But you have 95 2F... Am I doing something wrong?

EDIT2: Hmm... The second and third color for the route palette didn't work for me either... Was it only coincedence that the first color seemed to have worked, but I'm actually doing this wrong?

Last edited by Danny-E 33 (2012-07-06 10:37:02)


Red Hack: Pokémon Prototype

Total number of registered users: 7000+
Total number of active users: ~12

Offline

#9 2012-07-06 13:01:42

478/700

Re: Pokemon Red: Palettes

Other way around.

Danny-E 33 wrote:

EDIT: Hold on. Your second example says "21,28,11" So:
21=10101
28=11100
11=01011
10101 11100 01011 = 57 8B ?
But you have 95 2F... Am I doing something wrong?

01011 11100 10101 = 0x2f95 → 95 2f

#10 2012-07-06 17:05:18

Danny-E 33
Administrator
Registered: 2012-06-09
Post 39/1,025

Re: Pokemon Red: Palettes

Oh! That's why the first example works out anyway. Thanks alot.


Red Hack: Pokémon Prototype

Total number of registered users: 7000+
Total number of active users: ~12

Offline

#11 2012-07-07 08:16:14

Danny-E 33
Administrator
Registered: 2012-06-09
Post 44/1,025

Re: Pokemon Red: Palettes

Danny-E 33 wrote:

The next best thing is the block of zeros that runs til the end of the bank which starts at 0x73BA0. But if I did my calculations correctly, that block of zeros seems to be about 48 pokemon too short. In other words, you'll need to have around 48 Pokemon share a palette with another Pokemon in order to scrunch all the palettes in... It is inconvenient, but I think it's do-able. Do you have any other suggestions?

Holy crap, this is embarrsaing. I think I really confused some base 16 numbers with some base 10 numbers when doing this math... Now I'm the one that needs more sleep!
Ok. The most free space in bank 1C starts at 0x73BA0 and goes until the end of the bank. Which is 0x460 bytes. If I need 141 (or 0x8D) more palette entries that are each 8 bytes long, and there is room for 0x8C (0x460/8) more entries, than that amount of free space is only 8 bytes, or one palette entry, too short. Did I do it right this time?? Jeeze... :P

Okay, okay. I promise I'm not always this stupid. Let me just start over...
So the blank space at the end of bank 1C starts at 0x73BA0. There are 37 (0x25) palettes from the original table that should be copied here so all towns/routes/titlescreen etc. work fine. This puts you at 0x73CC8. Between 0x73CC8 and the end of the bank, there are 0x338 bytes which is enough room for 103 custom palettes. You can also reuse the orignal 9 palettes that are only used for Pokemon (excluding the Human/Mew/Mewtwo palette, since you would still most likely want humans to keep their palette. Then Mew and Mewtwo can just have a new palette of their own) This gives you 112 palettes to use for the 151 Pokemon, which means there will need to be at least 39 Pokemon that share a palette with another Pokemon.
Alright. I'm done now. No more mistakes. :P

Last edited by Danny-E 33 (2012-07-11 17:51:45)


Red Hack: Pokémon Prototype

Total number of registered users: 7000+
Total number of active users: ~12

Offline

#12 2012-08-08 00:23:06

Danny-E 33
Administrator
Registered: 2012-06-09
Post 73/1,025

Re: Pokemon Red: Palettes

Is there a peice of assembly that is responsible for making every trainer sprite use the "Human/Mews" palette? Could this be modified so each trainer id is associated with it's own palette id?


Red Hack: Pokémon Prototype

Total number of registered users: 7000+
Total number of active users: ~12

Offline

#13 2012-08-20 04:04:06

Danny-E 33
Administrator
Registered: 2012-06-09
Post 80/1,025

Re: Pokemon Red: Palettes

So I have quite a bit more I want to do with palettes. There is what I said in my last post:
The original RBY has one palette that is used for every trainer sprite, along with Mewtwo and Mew which is the palette labled "Human/Mews/Chapel" in the RB Rom Map, although I don't know what chapel means...
Anyway, Mew and Mewtwo already have their own palette because I edited the table that IIMarckus provided further up this page.
So my question is, is there an asm routine in that same general area as the sprite assingment table that basically says "If the sprite being loaded is a trainer sprite, use human/mews palette"? and could this routine be extended to say "If the sprite being loaded is trainer id xx, use palette id yy"?
Could this routine be partially dirived from the GSC engine?
This would greatly help make GSC trainer sprites look more natural in a RBY hack.

And now something that might be so much work that I might not be able to pull it off, even though I don't think there's any reason to say it would be impossible:
Currently, I would assume that when you walk onto a new map, it checks the map id to load the correct palette (pallet town, viridian city, route palette etc.)
Could this simple part of the engine be completely overhauled so that whenever you walk onto a map, instead of checking the map id, it checks the tileset number and from there loads an individual palette for each tile number of that specfic tileset from a pool of palettes determined by the tileset?
Again, could parts of GSC be used as example in learning how to implement this into Red? Unfortunately, I know nothing about the engine of GSC since all my love is for RBY, so it's hard for me to go in and do the investigating myself.

Basically, this would make it operate alot more like GSC. And in addition to each Pokemon/trainer sprite having its own palette, it would essentially become a "Red in Color", right? It's just that it would be an engine hack of the original Red, and not a scratch-coded, error-free (in theory) game like KBM's (currently) uncompleted game.

These are all only ideas that I don't acutally have real information on. I would greatly appreciate anyone sharing some offsets of locations that would be useful in completing these tasks and anyone who has any insight to offer that may help me understand how to do these thing! Thank you!


Red Hack: Pokémon Prototype

Total number of registered users: 7000+
Total number of active users: ~12

Offline

#14 2012-08-20 06:00:34

503/700

Re: Pokemon Red: Palettes

Danny-E 33 wrote:

So my question is, is there an asm routine in that same general area as the sprite assingment table that basically says "If the sprite being loaded is a trainer sprite, use human/mews palette"? and could this routine be extended to say "If the sprite being loaded is trainer id xx, use palette id yy"?

Very likely.

Danny-E 33 wrote:

Could this routine be partially dirived from the GSC engine?

I doubt looking at GSC for this particular stuff will be very useful.

Danny-E 33 wrote:

And now something that might be so much work that I might not be able to pull it off, even though I don't think there's any reason to say it would be impossible:
Currently, I would assume that when you walk onto a new map, it checks the map id to load the correct palette (pallet town, viridian city, route palette etc.)
Could this simple part of the engine be completely overhauled so that whenever you walk onto a map, instead of checking the map id, it checks the tileset number and from there loads an individual palette for each tile number of that specfic tileset from a pool of palettes determined by the tileset?

Seems feasible to me, but it would be a lot of work.

#15 2012-08-21 04:54:16

Danny-E 33
Administrator
Registered: 2012-06-09
Post 82/1,025

Re: Pokemon Red: Palettes

Alright :) So to start, would you happen to know or how to find out the RAM offset of the trainer sprite id that is currently being loaded?
And then could you maybe help me locate the routine that defines all trainer's palettes as the Human/Mew palette?
I don't have any idea how to work through a rom and pinpoint a specific peice of code like that. And to be honest, I have no clue how to navigate myself through the Disassembly :/
I'm pretty sure I wouldn't need much more help than that for this problem.

The second problem however...
I don't exectly know where to begin, but I will try to gather my thoughts.
I would need to know the RAM offset of the current tileset number being loaded so that could replace the map id in that routine I mentioned.
I'm sure I would need help locating that routine that checks the map id to load the correct palette. Do you think that would most likely be in the same bank as all the other palette routines and data? Bank 1C?
And then I don't have much of an educated quess as to the actual structure of the new code that would define the palette for every tile number... I'm sure it would include a lot of compares? I'm sorry for not having much of an idea of what I'm doing. But I figured there's no harm in discussing the ideas I have.

Also, since I added 112 more palette entries for the rest of the Pokemon, all the free space is taken up. So whenever I replace either of these very short routines with a new routine that should obviously be much longer, I wouldn't have the room to repoint it. Do you think there would be an easy enough way to point it to another bank without any problems? or perhaps relocate the SGB border to a new bank?

Thanks for takin the time to read this and offering your advice :)

Last edited by Danny-E 33 (2012-08-21 05:29:29)


Red Hack: Pokémon Prototype

Total number of registered users: 7000+
Total number of active users: ~12

Offline

#16 2012-08-21 14:07:33

504/700

Re: Pokemon Red: Palettes

Danny-E 33 wrote:

Alright :) So to start, would you happen to know or how to find out the RAM offset of the trainer sprite id that is currently being loaded?
And then could you maybe help me locate the routine that defines all trainer's palettes as the Human/Mew palette?
I don't have any idea how to work through a rom and pinpoint a specific peice of code like that. And to be honest, I have no clue how to navigate myself through the Disassembly :/
I'm pretty sure I wouldn't need much more help than that for this problem.

Finding this part should be simple.

  1. Confirm that the Mew palette also affects humans: edit it to all black (or something otherwise visible), then fight a trainer and see that his palette changed.

  2. Use a debugger: set a read watchpoint on that palette in BGB and run until it gets read.

  3. Work backwards to see how the index ($10) got loaded into the accumulator.

Danny-E 33 wrote:

Also, since I added 112 more palette entries for the rest of the Pokemon, all the free space is taken up. So whenever I replace either of these very short routines with a new routine that should obviously be much longer, I wouldn't have the room to repoint it. Do you think there would be an easy enough way to point it to another bank without any problems? or perhaps relocate the SGB border to a new bank?

Calls may be easier. Replace the first part of the function with a bankswitch to another bank, and you’re golden.

#17 2012-08-22 02:35:22

Danny-E 33
Administrator
Registered: 2012-06-09
Post 84/1,025

Re: Pokemon Red: Palettes

IIMarckus wrote:
Danny-E 33 wrote:

Alright :) So to start, would you happen to know or how to find out the RAM offset of the trainer sprite id that is currently being loaded?
And then could you maybe help me locate the routine that defines all trainer's palettes as the Human/Mew palette?
I don't have any idea how to work through a rom and pinpoint a specific peice of code like that. And to be honest, I have no clue how to navigate myself through the Disassembly :/
I'm pretty sure I wouldn't need much more help than that for this problem.

Finding this part should be simple.

  1. Confirm that the Mew palette also affects humans: edit it to all black (or something otherwise visible), then fight a trainer and see that his palette changed.

  2. Use a debugger: set a read watchpoint on that palette in BGB and run until it gets read.

  3. Work backwards to see how the index ($10) got loaded into the accumulator.

Alright, I understood 1 and 3, but I don't know how to do step 2 because I've never figured out how to use bgb as a debugger. Perhaps now is the time to learn! :P

IIMarckus wrote:
Danny-E 33 wrote:

Also, since I added 112 more palette entries for the rest of the Pokemon, all the free space is taken up. So whenever I replace either of these very short routines with a new routine that should obviously be much longer, I wouldn't have the room to repoint it. Do you think there would be an easy enough way to point it to another bank without any problems? or perhaps relocate the SGB border to a new bank?

Calls may be easier. Replace the first part of the function with a bankswitch to another bank, and you’re golden.

So once I locate the orignal routine stating that all trainers use the Human/Mew palette, I should put a call right there to another bank where there was room for the new routine that leads back to bank 1C, and I should keep all the actually data for the palettes in the same bank?


Red Hack: Pokémon Prototype

Total number of registered users: 7000+
Total number of active users: ~12

Offline

#18 2012-08-30 05:32:18

Danny-E 33
Administrator
Registered: 2012-06-09
Post 89/1,025

Re: Pokemon Red: Palettes

So I really want to work this one out. If I try to use bgb as a debugger, how do I set a watchpoint to the address of the human palette?

IIMarckus wrote:

Replace the first part of the function with a bankswitch to another bank, and you’re golden.

What asm codes constitute a bank switch exactly?
Thanks :)


Red Hack: Pokémon Prototype

Total number of registered users: 7000+
Total number of active users: ~12

Offline

#19 2012-09-01 04:52:45

508/700

Re: Pokemon Red: Palettes

Danny-E 33 wrote:

So I really want to work this one out. If I try to use bgb as a debugger, how do I set a watchpoint to the address of the human palette?

Go to “Access Breakpoints” (should be reasonable to find) and put the pointer in the textbox.

Danny-E 33 wrote:
IIMarckus wrote:

Replace the first part of the function with a bankswitch to another bank, and you’re golden.

What asm codes constitute a bank switch exactly?
Thanks :)

In general: write the bank number to $2000. But Red has a function that will do this and handle switching back too: load hl with the pointer and a with the bank id, and call $35d6.

#20 2012-09-01 06:25:25

Danny-E 33
Administrator
Registered: 2012-06-09
Post 90/1,025

Re: Pokemon Red: Palettes

I'm sorry for not being self-sufficient right now, but I can't get this simple thing to work.
I open access breakpoints and in the textbox in the bottom-left corner I enter the pointer to ROM address 0x73C20 which is the Human palette(since I relocated the palette table), and click "Add" which puts that pointer in the big white space in that window.
I have played around with the check boxes like "on read" "on write" but I can't get anything to happen whenever that palette is loaded... is there somethin I'm doin wrong?

I think that it's most likey that I'm not entering the correct RAM address. Because that's what the breakpoints are watching, right? Just the addressess in RAM?

Last edited by Danny-E 33 (2012-09-01 06:50:58)


Red Hack: Pokémon Prototype

Total number of registered users: 7000+
Total number of active users: ~12

Offline

#21 2012-09-01 12:59:33

Sawakita
Administrator
Registered: 2010-10-16
Post 291/364

Re: Pokemon Red: Palettes

Have you used the correct format when inserting the pointer? The valid formats, that I'm aware of, are:

  • 16-bit pointer (refers to RAM), like 7C20;

  • "bank:address" pointer (refers to ROM) like 1C:7C20;

Offline

#22 2012-09-02 01:51:53

Danny-E 33
Administrator
Registered: 2012-06-09
Post 95/1,025

Re: Pokemon Red: Palettes

Gah, I'm sorry for being so clueless...
I've tried entering it in all kinds of ways in the hopes that something will happen, but it never breaks when it needs to load that palette..
Could one of you give this a try real quick? Of course, on a clean rom, that palette is located at 0x726E0.


Red Hack: Pokémon Prototype

Total number of registered users: 7000+
Total number of active users: ~12

Offline

#23 2012-09-02 06:59:38

Miksy91
Member
Registered: 2010-10-16
Post 1,068/2,311

Re: Pokemon Red: Palettes

Try adding breakpoints to the ram area that is used to call the human palette then.
BGB doesn't necessarily stop executing the program at that address but when that address is being "read/written/[can't remember the third one]".
For example, if we wanted to set breakpoint to ram address D127, the game would probably stop in this kind of function:
ld hl, D127

Offline

#24 2012-09-02 08:05:36

Danny-E 33
Administrator
Registered: 2012-06-09
Post 97/1,025

Re: Pokemon Red: Palettes

Ohh... I get what you mean!
So which one am I trying to do?
Do I want it to stop at the address, or whenever the address is being accessed? I don't know which one is supposed to be my goal here :P
Thank you for pointing out that difference that I never noticed! :)


Red Hack: Pokémon Prototype

Total number of registered users: 7000+
Total number of active users: ~12

Offline

#25 2012-09-02 08:14:38

Miksy91
Member
Registered: 2010-10-16
Post 1,071/2,311

Re: Pokemon Red: Palettes

According to IIMarckus,

2. Use a debugger: set a read watchpoint on that palette in BGB and run until it gets read.
3. Work backwards to see how the index ($10) got loaded into the accumulator.

I'd set the breakpoint to accessing human palette (you probably run into ld hl / ld de / ld bc, $palette), and start going backwards in code.

Offline

Board footer

Powered by FluxBB