pabel

I don't do scripting. So can't help. Sorry :(

hey, how're you doing? :)

First off you'll want to download DevKitARM. Just follow the guide here and you'll be fine. From there iirc most of my projects include a compile.bat which works across most if not all my projects in the event that one of them doesn't include the compile.bat. If you need an example to test on, use this project and go from there.

I don't

I have no idea how to force it to use those palettes. It will require ASM though.

All of the palettes above 0xA are unusable. The coding of the game prevents them from being used for OWs. I have no idea why, but it just is.

Close, it is only 1X 01 00 00. Only the lower half (the right half, the part with the lowest value) is applicable. That is the palette slot in the palette viewer that the OW will load it's palette into and then use.

Okay... I think you are missing what I am saying....

That is for a different issue. You litterally just need to hex edit the byte that controls where the palette is loaded to. That is in JPAN's manual, written out very clearly in the overworld section. Look for the picture of the bad player sprite.

Each OW has a byte associated with it that says which index it loads its palette into. That is the byte you need to change. JPAN outlines this byte in his documentation for his hacked engine.

I have no idea what you just said..... However, I will repeat, I do not know how to use the timer.

I don't know, never had to use it. Did you read his documentation?

My routine can be applied to a smaller image very easily. You just need to change where the data will get placed in the vram. Large images are the easiest because you don't have to worry about block wrapping. Also, my routine was based around the premise that you have been warped to a 1x1 all black map so that the vram is always locked in the same place. I could never get the calculations for where the current screen was located to work properly so I just forced it to be the same.

Well I can't see that, haha. It just looks like the crash screen I get when I fail to do +1. Now, my guess is that you overwrote the tilemap and now it is using the same tiles for every single block and those are not the right tiles.

You are calling the ASM improperly I believe and it is crashing the game. Did you remember the +1 on the call to the ASM routine?

You're welcome.

https://www.dropbox.com/s/1t21fopwfyd0gq3/BelaHack.zip

Sorry about that. What this is, is a routine that can be hooked into the special commands in scripting.

Yes, but I was overwriting the whole screen, which meant I could use any VRAM I wanted. You, on the other hand, need to keep the other stuff intact.

Well, I can tell you that SWI 0x12 will decompress LZ77 data. Look it up on GBATEK for the parameters. Then, you need to know the offset that you want you dump your tiles into and then the offset you want to dump your raw into. This is not going to be easy. You will have to find a section of vram (ie, what is shown in the tileviewer) that isn't used during normal play. Then you need to find a section in BG0 (where the raws are. The BG levels don't hold image data, they only say which tiles go where) that is large enough for your raw.

From there, you decompress the images via SWI 0x12 and viola, it shows up.

Ahh, I see now. Well, I would take a compressed image and just use the SWI functions to unzip it to BG0. Let me see if I can find the code I used for bela.