• Our software update is now concluded. You will need to reset your password to log in. In order to do this, you will have to click "Log in" in the top right corner and then "Forgot your password?".
  • Welcome to PokéCommunity! Register now and join one of the best fan communities on the 'net to talk Pokémon and more! We are not affiliated with The Pokémon Company or Nintendo.
    Register
Kimonas

Kimonas

%string not found 28 From Greece
Joined
Last seen
Messages
91
Reaction score
67

Profile posts Latest activity Postings About

  • A
    There's a good chance I just didn't paste a part of the bin or something, I made it in a rush. But good to hear the tool works!
    Phantom Phoenix
    oh I already download it and it worked without visual and.net..XD.and you used python.don't you?I mean its written in python.
    A
    SORRY. Just realized I never got back to you. Oops.
    https://www.dropbox.com/s/srn5ox8wy61u42d/JPAN%20OW.zip?dl=0
    Along with the patch, I included the source. Be advised that it breaking does not necessarily mean there is something wrong with your tool. I hadn't tried to expand with other tools either, so it is entirely possible that what I inserted is wrong, not the tools themselves. The palette table has not been repointed. Sorry about lying a few days ago :P
    Blah
    not exactly. The stack pointer has a fixed amount of space, it doesn't call malloc. Also, using malloc for function parameters means you'll need to free to used memory afterwards.

    Anyways, this is how it is done by convention/design. So..yeah :P
    Blah
    malloc takes an int size arguement in R0, and returns a pointer to free RAM space in R0.

    Memcpy takes a pointer to the destination in r0, a pointer to the source in r1 and the size of the data of the source in r2. It will copy the contents in r1 to the pointer at r0.

    By convention and standard, when calling a function, r0-r3 contain paramaters to the function. However, you will find functions with more than 4 paramaters, as such r0-r3 are not enough. In this case, the stack pointer is used instead to hold said paramaters. That is why you'll see sometimes functions writing to the SP before another function call. Sometimes functions will also use the SP as a small amount of free temporary RAM for their local variables and such.
    A
    Hmm, I'm rather puzzled now.
    I tried what I said earlier, and I have the same issue of OW Table 1 and only a single Overworld 0.

    In "Table Menu," I still have Table Address: 0x5F2F4 (even though I repointed it to match where JPAN put it).

    But it DOES know that Palette Table is at 0x1A2400??? o.O So wouldn't that indicate it "knows" I'm using JPAN's hacked engine?
    A
    Eh, it isn't that big a deal for me; it adds maybe three minutes of work, haha. I'm not a programmer, so I don't know a better way to manage it; perhaps an ini / xml format like some other tools use?

    One more thing - I realized that this doesn't appear to support expansion of palettes beyond 0xFF? Would that be possible? Hacked Engine also supports that feature; I believe it only requires repointing and terminating the table with some halfword; don't remember which one at the moment.

    EDIT: nvm I lied; you did handle palette expansion, I just had to move the table :D
    A
    Ahh I see, that's too bad.

    In JPAN's Hacked Engine, there's a source folder included to describe the changes, and I used those files to change the overworld routines. So the routines do the same thing, but I used different areas of free space because I don't like where he put them.

    So if I temporarily change the palette table pointers to match the Hacked Engine and temporarily place the pointers to Overworld tables at 0x1A2000, it shouldn't cause problems then? It seems "hacky," but for the time being, I could do that then just change them back to normal once I've imported the new overworlds.

    Yep, the overworld pointers at 0x39FDB0 were moved to the 0xF00000 area.

    The palettes aren't a problem, I repointed them myself prior to even opening the ROM in OWM.
    A
    Hmm thanks for the answer, but I don't think it was the pal table. I just checked, and I do have all three pointers, and they even match where they are in the hacked engine patch.
    Specifically 0x05F4D8, 0x05F570, and 0x05F5C8. The only difference is that they're not pointing to 0x081A2400.
    I'm pretty sure that the issue is with the overworlds table, because the tool seems to be reading the new table with pointers to the other overworld tables (and there's only one pointer right now) as a pointer to an actual overworld, which obviously isn't going to load correctly.
    I guess the better question is how the tool "knows" when you're using a table of pointers to 1 of 256 tables, as opposed to automatically reading a table as a table.

    1) The pointer to the original overworld table is 0x8DFDF8
    2) I wanted to insert their data in the same way that is used with JPAN's engine, so up to 256 tables pointing to tables of 256 overworlds.
    3) I did repoint the original overworlds table to the 0xF00000 range, but I also did update the pointer to it at the offset indicated in my answer to (1)

    Btw, I don't see a need for you to update the tool. All I needed was how the tool "knows" when it is using JPAN's table method, and I can easily update my routines / location of literal pools to be compatible :)
    lilbluedemon
    Hey, I saw your thread of the FR styled HGSS Overworld.
    I have a donation, of sorts:


    It's something I was making weeks back, but never finished, you can use it, if you like, I never finished the side frames though.


    Nice work on them OWs anyway. ~
  • Loading…
  • Loading…
  • Loading…
Back
Top