Forums

Hello, again!
I'm currently trying to develop a compatibility layer to compile GBDK games to devkitSMS.

https://github.com/haroldo-ok/sms-gbdk-compat

This is a work in progress. So far, only galaxy.c has been tested, though it still required some minor adjustments.

galaxy.gg.png (6.51 KB)

Attachment fairy

That's cool! :)
Please keep us updated!

Well, now dscan.c is running too, sort of. I still gotta find out why is everything running so slow... :P

if joypad() should return a byte, then you shouldn't do

#define J_SELECT PORT_B_KEY_START

as PORT_B_KEY_START is 0x0400... you probably want to make that 0x40, but to map that to PORT_B_KEY_START you have to shuffle some bits around as in

return (key & 0x3F) | ((key & GG_KEY_START) ? J_START : 0) | ((key & PORT_B_KEY_START) ? J_SELECT : 0);

***EDIT*** nevermind, I forgot you're using a GG :|
(how will you emulate the 'select' key on a GG btw?)

edit: also, I believe it'll always be very slow if you delay this way:

void delay(UWORD d) {
for (; d; d--) {
SMS_waitForVBlank();
}
}

as every call for SMS_waitForVBlank() waits for the next vBlank to start (thus delay(60) would make this stuck for a whole second...)

That's Awesome!!!
Please keep us updated!

sverx wrote

if joypad() should return a byte, then you shouldn't do

#define J_SELECT PORT_B_KEY_START

as PORT_B_KEY_START is 0x0400... you probably want to make that 0x40, but to map that to PORT_B_KEY_START you have to shuffle some bits around as in

return (key & 0x3F) | ((key & GG_KEY_START) ? J_START : 0) | ((key & PORT_B_KEY_START) ? J_SELECT : 0);

***EDIT*** nevermind, I forgot you're using a GG :|
(how will you emulate the 'select' key on a GG btw?)

Well, yeah, emulating the select button will be a problem on the GG. :P
I guess that part would have to be done manually, depending on the game.

sverx wrote

edit: also, I believe it'll always be very slow if you delay this way:

void delay(UWORD d) {
for (; d; d--) {
SMS_waitForVBlank();
}
}

as every call for SMS_waitForVBlank() waits for the next vBlank to start (thus delay(60) would make this stuck for a whole second...)

Silly me, I must have confused the delay() function with something else... :P

haroldoop wrote

Well, yeah, emulating the select button will be a problem on the GG. :P

You could make START+2, masking them out when pressed together. You could make that under conditional compile switch, eventually...

sverx wrote

haroldoop wrote

Well, yeah, emulating the select button will be a problem on the GG. :P

You could make START+2, masking them out when pressed together. You could make that under conditional compile switch, eventually...

Yes, I guess that would be a fair compromise for most games.

What about reviving this old project?
I think it might be nice!

I think it could be a nice idea; I currently have other ideas in my head, but I may eventually come back to this.

As a test, I'm trying to "convert" quadratino.

So far I found out I had to add this

cgb_compatibility();
move_bkg(0, 0);

right at the beginning to load a palette (something that the GameBoy doesn't have, AFAIK) and to move the viewport from the center of the map (GameGear default) to the upper left corner (GameBoy default, AFAIK) - which both suggest we should create a single function to 'initialize' the GameGear to something suitable for the GameBoy 'emulation'.

Now I'm quite stuck. While at the menu both A & B buttons (1 and 2 buttons) don't seem to respond. Start starts the game, which results in a small square going around screen with nothing to hit or nothing to collect, so I don't get it.

So I was wondering... is there something else I'm missing here? Because it seems it's loading tiles and tilemaps correctly, it seems it's updating the tilemap correctly, it seems to read the pad inputs correctly so... what could be wrong now?

Thanks for your support! :)

edit: oh, wait... sprites!!! Ok, let's see how to fix that :)

edit again: I'm trying also with Flappybird-gb. So far, so good... but also here the sprites seems not to be placed on screen exactly where expected... why is it so? Does the GameBoy expect some offset?

sverx wrote

Does the GameBoy expect some offset?

Yes, it's 8 pixels on the x axis and 16 pixels on the y axis. :)

Thank you!
Also, I forgot that even if I scroll the background 'viewport' at (0,0) the Game Gear will still make me see the sprites as centered on the SMS screen, so I have to offset sprites (256-160)/2 horizontally and (192-144)/2 vertically...

sverx wrote

As a test, I'm trying to "convert" quadratino.

So far I found out I had to add this

cgb_compatibility();
move_bkg(0, 0);

right at the beginning to load a palette (something that the GameBoy doesn't have, AFAIK) and to move the viewport from the center of the map (GameGear default) to the upper left corner (GameBoy default, AFAIK) - which both suggest we should create a single function to 'initialize' the GameGear to something suitable for the GameBoy 'emulation'.

That's a good idea; the best way to know which features the tool is lacking, is by trying to convert something.

BTW, the GB does have a palette, but it's basically just choosing which of the four shades of gray will be mapped to which of the four palette slots for each of the 3 palettes (one for BG, two for sprites); good enough for fades and blinking things, but not much else.

sverx wrote

Now I'm quite stuck. While at the menu both A & B buttons (1 and 2 buttons) don't seem to respond. Start starts the game, which results in a small square going around screen with nothing to hit or nothing to collect, so I don't get it.

That's really weird; looking at the source code, it does not seem to be doing anything unusual with the joypad input.

sverx wrote

So I was wondering... is there something else I'm missing here? Because it seems it's loading tiles and tilemaps correctly, it seems it's updating the tilemap correctly, it seems to read the pad inputs correctly so... what could be wrong now?

Thanks for your support! :)

edit: oh, wait... sprites!!! Ok, let's see how to fix that :)

It's exactly that. ;)
Perhaps one way to make the sprite handling closer to the way GBDK does things would be to add some VBlank interrupt handler that would automatically update the sprite list if necessary; something similar could also be used to transparently simulate SCX_REG, SCY_REG, BGP_REG, OBP0_REG and OBP1_REG (hardware.h).

sverx wrote

edit again: I'm trying also with Flappybird-gb.

That will be nice to see.

sverx wrote

Also, I forgot that even if I scroll the background 'viewport' at (0,0) the Game Gear will still make me see the sprites as centered on the SMS screen, so I have to offset sprites (256-160)/2 horizontally and (192-144)/2 vertically...

Oh, it seems I forgot about that small detail, too... :P
That offset could be computed internally by the sprite functions themselves, so that less modifications would be required.

haroldoop wrote

BTW, the GB does have a palette, but it's basically just choosing which of the four shades of gray will be mapped to which of the four palette slots for each of the 3 palettes (one for BG, two for sprites); good enough for fades and blinking things, but not much else.

I see. I'll investigate more on this later.

haroldoop wrote

Perhaps one way to make the sprite handling closer to the way GBDK does things would be to add some VBlank interrupt handler that would automatically update the sprite list if necessary; something similar could also be used to transparently simulate SCX_REG, SCY_REG, BGP_REG, OBP0_REG and OBP1_REG (hardware.h).

Yes, that's the direction I took already. So far I'm only updating the SAT, though, I still have to see what all these other things actually do...

haroldoop wrote

Oh, it seems I forgot about that small detail, too... :P
That offset could be computed internally by the sprite functions themselves, so that less modifications would be required.

Yes, I thought that too, so I fixed the sprite functions.

Now I'm wondering if is there a feasible way to emulate the APA mode, but I yet have to read more details on how it works (links to tech documents are appreciated!)... Doctor How splash screen is using this mode, so I temporary had to deactivate it...

Also, I suspect there's no easy way to support the so called window, it seems to me it's kind of another background layer that could be freely scrolled around... something completely absent on our Game Gear :|

Finally, any idea on how to implement gprintf()?

OK, let's forget gprintf(), it's APA mode anyway.
I fixed background scroll and some other little stuff.
To test the compatibility layer on a fresh project, I took Novascape source code... and it compiled straight, no errors!
All I had then to do is to add this, to properly initialize the Game Gear:

smsgbdk_init(SMSGBDK_MODE_NORMAL);

right after

int main() {

Unfortunately the game still doesn't work. It loads the assets and then it should show the menu, but it all turns rightly into the black GAME OVER screen. Weird, uh? I'm quite lost.

sverx wrote

haroldoop wrote

Perhaps one way to make the sprite handling closer to the way GBDK does things would be to add some VBlank interrupt handler that would automatically update the sprite list if necessary; something similar could also be used to transparently simulate SCX_REG, SCY_REG, BGP_REG, OBP0_REG and OBP1_REG (hardware.h).

Yes, that's the direction I took already. So far I'm only updating the SAT, though, I still have to see what all these other things actually do...

SCX_REG and SCY_REG are memory-mapped scroll registers; I don't think they could be directly implemented without requiring source code modification, but it would be possible to simply map them to temporary variables, that would be read by the VBL handler.

BGP_REG, OBP0_REG and OBP1_REG are memory-mapped palette registers; again, they probably can't be implemented directly, but could use the aforementioned trick.

sverx wrote

Now I'm wondering if is there a feasible way to emulate the APA mode, but I yet have to read more details on how it works (links to tech documents are appreciated!)... Doctor How splash screen is using this mode, so I temporary had to deactivate it...

Well, your best source would be the GBDK documentation itself for the high-level stuff, and its source code for the low-level stuff.

Basically, it works by setting a fixed BG map and then changing the tileset dinamically, similar to my old APA experiment. Most of GBDK's APA implementation is in assembly, but since GB-Z80 assembly is very similar to Z80, that shouldn't be an obstacle for understanding; in fact, converting it would be mostly search-and-replace, if it wasn't for huge differences in the way VRAM is acessed: GB's VRAM can be directly acessed by the CPU as if it was RAM, while the SMS/GG's uses a "blackbox-with-a-keyhole"/"build-a-ship-inside-a-bottle" approach. :P

sverx wrote

Also, I suspect there's no easy way to support the so called window, it seems to me it's kind of another background layer that could be freely scrolled around... something completely absent on our Game Gear :|

Yes, the window is essentially a large opaque rectangle with its own separate BG map that can be placed anywhere on the screen. I don't believe it could be implemented in a generic way on SMS/GG hardware.

sverx wrote

Finally, any idea on how to implement gprintf()?

It works by drawing the current font's pixels to the APA; once APA is implemented, gprintf() would become just be a minor detail.

I'm guessing the Window was largely intended to be used for creating HUDs.

SMS basically had a HUD feature built in (the scroll locks), though I assume the cropped display area of the GG basically nullified that?

NES though, to get a graphical HUD, programmers had to play tricks with the background layer scrolling.

haroldoop wrote

SCX_REG and SCY_REG are memory-mapped scroll registers; I don't think they could be directly implemented without requiring source code modification, but it would be possible to simply map them to temporary variables, that would be read by the VBL handler.

Yes, that's actually what I'm planning to do :)

haroldoop wrote

BGP_REG, OBP0_REG and OBP1_REG are memory-mapped palette registers; again, they probably can't be implemented directly, but could use the aforementioned trick.

I'll read more on those later.

haroldoop wrote

Basically, [APA] works by setting a fixed BG map and then changing the tileset dinamically, similar to my old APA experiment. Most of GBDK's APA implementation is in assembly, but since GB-Z80 assembly is very similar to Z80, that shouldn't be an obstacle for understanding; in fact, converting it would be mostly search-and-replace, if it wasn't for huge differences in the way VRAM is acessed: GB's VRAM can be directly acessed by the CPU as if it was RAM, while the SMS/GG's uses a "blackbox-with-a-keyhole"/"build-a-ship-inside-a-bottle" approach. :P

On Game Gear fortunately we've got enough memory to fill the screen with different tiles so maybe this is possible too. I think I will ask you for some collaboration, here... ;)

SCX_REG and SCY_REG should work now.
APA mode draw_image() function was a breeze, after all. I just had to load the 360 2bpp tiles from the blob and build an appropriate map... and that's it.
Printing text in APA mode anyway won't be so straightforward, as it requires updating a few bytes in VRAM for each affected pixel :|

The SMS drawing board is basically doing APA, and it has a bunch of optimisations for things like filling but mostly spends its time plotting pixels slowly. My disassembly might be helpful for reference.

Thanks! I'm still not sure I'm going to embark on such a project by the way... I don't see the point of APA to be honest.

sverx wrote

Thanks! I'm still not sure I'm going to embark on such a project by the way... I don't see the point of APA to be honest.

Yes, AFAIK, almost no GBDK program uses it, anyway.

Author	Message
haroldoop Joined: 25 Feb 2006 Posts: 874 Location: Belo Horizonte, MG, Brazil	Compiling old GBDK games on devkitSMS Posted: Wed Sep 23, 2015 2:33 am
	Hello, again! I'm currently trying to develop a compatibility layer to compile GBDK games to devkitSMS. https://github.com/haroldo-ok/sms-gbdk-compat This is a work in progress. So far, only galaxy.c has been tested, though it still required some minor adjustments. galaxy.gg.png (6.51 KB) Attachment fairy

sverx Joined: 05 Sep 2013 Posts: 3827 Location: Stockholm, Sweden	Posted: Wed Sep 23, 2015 9:32 am
	That's cool! :) Please keep us updated!

haroldoop Joined: 25 Feb 2006 Posts: 874 Location: Belo Horizonte, MG, Brazil	Posted: Thu Sep 24, 2015 12:23 am
	Well, now dscan.c is running too, sort of. I still gotta find out why is everything running so slow... :P

sverx Joined: 05 Sep 2013 Posts: 3827 Location: Stockholm, Sweden	Posted: Thu Sep 24, 2015 3:24 pm Last edited by sverx on Thu Sep 24, 2015 6:57 pm; edited 1 time in total
	if joypad() should return a byte, then you shouldn't do #define J_SELECT PORT_B_KEY_START as PORT_B_KEY_START is 0x0400... you probably want to make that 0x40, but to map that to PORT_B_KEY_START you have to shuffle some bits around as in return (key & 0x3F) \| ((key & GG_KEY_START) ? J_START : 0) \| ((key & PORT_B_KEY_START) ? J_SELECT : 0); *EDIT* nevermind, I forgot you're using a GG :\| (how will you emulate the 'select' key on a GG btw?) edit: also, I believe it'll always be very slow if you delay this way: void delay(UWORD d) { for (; d; d--) { SMS_waitForVBlank(); } } as every call for SMS_waitForVBlank() waits for the next vBlank to start (thus delay(60) would make this stuck for a whole second...)

Linkuei Joined: 21 Sep 2015 Posts: 10	Posted: Thu Sep 24, 2015 4:37 pm
Linkuei Joined: 21 Sep 2015 Posts: 10	That's Awesome!!! Please keep us updated!

haroldoop Joined: 25 Feb 2006 Posts: 874 Location: Belo Horizonte, MG, Brazil	Posted: Thu Sep 24, 2015 11:07 pm
	sverx wrote if joypad() should return a byte, then you shouldn't do #define J_SELECT PORT_B_KEY_START as PORT_B_KEY_START is 0x0400... you probably want to make that 0x40, but to map that to PORT_B_KEY_START you have to shuffle some bits around as in return (key & 0x3F) \| ((key & GG_KEY_START) ? J_START : 0) \| ((key & PORT_B_KEY_START) ? J_SELECT : 0); *EDIT* nevermind, I forgot you're using a GG :\| (how will you emulate the 'select' key on a GG btw?) Well, yeah, emulating the select button will be a problem on the GG. :P I guess that part would have to be done manually, depending on the game. sverx wrote edit: also, I believe it'll always be very slow if you delay this way: void delay(UWORD d) { for (; d; d--) { SMS_waitForVBlank(); } } as every call for SMS_waitForVBlank() waits for the next vBlank to start (thus delay(60) would make this stuck for a whole second...) Silly me, I must have confused the delay() function with something else... :P

sverx Joined: 05 Sep 2013 Posts: 3827 Location: Stockholm, Sweden	Posted: Fri Sep 25, 2015 8:08 am
	haroldoop wrote Well, yeah, emulating the select button will be a problem on the GG. :P You could make START+2, masking them out when pressed together. You could make that under conditional compile switch, eventually...

haroldoop Joined: 25 Feb 2006 Posts: 874 Location: Belo Horizonte, MG, Brazil	Posted: Fri Sep 25, 2015 11:11 pm
	sverx wrote haroldoop wrote Well, yeah, emulating the select button will be a problem on the GG. :P You could make START+2, masking them out when pressed together. You could make that under conditional compile switch, eventually... Yes, I guess that would be a fair compromise for most games.

sverx Joined: 05 Sep 2013 Posts: 3827 Location: Stockholm, Sweden	Posted: Tue Dec 27, 2016 2:12 pm
	What about reviving this old project? I think it might be nice!

haroldoop Joined: 25 Feb 2006 Posts: 874 Location: Belo Horizonte, MG, Brazil	Posted: Tue Dec 27, 2016 9:30 pm
	I think it could be a nice idea; I currently have other ideas in my head, but I may eventually come back to this.

sverx Joined: 05 Sep 2013 Posts: 3827 Location: Stockholm, Sweden	Posted: Wed Dec 28, 2016 9:33 am
	As a test, I'm trying to "convert" quadratino. So far I found out I had to add this cgb_compatibility(); move_bkg(0, 0); right at the beginning to load a palette (something that the GameBoy doesn't have, AFAIK) and to move the viewport from the center of the map (GameGear default) to the upper left corner (GameBoy default, AFAIK) - which both suggest we should create a single function to 'initialize' the GameGear to something suitable for the GameBoy 'emulation'. Now I'm quite stuck. While at the menu both A & B buttons (1 and 2 buttons) don't seem to respond. Start starts the game, which results in a small square going around screen with nothing to hit or nothing to collect, so I don't get it. So I was wondering... is there something else I'm missing here? Because it seems it's loading tiles and tilemaps correctly, it seems it's updating the tilemap correctly, it seems to read the pad inputs correctly so... what could be wrong now? Thanks for your support! :) edit: oh, wait... sprites!!! Ok, let's see how to fix that :) edit again: I'm trying also with Flappybird-gb. So far, so good... but also here the sprites seems not to be placed on screen exactly where expected... why is it so? Does the GameBoy expect some offset?

Calindro Joined: 14 Apr 2013 Posts: 624	Posted: Wed Dec 28, 2016 11:08 am
Calindro Joined: 14 Apr 2013 Posts: 624	sverx wrote Does the GameBoy expect some offset? Yes, it's 8 pixels on the x axis and 16 pixels on the y axis. :)

sverx Joined: 05 Sep 2013 Posts: 3827 Location: Stockholm, Sweden	Posted: Wed Dec 28, 2016 1:42 pm
	Thank you! Also, I forgot that even if I scroll the background 'viewport' at (0,0) the Game Gear will still make me see the sprites as centered on the SMS screen, so I have to offset sprites (256-160)/2 horizontally and (192-144)/2 vertically...

haroldoop Joined: 25 Feb 2006 Posts: 874 Location: Belo Horizonte, MG, Brazil	Posted: Wed Dec 28, 2016 9:41 pm
	sverx wrote As a test, I'm trying to "convert" quadratino. So far I found out I had to add this cgb_compatibility(); move_bkg(0, 0); right at the beginning to load a palette (something that the GameBoy doesn't have, AFAIK) and to move the viewport from the center of the map (GameGear default) to the upper left corner (GameBoy default, AFAIK) - which both suggest we should create a single function to 'initialize' the GameGear to something suitable for the GameBoy 'emulation'. That's a good idea; the best way to know which features the tool is lacking, is by trying to convert something. BTW, the GB does have a palette, but it's basically just choosing which of the four shades of gray will be mapped to which of the four palette slots for each of the 3 palettes (one for BG, two for sprites); good enough for fades and blinking things, but not much else. sverx wrote Now I'm quite stuck. While at the menu both A & B buttons (1 and 2 buttons) don't seem to respond. Start starts the game, which results in a small square going around screen with nothing to hit or nothing to collect, so I don't get it. That's really weird; looking at the source code, it does not seem to be doing anything unusual with the joypad input. sverx wrote So I was wondering... is there something else I'm missing here? Because it seems it's loading tiles and tilemaps correctly, it seems it's updating the tilemap correctly, it seems to read the pad inputs correctly so... what could be wrong now? Thanks for your support! :) edit: oh, wait... sprites!!! Ok, let's see how to fix that :) It's exactly that. ;) Perhaps one way to make the sprite handling closer to the way GBDK does things would be to add some VBlank interrupt handler that would automatically update the sprite list if necessary; something similar could also be used to transparently simulate SCX_REG, SCY_REG, BGP_REG, OBP0_REG and OBP1_REG (hardware.h). sverx wrote edit again: I'm trying also with Flappybird-gb. That will be nice to see. sverx wrote Also, I forgot that even if I scroll the background 'viewport' at (0,0) the Game Gear will still make me see the sprites as centered on the SMS screen, so I have to offset sprites (256-160)/2 horizontally and (192-144)/2 vertically... Oh, it seems I forgot about that small detail, too... :P That offset could be computed internally by the sprite functions themselves, so that less modifications would be required.

sverx Joined: 05 Sep 2013 Posts: 3827 Location: Stockholm, Sweden	Posted: Thu Dec 29, 2016 9:23 am
	haroldoop wrote BTW, the GB does have a palette, but it's basically just choosing which of the four shades of gray will be mapped to which of the four palette slots for each of the 3 palettes (one for BG, two for sprites); good enough for fades and blinking things, but not much else. I see. I'll investigate more on this later. haroldoop wrote Perhaps one way to make the sprite handling closer to the way GBDK does things would be to add some VBlank interrupt handler that would automatically update the sprite list if necessary; something similar could also be used to transparently simulate SCX_REG, SCY_REG, BGP_REG, OBP0_REG and OBP1_REG (hardware.h). Yes, that's the direction I took already. So far I'm only updating the SAT, though, I still have to see what all these other things actually do... haroldoop wrote Oh, it seems I forgot about that small detail, too... :P That offset could be computed internally by the sprite functions themselves, so that less modifications would be required. Yes, I thought that too, so I fixed the sprite functions. Now I'm wondering if is there a feasible way to emulate the APA mode, but I yet have to read more details on how it works (links to tech documents are appreciated!)... Doctor How splash screen is using this mode, so I temporary had to deactivate it... Also, I suspect there's no easy way to support the so called window, it seems to me it's kind of another background layer that could be freely scrolled around... something completely absent on our Game Gear :\| Finally, any idea on how to implement gprintf()?

sverx Joined: 05 Sep 2013 Posts: 3827 Location: Stockholm, Sweden	Posted: Thu Dec 29, 2016 2:38 pm
	OK, let's forget gprintf(), it's APA mode anyway. I fixed background scroll and some other little stuff. To test the compatibility layer on a fresh project, I took Novascape source code... and it compiled straight, no errors! All I had then to do is to add this, to properly initialize the Game Gear: smsgbdk_init(SMSGBDK_MODE_NORMAL); right after int main() { Unfortunately the game still doesn't work. It loads the assets and then it should show the menu, but it all turns rightly into the black GAME OVER screen. Weird, uh? I'm quite lost.

haroldoop Joined: 25 Feb 2006 Posts: 874 Location: Belo Horizonte, MG, Brazil	Posted: Thu Dec 29, 2016 10:13 pm
	sverx wrote haroldoop wrote Perhaps one way to make the sprite handling closer to the way GBDK does things would be to add some VBlank interrupt handler that would automatically update the sprite list if necessary; something similar could also be used to transparently simulate SCX_REG, SCY_REG, BGP_REG, OBP0_REG and OBP1_REG (hardware.h). Yes, that's the direction I took already. So far I'm only updating the SAT, though, I still have to see what all these other things actually do... SCX_REG and SCY_REG are memory-mapped scroll registers; I don't think they could be directly implemented without requiring source code modification, but it would be possible to simply map them to temporary variables, that would be read by the VBL handler. BGP_REG, OBP0_REG and OBP1_REG are memory-mapped palette registers; again, they probably can't be implemented directly, but could use the aforementioned trick. sverx wrote Now I'm wondering if is there a feasible way to emulate the APA mode, but I yet have to read more details on how it works (links to tech documents are appreciated!)... Doctor How splash screen is using this mode, so I temporary had to deactivate it... Well, your best source would be the GBDK documentation itself for the high-level stuff, and its source code for the low-level stuff. Basically, it works by setting a fixed BG map and then changing the tileset dinamically, similar to my old APA experiment. Most of GBDK's APA implementation is in assembly, but since GB-Z80 assembly is very similar to Z80, that shouldn't be an obstacle for understanding; in fact, converting it would be mostly search-and-replace, if it wasn't for huge differences in the way VRAM is acessed: GB's VRAM can be directly acessed by the CPU as if it was RAM, while the SMS/GG's uses a "blackbox-with-a-keyhole"/"build-a-ship-inside-a-bottle" approach. :P sverx wrote Also, I suspect there's no easy way to support the so called window, it seems to me it's kind of another background layer that could be freely scrolled around... something completely absent on our Game Gear :\| Yes, the window is essentially a large opaque rectangle with its own separate BG map that can be placed anywhere on the screen. I don't believe it could be implemented in a generic way on SMS/GG hardware. sverx wrote Finally, any idea on how to implement gprintf()? It works by drawing the current font's pixels to the APA; once APA is implemented, gprintf() would become just be a minor detail.

KingMike Joined: 14 Oct 2008 Posts: 510	Posted: Fri Dec 30, 2016 3:46 am
KingMike Joined: 14 Oct 2008 Posts: 510	I'm guessing the Window was largely intended to be used for creating HUDs. SMS basically had a HUD feature built in (the scroll locks), though I assume the cropped display area of the GG basically nullified that? NES though, to get a graphical HUD, programmers had to play tricks with the background layer scrolling.

sverx Joined: 05 Sep 2013 Posts: 3827 Location: Stockholm, Sweden	Posted: Fri Dec 30, 2016 8:57 am
	haroldoop wrote SCX_REG and SCY_REG are memory-mapped scroll registers; I don't think they could be directly implemented without requiring source code modification, but it would be possible to simply map them to temporary variables, that would be read by the VBL handler. Yes, that's actually what I'm planning to do :) haroldoop wrote BGP_REG, OBP0_REG and OBP1_REG are memory-mapped palette registers; again, they probably can't be implemented directly, but could use the aforementioned trick. I'll read more on those later. haroldoop wrote Basically, [APA] works by setting a fixed BG map and then changing the tileset dinamically, similar to my old APA experiment. Most of GBDK's APA implementation is in assembly, but since GB-Z80 assembly is very similar to Z80, that shouldn't be an obstacle for understanding; in fact, converting it would be mostly search-and-replace, if it wasn't for huge differences in the way VRAM is acessed: GB's VRAM can be directly acessed by the CPU as if it was RAM, while the SMS/GG's uses a "blackbox-with-a-keyhole"/"build-a-ship-inside-a-bottle" approach. :P On Game Gear fortunately we've got enough memory to fill the screen with different tiles so maybe this is possible too. I think I will ask you for some collaboration, here... ;)

sverx Joined: 05 Sep 2013 Posts: 3827 Location: Stockholm, Sweden	Posted: Fri Dec 30, 2016 3:23 pm
	SCX_REG and SCY_REG should work now. APA mode draw_image() function was a breeze, after all. I just had to load the 360 2bpp tiles from the blob and build an appropriate map... and that's it. Printing text in APA mode anyway won't be so straightforward, as it requires updating a few bytes in VRAM for each affected pixel :\|

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14740 Location: London	Posted: Fri Dec 30, 2016 9:36 pm
	The SMS drawing board is basically doing APA, and it has a bunch of optimisations for things like filling but mostly spends its time plotting pixels slowly. My disassembly might be helpful for reference.

sverx Joined: 05 Sep 2013 Posts: 3827 Location: Stockholm, Sweden	Posted: Sun Jan 01, 2017 11:30 am
	Thanks! I'm still not sure I'm going to embark on such a project by the way... I don't see the point of APA to be honest.

haroldoop Joined: 25 Feb 2006 Posts: 874 Location: Belo Horizonte, MG, Brazil	Posted: Sun Jan 01, 2017 11:44 am
	sverx wrote Thanks! I'm still not sure I'm going to embark on such a project by the way... I don't see the point of APA to be honest. Yes, AFAIK, almost no GBDK program uses it, anyway.

Forums

View topic - Compiling old GBDK games on devkitSMS