• 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.
jiangzhengwenjzw
Reaction score
42

Profile posts Latest activity Postings About

  • Any local variable will be created in the stack, or a register would be used instead.

    Try this:

    u8 i = 5;
    set_attr (pokemon, attr_HP, &i);

    "i" would be created in the stack, and the SP would be passed into set_attr.

    In almost all situations, programming in C is superior to programming in ASM. However, I should note that the ASM instructions generated by GCC/DevkitARM/whatever_you're_using, will always not be as efficient as hand written ASM will be. A competent human writing ASM will, in some cases, write code more efficiently than the compiler generated code. However, the benefits of writing the exact code in ASM isn't exactly worth it. Consider this: Would you rather spend 10 mins writing C code which executes 100 CPU cycles slower? Or spend 30 minutes writing ASM code which executes 100 CPU cycles faster? 100 CPU cycles is very negligible depending on the nature of your code and where it's used. In 99% of cases, we wouldn't care about the slight efficiency drop. The GBA's processor has a clock speed of 16.78Mhz. That means every second it has the potential to do 16780000 cpu cycles. Saving 100 cycles and spending 20 minutes does absolutely nothing. Something like this would only matter in an area like the main loop, which is executed extremely frequently.
    You can make an array/define one loosely using a pointer. For example,
    char [10] from a char array can be declared as type char *.
    Both can work.

    Here is another example of something that "works":
    http://pastebin.com/U8hx1ZzQ

    It uses a nested struct instead.
    No, this example would be "struct poke_str poke_oppo[6]". No stars. Jiang, what I've been saying is correct, trust me :P
    0x300500C isn't a pointer, it simply contains a pointer. 0x300500C's type is pointer to struct, or "struct *" then.
    The compiler will think that 0x300500C contains a pointer to a pointer, but actually it's just contains a pointer to the data. You are confusing pointers and addresses. Just use one "*" and it'll work fine.
    struct trainer **saveblock2 = (struct trainer**)0x300500C;

    Why the double "**"? It's a pointer to the data that's contained at 0x300500C. So that wouldn't be double "**", rather it'd be single. Also you should still use the python scripts, they don't add extra difficulty, but come with a few command line arguements and hook support.
    "F5" is very useful, I prefer it to reading raw ASM sometimes. It bugs out when it comes to functions with create data structures in the stack. There are other minor points of unreliability too, but all things considered, it's pretty useful.

    For your problem of getting things to compile in order, it's not going to compile in order. You'd need to use "python insert --debug" to figure out what got compiled where.
    I'm sorry I do not understand this part
    *Change all 1D 1E 0A 08 to the pointer (+1) to this routine, and please do the change before inserting the routine!!!!!!!!!!!!!!!!!!*/
    Sure, I will be a little late today because of a tight schedule. Not sure if you will be on by then :/
    I had inserted all the routines in my hack and I'm kind of glad that it doesn't crash the game or make any unwanted errors, well my problem is even though I set the percentage value of double wild pokemon appearance to 64, which is 100%, nothing happens. The grass ID is the default, 0xD, and all are fine.

    Do you have any idea why setting it to 64 doesn't create a 100% double wild pokemon appearance?
    The sole purpose is to bother people and take up inventory space. I actually completely forgot to give it any sort of use...
  • Loading…
  • Loading…
  • Loading…
Back
Top