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.
So, there is this issue I have in bgb. Pretty much, I switch banks, load 4 sprites into the VRAM and then switch back, but for some reason after doing this the display goes a bit mental and starts stewing up a lot of the sprites brig displayed, however this does not occur when I run the game in VBA. Can anyone tell me which is closer to the true device, I can't test it out on my gameboy until I get back to my dorm early next month so that I can use my flash cart adapter. So I'm unsure if this is an issue I need to solve or just the emulator, ill upload a copy of the .gb file so peeps can see exactly what I'm facing later today, or rather early in the morning for everyone else's tomorrow.
Offline
Can you show code instead of just sharing the assembled ROM?
Offline
BGB is by far closer to what you can expect from the actual hardware.
Sounds like you might be altering the pointer to the OAM using a 16-bit INC, DEC, LDI or LDD.
There's a hardware issue on the Gameboy where doing so will cause garbage to be written into the OAM, resulting in unexpected sprite behaviour.
Offline
By the way, "loading sprites to VRAM" doesn't mean anything ; are you loading tiles to VRAM (8000-9FFF), or writing to OAM (FE00-FE9F) ?
If the latter, then you should watch out for 16-bit inc/dec in range FE00-FE9F
By the way, go to BGB's options, tab "Exceptions", and check everything (besides "Break on SGB transfer start"). This will make BGB's debugger pop when you do a lot of wrong things.
Offline
I'll keep that in mind, here are the files requested: https://drive.google.com/file/d/1n1ikd8 … sp=sharing
Offline
Sorry, I should mention that the issue only occurs when I switch to the eleventh bank in order to load the tiles for sprite 3. Regardless of whether or not I actually even initiate a third sprite, as soon as I call that bank switch, even if that's the only thing I do and then I switch back, the issue occurs.
Offline
I checked out, and the reason why your game is acting like a crazy abomination isn't because of that hardware bug.
It's because for some reason one of the first things the game does is put the stack in Echo RAM, in the middle of the OAM buffer.
(For those interested in debugging, @20C3, a `jp hl` instruction is executed, which jumps to a function adding $7D (??!?!?!!!?!????) to sp)
I have no idea why this occurs, because honestly, trying to debug GBDK come makes me wanna throw up
Seriously, I saw THIS several times :
push af inc sp ld a, $00 push af inc sp
Here's some C advice, though :
You should definitely avoid using printf. It's intended only for printing debug info, and using it to display text is a terrible idea ; for example, it clobbers approx. half of your available tiles. You should use another function.
Using printf to clear the screen is especially inefficient.
Offline
Ok, so this problem command, where would I find it in the C file, its not: OBP0_REG = 0xE1; // $E1 = %11100001, is it? because I need to call that to change the background color being used by the sprites. I'm afraid I don't speak assembly very well.
Last edited by jobalisk (2018-01-19 18:18:49)
Offline
I have no idea where this comes from. I believe it's GBDK producing worse code than usual, because this looks like library code.
Offline
yay me. Well it dosn't show up in VBA, so I guess Ill just have to press on and hope it dosn't show up on the gameboy, though I bet it will. Perhaps if I try to put the sprites in another bank before number 11 and call them from that it might work ok.
Ok, can confirm that dosn't work either. It just really hates having its bank switch out after loading in the sprites from bank 1 even though they are already in the VRAM.
Last edited by jobalisk (2018-01-19 22:42:44)
Offline
No, the problem isn't banking or loading data, it's that the stack is being moved for a reason I cannot determine because GBDK generates horrible code.
The reason why it doesn't show up on VBA is because VBA doesn't emulate Echo RAM.
Offline
damn, is there anyway around that, a different gameboy C compiler or something? Is it possible to manually change it in assembly after compiling?
Last edited by jobalisk (2018-01-19 23:54:45)
Offline
Well I fixed it... sort of. I mean, the problems gone, but the code kinda looks more broken now than it did before, and that's saying something. I mean, there's one point where I call an array that's in another bank without switching banks, which somehow works. The weird thing is, if I switch the bank before I call it the problem comes back, so that's just damn confusing but what the hell.
Offline
Maybe if you wait_vbl_done() befare loading data, it also solves the problem.
Offline
thanks, I'll remember that. As it is though, I've gone and taken this game in a different direction switching from a platformer to a top-down scrolling adventure which is what I had originally intended anyway. Currently, the issue is no longer a problem. Still, I have a feeling that it may come back to bite me in the butt later.
Offline