Discussion about software development for the old-school Gameboys, ranging from the "Gray brick" to Gameboy Color
(Launched in 2008)
You are not logged in.
After re-reading some documents, I've just now begun to understand some graphics corruption in my game.
Since I have 32x32 sprites with animations, I've run out of tile space. I have been loading sprite frames and other bg tiles dynamically, but I now see that writing these tiles causes occasional pixel corruption. Until this point I was not trying to work around the mode 3 vram access restriction. Now that I better understand it, I'm wondering if there is a way to work with the issue w/o re-writing or scrapping my current game.
Does anyone have reference to some dynamic tile loading code that they could share?
For instance, when loading single tile data for a dialog sequence, I've inserted some code to wait for mode 3 to complete. It's helped dramatically reduce the corruption, but not completely:
https://imgur.com/a/uWV8U4X
This text is rendered by writing a single font tile at a time to the bg - where those characters are mapped to the dialog area of the window.
PUSH_BANK(2); while((STAT_REG & 0x2) != 0); set_bkg_data(currentTile, 1, &(ascii.data->data[((*currentChar)-32)*16])); POP_BANK;
So even tho I'm waiting on mode3, apparently during the write, mode3 is blocking vram again.
Any suggestions, pseudo code or references about solving this would be helpful.
Offline
Also, I just now inspected the assembly in gbdk's libc file set_data.s - It appears to be accounting for mode 3 already as a built-in feature of set_bkg_data:
_set_bkg_data:: _set_win_data:: ... 4$: LDH A,(.STAT) AND #0x02 JR NZ,4$
now I'm confused
Offline