Mode 5 colour limitations?

Discussion of hardware and software development for Super NES and Super Famicom. See the SNESdev wiki for more information.

Moderator: Moderators

Forum rules
  • For making cartridges of your Super NES games, see Reproduction.
Myself086
Posts: 158
Joined: Sat Nov 10, 2018 2:49 pm

Re: Mode 5 colour limitations?

Post by Myself086 »

iNCEPTIONAL wrote: Mon May 02, 2022 3:32 pm Yeah, I can't think of a great use for direct colour. But, honestly, I still don't really get how it works. I know the SNES normally has up to 128 colours for the backgrounds and another separate 128 for sprites, and the background colours get divided into different palettes of different sizes depending on the background mode (usually the sprite palette is totally separate but in I think one mode it gets lumped in with the backgrounds too), but, beyond that, I don't know how those colours get arranged/applied when direct colour is used. Like, do I just have access to the full 32,768 colours (minus pure black and pure white, I think) to use as I see fit in each tile? Are tiles still 8bpp/4bpp/2bpp in this mode? Do the sprite colours get lumped in the with background colours? I don't really know any of these things, only that the direct colour mode is not a typical SNES palette as such.
Direct color mode applies to 8bpp BG only. An 8bpp BG has access to 256 colors, overlapping with sprite palettes. But direct color mode uses the 8-bit color as RGB332 (3 red, 3 green, 2 blue) with an additional bit for each color per tile, so the entire 8x8 is affected by R.1, G.1 and B.2 respectively. RGB443 is 2048 colors.
iNCEPTIONAL wrote: Mon May 02, 2022 3:32 pm So, offset-per-tile basically allows you to scroll both 8 pixel columns and/or 8 pixel rows, correct?
It's per 1 pixel vertically and per 8 pixels horizontally.
iNCEPTIONAL wrote: Mon May 02, 2022 3:32 pm What background mode(s) is this available in?
2, 4 and 6.
iNCEPTIONAL

Re: Mode 5 colour limitations?

Post by iNCEPTIONAL »

Myself086 wrote: Mon May 02, 2022 3:50 pm Direct color mode applies to 8bpp BG only. An 8bpp BG has access to 256 colors, overlapping with sprite palettes. But direct color mode uses the 8-bit color as RGB332 (3 red, 3 green, 2 blue) with an additional bit for each color per tile, so the entire 8x8 is affected by R.1, G.1 and B.2 respectively. RGB443 is 2048 colors.
Well I'll ponder it....
Myself086 wrote: Mon May 02, 2022 3:50 pm
iNCEPTIONAL wrote: Mon May 02, 2022 3:32 pm So, offset-per-tile basically allows you to scroll both 8 pixel columns and/or 8 pixel rows, correct?
It's per 1 pixel vertically and per 8 pixels horizontally.
iNCEPTIONAL wrote: Mon May 02, 2022 3:32 pm What background mode(s) is this available in?
2, 4 and 6.
So, you're talking about this: https://youtu.be/5SBEAZIfDAg?t=206

And, specifically, you want me to think of a way to use the horizontal scrolling aspect?
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: Mode 5 colour limitations?

Post by lidnariq »

kulor wrote: Mon May 02, 2022 2:16 pm something to do with direct color mode
Direct Color mode is specifically useful when you've already used up your entire palette on 4bpp layers and sprites, but need even more colors for a 8bpp background. I used it in my modes 0-6 test so that the demonstrations of modes 3 and 4 didn't have the share the same pastels I was using in the rest of the screen.

Effectively it lets you have 511 colors on screen without color math or extra palette RAM, but with some rather restrictive constraints.
iNCEPTIONAL

Re: Mode 5 colour limitations?

Post by iNCEPTIONAL »

lidnariq wrote: Mon May 02, 2022 4:04 pm
kulor wrote: Mon May 02, 2022 2:16 pm something to do with direct color mode
Direct Color mode is specifically useful when you've already used up your entire palette on 4bpp layers and sprites, but need even more colors for a 8bpp background. I used it in my modes 0-6 test so that the demonstrations of modes 3 and 4 didn't have the share the same pastels I was using in the rest of the screen.

Effectively it lets you have 511 colors on screen without color math or extra palette RAM, but with some rather restrictive constraints.
A few things there:

1. What's your 0-6 test, and where can I check it out?

2. 511 colours without colour math or extra palette RAM. What!

3. What are the restrictive constraints?
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: Mode 5 colour limitations?

Post by lidnariq »

iNCEPTIONAL wrote: Mon May 02, 2022 4:26 pm 1. What's your 0-6 test, and where can I check it out?
Just a very simple demonstration of modes 0-6, all on screen at the same time.
Link: the sfc in viewtopic.php?p=174494#p174494
2. 511 colours without colour math or extra palette RAM. What!
3. What are the restrictive constraints?
The 8bpp layer only has access to the standard R3G3B2 256 color palette. This one: https://en.wikipedia.org/wiki/List_of_s ... levels_RGB ... except black. That color is transparent instead.
iNCEPTIONAL

Re: Mode 5 colour limitations?

Post by iNCEPTIONAL »

lidnariq wrote: Mon May 02, 2022 4:39 pm
iNCEPTIONAL wrote: Mon May 02, 2022 4:26 pm 1. What's your 0-6 test, and where can I check it out?
Just a very simple demonstration of modes 0-6, all on screen at the same time.
Link: the sfc in viewtopic.php?p=174494#p174494
2. 511 colours without colour math or extra palette RAM. What!
3. What are the restrictive constraints?
The 8bpp layer only has access to the standard R3G3B2 256 color palette. This one: https://en.wikipedia.org/wiki/List_of_s ... levels_RGB ... except black. That color is transparent instead.
Eh, I downloaded the ppubusactivity_rev2.sr zip file from the first post, tried drag any/all the files into bsnes and nothing happens. Is this not something I can check in the emulator? Did I download the wrong thing?

Edit: My bad. I downloaded the wrong one. Got it working now. :)

Edit 2: Ha! Very cool that you're switching modes 6 times down the screen, and then also doing stuff with each mode in the area it's activated. I've seen mode switches maybe three times down the screen in a game. I'm impressed SNES can literally show all modes running at once like this (although the high-res modes don't seem to be displaying properly, even though they do in games like RPM Racing and Secret of Mana 2). Ideas starting to form. . . .
creaothceann
Posts: 611
Joined: Mon Jan 23, 2006 7:47 am
Location: Germany
Contact:

Re: Mode 5 colour limitations?

Post by creaothceann »

Like any machine without a framebuffer (which is needed for 3D acceleration), the SNES is mostly a line-based machine. The background mode can be set by writing a single byte to register 2105h, which can be done in HBLANK for example with HDMA, so you could have every line with its own background mode if you wanted to.

Examples of vertical offset-per-tile: Tetris Attack (Panel de Pon) for scrolling the columns, Yoshi's Island for the drugs, lava and vertical stone platforms. (I haven't checked but it might also be used by SMW's castle stone platforms.) Horizontal offset-per-tile: Chrono Trigger's intro when the Black Omen phases in.

Direct Color mode is used by Secret of Mana (a long way in the game, try a SRAM) and Actraiser 2 (right at the beginning). You'd need an early emulator to see the difference, e.g. ZSNES < April 2006.
My current setup:
Super Famicom ("2/1/3" SNS-CPU-GPM-02) → SCART → OSSC → StarTech USB3HDCAP → AmaRecTV 3.10
User avatar
rainwarrior
Posts: 8734
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: Mode 5 colour limitations?

Post by rainwarrior »

I wanted something I could play with and test for myself, so... I wrote my own Mode 5 hires + interlacing test. Thread here.
iNCEPTIONAL

Re: Mode 5 colour limitations?

Post by iNCEPTIONAL »

dougeff wrote: Tue Apr 26, 2022 11:13 am Seiken Densetsu 3 uses mode 5 for the text screens at the beginning of the game.
It's interesting to note that while still a rather drab image, this does a nicer job with the high-res background art than RPM Racing managed. And I know 120 colours used properly could look even better. Much potential, me thinks. :)
Last edited by iNCEPTIONAL on Tue May 03, 2022 4:56 am, edited 1 time in total.
iNCEPTIONAL

Re: Mode 5 colour limitations?

Post by iNCEPTIONAL »

rainwarrior wrote: Tue May 03, 2022 2:38 am I wanted something I could play with and test for myself, so... I wrote my own Mode 5 hires + interlacing test. Thread here.
I checked it and I can see the potential there. :)
iNCEPTIONAL

Re: Mode 5 colour limitations?

Post by iNCEPTIONAL »

dougeff wrote: Sun May 01, 2022 10:51 am
iNCEPTIONAL wrote: Sun May 01, 2022 10:27 am
Joe wrote: Sun May 01, 2022 10:20 am
You can't turn off the deinterlacer when the input is interlaced. And, at least in my experience, most TVs have no settings to control the deinterlacer.
Yeah, I actually have little idea of what you guys are talking about regarding the whole Mode 5 and interlaced stuff to be honest, so I was just checking--just in case. lol
I'm no expert, but I believe it works like this. First it draws every even horizontal line to the screen, then in the next frame it draws every odd line. In Mode 5/6, it draws one of those a half pixel lower than the other frame.

So, while the PPU can't really draw 448 scanlines, it fakes it by doing 224 one frame and 224 another frame.
where someone tries to convince me that now Mode 6 high-res column scrolling is worthless too
Yes. I am actually trying to discourage you from using mode 6, but not because it's "worthless", but for the reason I stated, that it has only 1 layer. You have to weigh the options and choose which best suits the kind of game you want to make.


If you can make the same visual effect by swapping tiles, in a mode that has more layers, I would prefer that method.
By the way, don't you think this undulating demon head effect would look even cooler using that high-res Mode 6 column scrolling + line scrolling capability: https://youtu.be/Tl7D25I6yDc?t=2837

I do. :D

And you could even show everything else seen on the screen there too by using a nice blue HDMA gradient on the system background colour, 4 repeating 64x64 sprites for the clouds, a bunch of 8x8 sprites for the stars, window 'shape masking to draw the full circle of the planet with a handful of sprites to do the visible edge, which would also get clipped by the window/shape mask, and few sprites for the ship.

Then you just fade out the head, switch to mode 1 again, doing whatever to organise the graphics into actual backgrounds and so on, and off you with the rest of the level. . . .

Edit: Although, given the way the effect is done here, where I think it's actually just a distorted image to start with and he's simply line scrolling for the overall effect, it could be done in Mode 5 easier to be honest.
User avatar
kulor
Posts: 33
Joined: Thu Mar 15, 2018 12:49 pm

Re: Mode 5 colour limitations?

Post by kulor »

kulor wrote: Sat Apr 30, 2022 11:43 pm I also don't think VRAM is a concern, because, while it's true that you need 4x more VRAM for the same coverage for your graphics, you also lose out on a whole 4bpp layer's worth of VRAM consumption, since mode 5 trades a 4bpp layer for that extra horizontal crispness.
Wanted to elaborate on this, because after doing some more investigation, I'm definitely convinced VRAM is not a concern for mode 5. Something to consider is that character addressing still works in 8x8 tile chunks with 16x16 tiles, so the VRAM consumption of all the unique tiles you can address per-layer is actually the same regardless of if you use 8x8 tiles or 16x16 tiles, high-res or low-res.
For example, in mode 1, let's say you want as many unique tiles as possible for each layer. For each of the 4bpp layers, you need 1024x 8x8 tiles, which are 32 bytes each, for a total of 32KB VRAM, multiplied by two for the two layers. For the 2bpp layer, the tiles are 16 bytes each, so you need 16KB for that. Grand total is 80KB of VRAM use, which is more than you actually have, so you can't actually have the maximum number of unique tiles for all layers in mode 1.
In mode 5, because it's 16x16 tiles, you only get 256 unique tiles, as well as the probably-useless half-steps between unique tiles. For the 4bpp layer, you need 256x 16x16 tiles, which are 128 bytes each, for 32KB. For the 2bpp layer, they're 64 bytes each, so it's 16KB. Grand total is just 48KB, which is actually less than mode 1!
In fact, if you had 64x32 tilemaps for each of the layers, you could theoretically fill up your VRAM with 256 unique 16x16 tiles for the 4bpp layer, 128 unique 16x16 tiles for the 2bpp layer, and have your 8KB tilemaps and 16KB sprite space too. I think it's fair to say that "mode 5 uses too much VRAM" is a myth.
User avatar
rainwarrior
Posts: 8734
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: Mode 5 colour limitations?

Post by rainwarrior »

kulor wrote: Wed May 11, 2022 1:38 pmI think it's fair to say that "mode 5 uses too much VRAM" is a myth.
I agree that the allowed tiles for the 2 layers + sprites fits in VRAM just fine... but is that what people really mean? I'm not sure what the source of the myth in question is.

Maybe it's a semantic difference, but I feel that hires does have a very significant memory issue, which is screen coverage. It's not that it has less tiles, it's that each tile is 1/2 or 1/4 the size.

You just get less variety per screen. You have to trade that away for the fine details.

FF2_vs_FF3.png

Like, I think the typical FF2 town map could easily have budgeted VRAM for hires (2x), ignoring the added ROM/art cost. FF3 not so much. What is tile variety worth, and how does that compare to the value of high resolution?

Not entirely a fair comparison for a number of reasons, obviously it's more than just tile budget. A better comparison would maybe be to make a real hires mockup of FF3, with needed reduction in variation to accommodate, with all the artistic care and skill it is due... I'm not up to that task to make a point, but I think this illustrates imperfectly what I mean.


So... hires is absolutely feasible, and honestly skilled art work probably makes more of a difference than tile budget. You can definitely make something good with mode 5. A lot of NES games did really well with a similarly lacking ability to cover the screen with tiles.

...but all else being equal, the sacrifices are pretty clear too. This is just one of them. I don't find its lack of use in the SNES library unsurprising at all? The exceptions become very interesting.

I guess everything just said also applies to mode 3, but the trade gain seems even more subtle.
User avatar
kulor
Posts: 33
Joined: Thu Mar 15, 2018 12:49 pm

Re: Mode 5 colour limitations?

Post by kulor »

rainwarrior wrote: Wed May 11, 2022 5:30 pm What is tile variety worth, and how does that compare to the value of high resolution?
I think it's a question of application. Could you recreate Narshe in mode 5 to the same level of detail? Probably not, but with all the layering and moving around you do in the overworld parts of that game, maybe mode 5 wouldn't really make sense there anyway. But a battle screen background? I'm a little surprised nobody attempted it, given how many RPGs are on the thing.
Also worth noting mode 7 is equally limited with tile variety, maybe even moreso because you only get 256 tiles for a single layer. If devs were able to work around that and make good looking mode 7 stuff, I absolutely think they could've done the same for mode 5.
93143
Posts: 1717
Joined: Fri Jul 04, 2014 9:31 pm

Re: Mode 5 colour limitations?

Post by 93143 »

kulor wrote: Wed May 11, 2022 1:38 pmafter doing some more investigation, I'm definitely convinced VRAM is not a concern for mode 5. Something to consider is that character addressing still works in 8x8 tile chunks with 16x16 tiles, so the VRAM consumption of all the unique tiles you can address per-layer is actually the same regardless of if you use 8x8 tiles or 16x16 tiles, high-res or low-res.
Counterpoint: BG character namebase is writable during HBlank.

This doesn't completely solve the problem, but it could be useful in certain scenarios, and it would be a lot more useful if the SNES had more VRAM.
Attachments
bgname.sfc
(32 KiB) Downloaded 42 times
Post Reply