Re: Pokemon Red: Palettes

@Danny-E 33:I didn't found practical notes. Anyway, to use dynamic SGB packets instead of hardcoding each one by itself, you could write a routine that loads a "base" PAL_SET packet (which you can accomplish by copying the existing packet located at 0x72428) into RAM:CF1D. You can use routine 0x9D to copy data from a different bank into RAM. Here's the source code from pokered, if you want to see what it does:

Notice that you have to specify the bank, source pointer, destination pointer and the number of bytes to copy (in your case it would be 0x10 bytes). Your new routine would then overwrite the byte at 0xCF1E with a parametric palette ID, and then call the routine that sends SGB packets.

This way you could call the new routine passing the palette ID as a parameter, each time you want to change the palette. Something like:

ld a,SOME_PALETTE_ID
call SendDynamicallyBuiltPalettePacket

--

Miksy91 wrote:

the code isn't that large though

I never said it was.

Miksy91 wrote:

Of course if the space in rom bank 0 is so limited that there is no point in adding such code, no particular reason in creating one either.

Well, taking advantage of the RST vectors would neither affect nor be affected by the free space in bank 0; vectors have their 8 bytes reserved in the beginning of the ROM anyway, so you would just implement them as shortcuts to some existing often-used routines (Bankswitch and Predef come to mind), and be done (of course doing this would make sense only if you had the complete source code of the game, not the assembled/linked result).

stag019 wrote:

Which makes me wonder though. How much space does it save? How many calls are there to this function in Generation I? I'd like to know how much it would have benefitted to have used the RST vectors in Generation I, since it's been said that space was an issue during development.

This survey didn't considered that some of the matches are probably just random data and not actual code, but even reducing the number of matches, you would still have more than 1KB of saved space (in a very cheap and quick way, which is relevant). On a 512KB cartridge (that is the size of original Red/Green japanese ROMs, if I'm not wrong) is not bad. Probably better than putting together a messy and hacky engine just to get everything fit in.

After sending each packet at $5FEB, it returns to the end of the bankswitch routine to return the bank to ROM 01 and continues the Oak script.

This works very successfully. Do you have any advice for optimization?As far as optimization, can you think of a way to eliminate all the push/pops to retrieve the id from the stack?Also, you've said that the packets in RAM start at $CF1D, and you've also said $CF2D. After taking a deeper look at it, I believe you mean $CF2D, right?And just a note, at $614C, I overwrote the 8 wasted bytes that are the bit check to skip the Oak intro in order to get a bit extra space.

Re: Pokemon Red: Palettes

After sending each packet at $5FEB, it returns to the end of the bankswitch routine to return the bank to ROM 01 and continues the Oak script.

This works very successfully. Do you have any advice for optimization?As far as optimization, can you think of a way to eliminate all the push/pops to retrieve the id from the stack?

An alternative that comes to mind is storing/retrieveing a's value into/from RAM (for example 0xCF91 and 0xD11E seem to be two general purpose temporary storage RAM locations) instead of pushing/popping, maybe. It wouldn't save you any space in the total computation of bytes used, though, because you would use 2 more bytes in the calling code (bank 1) and 2 less bytes in the called routine (bank 1C).

Danny-E 33 wrote:

Also, you've said that the packets in RAM start at $CF1D, and you've also said $CF2D. After taking a deeper look at it, I believe you mean $CF2D, right?

I should re-check my notes but IIRC there are two "buffer", so you can store two dynamic packets at the same time. I'll see and add on to this later, if I find something.

Re: Pokemon Red: Palettes

No worries. :)And thanks! You know I couldn't have accomplished such a web of code without you as my teacher! :)

Sawakita wrote:

Danny-E 33 wrote:

After sending each packet at $5FEB, it returns to the end of the bankswitch routine to return the bank to ROM 01 and continues the Oak script.

This works very successfully. Do you have any advice for optimization?As far as optimization, can you think of a way to eliminate all the push/pops to retrieve the id from the stack?

An alternative that comes to mind is storing/retrieveing a's value into/from RAM (for example 0xCF91 and 0xD11E seem to be two general purpose temporary storage RAM locations) instead of pushing/popping, maybe. It wouldn't save you any space in the total computation of bytes used, though, because you would use 2 more bytes in the calling code (bank 1) and 2 less bytes in the called routine (bank 1C).

Yeah, I didn't think about that. I think I'll just leave it the way it is. I haven't noticed any problems so far from disturbing the stack. Do you have a preference?

Sawakita wrote:

Danny-E 33 wrote:

Also, you've said that the packets in RAM start at $CF1D, and you've also said $CF2D. After taking a deeper look at it, I believe you mean $CF2D, right?

I should re-check my notes but IIRC there are two "buffer", so you can store two dynamic packets at the same time. I'll see and add on to this later, if I find something.

Sounds good.

Also, I still haven't successfully replaced the palette for the Pokedex screen with the red health bar palette.I tried finding the call it uses to $5FEB but I've learned that the code it is reading when it executes that call is code that is read in multiple instances to send a palette $10 packet. So adding in some code or modifying the packet it sends doesn't work because it affects the packet everytime that code is read.I've learned from editing the Oak intro script that it is near immpossible to make the code skip the palette changes entirely. So for example, the Oak intro still sends palette $10 packets throughout (such as when the New Name screen comes up), but then a custom packet is always sent before sprites are displayed on the screen.I plan on doing a similar thing here. Let it send a palette $10 packet and then add in code to send a custom packet.So now it's a matter of finding a specific ASM script responsible for putting together the Pokedex screen.Well, finding a call to $5FEB already failed... I tried a call to $1922, but then I realized there are no text boxes on the Pokedex screen...Are there other big (probably Bank 00) routines that are called to generate things on the screen such as text that I should try a breakpoint at and then trace back in the stack to find where it was called from in order to find the Pokedex screen's ASM script?I fear my knowledge of big, game-engine routines is too small to think of where to put a break point in order to find the Pokedex screen's script.

Re: Pokemon Red: Palettes

Re: Pokemon Red: Palettes

Actually, yes! I didn't thing that was gonna be possible (it is definitely near impossible for the Oak script like when the player types in a new name), but with the address stag019 provided, it actually cut around sending a useless packet because I got rid of the code that called $3DEF with a certain parameter in b. I think it was $08.