Gb-studio: [Feature] Update gbdk-2020

Created on 19 Sep 2020  路  68Comments  路  Source: chrismaltby/gb-studio

Is your feature request related to a problem? Please describe.
No.

Describe the solution you'd like
Updating gbdk-2020. There have been several pull requests that would seemingly speed things up, such as faster sprite handling.

Describe alternatives you've considered
N/A

Additional context
I have compiled the latest gbdk-2020 for Ubuntu and get the following output when trying to build a game in GB Studio 2 Beta:

Preparing variables...
Preparing strings...
Preparing images...
Preparing ui...
Preparing sprites...
Preparing avatars...
Preparing music...
Preparing scenes...
Preparation complete
Compiling events...
Unlink _gbsbuild
Copy default engine
Looking for local engine in assets/engine
Local engine not found, using default engine
Generate header: data_ptrs.h
Generate data file: data_ptrs.c
Generate header: banks.h
Generate data file: bank_6.c
Generate data file: bank_7.c
Generate object file: bank_6.o
Generate object file: bank_7.o
music_track_101_ approx size in bytes: 6056
music_track_102_ approx size in bytes: 263
Approximate Music bank sizes: 1
Music bank for each track: 8, 8
data_ptrs.c rewritten with new song banks

lcc -Wa-l -Iinclude -c -o obj/main.o src/main.c
lcc -Wa-l -Iinclude -c -o obj/asm.macros.o src/core/asm.macros.s
lcc -Wa-l -Iinclude -c -o obj/Scroll_a.o src/core/Scroll_a.s
lcc -Wa-l -Iinclude -c -o obj/Camera_a.o src/core/Camera_a.s
lcc -Wa-l -Iinclude -c -o obj/gbt_player_bank1.o src/core/gbt_player_bank1.s
lcc -Wa-l -Iinclude -c -o obj/Actor_a.o src/core/Actor_a.s
lcc -Wa-l -Iinclude -c -o obj/gbt_player.o src/core/gbt_player.s
lcc -Wa-l -Iinclude -c -o obj/Math.o src/core/Math.c
lcc -Wa-l -Iinclude -c -o obj/Scroll.o src/core/Scroll.c
lcc -Wa-l -Iinclude -c -o obj/Sprite.o src/core/Sprite.c
lcc -Wa-l -Iinclude -c -o obj/Scroll_b.o src/core/Scroll_b.c
lcc -Wa-l -Iinclude -c -o obj/Sprite_b.o src/core/Sprite_b.c
lcc -Wa-l -Iinclude -c -o obj/Camera.o src/core/Camera.c
lcc -Wa-l -Iinclude -c -o obj/Core_Main.o src/core/Core_Main.c
lcc -Wa-l -Iinclude -c -o obj/FadeManager.o src/core/FadeManager.c
lcc -Wa-l -Iinclude -c -o obj/FadeManager_b.o src/core/FadeManager_b.c
lcc -Wa-l -Iinclude -c -o obj/Projectiles.o src/core/Projectiles.c
lcc -Wa-l -Iinclude -c -o obj/Projectiles_b.o src/core/Projectiles_b.c
lcc -Wa-l -Iinclude -c -o obj/UI_b.o src/core/UI_b.c
lcc -Wa-l -Iinclude -c -o obj/MusicManager.o src/core/MusicManager.c
lcc -Wa-l -Iinclude -c -o obj/Actor.o src/core/Actor.c
lcc -Wa-l -Iinclude -c -o obj/ScriptRunner.o src/core/ScriptRunner.c
lcc -Wa-l -Iinclude -c -o obj/Actor_b.o src/core/Actor_b.c
lcc -Wa-l -Iinclude -c -o obj/BankManager.o src/core/BankManager.c
lcc -Wa-l -Iinclude -c -o obj/ScriptRunner_b.o src/core/ScriptRunner_b.c
lcc -Wa-l -Iinclude -c -o obj/Stack.o src/core/Stack.c
lcc -Wa-l -Iinclude -c -o obj/DataManager.o src/core/DataManager.c
lcc -Wa-l -Iinclude -c -o obj/Collision.o src/core/Collision.c
lcc -Wa-l -Iinclude -c -o obj/Trigger.o src/core/Trigger.c
lcc -Wa-l -Iinclude -c -o obj/Trigger_b.o src/core/Trigger_b.c
lcc -Wa-l -Iinclude -c -o obj/Input.o src/core/Input.c
lcc -Wa-l -Iinclude -c -o obj/UI.o src/core/UI.c
lcc -Wa-l -Iinclude -c -o obj/BankData.o src/core/BankData.c
lcc -Wa-l -Iinclude -c -o obj/Palette.o src/core/Palette.c
lcc -Wa-l -Iinclude -c -o obj/Platform.o src/states/Platform.c
lcc -Wa-l -Iinclude -c -o obj/PointNClick.o src/states/PointNClick.c
lcc -Wa-l -Iinclude -c -o obj/Shmup.o src/states/Shmup.c
lcc -Wa-l -Iinclude -c -o obj/TopDown.o src/states/TopDown.c
lcc -Wa-l -Iinclude -c -o obj/Adventure.o src/states/Adventure.c
lcc -Wa-l -Iinclude -c -o obj/data_ptrs.o src/data/data_ptrs.c  
mkdir -p build/rom
lcc -Wl-yo16 -Wa-l -Wl-g_shadow_OAM=0xC000 -Wl-m -Wl-j -Wl-yt27 -Wl-ya4 -Iinclude -o build/rom/game.gb obj/main.o obj/asm.macros.o obj/Scroll_a.o obj/Camera_a.o obj/gbt_player_bank1.o obj/Actor_a.o obj/gbt_player.o obj/Math.o obj/Scroll.o obj/Sprite.o obj/Scroll_b.o obj/Sprite_b.o obj/Camera.o obj/Core_Main.o obj/FadeManager.o obj/FadeManager_b.o obj/Projectiles.o obj/Projectiles_b.o obj/UI_b.o obj/MusicManager.o obj/Actor.o obj/ScriptRunner.o obj/Actor_b.o obj/BankManager.o obj/ScriptRunner_b.o obj/Stack.o obj/DataManager.o obj/Collision.o obj/Trigger.o obj/Trigger_b.o obj/Input.o obj/UI.o obj/BankData.o obj/Palette.o obj/Platform.o obj/PointNClick.o obj/Shmup.o obj/TopDown.o obj/Adventure.o obj/bank_6.o obj/data_ptrs.o obj/bank_7.o obj/music_bank_8.o  
?ASlink-Warning-Undefined Global _NR13_REG referenced by module _tmp_lcc352891
?ASlink-Warning-Undefined Global _NR14_REG referenced by module _tmp_lcc352891
?ASlink-Warning-Undefined Global _NR50_REG referenced by module _tmp_lcc352891
?ASlink-Warning-Undefined Global _NR41_REG referenced by module _tmp_lcc352891
?ASlink-Warning-Undefined Global _set_sprite_prop referenced by module 
?ASlink-Warning-Undefined Global _NR51_REG referenced by module _tmp_lcc352891
?ASlink-Warning-Undefined Global _NR42_REG referenced by module _tmp_lcc352891
?ASlink-Warning-Undefined Global _NR52_REG referenced by module _tmp_lcc352891
?ASlink-Warning-Undefined Global _NR43_REG referenced by module _tmp_lcc352891
?ASlink-Warning-Undefined Global _strcpy referenced by module _tmp_lcc353391
?ASlink-Warning-Undefined Global _rand referenced by module _tmp_lcc353091
?ASlink-Warning-Undefined Global _NR44_REG referenced by module _tmp_lcc352891
?ASlink-Warning-Undefined Global _LYC_REG referenced by module _tmp_lcc352651
?ASlink-Warning-Undefined Global _SCX_REG referenced by module _tmp_lcc352651
?ASlink-Warning-Undefined Global _SCY_REG referenced by module _tmp_lcc352651
?ASlink-Warning-Undefined Global _move_sprite referenced by module 
?ASlink-Warning-Undefined Global _BGB_profiler_message referenced by module _tmp_lcc352251
?ASlink-Warning-Undefined Global __moduchar 
referenced by module _tmp_lcc352851
?ASlink-Warning-Undefined Global __moduchar referenced by module _tmp_lcc353091
?ASlink-Warning-Undefined Global __muluschar referenced by module _tmp_lcc352811
?ASlink-Warning-Undefined Global __muluschar referenced by module _tmp_lcc353091
?ASlink-Warning-Undefined Global __muluschar referenced by module _tmp_lcc353551
?ASlink-Warning-Undefined Global __muluschar referenced by module _tmp_lcc353591
?ASlink-Warning-Undefined Global __muluschar referenced by module _tmp_lcc353631
?ASlink-Warning-Undefined Global __muluschar referenced by module _tmp_lcc353671
?ASlink-Warning-Undefined Global _LCDC_REG referenced by module _tmp_lcc352451
?ASlink-Warning-Undefined Global _LCDC_REG referenced by module _tmp_lcc352651
?ASlink-Warning-Undefined Global _LCDC_REG referenced by module _tmp_lcc353091
?ASlink-Warning-Undefined Global __divuchar referenced by module _tmp_lcc353091
?ASlink-Warning-Undefined Global __mulint referenced by module _tmp_lcc352451
?ASlink-Warning-Undefined Global __mulint referenced by module _tmp_lcc353231
?ASlink-Warning-Undefined Global _set_win_tiles referenced by module _tmp_lcc352851
?ASlink-Warning-Undefined Global _set_win_tiles referenced by module _tmp_lcc353391
?ASlink-Warning-Undefined Global _set_sprite_data referenced by module _tmp_lcc353181
?ASlink-Warning-Undefined Global _set_sprite_data referenced by module _tmp_lcc353431
?ASlink-Warning-Undefined Global _add_LCD referenced by module _tmp_lcc352651
?ASlink-Warning-Undefined Global __muluchar referenced by module _tmp_lcc353091
?ASlink-Warning-Undefined Global _joypad referenced by module _tmp_lcc352651
?ASlink-Warning-Undefined Global ___sdcc_call_hl referenced by module _tmp_lcc352651
?ASlink-Warning-Undefined Global ___sdcc_call_hl referenced by module _tmp_lcc352971
?ASlink-Warning-Undefined Global _memcpy referenced by module _tmp_lcc352971
?ASlink-Warning-Undefined Global _memcpy referenced by module _tmp_lcc353181
?ASlink-Warning-Undefined Global _memcpy referenced by module _tmp_lcc353391
?ASlink-Warning-Undefined Global _memcpy referenced by module _tmp_lcc353431
?ASlink-Warning-Undefined Global _WX_REG referenced by module _tmp_lcc352651
?ASlink-Warning-Undefined Global _WX_REG referenced by module _tmp_lcc352851
?ASlink-Warning-Undefined Global _WY_REG referenced by module _tmp_lcc352651
?ASlink-Warning-Undefined Global _WY_REG referenced by module _tmp_lcc352851
?ASlink-Warning-Undefined Global _OBP0_REG referenced by module _tmp_lcc352651
?ASlink-Warning-Undefined Global _OBP0_REG referenced by module _tmp_lcc352731
?ASlink-Warning-Undefined Global _OBP1_REG referenced by module _tmp_lcc352651
?ASlink-Warning-Undefined Global _set_sprite_tile referenced by module 
?ASlink-Warning-Undefined Global _strcat referenced by module _tmp_lcc353391
?ASlink-Warning-Undefined Global _add_TIM referenced by module _tmp_lcc352651
?ASlink-Warning-Undefined Global _TAC_REG referenced by module _tmp_lcc352651
?ASlink-Warning-Undefined Global _BGP_REG referenced by module _tmp_lcc352651
?ASlink-Warning-Undefined Global _BGP_REG referenced by module _tmp_lcc352731
?ASlink-Warning-Undefined Global _strlen referenced by module _tmp_lcc352851
?ASlink-Warning-Undefined Global _set_bkg_data referenced by module _tmp_lcc352851
?ASlink-Warning-Undefined Global _set_bkg_data referenced by module _tmp_lcc353181
?ASlink-Warning-Undefined Global _set_bkg_data referenced by module _tmp_lcc353431
?ASlink-Warning-Undefined Global _STAT_REG referenced by module _tmp_lcc352651
?ASlink-Warning-Undefined Global _initrand referenced by module _tmp_lcc352411
?ASlink-Warning-Undefined Global __modsint referenced by module _tmp_lcc352811
?ASlink-Warning-Undefined Global __modsint referenced by module _tmp_lcc352851
?ASlink-Warning-Undefined Global _NR10_REG referenced by module _tmp_lcc352891
?ASlink-Warning-Undefined Global _NR11_REG referenced by module _tmp_lcc352891
?ASlink-Warning-Undefined Global _TMA_REG referenced by module _tmp_lcc352651
?ASlink-Warning-Undefined Global _NR12_REG referenced by module _tmp_lcc352891
?ASlink-Warning-Undefined Global __divsint referenced by module _tmp_lcc352851
make: *** [Makefile:53: build/rom/game.gb] Error 1
2

Warnings:
- ?ASlink-Warning-Undefined Global _NR13_REG referenced by module _tmp_lcc352891
- ?ASlink-Warning-Undefined Global _NR14_REG referenced by module _tmp_lcc352891
- ?ASlink-Warning-Undefined Global _NR50_REG referenced by module _tmp_lcc352891
- ?ASlink-Warning-Undefined Global _NR41_REG referenced by module _tmp_lcc352891
- ?ASlink-Warning-Undefined Global _set_sprite_prop referenced by module 
- ?ASlink-Warning-Undefined Global _NR51_REG referenced by module _tmp_lcc352891
- ?ASlink-Warning-Undefined Global _NR42_REG referenced by module _tmp_lcc352891
- ?ASlink-Warning-Undefined Global _NR52_REG referenced by module _tmp_lcc352891
- ?ASlink-Warning-Undefined Global _NR43_REG referenced by module _tmp_lcc352891
- ?ASlink-Warning-Undefined Global _strcpy referenced by module _tmp_lcc353391
- ?ASlink-Warning-Undefined Global _rand referenced by module _tmp_lcc353091
- ?ASlink-Warning-Undefined Global _NR44_REG referenced by module _tmp_lcc352891
- ?ASlink-Warning-Undefined Global _LYC_REG referenced by module _tmp_lcc352651
- ?ASlink-Warning-Undefined Global _SCX_REG referenced by module _tmp_lcc352651
- ?ASlink-Warning-Undefined Global _SCY_REG referenced by module _tmp_lcc352651
- ?ASlink-Warning-Undefined Global _move_sprite referenced by module 
- ?ASlink-Warning-Undefined Global _BGB_profiler_message referenced by module _tmp_lcc352251
- ?ASlink-Warning-Undefined Global __moduchar 
- referenced by module _tmp_lcc352851
- ?ASlink-Warning-Undefined Global __moduchar referenced by module _tmp_lcc353091
- ?ASlink-Warning-Undefined Global __muluschar referenced by module _tmp_lcc352811
- ?ASlink-Warning-Undefined Global __muluschar referenced by module _tmp_lcc353091
- ?ASlink-Warning-Undefined Global __muluschar referenced by module _tmp_lcc353551
- ?ASlink-Warning-Undefined Global __muluschar referenced by module _tmp_lcc353591
- ?ASlink-Warning-Undefined Global __muluschar referenced by module _tmp_lcc353631
- ?ASlink-Warning-Undefined Global __muluschar referenced by module _tmp_lcc353671
- ?ASlink-Warning-Undefined Global _LCDC_REG referenced by module _tmp_lcc352451
- ?ASlink-Warning-Undefined Global _LCDC_REG referenced by module _tmp_lcc352651
- ?ASlink-Warning-Undefined Global _LCDC_REG referenced by module _tmp_lcc353091
- ?ASlink-Warning-Undefined Global __divuchar referenced by module _tmp_lcc353091
- ?ASlink-Warning-Undefined Global __mulint referenced by module _tmp_lcc352451
- ?ASlink-Warning-Undefined Global __mulint referenced by module _tmp_lcc353231
- ?ASlink-Warning-Undefined Global _set_win_tiles referenced by module _tmp_lcc352851
- ?ASlink-Warning-Undefined Global _set_win_tiles referenced by module _tmp_lcc353391
- ?ASlink-Warning-Undefined Global _set_sprite_data referenced by module _tmp_lcc353181
- ?ASlink-Warning-Undefined Global _set_sprite_data referenced by module _tmp_lcc353431
- ?ASlink-Warning-Undefined Global _add_LCD referenced by module _tmp_lcc352651
- ?ASlink-Warning-Undefined Global __muluchar referenced by module _tmp_lcc353091
- ?ASlink-Warning-Undefined Global _joypad referenced by module _tmp_lcc352651
- ?ASlink-Warning-Undefined Global ___sdcc_call_hl referenced by module _tmp_lcc352651
- ?ASlink-Warning-Undefined Global ___sdcc_call_hl referenced by module _tmp_lcc352971
- ?ASlink-Warning-Undefined Global _memcpy referenced by module _tmp_lcc352971
- ?ASlink-Warning-Undefined Global _memcpy referenced by module _tmp_lcc353181
- ?ASlink-Warning-Undefined Global _memcpy referenced by module _tmp_lcc353391
- ?ASlink-Warning-Undefined Global _memcpy referenced by module _tmp_lcc353431
- ?ASlink-Warning-Undefined Global _WX_REG referenced by module _tmp_lcc352651
- ?ASlink-Warning-Undefined Global _WX_REG referenced by module _tmp_lcc352851
- ?ASlink-Warning-Undefined Global _WY_REG referenced by module _tmp_lcc352651
- ?ASlink-Warning-Undefined Global _WY_REG referenced by module _tmp_lcc352851
- ?ASlink-Warning-Undefined Global _OBP0_REG referenced by module _tmp_lcc352651
- ?ASlink-Warning-Undefined Global _OBP0_REG referenced by module _tmp_lcc352731
- ?ASlink-Warning-Undefined Global _OBP1_REG referenced by module _tmp_lcc352651
- ?ASlink-Warning-Undefined Global _set_sprite_tile referenced by module 
- ?ASlink-Warning-Undefined Global _strcat referenced by module _tmp_lcc353391
- ?ASlink-Warning-Undefined Global _add_TIM referenced by module _tmp_lcc352651
- ?ASlink-Warning-Undefined Global _TAC_REG referenced by module _tmp_lcc352651
- ?ASlink-Warning-Undefined Global _BGP_REG referenced by module _tmp_lcc352651
- ?ASlink-Warning-Undefined Global _BGP_REG referenced by module _tmp_lcc352731
- ?ASlink-Warning-Undefined Global _strlen referenced by module _tmp_lcc352851
- ?ASlink-Warning-Undefined Global _set_bkg_data referenced by module _tmp_lcc352851
- ?ASlink-Warning-Undefined Global _set_bkg_data referenced by module _tmp_lcc353181
- ?ASlink-Warning-Undefined Global _set_bkg_data referenced by module _tmp_lcc353431
- ?ASlink-Warning-Undefined Global _STAT_REG referenced by module _tmp_lcc352651
- ?ASlink-Warning-Undefined Global _initrand referenced by module _tmp_lcc352411
- ?ASlink-Warning-Undefined Global __modsint referenced by module _tmp_lcc352811
- ?ASlink-Warning-Undefined Global __modsint referenced by module _tmp_lcc352851
- ?ASlink-Warning-Undefined Global _NR10_REG referenced by module _tmp_lcc352891
- ?ASlink-Warning-Undefined Global _NR11_REG referenced by module _tmp_lcc352891
- ?ASlink-Warning-Undefined Global _TMA_REG referenced by module _tmp_lcc352651
- ?ASlink-Warning-Undefined Global _NR12_REG referenced by module _tmp_lcc352891
- ?ASlink-Warning-Undefined Global __divsint referenced by module _tmp_lcc352851
- make: *** [Makefile:53: build/rom/game.gb] Error 1
- 2

Additionally, the pull request I linked above states:

.OAM name changed to _shadow_OAM - must pass that into the linker through the commandline: -g _shadow_OAM=0xC000

I am not sure if I did this correctly by modifying the LFLAGS line in gb-studio/appData/src/gb/Makefile to read:
LFLAGS = $(LFLAGS_NBANKS) -Wa-l -Wl-g_shadow_OAM=0xC000 -Wl-m -Wl-j -Wl-yt27 -Wl-ya4
but it did remove one warning for _shadow_OAM being undefined.

enhancement

Most helpful comment

All 68 comments

I already made an issue for this: https://github.com/chrismaltby/gb-studio/issues/424

I'm not sure I see a pull request. However, the v2beta branch already switched over from gbdk to gbdk-2020. To my understanding, there have been further optimisations made to gbdk-2020 since it was incorporated in the beta, which would be great to have.

Sorry, I meant issue. 馃槄

Update:
Using the latest commit of gbdk-2020, the linker warnings have gone down drastically. "-Wl-g_shadow_OAM=0xC000" is no longer necessary, as gbdk-2020 now sets this. Building the same project now only gives the following warnings:

?ASlink-Warning-Undefined Global '_set_sprite_prop' referenced by module ''
?ASlink-Warning-Undefined Global '_move_sprite' referenced by module ''
?ASlink-Warning-Undefined Global '_set_sprite_tile' referenced by module ''
make: *** [Makefile:53: build/rom/game.gb] Error 1
2

"_set_sprite_prop", "_move_sprite", and "_set_sprite_tile" were removed in the same commit and are only referenced in appData/src/gb/src/core/Actor_a.s
I'm not sure what it would take to fix this. I tried renaming "_set_sprite_prop" to ".set_sprite_prop", "_set_sprite_tile" to ".set_sprite_tile", and "_move_sprite" to "move_sprite" and now get this error:

error: size of the buffer is too small.
make: *** [Makefile:53: build/rom/game.gb] Error 1
2

I imagine it isn't quite as simple as renaming things, so I have to leave this to the pros while I learn more, but this is what I've discovered so far.

Might wait for a master release of gbdk2020, but thanks for testing with the development branch!

Looks like @untoxa has found a faster way of doing these functions for c, but we'll need to redo how it's called in asm, you're probably on the right track swaping _ for . But we might need to pass data differently, seems all the indexing math is added with the inline c compile instead of the assembly function.

most of GBDK library is designed as follows: you have a function that begins with a dot, say .SOME , that contains "payload" and C "wrapper", that begins with underline: _SOME and the purpose of that wrapper is to make .SOME be compatible with smallc calling convention. It fetches parameters from stack, put them into registers that function expects, preserves BC register pair, returns result in HLDE if expected, call .SOME in the middle of it.

if you are writing something in ASM, it is couter-productive to put function parameters on stack to make them being fetched and so on. you should call .SOME instead, passing parameters into it, the way it expects.

new GBDK uses efficient inline functions for *_sprite() functions. that means that there is no code in the library that is called from C now, the code of those functions is inlined with the code of the "game", that's why wrappers are no longer needed. it turns out, that inlining of those functions emits smaller code than for pushing parameters and calling the wrapper! :)

as for ASM, you should either access _shadow_OAM array directly (making the similar inlining), or call those LEGACY .SOME functions. of course you should pass parameters into them differently. that will reduce code size and increase speed twice or, maybe, more.

ps: btw, mentioned above, UpdateActors() does not preserve BC.

Thank you @untoxa for the amazing work! I tried your build of GB Studio with the dev branch of gbdk-2020 yesterday morning and nearly got a working ROM. The makefile gave an error that it couldn't open "build/rom/game.ihx". I tried editing the makefile, changing ".gb" to ".ihx" and no luck. Ran out of time since to figure it out. I think that's the only thing left to fix at this point.

that because of the problems with LCC. they are fixed by @zal0 today, i believe. just try the 4.0 release.

No luck, I'm afraid. Still getting the following using the released version:

?ASlink-Error-<cannot open> : "build/rom/game.ihx"
make: *** [Makefile:53: build/rom/game.gb] Error 1
2

On Manjaro, your build of GB Studio V2, official released version of gbdk-2020 v4.0 for Linux.
Edit:
Cleared the build cache and also the /tmp directory, which sometimes helps resolve gbdk-related issues with GB Studio, and no luck either. Also, just tried compiling gbdk-2020 v4.0 myself and same results.

what is the command it issues? with that line 53. i mean what that line of makefile

$(CC)` $(LFLAGS) -Iinclude -o $@ $^

is resolved into.

With the unmodified makefile, it's resolved to

lcc -Wl-yo16 -Wa-l -Wl-m -Wl-j -Wl-yt27 -Wl-ya4 -Wl-yp0x143=0x80 -Iinclude -o build/rom/game.gb obj/main.o obj/Actor_a.o obj/asm.macros.o obj/Camera_a.o obj/gbt_player_bank1.o obj/gbt_player.o obj/Scroll_a.o obj/Actor_b.o obj/Actor.o obj/BankData.o obj/BankManager.o obj/Camera.o obj/Collision.o obj/Core_Main.o obj/DataManager.o obj/FadeManager_b.o obj/FadeManager.o obj/Input.o obj/Math.o obj/MusicManager.o obj/Palette.o obj/Projectiles_b.o obj/Projectiles.o obj/ScriptRunner_b.o obj/ScriptRunner.o obj/Scroll_b.o obj/Scroll.o obj/Sprite_b.o obj/Sprite.o obj/Stack.o obj/Trigger_b.o obj/Trigger.o obj/UI_b.o obj/UI.o obj/Adventure.o obj/Platform.o obj/PointNClick.o obj/Shmup.o obj/TopDown.o obj/bank_10.o obj/bank_6.o obj/bank_7.o obj/bank_8.o obj/bank_9.o obj/data_ptrs.o obj/music_bank_11.o

Modified by replacing all instances of ".gb" with ".ihx":

lcc -Wl-yo16 -Wa-l -Wl-m -Wl-j -Wl-yt27 -Wl-ya4 -Wl-yp0x143=0x80 -Iinclude -o build/rom/game.ihx obj/main.o obj/Actor_a.o obj/asm.macros.o obj/Camera_a.o obj/gbt_player_bank1.o obj/gbt_player.o obj/Scroll_a.o obj/Actor_b.o obj/Actor.o obj/BankData.o obj/BankManager.o obj/Camera.o obj/Collision.o obj/Core_Main.o obj/DataManager.o obj/FadeManager_b.o obj/FadeManager.o obj/Input.o obj/Math.o obj/MusicManager.o obj/Palette.o obj/Projectiles_b.o obj/Projectiles.o obj/ScriptRunner_b.o obj/ScriptRunner.o obj/Scroll_b.o obj/Scroll.o obj/Sprite_b.o obj/Sprite.o obj/Stack.o obj/Trigger_b.o obj/Trigger.o obj/UI_b.o obj/UI.o obj/Adventure.o obj/Platform.o obj/PointNClick.o obj/Shmup.o obj/TopDown.o obj/bank_10.o obj/bank_6.o obj/bank_7.o obj/bank_8.o obj/bank_9.o obj/data_ptrs.o obj/music_bank_11.o

That results in the error:

?ASlink-Error-<cannot open> : "build/rom/game.ihx"
make: *** [Makefile:53: build/rom/game.ihx] Error 1
2

direct patching of roms with -Wl-ypXXX=YYY is not supported anymore. use gameboy specific options of makebin.

No luck. With a DMG (non-Color) game, results in:

lcc -Wl-yo16 -Wa-l -Wl-m -Wl-j -Wl-yt27 -Wl-ya4 -Iinclude -o build/rom/game.gb obj/main.o obj/Actor_a.o obj/asm.macros.o obj/Camera_a.o obj/gbt_player_bank1.o obj/gbt_player.o obj/Scroll_a.o obj/Actor_b.o obj/Actor.o obj/BankData.o obj/BankManager.o obj/Camera.o obj/Collision.o obj/Core_Main.o obj/DataManager.o obj/FadeManager_b.o obj/FadeManager.o obj/Input.o obj/Math.o obj/MusicManager.o obj/Palette.o obj/Projectiles_b.o obj/Projectiles.o obj/ScriptRunner_b.o obj/ScriptRunner.o obj/Scroll_b.o obj/Scroll.o obj/Sprite_b.o obj/Sprite.o obj/Stack.o obj/Trigger_b.o obj/Trigger.o obj/UI_b.o obj/UI.o obj/Adventure.o obj/Platform.o obj/PointNClick.o obj/Shmup.o obj/TopDown.o obj/bank_6.o obj/bank_7.o obj/bank_8.o obj/data_ptrs.o    
error: size of the buffer is too small.
make: *** [Makefile:53: build/rom/game.gb] Error 1
2

and with a Color game:

lcc -Wl-yo16 -Wa-l -Wl-m -Wl-j -Wl-yt27 -Wl-ya4 -Wm-yc -Iinclude -o build/rom/game.gb obj/main.o obj/Actor_a.o obj/asm.macros.o obj/Camera_a.o obj/gbt_player_bank1.o obj/gbt_player.o obj/Scroll_a.o obj/Actor_b.o obj/Actor.o obj/BankData.o obj/BankManager.o obj/Camera.o obj/Collision.o obj/Core_Main.o obj/DataManager.o obj/FadeManager_b.o obj/FadeManager.o obj/Input.o obj/Math.o obj/MusicManager.o obj/Palette.o obj/Projectiles_b.o obj/Projectiles.o obj/ScriptRunner_b.o obj/ScriptRunner.o obj/Scroll_b.o obj/Scroll.o obj/Sprite_b.o obj/Sprite.o obj/Stack.o obj/Trigger_b.o obj/Trigger.o obj/UI_b.o obj/UI.o obj/Adventure.o obj/Platform.o obj/PointNClick.o obj/Shmup.o obj/TopDown.o obj/bank_10.o obj/bank_6.o obj/bank_7.o obj/bank_8.o obj/bank_9.o obj/data_ptrs.o obj/music_bank_11.o  
error: can't open : No such file or directory
make: *** [Makefile:53: build/rom/game.gb] Error 1
2

did you compile GBDK-2020 yourself or took a binary release?
sdcc -v

Both, same output.
sdcc -v gives me:

SDCC : mcs51/z80/z180/r2k/r3ka/gbz80/tlcs90/ez80_z80/ds390/pic16/pic14/TININative/ds400/hc08/s08/stm8/pdk13/pdk14/pdk15 4.0.0 #11528 (Linux)
published under GNU General Public License (GPL)

SDCC on this machine was from the latest binary release. On my arm64-based PinePhone, had to compile SDCC myself. It's currently out of battery, so can't run the command atm, but I get the same output there.

no. you should use at least 4.0.3 #11875 from here: http://sdcc.sourceforge.net/snap.php

Oops, yeah I goofed that up, my apologies.

SDCC : mcs51/z80/z180/r2k/r3ka/gbz80/tlcs90/ez80_z80/z80n/ds390/pic16/pic14/TININative/ds400/hc08/s08/stm8/pdk13/pdk14/pdk15 4.0.3 #11875 (Linux)
published under GNU General Public License (GPL)

Unfortunately, no change afterwards for Color mode. DMG mode now builds the game, but the screen is entirely blank.
Screenshot from 2020-10-02 13-54-34
Emptied the build cache, cleared /tmp, and tried the builtin emulator as well as VBA-M and an online one.

if you built the gbdk library yourself with #11528, you must rebuild it again with #11875. or just take a precompiled release.

That's what I've done, rebuild with #11875 and tried the precompiled release. Same result. I'll try Windows and see if there's any difference.
Edit:
Still waiting on the game to build. Using the precompiled release of gbdk. This is strangly taking much longer to build the game on a much more powerful desktop than on my old laptop.
Alright, nearly five minutes into building the game, it finally built. No difference in output, only about 4x slower for some reason (again, on more powerful hardware this time).
Capture_1

is it color or dmg? long build because of the optimizer that tries to allocate registers better.

This is DMG. Color doesn't build at all.
Is the optimiser only enabled on the Windows build?

no. should be identical on all targets. i'm not sure what's the difference in gbc vs dmg here. build process only differs with that -Wm-yc switch that can't be the problem. can you put your rom somewhere? together with map and so on. also add -Wl-w.
ps: also: are you compiling generic example?

Strange. I'm not sure why an old laptop could build it from scratch in just over a minute (4GB RAM, integrated graphics, dual-core CPU @1.2GHz) whereas my desktop took five minutes (32GB RAM, GTX 970, six-core/12-thread CPU @3.8GHz). That seems a wee off to me. Mind you, I just wiped the laptop and installed Manjaro a couple days ago, and the Windows install on my desktop is a couple years old. I'll wipe it when I get the chance and test that part again hopefully soon. It's possible it could just be my Windows install, though the older gbdk took less than a minute on that system.

Added -Wl-w to the end of LFLAGS on line 6 of the makefile. The DMG game is a custom game I've been working on, but I did use the generic example for the Color game, which doesn't build.
game.zip
That is the output of the DMG game.

do you have a working copy built with the previous gbdk-2020? i want to compare and also be sure that the problem is in the update, not your game.
LoadScene() loads garbage.

Aye, here it is:
game.zip
Built from my Linux machine, latest commit of the v2beta branch

that is your old rom:
old1

that is your new rom:
new1

as you can see, some data is missing. probably, we found a bug in makebin?

ps: you might have a problem with your old rom too: bank6 seem to overflow.

hm... i just modified standard banks.c example to occupy banks 4-7, and i have this picture:
banks
so, the problem seems to be in GBStudio or your project, not GBDK.

Great find! The project I created just uses the standard features of GB Studio; there's no custom code by ejecting the engine. Also, the sample project from GB Studio V1 (a DMG game) does the same thing, so I have to imagine this is something to do with GB Studio.
As a side note: I did make a couple bastardised versions of gbdk-2020 two weeks ago. I only have one of the two versions and deleted the other. The first, I tried taking the version of gbdk-2020 that is in GB Studio V2 now and manually modified the files, adding most commits up to this one with the exception of the changes causing the massive amount of warnings as listed in the OP. DMG and Color games built fine, but the sprites were beyond corrupted. Mind you, this was when I simply changed "_set_sprite_tile" to ".set_sprite_tile" and so on in GB Studio. Unfortunately, that was the one I deleted. The other version I manually merged fewer commits, some of the itoa and sprintf ones, which I do have, but doesn't have the sprite and screen optimisations. This one works as expected. I'll see if I can replicate the first bastardised version to remember what I omitted. Either the things I omitted or something from after the commit above can hopefully give us a clue what is going on.
Thank you for all your hard work at this!

  1. Take a 100% working branch of gb studio 2.0. Fork it. Compile it as is, make sure everything is working (example project).
  2. Put binaries from gbdk-2020 v4.0 into that working fork (take everything from the binary release, don't compile yourself).
  3. Take my two commits only from that pull request: actor_a.s and makefile. Update the core with them.
  4. Compile example project once more (make a full cleanup before).
  5. Check.

You described what I've already done several times.

  1. Latest commit of GB Studio 2.0 works well. Example project compiles.
git clone -b v2beta https://github.com/chrismaltby/gb-studio
cd gb-studio
yarn
npm run start

Create a new project, with the V2 sample (Color game). Hit the build button, it works. Closed the program.

  1. Deleted the gbdk folder from GB Studio 2.0 and replaced with precompiled version.
  2. Edited the files actor_a.s and makefile appropriately.
npm run start
  1. Cleared /tmp and the build cache. Hit the build button.
  2. No good.
  1. i took GBStudio public beta 3, compiled version from itch.io
  2. extracted sources of demo project with menu item
  3. edited make.bat: corrected paths to lcc and files, added assets that were missing (!!!):
gbdk\bin\lcc -Wa-l -Iinclude -DCGB -c -o obj/bank_9.o        src/data/bank_9.c
gbdk\bin\lcc -Wa-l -Iinclude -DCGB -c -o obj/bank_8.o        src/data/bank_8.c       
gbdk\bin\lcc -Wa-l -Iinclude -DCGB -c -o obj/bank_7.o        src/data/bank_7.c       
gbdk\bin\lcc -Wa-l -Iinclude -DCGB -c -o obj/bank_6.o        src/data/bank_6.c       
gbdk\bin\lcc -Wa-l -Iinclude -DCGB -c -o obj/bank_10.o       src/data/bank_10.c      
gbdk\bin\lcc -Wa-l -Iinclude -DCGB -c -o obj/music_bank_11.o src/music/music_bank_11.c
  1. put updated actor_a.s
  2. ran make.bat
  3. i got a GBC rom with everything in place with the original one

unfortunately, it is not running, something else is wrong. i debugged that a bit - at least VRAM is loaded with the correct tiles, something breaks when it tries to run the script. this is what i get:
my_update

at least, compiling process is smooth (except pt. 3 above), rom layout is correct. it's a GBC rom too.

Thanks @untoxa I've tried out your branch with the GBDK 2020 v4 builds and these are my findings.

Looks like the Mac release on https://github.com/Zal0/gbdk-2020/releases/tag/v4.0 might have an old SDCC version, the included binary is this one
SDCC : mcs51/z80/z180/r2k/r3ka/gbz80/tlcs90/ez80_z80/z80n/ds390/pic16/pic14/TININative/ds400/hc08/s08/stm8/pdk13/pdk14/pdk15 4.0.3 #11868 (Mac OS X x86_64) (11868 rather than 11875)

I've compiled it from source with the right SDCC nightly but even then I'm getting a similar issue to @patrickmollohan

```lcc -Wl-yo -Wa-l -Wl-m -Wl-j -Wl-yt27 -Wl-ya4 -Iinclude -o build/rom/game.gb obj/main.o obj/Actor_a.o obj/Camera_a.o obj/Scroll_a.o obj/asm.macros.o obj/gbt_player.o obj/gbt_player_bank1.o obj/Actor.o obj/Actor_b.o obj/BankData.o obj/BankManager.o obj/Camera.o obj/Collision.o obj/Core_Main.o obj/DataManager.o obj/FadeManager.o obj/FadeManager_b.o obj/Input.o obj/Math.o obj/MusicManager.o obj/Palette.o obj/Projectiles.o obj/Projectiles_b.o obj/ScriptRunner.o obj/ScriptRunner_b.o obj/Scroll.o obj/Scroll_b.o obj/Sprite.o obj/Sprite_b.o obj/Stack.o obj/Trigger.o obj/Trigger_b.o obj/UI.o obj/UI_b.o obj/Adventure.o obj/Platform.o obj/PointNClick.o obj/Shmup.o obj/TopDown.o obj/bank_10.o obj/bank_6.o obj/bank_7.o obj/bank_8.o obj/bank_9.o obj/data_ptrs.o obj/music_bank_11.o
?ASlink-Error- : "build/rom/game.ihx"
make: * [build/rom/game.gb] Error 1

This is my SDCC now

SDCC : mcs51/z80/z180/r2k/r3ka/gbz80/tlcs90/ez80_z80/z80n/ds390/pic16/pic14/TININative/ds400/hc08/s08/stm8/pdk13/pdk14/pdk15 4.0.3 #11875 (Mac OS X x86_64)
published under GNU General Public License (GPL)

This is the game I'm trying to build
[game-gbdk2020v4-test.zip](https://github.com/chrismaltby/gb-studio/files/5321841/game-gbdk2020v4-test.zip)

and I'm just running the following in a Bash prompt to compile

```bash
export GBDKDIR="/Users/cmaltby/Desktop/gbdk2020/"
export PATH="/Users/cmaltby/Desktop/gbdk2020/bin:$PATH"
make clean
make rom

I've added -v to CFLAGS to see all the individual commands that lcc is calling and put the full log up here if that helps:

https://gist.github.com/chrismaltby/2e3987a1d684408a1377e516e6d365c9

I also tried the Windows release and have managed to get a little bit further, it generates a ROM that's just a blank screen! Can probably debug from there though, my first thought would be to strip everything out to just get a single sprite to appear and bring each file back in one-by-one until it stops working.

The problem is though the Windows version is running very slow for me, the project above takes around 7 minutes on a machine with 2.4 GHz 8-Core Intel Core i9 / 64 GB 2667 MHz DDR4!

I'll keep trying things but this is what I've worked out so far.

I'm wondering if the best option is to try to get the game from that attached zip working first (forgetting GB Studio for the moment) and then we can use the working version to make any updates needed to the app.

Thanks everyone for looking into this, definitely excited to get this working!

ah! i commented yout gist, maybe here that info is more useful:
lcc -Wl-yo -Wa-l
must be:
-yo<HOW MUCH>
define the $(CART_SIZE)

i also tried another daily build of SDCC (#11885) it builds much faster in windows. but the problem with non-working rom exists.

crashes on updateFuncs[scene_type]();

scene_type is invalid (0x11h) after LoadScene()

I suggest using far_ptr.h instead of those constructions with pushbank/popbank.

Oh sorry my bad, yeah I've just set CART_SIZE and it builds to the same blank screen we're seeing on Windows, progress!

I actually got the BankManager from ZGB https://github.com/Zal0/ZGB/commit/5b200d37831e52c7cf125a978eaf8b6b76b326d2#diff-0febabe82127c9b9438610d6496b2a57 looks like theres been an update to move it inline asm in recent releases https://github.com/Zal0/ZGB/blob/master/common/src/BankManager.c

Hadn't seen far_ptr.h before, was that new in GBDK2020, just looking at the examples now. So am I right in thinking you use the TO_FAR_PTR macro (or to_far_ptr function to do it in runtime) giving it a function pointer and a bank number to make a far pointer and you can call it with FAR_CALL and it just handles the bank switching for you?

Definitely. Yes. Call stub is not reentrant, because it uses a global var for the short time, but that is not a problem, unless you are using my posix-like threading library for game boy (see examples among my repos).

Cool, thanks I'll try that out. I've just made a new repo just for handling this issue.

https://github.com/chrismaltby/gbdk2020v4-testgame

This is just a single scene taken from the latest sample project, I've included the sample files and the working rom made by the current GB Studio for comparison.

Screenshot 2020-10-04 at 12 13 12

I'm just going to try branches off that to see what works and what doesn't

So I've had a go at fixing that project, starting by removing almost everything and using the galaxy.c example and bringing parts in bit by bit and got to the minimal changes to make a working version of doing the following

https://github.com/chrismaltby/gbdk2020v4-testgame/pull/2/files

adding a BGB log message around LoadScene fixed it!?! Well, kind of fixed it

Screenshot 2020-10-04 at 19 12 54

all the sprites are using the first sprite tile which I think might be an issue with the new Actor_a.s file, not had chance to look into that yet. Other than that it seems to work as expected.

After working out a single log line could fix the engine I tried another fix which is a single line setting the value of bank to a global that's unneeded and gets overwritten a few lines later fixes it too...

https://github.com/chrismaltby/gbdk2020v4-testgame/pull/3/files

I don't know how the new compiler works but looking at the code around it and what happens it almost feels like the compiler is deferring fetching the value of bank until after the POP_BANK so when it tries to use it on 179 the bank has already switched and it's fetching the wrong value. Could be very wrong about that though.

https://github.com/chrismaltby/gbdk2020v4-testgame/blob/41677d575766c4c11dd0099f028a5342a1ca96f0/src/core/DataManager.c#L166-L179

So getting closer, though it would be good to know why this line has an issue because potentially there's other similar bugs that have been introduced that might be harder to spot.

The other thing I noticed is that if I compile with the environment variable set to COLOR=1 to make a GBC rom it fails to build, might be some flags are wrong again there, this is the full output I'm getting

https://gist.github.com/chrismaltby/cd07264c6d765d9303423c18c5ea6bea

Also I had a go at switching out some of the functions to use far_ptr.h but I didn't want to change too much since I managed to get it working without them. Will definitely switch them out once we've narrowed down this issue though.

i suggest

  static UBYTE bank;
  static UBYTE* data_ptr;

Actor_a.s -- my bad:

.set_spr_prop:                                  ;; c - sprite no, e - value, preserves bc, spoils hl
        push bc
        ld hl, #_shadow_OAM+3 
        sla c
        sla c
        ld b, #0
        add hl, bc
        ld (hl), e
        pop bc
        ret

.set_spr_tile:                                  ;; c - sprite no, b - value, preserves bc, spoils hl
        push bc
        ld hl, #_shadow_OAM+2 
        sla c
        sla c
        ld a, b
        ld b, #0
        add hl, bc
        ld (hl), a
        pop bc
        ret

commit https://github.com/chrismaltby/gb-studio/pull/588/commits/da648757b27b05209191df137d1503f40cabdc94 in the pr: https://github.com/chrismaltby/gb-studio/pull/588

i noticed that save name is garbaged, and also platformer crashes when you hit the enemy. overall performance is better.

GBC rom COLOR=1 compiles under windows without any problems. Did you set LFLAGS += -Wm-yc ?
`

@chrismaltby can you please help me try to cut out piece of code with that weird SDCC behaviour to make a minimal example of faulty code generation? that is important for reporting the bug to SDCC team. declaring bank as static https://github.com/chrismaltby/gb-studio/issues/543#issuecomment-703300587 fixes the issue reliably, but it is important to fix the compiler too! that flaw seems to happen because some variables become register-allocated (that is where speed gain comes) and saving/juggling is faulty or missing in some particular case.

Hi @untoxa sure thing, I'll see if I can make a minimal reproducible project from that issue.

I've managed to get color working on Mac by the way, I had to compile from the latest develop branch on gbdk-2020 rather than using the sources from the zip on the v4 release. Not sure what changed but I was all set to figure it and submit a PR when trying the dev branch just fixed it!

Using your latest changes I've actually now got a Mac build of GB Studio that from what I can tell is fully working, I'll push my changes to your PR later.

@chrismaltby yes, LCC changed: https://github.com/Zal0/gbdk-2020/commit/8b3e5492980fdc818333999d80938224cb7db590 processing of that -Wm-yC and similar. also i suggest you to use vs.code & emulicious to debug the core - that helps much (update the emulator). if you need to pass some long parameters into sdcc frontend, also with spaces, then use that kind of construction: -Wf'--max-allocs-per-node 50000' (this one makes register allocation better, for example)

does killing of enemies ~platformer~ ~topdown~ shmup (one with space ship) works? i'm playing with your game from here https://github.com/chrismaltby/gb-studio/issues/543#issuecomment-703116622 , not from the git repo.

ps: also, what do you say about performance?

Hi @untoxa I've cut down as much as I could while still keeping the weird SDCC behaviour in this branch of my test project
https://github.com/chrismaltby/gbdk2020v4-testgame/tree/minimalbug

When compiling that project I get a ROM that just displays the following:

Screenshot 2020-10-05 at 22 31 00

but if I change only the bank variable to be static then I get a working ROM

void LoadScene(UINT16 index) {
  static UBYTE bank;
  // UBYTE bank;
  UBYTE* data_ptr;

that should just display the following

Screenshot 2020-10-05 at 22 31 34

Here's the two ROMs with the only difference being that one variable being static or not.

working_rom.gb.zip

broken_rom.gb.zip

Not had chance to try out the performance on the working version just yet as I've been putting this together but I'll try to have a look at that tomorrow

@chrismaltby unfortunately, roms are not of much help here, we need to report it like this: https://sourceforge.net/p/sdcc/bugs/3097/ look into test4.c attached to that issue.

@untoxa Ah I see, needs to be a much smaller reproduction of the issue, I'll have another go at it.

By the way I've pushed up the changes need to GB Studio to work with GBDK 2020v4 into this branch forked from your PR https://github.com/chrismaltby/gb-studio/tree/features/gbdk2020v4 I've only included the Mac binaries so far.

In testing though I am getting issues you mentioned when shooting the enemies on the space level where the graphics become corrupted and the game crashes.

Screenshot 2020-10-06 at 20 19 12

@chrismaltby definitely. but i'm not familliar with the engine enough yet to figure out where that code lies. :) definitely it's not shmup.c, it's something inside the core. probably in the script runner?
ps: please, answer me on discord.

unfortunately, that issue with crashing while hit the enemies in shmup stage still exists, even after updating. i thought i fixed it, but i was wrong, it was workarounded with --nolospre switch. but it is necessary to find the source of the problem, not just blindly workaround it. if anyone has a clue what function is faulty - i'll be much obliged.

ah!!! i did that. :)
at first, about the metod, that might be useful for such hopeless cases. i was trying to find the problem for some days, but at last i realized, that i had enough of fishing with the fishing rod and now it's time for dynamite.

inputs: we have a working engine if compiled with --nolospre and engine that breaks when you hit enemies if compiled without that switch.

solution:

  1. i compiled a working rom, and took out all asm-files from the object directory, that were the result of compilation.
  2. i compiled non-working rom and did the same
  3. i took asm files from the sources and added them too, so i got an asm-only gb-studio engine.
  4. then i made a makefile that builds the engine from asm sources only - that's easy
  5. i compared the files in "bad" and "ok" folders - some of them has different size. not that many.
  6. then i re-compiled the engine from "bad" state replacing files one by one from "ok" and checked the result.
  7. bingo! the problem was in Projectiles_b.asm

here is the project: 2.zip

so, the problem was, as i expected, with some corner case of the optimizer, just as it was above: https://github.com/chrismaltby/gb-studio/issues/543#issuecomment-704497615 but, unfortunately, another one.

anyway, the workaround is very simple:

void UpdateProjectiles_b() {
  static UBYTE hit;
  UBYTE i, k, j, frame, flip, fo;
//  UBYTE i, k, j, hit, frame, flip, fo;

and the source of the problem is that hit gets optimized, but something goes wrong and when execution gets to the ScriptStartBg(&actors[hit].hit_1_ptr, hit); garbage is executed, so we observe marvelous pictures as above.

!!!! i still need some help with making a minimal example of invalid code generation for reporting it to SDCC devs! @chrismaltby please, help me.

thank you for reading this.

You legend! Thanks @untoxa!! I'll see if I can get some time over the next few days to get you another minimal reproduction of this issue. Looks like we're almost there! 馃榿

maybe Philipp @spth can also have a look onto this: https://github.com/chrismaltby/gb-studio/issues/543#issuecomment-707750833

Hi @untoxa After a LOT of struggling I think I've got about a minimal example of the second issue on this branch:
https://github.com/chrismaltby/gbdk2020v4-testgame/tree/minimalbug-projectiles

#include <gb/gb.h>
#include <stdio.h>

#define MAX_PROJECTILES 5
#define MAX_ACTIVE_ACTORS 11
#define MAX_ACTORS 31

typedef struct _BankPtr
{
  unsigned char bank;
  unsigned int offset;
} BankPtr;

typedef struct _PROJECTILE {
  UBYTE col_group;
} Projectile;

typedef struct {
  BankPtr hit_1_ptr;
  BankPtr hit_2_ptr;
} Actor;

Projectile projectiles[MAX_PROJECTILES];
UBYTE actors_active[MAX_ACTIVE_ACTORS];
Actor actors[MAX_ACTORS];

void TestFn2(BankPtr* events_ptr) {
  if (events_ptr->bank == 5 && events_ptr->offset == 0xFC00) {
    printf("OK\n");
  }
  else
  {
    printf("FAIL\n");
  }
}

void TestFn() {
  UBYTE hit;
  UBYTE i;

  for (i = 0; i != 1; i++) {
      hit = actors_active[0];
      if (hit != 0xFF) {
        if (projectiles[i].col_group == 2) {
            TestFn2(&actors[hit].hit_1_ptr);
        } else if (projectiles[i].col_group == 4) {
            TestFn2(&actors[hit].hit_2_ptr);
        }
      }
  }
}

int main()
{
  LCDC_REG = 0x67;
  BGP_REG = OBP0_REG = OBP1_REG = 0xE4U;
  WX_REG = MAXWNDPOSX;
  WY_REG = MAXWNDPOSY;

  projectiles[0].col_group = 2;
  actors_active[0] = 0;
  actors[0].hit_1_ptr.bank = 5;
  actors[0].hit_1_ptr.offset = 0xFC00;

  TestFn();

  return 0;
}

Same as in the GB Studio engine switching UBYTE hit; for static UBYTE hit; fixes the issue, interestingly removing the loop (that in this example doesn't even really do anything but is needed in the engine) also fixes the issue, maybe hit and i are using the same registers?

@chrismaltby not exactly. here is my view on the problem: https://sourceforge.net/p/sdcc/bugs/3135/

@chrismaltby, here is the latest GBDK-2020 v4.0.1rc: gbdk-2020-v401.zip with the latest SDCC r11925; GB Studio core compiles nicely and i don't see any problems with it.

to make that all a bit more difficult :) i rewrote initialization code of the runtime library, so now it does not fill all WRAM with 0 on start. that allows you to catch errors in code when you use non-initialized variables. you can do that with BGB, by setting it to raise an exception, when non-initialized variable is read:
image

enabling that, raised loads of exceptions when i tried to run GB Studio game. i fixed them all, please have a look: 4.zip

please note, that, say, ScriptContext script_ctxs[MAX_SCRIPT_CONTEXTS] = {{0}}; does not initialize all array of structs with zeros, look at the generated code:

    .globl  C$ScriptRunner.c$23$1_0$156
;src/core/ScriptRunner.c:23: ScriptContext script_ctxs[MAX_SCRIPT_CONTEXTS] = {{0}};
    ld  hl, #_script_ctxs
    xor a, a
    ld  (hl+), a
    ld  (hl), a

everything is working, ready to merge, gbdk-2020 v4.0.1 is released: https://github.com/chrismaltby/gb-studio/pull/588

Was this page helpful?
0 / 5 - 0 ratings

Related issues

Veund picture Veund  路  3Comments

timsamoff picture timsamoff  路  4Comments

wrt0302 picture wrt0302  路  5Comments

mrcampbell picture mrcampbell  路  5Comments

JasonB32 picture JasonB32  路  3Comments