pret / pokeruby Goto Github PK

hey! i was interested in this so i wanted to try building it before doing any modifications. unfortunately running the makefile seems to throw up several errors. here's the full list

make: tools/scaninc/scaninc: Command not found
mkdir -p genasm
echo -e "\t.syntax divided" >genasm/prefix.tmp
mkdir -p genasm
echo -e "\t.syntax unified" >genasm/suffix.tmp
mkdir -p genasm
gbacc -O -mthumb-interwork -Iinclude -o genasm/agb_flash_1m.s.tmp src/agb_flash_1m.c -S
make: gbacc: Command not found
make: *** [genasm/agb_flash_1m.s] Error 127

any idea what's causing this?

Right now all the songs in sound/songs/ have to be .s to match, since mid2agb can't convert to midi and back and still match. When this is fixed, the songs can be converted to midi.

MapObject2->mapobj_unk_19 and MapObject2->mapobj_unk_19b are the x and y maximum displacement from starting coords, respectively. Functions which mess around with MapObject->mapobj_unk_19 are actually manipulating both 4-bit fields at once. MapObjectTemplate->unkA_0 and MapObjectTemplate->unkA_4 are the same fields.

The object_event macro and all its uses should be overhauled to match MapObjectTemplate, or the .inc files should be replaced with C data files declaring the const structs (perhaps with a C99-compliant macro)

The pokeruby tools for windows, at yamaarashi's github page, have been 404'd.

A lot of the source code files are in directories that don't really make sense, especially field, and this makes it kind of a pain to find some given piece of code. I initially agreed to the idea of using subdirectories, but now it makes it harder to navigate. Currently, emerald doesn't use them, and it's not a problem. We need to either come up with a directory structure that makes sense or get rid of the subdirectories. What are your thoughts on organizing the files?

It seems that support for exporting 4-bit (16 color) PNG images is poor among popular graphics editors. gbagfx should be able to do the conversion as long as the image uses no more than 16 colors.

Undecompiled

• contest_ai.s
• contest_effect.s
• contest_link_80C2020.s
• contest_link_80C857C.s

Decompiled

• contest.c

<marijnvdwerf> The macro for setvaddress in pokeruby is wrong btw. It only takes a pointer as argument, no u16.

unknown_E81098 appears to be an 8bpp image. The palette appears to start at gUnknown_083F86BC, but seems to be longer than currently defined in the data file. LoadPalette(gUnknown_083F86BC, 0, 448) is called, but I'm having trouble to figure out where that means the data should end.

Some of the code changes being made for German R/S, like bugfixes, apply to all European non-English localisations.

I propose adding something like this to config.h:

#if defined(GERMAN)
#define EUROPE 1
#endif

...then check for the "EUROPE" define for the specific changes / etc that apply for all European non-English localisations.

This should avoid lots of repeated checks for several languages (possibly in several files) in the future.

Every time I edit a picture/sprite or resize it and then do the Make command, I get this:
"$ make
"graphics/title_screen/rubyversion.png" has an unsupported color type.
make: *** [graphics/title_screen/rubyversion.8bpp] Error 1"

Does anyone know why this is? and what fixes can be taken so that this error doesn't appear again?

Undecompiled

• pokemon_storage_system.s

Decompiled

• pokedex.c
• pokedex_area_screen.c
• pokedex_cry_screen.c
• pokemon_item_effect.c
• pokemon_1.c
• pokemon_2.c
• pokemon_3.c
• pokemon_menu.c
• pokemon_size_record.c
• pokemon_summary_screen.c
• learn_move.c
• mail.c
• mail_data.c
• mon_markings.c
• pokemon_icon.c

I only recently joined the hype train on this and I've been trying to compile it to no avail. Here's what I did:

Copied pokeruby-tools/tools inside pokeruby-master/tools
Opened MSYS from the start menu.
Changed directory to the root of the project.
Typed make.
Error: "make: *** [build/ruby/sym_bss.ld] Error 123"
Typed make ruby.
Error: "make: *** [build/ruby/agb_flash.o] Error 127"

Sorry if this is a very noobish issue. Your instructions were very vague too. I suggest rewriting it. Thank you for the time. :)

Undecompiled

• contest_painting_effects.s

Decompiled

• berry_blender.c
• egg_hatch.c
• intro_credits_graphics.c
• hall_of_fame.c
• evolution_graphics.c
• evolution_scene.c
• intro.c
• contest_painting.c
• credits.c
• title_screen.c
• new_game.c // birch scene is considered a special scene.

Decompiled

• bard_music.c
• bike.c
• berry.c
• braille_puzzles.c
• cable_car.c
• cable_car_util.c
• daycare.c
• decoration.c
• fieldmap.c
• field_camera.c
• field_control_avatar.c
• field_door.c
• field_effect.c
• field_effect_helpers.c
• field_fadetransition.c
• field_ground_effect.c
• field_map_obj.c
• field_map_obj_helpers.c
• field_player_avatar.c
• field_poison.c
• field_screen_effect.c
• field_special_scene.c
• fldeff_cut.c
• fldeff_softboiled.c
• fldeff_strength.c
• fldeff_sweetscent.c
• fldeff_teleport.c
• heal_location.c
• mauville_old_man.c
• map_obj_lock.c
• metatile_behavior.c
• roamer.c
• rotating_gate.c
• safari_zone.c
• scrcmd.c
• script_movement.c
• secret_base.c
• trainer_see.c
• wild_encounter.c

We have to make sure that data which is copied using certain functions follows the correct alignment requirements.

LZ77 data has to be aligned to 32-bit boundaries.

CpuSet and DMA have 16-bit and 32-bit variations. Data must be aligned accordingly.

CpuFastSet data has to be be aligned to 32-bit boundaries.

I get this error upon trying to compile the current source.

c:\devkitPro\msys\home\Cameron\pokeruby/src/var.c:14: undefined reference to `gSaveBlock10xffff9340'
make: *** [pokeruby.elf] Error 1

Not really sure what's going on here. This is what the generated var.s file contains (empty lines removed).

    .thumb_func
GetVarPointer:
.LFB1:
.LM1:
    push    {lr}
    lsl r0, r0, #0x10
    lsr r1, r0, #0x10
    add r2, r1, #0
.LM2:
    ldr r0, .L7
    cmp r1, r0
    bhi .L3 @cond_branch
.LM3:
    mov r0, #0x0
    b   .L5
.L8:
    .align  2, 0
.L7:
    .word   0x3fff
.L3:
.LM4:
    lsl r0, r1, #0x10
    cmp r0, #0
    bge .L4 @cond_branch
.LM5:
    ldr r0, .L9
    ldr r2, .L9+0x4
    add r1, r1, r2
    lsl r1, r1, #0x2
    add r1, r1, r0
    ldr r0, [r1]
    b   .L6
.L10:
    .align  2, 0
.L9:
    .word   gSpecialVars
    .word   0xffff8000
.L4:
.LM6:
    lsl r0, r2, #0x1
    ldr r1, .L11
    add r0, r0, r1
.L6:
.L5:
.LM7:
    pop {r1}
    bx  r1
.L12:
    .align  2, 0
.L11:
    .word   gSaveBlock10xffff9340
.LFE1:
.Lfe1:
    .size    GetVarPointer,.Lfe1-GetVarPointer

Could this be a compiler bug? I don't know where the stray 0xffff9340 is coming from.

If you are decompiling a file, claim it here.

Currently the ROM's checksum in the header is hardcoded. gbafix should be called in the Makefile to dynamically calculate this value.

If preproc comes across a global label, it inserts a new line with the global command.

test.s

1 _stuff:
2    . string "foo"
3
4 _bar:
5     .string "bar"
6
7 kStuff::
8     .4byte _stuff
9     .4byte_bar

test.s.i

 1 # 1 test.s
 2 _stuff:
 3    . string "foo"
 4
 5 _bar:
 6     .string "bar"
 7
 8     .global kStuff
 9 kStuff:
10     .4byte _stuff
11     .4byte_bar

Starting from line 7, everything shifts downward. When you get a compiler error, it refers to line 10, which doesn't even exist in the original.

test.s.i

 1 # 1 test.s
 2 _stuff:
 3    . string "foo"
 4
 5 _bar:
 6     .string "bar"
 7
 8     .global kStuff
 9 # 7 test.s
10 kStuff:
11     .4byte _stuff
12     .4byte_bar

Adding a location comment after the .global line, would probably correct these issues.

The link in INSTALL.md 404s.

Installing make using Homebrew fixed it howver. Would it be an idea to let the Makefile output a warning if the version number is lower than required?

Output for make -v

GNU Make 3.81
Copyright (C) 2006  Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.

This program built for i386-apple-darwin11.3.0

This would help other GBA-Reverse Engineering projects immensely and allow for improvements more easily/efficiently.
I imagine it being compilable in these steps:

• Get the code from Git
• Run a Makefile or Batch-Script to create the .lib/.o file [would require DevkitPro]
• Call the functions inside the .lib by including it in the project.

How do i install in windows like install.md does not help

$make

make generated
make[1]: Entering directory '/c/Users/user/Desktop/git/pokeruby'
make[1]: Nothing to be done for 'generated'.
make[1]: Leaving directory '/c/Users/user/Desktop/git/pokeruby'
make rom
make[1]: Entering directory '/c/Users/user/Desktop/git/pokeruby'
make[1]: *** No rule to make target 'baserom.gba', needed by 'asm/crt0.o'. Stop.
make[1]: Leaving directory '/c/Users/user/Desktop/git/pokeruby'
make: *** [all] Error 2

I am on Windows.

See above. I've got some documented stuff on Emerald. Wouldn't mind starting pokeEmerald if I knew how it all is done. Tried contacting you, didn't work. My profile on PokeCommunity http://www.pokecommunity.com/member.php?u=454295.

test2.zip

Running this through our mid2agb crashes, while the official Nintendo one from the SDK doesn't.

Compilation yields incorrect checksum for all targets. After comparing the original and built ROMs (I used pokeruby_rev2 for comparison), it seems that some variables in iwram were assigned incorrect addresses (the assigned addresses were 4 or 8 bytes higher). For example, gUnknown_030005A0 is correctly assigned to 0x030005A0, but gUnknown_030005A4 is assigned to 0x030005A8 and gLinkTransferringData is assigned to to 0x300176C instead of 0x3001764.

sound/direct_sound_samples/ contains many files named after their address, like 8456330.aif. These should have meaningful names.

The labels in sound/direct_sound_data.inc (used in sound/voice_groups.inc) should also use the new name.

sound/direct_sound_samples/8456330.aif -> sound/direct_sound_samples/crowd.aif
DirectSoundWaveData_8456330 -> DirectSound_crowd

Managed to match up some tilemaps with tilesheets. Not 100% sure about all of them, but in general these seem to make sense.

Undecompiled

• battle_anim_812C144.s
• battle_anim_813F0F4.s

Decompiled

• battle_anim_807B69C.c
• battle_anim_80CA710.c
• battle_anim_81258BC.c
• pokeball.c
• battle_anim.c
• battle_anim_80A7E7C.c
• smokescreen.c
• battle_anim_8137220.c

Undecompiled

• pokenav.s

Decompiled

• berry_tag_screen.c
• birch_pc.c
• choose_party.c
• coins.c
• coord_event_weather.c
• decoration_inventory.c
• dewford_trend.c
• diploma.c
• easy_chat.c
• event_data.c
• field_region_map.c
• field_message_box.c
• field_specials.c
• field_tasks.c
• hof_pc.c
• item.c
• item_use.c
• landmark.c
• lottery_corner.c
• map_name_popup.c
• money.c
• party_menu.c
• pokeblock.c
• pokeblock_feed.c
• player_pc.c
• roulette.c
• roulette_util.c
• script_menu.c
• shop.c
• slot_machine.c
• start_menu.c
• starter_choose.c
• use_pokeblock.c
• wallclock.c
• tv.c
• item_menu.c
• region_map.c
• trader.s
• fldeff_flash.s
• menu_helpers.s

The issur is while pokemon cry Comes up in battle or what ever freezes an Instrument of the BackgroundMusic. Or this already fixed for win 10 Compiler users? Sorry for my bad english.

https://github.com/pret/pokeruby/blob/master/charmap.txt

The semi colon is not contained. I believe this would be 036.

The 'SetMonData' function takes the third argument as const u8* which I think should be changed to const void*, because of ugly casting that happens whenever that function is called and the set data is a hword or a word.

Currently, MON_DATA_SPD is an ambiguous macro name as outside of the context of MON_DATA_SPDEF it is unclear if it refers to the Speed stat or the Special Defense stat.

Either settle on a consistent length and use SPE for Speed:

• MON_DATA_SPA
• MON_DATA_SPD
• MON_DATA_SPE

Or spell out SPEED in full:

• MON_DATA_SPATK
• MON_DATA_SPDEF
• MON_DATA_SPEED
  Note that SPEED is five characters, which is the same as SPATK and SPDEF which is currently in use.

The former is arguably easier, but the latter is completely unambiguous while being slightly more verbose.

When running 'make' to rebuild the project after changing a single file (or when not even changing anything), it takes almost a whole minute before it starts compiling. This makes it rather annoying when trying to test my C code against the disassembly. I presume this is due to the massive amount of dependencies that Make has to keep track of and checking the timestamp on the thousands of files in the graphics directory takes some time.

Running make won't check if a file's header was modified. I'm not sure if it should do that by default or there should be an additional argument like (make HEADER_CHECK = 1) but it's definitely something that should be implemented.

This system has been decompiled!

Decompiled

• battle_1.c
• battle_2.c
• battle_3.c
• battle_4.c
• battle_5.c
• battle_6.c
• battle_7.c
• battle_8.c
• battle_9.c
• battle_10.c
• battle_811DA74.c
• battle_interface.c
• battle_message.c
• battle_party_menu.c
• battle_records.c
• battle_tower.c
• battle_transition.c
• battle_setup.c
• battle_ai.c
• calculate_base_damage.c // note: doesnt match but is probably functionally equivalent.
• post_battle_event_funcs.c

Note: A file isnt checked just cause its decompiled, its larger utility to the overall system has to be identified.

Decompiled

• rom3.c
• rom4.c
• rom5.c
• rom6.c
• de_rom_8040FE0.c
• rom_8077ABC.c
• unk_text_8095904.c
• unused_8124F94.c
• unused_81258BC.c
• script_pokemon_util_80C4BF0.c
• script_pokemon_util_80F99CC.c
• contest_link_80C857C.c
• battle_anim_80A7E7C.c
• battle_anim_80CA710.c
• battle_anim_807B69C.c

Undecompiled

• battle_anim_812C144.s
• contest_link_80C2020.s
• battle_anim_813F0F4.s

Undecompilable @ they are written in asm.

• crt0.s
• m4a_1.s
• libagbsyscall.s
• libgcnmultiboot.s

Undecompiled

• m4a_3.s

Decompiled/Available in C

• agb_flash.c
• agb_flash_1m.c
• agb_flash_le.c
• agb_flash_mx.c
• blend_palette.c
• cable_club.c
• clear_save_data_menu.c
• clock.c
• decompress.c
• libc.c
• link.c
• load_save.c
• m4a_2.c
• m4a_4.c
• m4a_tables.c
• main.c
• main_menu.c
• menu.c
• menu_cursor.c
• mystery_event_menu.c
• mystery_event_script.c
• name_string_util.c
• naming_screen.c
• option_menu.c
• palette.c
• play_time.c
• rtc.c
• record_mixing.c
• rng.c
• save.c
• save_failed_screen.c
• save_menu_util.c
• script.c
• siirtc.c
• sound.c
• sound_check_menu.c
• sprite.c
• strings.c // actually a data file of nothing but engine-relevent strings
• string_util.c
• task.c
• text.c
• text_window.c
• tileset_anim.c
• time_events.c
• trade.c
• trainer_card.c
• trig.c
• util.c
• reset_rtc_screen.c

Currently, one of the problems with not having an approachable dissassembly is that no gen 3 map editors support integration with pokeruby. This will also apply to other gen 3 dissassemblies in the future. How do we wanna do this? Refactor maps/ ? Add JSON files to tell the editor where to look?

I got several errors while trying to compile the makefile. I have my baserom.gba has the correct sha1 checksum.

After trying to build Sapphire after running make clean, the checksum does not match. I get a checksum of 54a88794fc62ab9cc286b0a9add517e0fa8de2b3 instead of 3ccbbd45f8553c36463f13b938e833f652b793e4. The rom appears to differ at 0x2165BC.

Originally, the font graphics were supposed to use colored backgrounds to identify the width of each glyph. I'm not sure whether this was removed or just never implemented.

rsfont will need to support this behavior as well.

include/fonts/font0_widths.h:

static const u8 sFont0Widths[] =
{
    3, 6, 6, 6, 6, 6, 6, 6, 6, 6, 8, 6, 6, 6, 6, 6,
    6, 6, 6, 6, 6, 6, 6, 6, 8, 6, 6, 6, 6, 6, 4, 8,
    6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 8, 6, 6, 8,
    8, 8, 8, 8, 8, 8, 3, 8, 8, 8, 8, 8, 8, 8, 8, 8,
    8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8,
    7, 6, 4, 8, 8, 8, 7, 8, 8, 4, 6, 6, 4, 4, 8, 8,
    8, 8, 8, 8, 8, 8, 8, 8, 6, 7, 8, 7, 7, 8, 8, 4,
    7, 8, 8, 8, 8, 8, 7, 8, 7, 7, 7, 7, 7, 7, 8, 7,
    7, 7, 7, 7, 5, 6, 6, 8, 8, 8, 8, 8, 8, 8, 8, 8,
    8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8,
    8, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 3, 6, 3, 5, 3,
    6, 6, 6, 3, 3, 6, 6, 6, 3, 6, 6, 6, 6, 6, 6, 6,
    6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6,
    6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 4, 5, 6,
    3, 6, 6, 6, 6, 6, 5, 6, 6, 6, 6, 6, 6, 6, 6, 7,
    3, 6, 6, 6, 6, 6, 6, 7, 7, 7, 7, 7, 1, 1,
};

When I try to edit black and white images, it does not appear correctly in the game. The image looks like it is in a different type because it always increases the size when saved. Is there any way to get it to compile properly or software that can edit it?
I already tried with GIMP, Paint, Paint XP, GraphicsGale, Irfanview and Photoshop. All with palette file too.

I think this function has a wrong name. It should be renamed to 'GetSetNationalPokedexFlag' or something similar, because it doesn't just get a flag, it can also set it.
Depending on the argument:
0 = get if seen
1 = get if caught
2 = set seen
3 = set caught

I'm working on decompiling rock.c and I've noticed that the C code for do_boulder_dust used REG_BG1CNT as a bit-struct instead of an integer.

Specifically, this C statement REG_BG1CNT.priority = 1; (used by do_boulder_dust) translates to:

LDR             R4, =0x400000A
LDRB            R1, [R4]
MOVS            R0, #4
NEGS            R0, R0
ANDS            R0, R1
MOVS            R1, #1
ORRS            R0, R1
STRB            R0, [R4]

While the equivalent yet more arithmetic version REG_BG1CNT = (REG_BG1CNT & ~3) | 1; (used by sub_809EC38 from pokemon_summary_screen.c) translates to:

LDR             R4, =0x400000A
LDRH            R1, [R4]
LDR             R0, =0xFFFC
ANDS            R0, R1
MOVS            R1, #1
ORRS            R0, R1
STRH            R0, [R4]
LDRH            R1, [R4]

To properly decompile that function, the REG_BGXCNT registers must be redefined as unions, so they can be used as both integers and bit structs. Meanwhile, in order to avoid refactoring pretty much everything else in order to decompile this function, I'm using ((struct BGCNT *) &REG_BG1CNT) as a temporary hack.

First column is the English 1.1, second is German 1.0, third is German debug.

http://marijnvdwerf.nl/u/1482242250-pokeruby-debug/

Seeing that so many of the graphics files are compressed, I think it would drastically improve build times if gbagfx was able to convert directly from example.png to example.4bpp.lz without creating a example.4bpp file first. A great deal of I/O would be reduced since the temporary example.4bpp file would not have to be written and then read again to be compressed.