gbadev.org forum archive

This is a read-only mirror of the content originally found on forum.gbadev.org (now offline), salvaged from Wayback machine copies. A new forum can be found here.

Beginners > Mixing modes together

#11684 - yaustar - Wed Oct 15, 2003 9:36 pm

Would it be posible to have the screen display the map and sprites from MODE 0 and then a mini map in the corner using pixels from MODE 4?
_________________
[Blog] [Portfolio]

#11686 - DekuTree64 - Wed Oct 15, 2003 10:35 pm

Nope. You can switch modes on HBlank, but according to my experiments on hardware you get a few lines of garbage before it settles into the new mode. And even then you can't have one mode on the left and another on the right side of the screen so it wouldn't help anyway.
For a mini-map, I'd say just make a buffer in EWRAM, draw to that, and copy it to tile/sprite mem one tile at a time. Or if possible, draw in tiles to begin with. That's usually pretty confusing and/or slow though.
_________________
___________
The best optimization is to do nothing at all.
Therefore a fully optimized program doesn't exist.
-Deku

#11687 - tepples - Wed Oct 15, 2003 10:49 pm

DekuTree64 wrote:
Nope. You can switch modes on HBlank, but according to my experiments on hardware you get a few lines of garbage before it settles into the new mode.

I can see how this might be true of switches involving bitmap modes (as the OP suggests), but Mario Kart Super Circuit seems to switch from mode 0 to mode 1 halfway down the screen just fine. Can you provide a test case that shows garbage on a switch among modes 0, 1, 2? Hint: Try setting up scroll registers and affine registers before you trigger the mode switch.

Quote:
For a mini-map, I'd say just make a buffer in EWRAM, draw to that, and copy it to tile/sprite mem one tile at a time.

I agree. Several games for Super NES and Sega Genesis had mini-maps, and those systems didn't have a linear bitmap mode. Heck, Qix for Game Boy is entirely a pseudo-bitmap engine on top of tile hardware.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#11691 - poslundc - Thu Oct 16, 2003 12:33 am

tepples wrote:
I can see how this might be true of switches involving bitmap modes (as the OP suggests), but Mario Kart Super Circuit seems to switch from mode 0 to mode 1 halfway down the screen just fine. Can you provide a test case that shows garbage on a switch among modes 0, 1, 2? Hint: Try setting up scroll registers and affine registers before you trigger the mode switch.


I've run into the same problem on hardware... it's been my observation that messing with REG_DISPCNT during VDraw (even just to enable/disable a background or window) usually garbles a couple of scanlines while the changes take hold, even if all of the other settings are in place.

Are you certain that Mario Cart Super Circuit switches modes? I haven't actually played the game, but from screenshots it seems to me that it could be done in Mode 1, with BGs 0 and 1 as the two parallax scrolling backgrounds and BG2 as the terrain, using a window to keep them separate. This is what the Mode 7 program I'm working on currently does (with only one backdrop, though).

Dan.

#11701 - tepples - Thu Oct 16, 2003 5:35 am

poslundc wrote:
Are you certain that Mario Cart Super Circuit switches modes? I haven't actually played the game, but from screenshots it seems to me that it could be done in Mode 1, with BGs 0 and 1 as the two parallax scrolling backgrounds and BG2 as the terrain

Then where would it have put the HUD? Most of the sprite pixels seemed to be in use for rot/scale objects on the track.

Quote:
This is what the Mode 7 program I'm working on currently does (with only one backdrop, though).

I dumped my MKSC Game Pak and ran it in VBA. I noticed strange different behavior in VBA's tile viewer; Auto Update seemed to use the mode settings from the last scanline (drawn in mode 1), while switching backgrounds with the radio buttons seemed to use the mode settings from the first scanline (drawn in mode 0).

Top half:
BG0 HUD, BG1 front bg layer, BG2 mid bg layer, BG 3 back bg layer
Bottom half:
BG0 HUD, BG1 front bg layer, BG2 track

So perhaps the front bg layer covers up a line or two of BG2 garbage.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#11713 - poslundc - Thu Oct 16, 2003 4:09 pm

tepples wrote:
Then where would it have put the HUD? Most of the sprite pixels seemed to be in use for rot/scale objects on the track.


Well, from the screenshots I would've assumed that they're done with sprites... if there's one thing I've learned from you it's that sprite pixels are not a definitive limitation, since they could be swapping other sprites into VRAM as necessary. Of course, picking it apart in VBA is bound to be more revelatory than mere speculation, so...

Quote:
I dumped my MKSC Game Pak and ran it in VBA. I noticed strange different behavior in VBA's tile viewer; Auto Update seemed to use the mode settings from the last scanline (drawn in mode 1), while switching backgrounds with the radio buttons seemed to use the mode settings from the first scanline (drawn in mode 0).


I've had to kind of guess at your meanings here, since I'm running the Mac version of VBA, which doesn't have all of the cool tile/background/oam viewer features (sadly enough; they would be quite helpful in my debugging work).

Quote:

Top half:
BG0 HUD, BG1 front bg layer, BG2 mid bg layer, BG 3 back bg layer
Bottom half:
BG0 HUD, BG1 front bg layer, BG2 track

So perhaps the front bg layer covers up a line or two of BG2 garbage.


Maybe, assuming that they timed the switching of priorities so that it didn't happen until a couple of scanlines after the mode switch. Or perhaps it could be done with windows, using the fact that win0 takes priority over win1. I'm not sure...

Is that middle bg layer always visible? From the screenshots it only seemed to me like there were two backdrop levels, not three.

Dan.

#11719 - tepples - Thu Oct 16, 2003 6:52 pm

poslundc wrote:
if there's one thing I've learned from you it's that sprite pixels are not a definitive limitation, since they could be swapping other sprites into VRAM as necessary.

Sprites != sprite pixels. The limit of 128 OAM entries isn't much of a limit given the sort of OAM-swapping that Super Puzzle Fighter II and many other GBA games do, but the 950 horizontal units per scanline limit is a real limit. A non-scaled sprite takes one unit per pixel of width, while a scaled sprite takes 26 units per 8 pixels, and a double-size sprite takes 52 (source: GBATEK by Martin Korth).

Quote:
Maybe, assuming that they timed the switching of priorities so that it didn't happen until a couple of scanlines after the mode switch. Or perhaps it could be done with windows, using the fact that win0 takes priority over win1. I'm not sure...

Is that middle bg layer always visible?

For example, in Peach Circuit, the front layer (BG1, visible at all times) is a layer of forest about 8px or so tall, the middle layer (BG2, visible on the top half) has the castle, and the back layer (BG3, visible on the top half) has a gradient and clouds.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#11720 - poslundc - Thu Oct 16, 2003 7:14 pm

[quote="tepples"]
poslundc wrote:
Sprites != sprite pixels. The limit of 128 OAM entries isn't much of a limit given the sort of OAM-swapping that Super Puzzle Fighter II and many other GBA games do, but the 950 horizontal units per scanline limit is a real limit. A non-scaled sprite takes one unit per pixel of width, while a scaled sprite takes 26 units per 8 pixels, and a double-size sprite takes 52 (source: GBATEK by Martin Korth).


Ah, ok. Well, from the screenshots on Nintendo's website it doesn't look like it would become a problem, but those aren't very telling I suppose.

Quote:
For example, in Peach Circuit, the front layer (BG1, visible at all times) is a layer of forest about 8px or so tall, the middle layer (BG2, visible on the top half) has the castle, and the back layer (BG3, visible on the top half) has a gradient and clouds.


So as long as BG1 is at least a few pixels tall in all courses, it should obscure any negative effects if the mode change is begun a few scanlines early. It would also seem to suggest that the graphical artifacts caused by modifying REG_DISPCNT only affect the layers that are altered by the new setting. So in the case of changing from Mode 0 to Mode 1, there would be no graphical artifacts on backgrounds 0 and 1, only backgrounds 1 and 2.

This is all still fairly hypothetical, of course. My tests were limited to turning backgrounds on and off in REG_DISPCNT; I didn't try changing modes at all.

I guess they must've really badly wanted four background layers for that top half.

Dan.

#11724 - yaustar - Thu Oct 16, 2003 9:08 pm

Well, I have though t of A solution to the mini map.

I was thinking of using a 64x64 (something like that) and change the data directly in the program. This would almost be like a bitmap mode. i just dont have a clue how efficient it would be. Saying this, I am not sure how the data is converted. From what I can tell, it's in converts it into 8x8 blocks (this is in 256 colour mode) left to right.

edit: (also in 256 colour mode) each value in the array represents two pixels, holding the colour number within the palette. Not sure about 16 colour modes though

Krom suggested that I use a window and use a layered (perhaps scaled down) and copy the VRAM over. Problem here is that I have already used all four layers (oops) for other things.
_________________
[Blog] [Portfolio]