don't click here

Sonic Battle Hacking

Discussion in 'Engineering & Reverse Engineering' started by Phase, Aug 6, 2015.

Page 2 of 2
  1. Jul 4, 2018 #21
    Phase

    Phase

    Member
    12
    0
    0
    Sonic Battle Hacking Suite
  2. Jul 31, 2018 #22
    Phase

    Phase

    Member
    12
    0
    0
    Sonic Battle Hacking Suite
    It's been about a month. In that time, I've been working on a completely new editor for SB.

    (prototype logo by Lavender The Great, our amazing artist)
    [​IMG]

    sbrx is being written in Rust, and will not suffer from a lot of the problems that plague SBHS.

    This SBHS codebase was written in Java circa 2015, and then was automatically converted to Kotlin years later.
    It shows. SBHS is ungodly slow. SBHS takes around 14 seconds to start up while sbrx takes ~400 miliseconds.
    I will also be focusing a lot more on the GUI to make sure the experience for modders is less of a pain.
    It's a pain right now.
    A big one.

    sbrx can currently only write spritesheets to the game, in the same format as SBHS, but it does not require a palette to be added in the top left.
    It became really apparent that users didn't understand the use of the palette so I just yanked it.
    The palette is generated by choosing the first 15 colors in the image, and then it defaults to the first one if there is a color outside the range.
    It'll soon show some clean error message once I get the GUI working.

    Rust is a newer programming language, and as such there aren't many good libraries for it. I wanted to try it out because it declares that it is a lot safer than C & C++, and because it has a nice type system (I'm a PLT nerd).
    I'm currently using GTK bindings for Rust, but GTK isn't an amazing interface. My main hurdle right now is getting everything to run smooth in a fresh Windows environment.
    Packaging the 1000000 dlls is also going to be annoying because I don't know if Rust can statically link GTK.
    As you can probably tell, I'm not a GUI programmer, nor a Rust programmer, so there has been a lot of trial and error.
    It is absolutely worth it, though, as the code is a lot cleaner and is a billion times faster.

    [​IMG]

    [hr]
    Glimmer also made this cool hack that changes the spritesheet depending on which way your facing. (I heard it might be used for an Infinite mod!)

    [​IMG]

    Code (Text):
    1.  
    2. ;Sonic Battle - Differing Sprites Based on Direction.
    3. ; by Glimmericious
    4.  
    5. .open sonic-battle-original.gba, sonic-battle-edited.gba, 0x08000000
    6. .gba
    7. .thumb
    8.  
    9. .org 0x8006D3A          ;Breaking off from the main code.
    10.     bl 0x0805582C
    11.     .pool
    12.  
    13. .org 0x805582C
    14.     push {r2-r3}        ;Stores the value of r2 and r3 on the stack, because we'll need that back later  Maybe.
    15.     ldr r2,=0x847AFD8   ;Store the address of the Sonic Sprites
    16.     cmp r1,r2           ;r1 stores the current spritesheet
    17.     bne originalCode    ; branch to the original code if it isn't Sonic's spritesheet
    18.     ldr r2,=0x03001C50  ;This bit of code loads the direction that the player is facing.
    19.     ldr r2,[r2]         ;Not 0 if right, 0 if left.
    20.     cmp r2,00           ;Check what direction the player is facing.
    21.     bne loadKnuckles    ;'Branch if equal' - so, if the player is facing right.  Else, this line will be ignored.
    22. loadSonic:
    23.     ldr r1,=0x0847AFD8  ;Loading a value into r1 - there are where Sonic's sprites begin.
    24.     b originalCode      ;Return us to the loop; the program is over.
    25. loadKnuckles:
    26.     ldr r1,=0x084CADF8  ;Loading Knuckles's sprites into r0.
    27. originalCode:
    28.     str r1,[r0]         ;Store the new sprite address.
    29.     pop {r2-r3}         ;Restore r2 and r3 from earlier.
    30.     ldr r0,=0x3001C40   ;This is all stuff that was in the original code.  I had to move it here.
    31.     mov r3,r8
    32.     sub r1,r7,r3
    33.     bl 0x8006D40
    34.     .pool
    35.  
    36. .close
    37.  

    [hr]

    I also spruced up the first page of this thread to maybe attract some modders. I'm not real good at managing threads, so hopefully people interested in hacking SB see the big Discord link.

    [hr]

    Sorry I never got around to addressing these points.

    Yes it absolutely could be done better, I am far from a GUI designer.
    The sprite format is hardcoded into the editor(s). I don't have experience with hacking GBA (or any) sprites so I'm not sure if it's a standard, but it goes like this:

    Code (Text):
    1.  
    2. 00 01 02 03 24 25
    3. 04 05 06 07 26 27
    4. 08 09 10 11 28 29
    5. 12 13 14 15 30 31
    6. 16 17 18 19 32 33
    7. 20 21 22 23 34 35
    Essentially, the first for columns are in order and the final two columns are placed at the bottom. And I think the effect sprites are sorted differently, but I haven't had a chance to look at those yet.

    The palette editor will be replaced with something like that + - super hot sexy   GUI, but for now the spritesheet will handle palette modifications.
    I just need to get it up to speed with the old editor.

    And yes Java sucks but I'm fast in it, sadly.
     
Page 2 of 2