How SuperFX assisted games displayed?

How SuperFX assisted games displayed?
For example SuperFX chip generates graphics and then it should be transferred to the screen.
SNES has quite low bandwidth.
Is it possible at all to transfer an array of image data to the screen with reasonable fps?
As far I can see so far such games have quite low fps.

Thanks!

I've read through your posts and I can't quite figure out what your experience level is here. Are you actually programming something? Do you know 65816? Are you familiar with working/developing on the SNES? Your posts have a strange feel to them that doesn't particularly give us any understanding of where your experience level lies. They give the impression of someone asking specific questions because they're experienced, but also are strange and give the impression of literally no experience.

Speaking more brashly: I literally cannot tell if you have written a single line of code on the SNES or if you are just asking about weird details and providing little-to-no context (for some reason).

So why would I start off my reply with the above?

A big part of it is the fact that the questions you're asking, if you're experienced, are things that you could self-answer (kind of -- I'll explain). For example, if you're asking about scanline effects using HDMA etc., and also about direct colour, then I am sort of inclined to think you might have SNES development familiarity? But there isn't any real further information provided. And often no context, as I said.

There is one post where you say something like "sorry for being a noob" -- and being a noob is 100% cool/OK! -- except that noobs normally don't go asking about the SuperFX or nuances like the above. Noobs tend to be more concerned with actually starting out and doing something very basic. See why I'm confused? :-)

If you're experienced, then you might know where you find out how the SuperFX works and "fits in" to the overall scheme of things on the SNES, thus answering your own question. If not (or if you aren't sure where to find out the answer), here's a hint: romhacking.net has some particularly, shall I say, "useful" documentation in PDF format on the SuperFX. (I do not link to it, or discuss specifics of it, however, for many reasons that I refuse to go into here out of safety for the retention of said documentation.) Start with that and see where it leads you.

I should be clear about my goal with the above: the goal is to try and teach you how to "help yourself" first, then ask questions here when you've learned what you can but have questions (about code, system, etc.) or to discuss problems/issues you're running into when developing. This allows for better use of everyone's time, but really, the proverb "give a man a fish, and you feed him for a day. Teach a man to fish, and you feed him for a lifetime" is what I'm trying to apply here.

If you are new to SNES development and the console, stop thinking about the SuperFX. Remove it from your mind entirely. It doesn't exist. Think about the basics of starting out, write some code, work your way up gradually. SFX, like SA-1, is highly advanced material.

Hi! Sorry that my question was not exact.
I am not experienced in SNES development.
However I have experience in Sega Genesis development.
Also I have checked SNES' hardware and couldn't find any way to make "direct colour" at a reasonable fps.
I was just curious maybe I missed something and someone much more experienced with SNES could guide me in the right direction.
Without experience I can judge only by the games. For example DOOM.
It runs at 15 fps at most. The visible area is reduced. The overall resolution is low as well.
It makes me think that SNES is not able to make "direct colour".
But it's only my assumption. I hope I am wrong.
But so far I haven't seen any SNES games doing "direct colour" and having a reasonable fps.

Look, he's trying to win the bounty for making a SNES demo that beats Titan's MD efforts, by jumping into the deep end head-first, okay?

What I can see so far is:
There is the Mode 3 having an 8-bit color for each pixel.
Each pixel needs 1 byte.
DMA bandwidth is around 170 bytes per scanline.
To fill the screen with a 256x224 image one needs 57344 bytes.
We get 6.76 fps if we transfer the data from ROM to VRAM only during the vblank.

I don't know if it's possible for SNES but it is so then we can turn the screen of a bit earlier and get extra 32 lines of vblank for each frame. Minus 16 pixels in the top and 16 pixels in the bottom.
Also we can make the viewport narrower. Thus we have 224x192 = 43008 bytes per "frame".
We have 38 + 32 = 70 vblank lines.
We get 16.6 fps.

As long as it seems to me unreal I don't take in account double buffering (though it likely will be needed).

16.6 fps is not perfect but playable enough. Especially for SNES players who are not used to high frame rates.

If I made any mistakes please correct me. Thanks!

You've now changed the subject of the thread (re: direct colour, a.k.a. CG direct). Let's stay on topic please. I will answer this and then immediately switch back to what this thread is about: SuperFX.

I only mentioned direct colour because it was an example of something you had inquired about previously, compounded with other strangely specific details of the SNES, yet I couldn't discern whether or not you really had any experience with the system. Your above post tells me what I need to know: you have no SNES/65816 experience, but have Genesis/68K experience. I myself am the exact opposite (and I also intentionally avoid the "expansion" chips on the SNES, e.g. DSP, SFX, SA-1). What I CAN tell you is that two systems are *substantially* different, i.e. the way you go about things and think about things (see: solutions) on each console is often vastly different.

If you are expecting to make a SNES title exclusively use CG direct mode and nothing else, you will likely get no where. I don't think this is feasible; you are approaching things from a very obtuse/weird angle. You haven't stated why or what you'd need this for anyway. The feature is limited to modes 3 and 4 where you'd get 2048 total colours, and mode 7 where you'd get a fixed 256 -- and in all cases you get only 1 background and sprites are no longer a thing. All it lets you do is use raw PPU RAM for raw RGB colour/pixel data, rather than relying on CGRAM (palette lookup). Thus, based on this design, IMO it's mainly intended for one thing alone: displaying still pictures/photos.

Now back to on topic:

I don't know of anyone who has "extensively" reverse-engineered SNES Doom to find out the reason for the lower frame rate. There is probably a very good reason for it. Randy Linden, AFAIK, is still around. If you really, truly, deeply wanted to know the reasons for this, you could probably track him down and ask him. SuperFX games did not inherently make things "better" and "overall faster" -- it's just a RISC CPU that provides a lot of fast/native mathematical operations, and (going off memory here) some X/Y colour plotting features (i.e. draw a pixel, rather than the usual SNES's tile-based system). I don't think anyone knows *how much* of the SuperFX was used in Doom (vs. stock 65816) either. As for the resolution, well, it's a 256x224 title vs. the PC's 320x200 -- those 64 extra pixels in width make a big difference -- but the SNES version also has a black border around the main part of the image making it effectively 216x144. There's a wiki page that talks about some of the nuances of SNES Doom, and I suspect part of it stems from the fact that it looked to have been ported from the Jaguar version (with bits/pieces from the PC version). I should add that StarFox has a pretty "meh" framerate as well. Yoshi's Island had a good framerate (60fps IIRC), but I get the impression most of the SFX features were used for sprite scaling and other whatnots, and *not* a focus on doing "3D things" like the other two games. Finally -- and I am hoping someone like byuu or Sour or anyone else more familiar with this chip corrects me if I'm wrong -- but I remember the SuperFX's graphical operations only applying to either cartridge RAM or system RAM, and *not* PPU RAM (i.e. DMA transfers from CPU to PPU still had to be done in 65816). Anyway, I really do insist that if you want to find out the answers about SNES Doom, to track down Linden and have a chat. Else read this interview/write-up.

It is fairly obvious that games *not* using the SFX were able to achieve 60fps, and that's because those were games designed with the tile-based system in mind. Everything from the ground up was designed that way. SNES Doom was a port focused on software 3D and per-pixel drawing, and Star Fox was a game focused on 3D polyfill and lines. Do you see the connection there with the slowdown? Think about it. :-) The SNES is not a "fast" or "high bandwidth" system in general. You design games/things with that in mind.

According to sources presumed to be familiar with the matter, the Super FX was not the bottleneck in SNES Doom, nor was the DMA speed.

Supposedly the SNES-side engine was in C, and the whole game could have been about 30% faster with an optimized assembly engine.

...

But yes, the Super FX can only write to Game Pak RAM, so to get the results to VRAM you have to use the SNES DMA unit, and there are limits to how fast you can do that.

Super FX games were often something like 224x192 at 4bpp, with other BG layers and sprites used to provide backdrop and HUD graphics. Black areas above and below the active area can be forced blank, which allows free access to VRAM, CGRAM, and OAM. With a bit less than 70 lines of DMA at 165.5 bytes per line, there's barely enough room for 30 fps if you don't have to fully refresh both CGRAM and OAM, or plenty of room for 20 fps if you do. Star Fox caps at 20 fps for this reason. But preparing the frames is the bottleneck in most situations, so it's rare to see the game actually run that fast.

Doom is 8bpp (as is Stunt Race FX; this should be taken into account when comparing it with Virtua Racing, as it doubles render time, buffer clear time and DMA time). This reduces the peak frame rate. On the other hand, the framebuffer is smaller in those games - Doom is 216x176, or 216x144 without the status bar, so while 30 fps is unrealistic, there's more than enough bandwidth for 20 fps. I doubt the rendering is fast enough to hit that speed with any regularity (the walls in Doom are probably rendered in vertical lines, and as mentioned in the linked thread, rendering vertical lines on the Super FX is very slow because of the bitplane format), but as mentioned above it seems the S-CPU code was even slower...

In other words, the type of games that were made for the Super FX were not radically bottlenecked by the DMA speed. It's not like Star Fox and Doom would have been 60 fps without that limitation; the power of the chip was reasonably well matched to the capabilities of the console.

...

Non-Super FX games were typically 60 fps, sometimes with drops, sometimes pretty solid - even with fast action games. Same as the Mega Drive. I don't know what you're on about with this "SNES players who are not used to high frame rates" stuff; if I didn't know better I'd swear it was bait...

Thanks a lot guys for your help!
Now everything is clear.

Concerning a lower frame rate: I have played a lot of Sega games and a lot of SNES games and I found that the latter ones have lower frame rates.
Maybe it's not so. I haven't checked it very well. It's just my assumption. Maybe it's my biased perception.
I understand that both consoles have very similar possibilities (except CPU but it doesn't matter too much).
There was no reason for a lower frame rate.

A bunch of early high-profile SNES games had a lot of slowdown. There are a few reasons for this - for instance, the CPU was significantly harder to program, much less widespread/popular, and somewhat less powerful than the one in the Mega Drive (more powerful per MHz, but slower, especially with early SlowROM carts), and the sprite system was less flexible and more fiddly to use than the MD's, even though it was more powerful on paper. Later games tended to have less slowdown, the standout example being Rendering Ranger's shmup sequences. Even early titles could be pretty solid if they didn't overreach (F-Zero was a solid 60 fps, and I recall only one instance of slowdown in Super Mario World despite its engine being reportedly very inefficient), but developers definitely got better at it - compare Super R-Type to R-Type III.

By the way, Super Mario Kart is locked 60 fps. Thunder Force IV is not. I don't know why people seem to think otherwise.

Race Drivin' was a disaster, possibly because the SNES graphics format is much more difficult to render into than the MD format. This may be one reason the Super FX has its complicated PLOT circuitry, while the SVP chip wasn't even specialized for rendering (then again, maybe if it had been, it might have been somewhat cost-competitive with the Super FX...).

It's true that MD games were often quicker and more twitchy than SNES games, which may contribute to the popular perception. But Sparkster works perfectly fine on SNES...

I can list off numerous Genesis games that can have "bad frame rates", and probably just as many on the SNES that have the same thing.

Small font time because off topic:

One thing that should probably be kept in mind -- and this is my own opinion, but it's based on how prevalent the chip was at the time: the 68000 was a CPU that "more" people overall were familiar with during the 16-bit era. It was often used in arcade systems as the primary CPU. As you know, it's a CPU with eight (8) 32-bit registers with ways to access/address each half of the register purely via the operand/addressing mode, in addition to things like native multiplication and division opcodes and up to 32-bit addressing space -- it's beefy and very capable, and also makes a decent CPU for higher-level PLs like C. The 65816 in contrast offers only three (3) 16-bit registers, only one of which can be used for general purposes/operations while the other two are purely used for indexing within addressing space (the total of which is 24-bit), and has no multiplication/division outside of the obvious bitshifts for x2/x4/x8... or ÷2/÷4/÷8... There's a lot more "messing about" on the 65816, and it does not cater well to any languages other than assembly and certain others (BASIC interpreters were common). My point is: more prevalence means generally people were more familiar with it, especially arcade companies, and this was compounded by having more breathing room/capability CPU-wise.

The 65816 was chosen on the SNES almost certainly because it was the successor to the 6502 in the NES (or 65C02 by that point), since it's backwards-compatible and thus existing NES/6502 programmers (read: companies making games for the SNES) would have some general familiarity with it, and see it as an upgrade (see: 16 bit registers, 256 opcodes, new addressing modes, 24-bit addressing support, etc.). But the fact remained, unlike with the 6502, it was an incredibly niche processor: the only things that used it that were mainstream or commonplace for the time period were the Apple IIGS and the SNES (I can't think of anything else that did, and it doesn't really matter). So that should make you ask: why did Nintendo go with the 6502 on the NES to begin with? The reason is actually known: Nintendo intentionally chose it because they deemed it obscure, nobody had heard of it / was using it widespread in Japan, and Nintendo was fearful of piracy/clones (ironic considering how many were made after the fact). So, with the SNES, they chose to use a 16-bit version of a CPU that was backwards-compatible (and just as obscure in Japan) with their previous choice from their earlier console (but with substantially better graphics. The SNES blows the NES out of the water.) Oh, and the 65816 was probably substantially cheaper; the 68K was known for being both expensive and physically large. Nintendo is still to this day well-known for making systems that are cheap/low cost to allow for maximising profit -- and that was in full effect in the 80s/90s too.

Sega, on the flip side, had been making arcade games and some (Z80) home console systems for some time, so their familiarity with both the Z80 and the 68000 should come as no surprise. Plus, their VDP stuff on the Genesis is very much along the lines as what some of their arcades did (an arena Nintendo was not familiar with). As such, this made the Genesis a really good candidate for ports of arcade games -- and there are plenty. There's a lot more work that goes into porting something to 65816, *especially* if you have things like ports of 68000 games. Want a good example of something that did port really well but certainly took a huge undertaking? Capcom's Magic Sword, which was CPS-1 (10MHz 68000 CPU + 4MHz Z80 for sound engine + YM2151) on the arcade, but was ported or converted to SNES (2.8/3.6MHz 65816 CPU + SPC700 (digital, no FM!)). That's a game that runs at nearly 60fps the entire time and is a very good port. Another example, also from Capcom: UN Squadron/Area 88. For other companies like Konami, they had Gradius 3 as a launch title, which was also 68000 ported to 65816. That game does have slow down during some levels, such as the bubble level, and reverse engineering analysis (gets into the nitty gritty in later pages) has proven it's not "CPU speed" or "system limitations" as much as it is some rushed or badly-engineered sprite management/collision -- i.e. not the hardware.

Finally: please remember the games I'm talking about came out in 1990 through 1992/1993. Time period/era is very important when it comes to talking about any of this. If you're too young to remember this era (i.e. you didn't live through it as either a late teenager or adult) then all of this will be lost on you and you will make silly comparison mistakes like assuming hardware was as cheap as it is today back then. Nope, it all was much, much more expensive.

It seems something psychological caused my false perception.

Am I right that double buffering is impossible if I use 224x192 8bpp resolution because there is no room for double buffer in 64 kB VRAM?
I was able to made double buffering on Sega having 64 kB VRAM because Sega was able to transfer 50% of data while VDP is rendering the previous half of the screen.

Am I right that If you are using double buffering you are limited to 32 kB viewport (about 224x140)?

And is it possible for SNES to turn the screen off and make forced VBlank for higher DMA transfers?

Full-screen double buffering is possible, just not anywhere near 60 fps. Forced blanking is also possible, and unlike on NES, there aren't severe sprite restrictions if a frame ends in forced blanking, so you can still use sprites for the HUD and the like.

224x192 is 80 percent of the width and height of the 4:3 frame. The markings for a 224x192 area on Nintendo's NES background planning sheet implies that Nintendo must have recommended that developers keep all important score indicators and the like in this area. It also happens to be the size of the picture rendered by the Super FX MARIO chip in Star Fox.

224x192 means there are 43,008 pixels on the screen. At 4 bits per pixel, this amounts to 21504 bytes, or 21 KiB. At 165.5 DMA bytes per scanline, it takes 130 scanlines' worth of DMA timeto send an entire picture.

224x192 means there are 193 active scanlines: one to bring the PPU cleanly out of forced blanking and 192 to display lines of picture. Subtract this from the 262 total lines of the NTSC NES and Super NES, and this leaves 69 usable to transfer data, or enough to transfer half a picture.

You can even get away with one and a half buffers. Divide the first 31.5 KiB of VRAM into three 224x96 pixel buffers, 10.5 KiB each. The top half of the screen is then double-buffered, while the bottom half isn't. In theory, if streaming from a sufficiently fast GPU, a game can follow the following four-field cadence for 30 fps operation:

1. Send top half to buffer 1, then display 2 and 3
2. Send bottom half to buffer 3, then display 1 and 3
3. Send top half to buffer 2, then display 1 and 3
4. Send bottom half to buffer 3, then display 2 and 3

224x192 4bpp 30 fps.
Not bad!
However bad that 4bpp only.

Unfortunately, a mild amount of letterboxing doesn't quite save 60 fps.
224x160: 35840 pixels, 17920 bytes, 109 lines' worth of DMA, but only 101 blanking lines. That's not quite enough for 60 fps.

60 fps isn't the objective at all.
It's obvious it's unreachable for direct colour.

We know that this (224x192 + 4bpp + 30 fps + double buffer) is possible.

At this moment I would really like to know what the max viewport I could achieve for a 8bpp color and 15-20 fps ( I don't know for sure but I guess 30 fps is unreachable)?

Given two NTSC refreshes (262 scanlines)
524 scanlines
X scanlines drawn
524-X scanlines spent in DMA
(524-X)*165.5 bytes sent during DMA

assuming a width of 256
X*256 bytes consumed during redraw
x*256/2 bytes consumed across two redraws because each byte is used twice
(524-X)*165.5 = x*128
x=295 scanlines across two redraws
x=147 scanlines each redraw

Double-checking the math:
256*147 pixels = 37632 bytes at 8bpp
262-147=115 scanlines for DMA per hardware redraw, 230 per transfer
230*165.5 = 38065 bytes available for DMA.

You can make it taller (and more windowboxed), but it cuts into DMA time so you'll be able to transfer less.

Didn't you ask us this already like 4 years ago?

Your Mega Drive video spec in that thread, 288x192 at 30 fps, corresponds roughly to 232x192 on SNES (or MD in H32 mode), which is actually quite achievable in 4bpp. Using an H-IRQ, it's possible to rewrite an entire 4bpp palette every scanline with DMA, so the "hundreds of colors" part works too.

If your goal is a 30 fps 8bpp video mode, you can do 256x144, 232x152, 200x160 or 176x168 with static maps and appropriate fractional buffering. (Actually, 176x168 is small enough to allow true double buffering.) You can also do 208x160 if you don't need to refresh the palette every frame, and you can do display heights that are not multiples of 8 to get more DMA at a given screen width (for example, 208x159 should leave enough time for a palette update, and 240x150 seems to barely work too).

At 15 fps, I think you can do 256x188 in 8bpp. [EDIT: not without tearing. Even with fractional buffering there's not enough VRAM.] If I understand the VRAM port address remapping feature correctly, it allows you to write lines instead of tiles if the display is 256 pixels wide, so you can write a row of partial tiles instead of wasting DMA writing whole tiles that end up partially hidden. (Somebody correct me if I've got that wrong; I haven't needed the feature myself and my brain is tired... even if I'm wrong, you can for sure do 256x184 or 248x189.)

Some have suggested a trick that might increase those numbers at the cost of the ability to display sprites. It is unclear if it will work; AFAIK it has not been tested. Don't sue me if it works and invalidates the above numbers, but also don't be shocked if it doesn't.

(Please note that "direct colour", as commonly understood, does not describe the 8bpp SNES picture modes as normally employed. They are still palettized, just with 256 colours instead of 16. It is possible to set these modes to use the index and palette selector bits as direct RGB colour instead of referencing CGRAM, but the bit depth of the RGB channels suffers when you do that, and it was not often done in commercial games.)

...

Not long after the 2015 thread linked at the top of this post, it was discovered that FantomBitmap, the DMA direct colour trick developed for the Mega Drive and described in the linked thread, can also be done on the SNES. It's not exactly the same technique because the MD and the SNES don't work the same way, but it's the same idea - you get full-screen true 15-bit colour at 60 fps by blasting data into CGRAM with DMA. Unfortunately, while the Mega Drive's DMA is 16-bit (well, 9-bit) when targeting CRAM, resulting in the colour changing every two pixels, the SNES has an 8-bit CPU data bus and takes two cycles to write each CGRAM entry, so the colour changes every four pixels and the horizontal resolution ends up too low to be useful.

It may be possible to make a full-resolution video mode out of a variation of this trick using colour math to combine it with a tiled layer, but it would be lossy and very very hard to render into.

Thanks a lot for your help 93143!

Yep. It was me around here 4 years ago with the similar question.
Time runs so fast... 4 years passed since then.

256x188 8bpp 15fps. acceptable.
I will try to implement it.

Cool! I didn't know SNES is able to "blast process".
As far I know that colour trick when you are sending DMA directly to the background colour into CRAM gave the name: blast processing.
Unfortunately neither Sega Genesis/MD nor SNES can use it because of doubled or even quaternary pixels.
Sega could use it for some games or at least video playback but there is a bad thing:
because of the memory refresh you have about 5 (doubled) columns of quaternary pixels (each 64 pixels) and it looks like as the image zooms through a lens.
Even tolerant to double pixels games looks ugly with those zooming columns.
It's acceptable if the image doesn't change. But once image changes you see the zooming columns and it becomes unacceptable for usage.

It's not visible well on a static image. I made a video 4 years ago to show those columns:
https://www.youtube.com/watch?v=TwGmg6S00_k

It should also be possible to do 256x172 at 20 fps. EDIT: not in 8bpp, it's not. Not enough VRAM for fractional buffering, so you'd get tearing.

Are you trying to make a Super FX demo or a video mode?

The SNES version of DMA direct colour manages to get around the DRAM refresh issue because it has a couple of extra layers of cause and effect between the DMA and the display. So it's possible to start the line early and prebuffer enough colours to cover the 10-pixel pause in the middle of the screen. Unfortunately this still only gives you the resolution of the MD version's refresh pauses over the whole screen, and you end up feeling like you need glasses:


However, it is possible to use sprites and BG3 even with this version of the technique, and VBlank is free. It's like an Atari VCS on steroids...

Really cool! Despite 4 pixel wide "pixels" it's still cool just as a demo.

256x172 20 fps is quite enough for a playable game. 4bpp right?

I plan to make a game (first person shooter) using an additional GPU to produce graphics and I need to display it.
But I would like to display it a bit faster than the DOOM did.

No, 8bpp.

Wait...

Aw nuts... I may have misled you. I should have remembered this; it's basic, and in fact I've done these calculations before and run into this exact issue...

...

The 256x188 8bpp frame takes 48128 bytes in VRAM. You can only transfer about 12247 bytes per frame with a picture that high, meaning that even if you don't change the palette, you still need to have loaded 35881 bytes of the next frame before you overwrite any of the current frame. Combined with a pair of tilemaps, this results in a total VRAM load of no less than 85 KB.

With 256x172 at 8bpp, you have 14895 bytes per frame of DMA, which means you need to have transferred 29137 bytes before the final update, and the VRAM load is at least 76 KB or so.

So I retract my claims above. You cannot do 8bpp graphics at 256x188 or even 256x172 at any frame rate, unless you want to put up with visible tearing due to overwriting part of the visible framebuffer. It simply doesn't fit. (You can still do 256x146, 240x150, 208x159, etc. in 8bpp at 30 fps. They all fit.)

...

At 8bpp, 256x152 fits, and you can transfer it at 20 fps. But that's not much bigger than 256x146, which should work at 30 fps. Narrower, taller windows might be more optimal, because they're smaller and might still work at 20 fps despite the reduced DMA bandwidth: for example, 216x176 at 8bpp should barely work at 20 fps even with a palette update.

You get much larger framebuffers and higher rates at 4bpp (not least because VRAM is no longer an issue). Star Fox was 224x190 (presumably with a 224x192 framebuffer) and could have run at 30 fps with a fast enough chip. I once worked out what a Super FX TIE Fighter port might look like in 4bpp, and it turned out that I could do a 240x200 rendered window with a 240x208 active area, and still maintain 20 fps. Basically, the Mega Drive doesn't have an advantage over the SNES in this area unless you exploit the fact that DMA to VRAM still sort of works during active display.


Keep in mind that if you use a status bar below the main rendered area, it will eat directly into your DMA time. Doom had a 216x144 rendered window, which by itself would allow 30 fps, but the status bar extends it to 176 pixels of display height, reducing the available DMA bandwidth and limiting the achievable frame rate to 20 fps. Sprites in the display area would not cause an issue, and have an advantage over BG2 in that they don't require VRAM space for an extra tilemap (no SAT in VRAM on SNES; OAM is separate).

If you want to display the player's gun using sprites or BG2, instead of rendering it with the coprocessor, the display probably won't end up any bigger than the one in Doom unless you drop to 4bpp. Even status sprites might take up too much room to permit a fully fractional-buffered 216x176 rendered layer in 8bpp.

No problem!
Still cool!

I decided to start learning SNES development.
I will be back after I have some demos.

Thanks a lot for your help guys!

I'm going to change the subject, but I don't see why the "direct colour mode" is of much interest. If I undertand it well, this mode does not use a palette, instead it uses the 8-bit palette index of a 8BP tile directly to pick a colour. Probably it is 2 bits for blue and 3 for the remaining colour components because human eye is less sensitive to blue. This means the palette is ignored, and basically you're using 8BP with a hard-wired palette instead.

But if you're using 8BP anyway, it makes much more sense to use the palette and really have the colours you need. This leads to much more flexibility, and it can not get worse than "direct colour". The only instance where "direct colour" would be of any use is if you're debugging and don't have a 256-colour palette ready to use, or if you are using split-screen effects, and use this mode only in a part of the screen where you don't want to use the palette which would be shared with the other part.

In mode 3, it lets you use a full R3G3B2 TrueColor visual for the 8bpp plane, while simultaneously getting eight 15-color palettes for the 4bpp plane and eight 15-color palettes for sprites. (Mode 4 is less compelling, because the 2bpp layer means that 112 of the palette entries are now unused, instead of only 16).

I used it in my "bus activity" demo for this reason.

OK I see the point as a whole.
However in the particular case of double-buffering FMV images, the 2 buffers for FMV themselves will take the entiere VRAM, so there's no room for any extra 4BPP plane nor sprites, if I'm not mistaken.

Just noting here that the palette selector bits raise that to R4G4B3. Unfortunately the extra bits are per tile, not per pixel... and of course this doesn't work in Mode 7, which has no palette selector bits...

Speaking of Mode 7, it should be possible to use EXTBG and get a direct-colour R3G3B2 BG1 and a 7bpp palettized BG2 with per-pixel priority out of the same pixel data, right? That could potentially be exploited, I'm sure... You can do a palette split without direct colour because of the top bit getting dropped/reinterpreted for BG2, but the sprite palettes kinda get in the way.


Depends what you want the FMV for. If you're rendering part of a game, you may still want a status display, a gun... really any element that doesn't need to be rendered by the coprocessor. Star Fox is the classic example of a Super FX game with a big colourful full-screen backdrop and a sprite-based HUD - it's conceivable that someone might want to do something like that in 8bpp. Still, 256 colours is a lot, and 8bpp really does eat VRAM for breakfast (as I belatedly realized upthread), so you might want to avoid getting too crazy...

Isn't the bit that's the priority bit the same as the blue MSBit? Seems like it'd be hard to use unless you specifically want a yellow-ish layer.

Or a dim layer, which might actually be what you want with some applications of colour math. You could also dodge around the sprite palettes to get a handful of specific high-temperature highlight colours, or even deliberately leave holes in the sprite palettes for the hot colours you want.

I don't think the direct colour mode was used a whole lot. It's not like Mode 7 or colour math where you've got obvious use cases coming out your ears...