Gameboy Development Forum

Depending on where you want to place the dialog box you might have to alter the main BG, yes.

If you're okay with having your dialog box on the right side of the screen, in the lower right, or bottom part of the screen you could place your text and dialog box in the window section and neatly slide it in from the bottom part of the screen
This allows for having dialog boxes that are just as big as your screen and they can be moved about without much of a hassle (can't pass outside the left side and upper bounds of the screen though).
I'm not quite sure if one COULD time disabling the window precisely enough to cut it off on the right hand side (this would require very precise timing since last HBlank), this could be risky though as I've heard that altering the screen setup outside of VBlank may cause damage to the screen.

Otherwise you're pretty much doomed to align the BG, rewrite the part of the tilemap you want to use your dialog box on, and once you remove the dialog box, look through the tilemap in ROM and restore the section it once covered.

Last edited by RoboTwo (2014-10-29 08:47:53)

Oh, I'm guessing you use GBDK then.
Sorry, haven't worked much with that, but the window and BG can share tiles and have individual tile maps, so the window is a excellent way to present dialogs without manipulating the main tilemap.

Will have to look into this and I'll return if I find something about drawing to the window map instead.

nitro2k01 wrote:

The timing is the least of your problems at that point. Once the LCD state machine is in the "rendering window" state, you can't disable the window rendering until the end of that line, if I recall correctly.

Ah, well I guess that's not a viable exploit then

Do you have any further knowledge about the text implementation of the GBDK, keeping with the subject?
Is there any easy way to switch it over to put characters into the $9C00 and onwards instead of $9800 and onwards?

I skimmed through some of the functions and noticed that there's functions for poking tiles manually into the window map in there, but found nothing about altering the destination map of the text functions.

Well it's pretty straightforward in ASM, considering you just poke a byte into the tilemap addresses you want to be represented graphically with the tile with that specific identifier.

But there's no native functionality for stuff like drawing text, loading fonts or the like.
So if you were to tackle making the game in ASM you'd have to set up a function to properly interpret the ASCII values and poke the correct tiles into the map, or make a tool for converting strings into a list of bytes representing the right tiles.

Skimming through the GBDK documentation there appears to be functions for manipulating the window already, mainly:

set_win_data(UBYTE first_tile,
                     UBYTE nb_tiles,
                     unsigned char *data);

and
move_win(UBYTE x,
                UBYTE y);


hardware wise the window layer can be enabled separately from the BG layer, so I'm guessing just like 'SHOW_BKG' you'll have to specify 'SHOW_WIN'.
I'm not sure about that though, just speculation.

there's also 'scroll_win', which takes the same arguments as 'move_win', but is relative to the windows current position, where as move_win is the absolute position.

So you can try using that for now if you haven't worked with the window earlier to get more familiar with how it works and what can and can't be done with it.

So far I can see no sign of the 'printf' function supporting the window, but it might be a easy fix depending on how it's structured.