bfbbdecomp/bfbb

Decompilation project for SpongeBob SquarePants: Battle for Bikini Bottom

SpongeBob SquarePants: Battle for Bikini Bottom

A work-in-progress decompilation of SpongeBob SquarePants: Battle for Bikini Bottom.

It builds the following DOL:

main.dol: sha1: 306526d90b48e99894c3138f5fc8f2716d9fecf6

This repository does not contain any game assets or assembly whatsoever. An existing copy of the game is required.

Supported versions:

• GQPE78: (NTSC-U)

Dependencies

Windows

On Windows, it's highly recommended to use native tooling. WSL or msys2 are not required.
When running under WSL, objdiff is unable to get filesystem notifications for automatic rebuilds.

• Install Python and add it to %PATH%.
  • Also available from the Windows Store.
• Download ninja and add it to %PATH%.
  • Quick install via pip: pip install ninja

macOS

• Install ninja:

  brew install ninja

• Install wine-crossover:

  brew install --cask --no-quarantine gcenx/wine/wine-crossover

After OS upgrades, if macOS complains about Wine Crossover.app being unverified, you can unquarantine it using:

sudo xattr -rd com.apple.quarantine '/Applications/Wine Crossover.app'

Linux

• Install ninja.
• For non-x86(_64) platforms: Install wine from your package manager.
  • For x86(_64), wibo, a minimal 32-bit Windows binary wrapper, will be automatically downloaded and used.

Building

• Clone the repository:

  git clone https://github.com/bfbbdecomp/bfbb.git

• Using Dolphin Emulator, extract your game to orig/GQPE78.

  • To save space, the only necessary files are the following. Any others can be deleted.
    • sys/main.dol

• Configure:

  python configure.py

  To use a version other than GQPE78 (NTSC-U), specify it with --version.

• Build:

  ninja

Visual Studio Code

If desired, use the recommended Visual Studio Code settings by renaming the .vscode.example directory to .vscode.

Diffing

Once the initial build succeeds, an objdiff.json should exist in the project root.

Download the latest release from encounter/objdiff. Under project settings, set Project directory. The configuration should be loaded automatically.

Select an object from the left sidebar to begin diffing. Changes to the project will rebuild automatically: changes to source files, headers, configure.py, splits.txt or symbols.txt.

bfbb's Issues

Re-organize new asm files into directories

rename typedefs to match Heavy Iron naming convention

int should be s32 instead of int32, etc. to match Heavy Iron's coding style.

Re-link 100% matching CPP files

Verify matches for src files and re-link them (objdiff will help).

Start with 100% completed source files. They should be able to be built and substituted and match.

Consider integrating the diff.py script from zeldaret/tp.

https://github.com/zeldaret/tp/blob/master/diff.py

Split COM symbols

Split COM symbols, they're currently stuffed at the end of one of the files.

• They'll be moved to individual files in the form of .comm name, size, align (align will be 4)

Make diff script not reset view to the top of function after reload

Set up continuous integration to test each commit

It would be very beneficial to set up a script that downloads dependencies and tests make on each commit/pull request so we know that nothing is broken.

Maybe also run clang format on the C++ source too.

Make diff script use symbol labels in original instead of hardcoded offsets

Example:

Define different levels for function progress

As discussed in the discord, I think we need to have different labels or #define's for a function's progress. For example, a #define for functions which we can say without a doubt will match the original game's behavior but don't 100% match. This would allow us to build the game with our "almost perfect" code if we chose to, also it would allow us to track progress of functions that aren't perfect matches.

We need to come up with a labeling system or agree on ways to define a function's completeness.

CI passes when it fails to OK

https://github.com/bfbbdecomp/bfbb/pull/230/checks?check_run_id=2277971968

Seems to have an error in the size of the ROM, but somehow passed the check when it was spamming the diff

Split data sections into the correct files.

This is a tracking issue so I can more easily see what I haven't moved yet

• bss.s
• ctors.s
• data.s
• dtors.s
• extabindex.s
• extab.s
• rodata.s
• sbss2.s
• sbss.s
• sdata2.s
• sdata.s

download tools from archive.org

Tools can probably be downloaded from the archive.org link in the readme instead of having a private encrypted repository. Workflow runs on forks fail because of bad credentials to the private repo.

Any #pragma GLOBAL_ASM that's commented out with '//' will still get compiled

If you comment out a #pragma GLOBAL_ASM as a single-line comment (//), the globalasm script will still replace the pragma with its corresponding asm function and the function will be compiled. It should be modified to ignore lines starting with //.

// func_8004D1F0
//#pragma GLOBAL_ASM("asm/Core/x/xTimer.s", "GetRandomizedTime__FP11xTimerAsset")

// func_8004D1F0
//
extern "C" {
asm static void GetRandomizedTime__FP11xTimerAsset() {
nofralloc
opword 0x9421FFE0
opword 0x7C0802A6
opword 0x90010024
opword 0x93E1001C

This also happens with multiline comments and #ifdef 0, but that is fine because the asm function will get placed inside the comment/ifdef so it'll still be ignored by the compiler.

/*
// func_8004D1F0
#pragma GLOBAL_ASM("asm/Core/x/xTimer.s", "GetRandomizedTime__FP11xTimerAsset")
*/

/*
// func_8004D1F0

extern "C" {
asm static void GetRandomizedTime__FP11xTimerAsset() {
nofralloc
opword 0x9421FFE0
opword 0x7C0802A6
opword 0x90010024
opword 0x93E1001C

Get diff script to work on windows

Stop stdout spam after first error

It's annoying when there are thousands of lines of errors spammed to stdout when there's some kind of CPP or linker error:

obj\src\Game\zFX.cp:6814: declaration syntax error
obj\src\Game\zFX.cp:6815: declaration syntax error
obj\src\Game\zFX.cp:6816: declaration syntax error
obj\src\Game\zFX.cp:6817: declaration syntax error
obj\src\Game\zFX.cp:6818: declaration syntax error
obj\src\Game\zFX.cp:6819: declaration syntax error
obj\src\Game\zFX.cp:6820: declaration syntax error
obj\src\Game\zFX.cp:6821: declaration syntax error
obj\src\Game\zFX.cp:6827: '}' expected
obj\src\Game\zFX.cp:6828: declaration syntax error
obj\src\Game\zFX.cp:6829: declaration syntax error

I'm sure there's got to be some flag or other way to stop execution after the first error encountered.

Make diff script only show relevant function, nothing beyond it

Make 'make' recipe strictly for creating a build, and one for building+diffing

As mentioned in #231, the CI doesn't know when a build fails to match, only when it fails to compile/link.

Learn why floating point functions fail

We have so many big functions that are nearly perfect, except for the fact that the floating point registers are swapped. Figuring out why this happens is important. Is it a compiler setting? Do we have the wrong compiler?

It may be worth writing a program which tries to run make with different permutations of compiler settings with a failing floating point function that we are certain should match.

Update compiler flags

• Use -common on for main source files (global BSS variables are pushed to the end of .bss and deduplicated)
• Use -sym on for main source files (affects function ordering & generates multiple .text sections)