Capabilities of various VDPs at parallax effects

[turboxray]

Is there no "other" section on the forums? Oh well, shameless plug for my "hi color demo"... a wip demonstration, for PCE:
https://www.youtube.com/watch?v=FjYw55qn8Rw


Via snes:
Direct color mode is okay, it has limitations of being stuck to a small overall color palette. I think mode 4 with 8bbp tiles, indexing 256 color, and pairing it with BG 2 as 2bbp layer - as the "intensity" for the 256 colors; 4 levels of intensity is ~1024 colors (or less, depending on repeats from the color math). That's a color freedom of a single pixel choosing one of the 1024 colors (direct color mode is "lossy", and doesn't allow this). On top of that, you have access to the full 32k color palette (which you don't in direct color mode). In my opinion, that's the best 'color mode/trick' on the SNES; 1024 on-screen colors out of a palette 32768 colors. The only drawback is that VRAM is just too tight, so you're going to have to clip the display a lil bit. Well, worth it IMO.

[Chilly Willy]

Is there no "other" section on the forums? Oh well, shameless plug for my "hi color demo"... a wip demonstration, for PCE:
https://www.youtube.com/watch?v=FjYw55qn8Rw

That's really good looking. Rendered games like Nintendo did for the SNES late in its life would do well with that sort of coloring.

[iNCEPTIONAL]

Is there no "other" section on the forums? Oh well, shameless plug for my "hi color demo"... a wip demonstration, for PCE:
https://www.youtube.com/watch?v=FjYw55qn8Rw


Via snes:
Direct color mode is okay, it has limitations of being stuck to a small overall color palette. I think mode 4 with 8bbp tiles, indexing 256 color, and pairing it with BG 2 as 2bbp layer - as the "intensity" for the 256 colors; 4 levels of intensity is ~1024 colors (or less, depending on repeats from the color math). That's a color freedom of a single pixel choosing one of the 1024 colors (direct color mode is "lossy", and doesn't allow this). On top of that, you have access to the full 32k color palette (which you don't in direct color mode). In my opinion, that's the best 'color mode/trick' on the SNES; 1024 on-screen colors out of a palette 32768 colors. The only drawback is that VRAM is just too tight, so you're going to have to clip the display a lil bit. Well, worth it IMO.

Yeah, I saw your PC Engine examples, and they look truly amazing. Far beyond anything I've seen on Genesis, and, so far, much nicer than anything I've seen the SNES dev scene put out too, which is bonkers.

Now, regarding the direct colour mode on SNES, doesn't the stuff in the following link apply here, so it would actually be around 2304 colours even before any other things like colour math, HDMA gradients, raster tricks or whatever pseudo effects are applied, if I've understood it correctly:

https://forums.atariage.com/topic/34527 ... pablities/

[Chilly Willy]

Yeah, I saw your PC Engine examples, and they look truly amazing. Far beyond anything I've seen on Genesis, and, so far, much nicer than anything I've seen the SNES dev scene put out too, which is bonkers.

The single biggest problem with the Genesis display is the small palette. 3 bits per gun (BGR) is really not enough for high color quality. It's good for the kind of games the Genesis does, but that's about all. With careful use of hilite and shadow, you can improve on that, but not by much, and hilite/shadow is hard to apply as needed for making those kinds of images. It would have done so much better with 4 bits per gun like the Amiga. It's why Amiga games don't look quite as good on the MD as they do on the Amiga - the limited palette.

The PCE has a high resolution mode that allows blending colors to move beyond its palette. The Genesis can also do this... on composite output on a TV that filters composite input. Blending colors really eats into detail, though, which is why having the high resolution mode on the PCE makes blending easier than on the Genesis. A number of Genesis games use blending for more color - you can see the dithering of the pixels meant to blend together in emulators or on good TVs, especially if you're not using composite video.

[turboxray]

Yeah, this isn't exploiting chroma <--> luma interference like on many other "hi color" demos for multiple systems (Apple 2, CoCo 3, MD, etc). The Genesis/MD, for NTSC, gets blended colors simply because the Luma signal is almost twice the chroma signal, and it's difficult to separate (there's no alternative chroma burst mechanism). But obviously that doesn't work for PAL composite/RF output for Megadrive. It softened in the PAL signal, for MD, but it's visibly there. But I guess if you had a pretty low grade consumer TV, the CRT TVL resolution also helps blend things regardless of how sharp/crisp the signal is (even for RGB) - everyone likes to run with PVM or BVMs these days, but that wasn't realistic for gamers BITD.

I don't mean to disregard S/H mode on the Genesis, I just wanted to point out the dithering approach on NTSC Genesis/MD. I don't think anyone has made a decent converter for images using S/H.. at least not publicly.



The high-res blend down on the PCE method, works both in NTSC and PAL composite (I have a PAL TurboGrafx). Matter of fact, the NTSC version is very crisp because of the PCE's alternating 180 degree color burst every other line, and inverted on the next frame. These images have no color fringing on NTSC composite. And the other side to this, is that for these images - I spent a considerable amount of time making my own gui app that allows you to tweak all kinds of parameters for the image and dithering encoding (the error diffusion one is a variation of floyd-steinberg, but only the error distribution matrix - the rest of the dithering is completely different from standard floyd-steinberg).

What this means is that I don't simply treat the pixels in the image as a double pair pixel (you can, and that's easiest approach). But rather, I do the error diffusion dithering at 10.74mhz frequency; so on a perfect blend you get a 256px (5.37mhz) pixel clock with hi-color.. with 5.37mhz frequency dither, but when you look at it raw/zero-blend.. it's 512px (10.74) pixel clock with high res detail.

And so, think of it as a spectrum - as you go to one end you get hi color lower res, and as you go to the other end you get lower color with high resolution with more detail (but the high frequency dither pattern kicks in! So it still blends nice too). It's the best of both worlds! If it starts to "leak" higher res pixels (higher frequency detail) as the blending breaks down, then your image starts to show more detail (become higher res) haha. It works really well and I'm not actually dependent on a "perfect" blend. I've had people test it with RGB->Component converters and it looked amazing. Same with s-video. These are on higher end consumer CRTs too. (I suspect people are using SD video amps for the pce RGB mods that have a 8mhz low pass filter though).

Btw - these images in the video are specifically test images. I was exploring what range was possible - not just trying to throw as much color as possible; that just happens to be a side effect haha. Most of them just happened to come out pretty good. What doesn't come through on the video, but does on the CRT, is the 'glowing light'. Some of the images simply look stunning on a CRT because it looks like a real bright/hot light source in the images (like the floating astronaut against the blackhole with the event horizon). They also somehow look higher res than 256px on the CRT too, while still perfectly blending. You really have to see it on a CRT for yourself haha. I'm still in awe at how some of these turned out.



If I were to use this in game though, I'd probably do a double pair pixel approach. Mostly so I could do some transparency effects with the blending. But it's not an either/or thing. I can do both.

Yeah, I saw your PC Engine examples, and they look truly amazing. Far beyond anything I've seen on Genesis, and, so far, much nicer than anything I've seen the SNES dev scene put out too, which is bonkers.

The single biggest problem with the Genesis display is the small palette. 3 bits per gun (BGR) is really not enough for high color quality. It's good for the kind of games the Genesis does, but that's about all. With careful use of hilite and shadow, you can improve on that, but not by much, and hilite/shadow is hard to apply as needed for making those kinds of images. It would have done so much better with 4 bits per gun like the Amiga. It's why Amiga games don't look quite as good on the MD as they do on the Amiga - the limited palette.

Even with the same 4 subpalette limitation in place on the Genesis, 4bits per element would have really helped! I know hindsight and all, but...

Now, regarding the direct colour mode on SNES, doesn't the stuff in the following link apply here, so it would actually be around 2304 colours even before any other things like colour math, HDMA gradients, raster tricks or whatever pseudo effects are applied, if I've understood it correctly:

https://forums.atariage.com/topic/34527 ... pablities/

First off, we need to split that 2304 number up. It's 2048 + 128 + 128, which 128 isn't correct.. it's 120 because of the reserved color slot in each subpalette. So focusing on the 2048 colors. The RGB direct value mode uses 3:3:2 (R:G:B) which gives you 256 colors - both for the palette and the total number of colors in that tile. 256 colors is great for total number of colors in a single tile, but overall is pretty crap of a palette (I mean, considering the SNES has a 32768 color palette). The reason why it magically turns into 2048 colors is because direct color mode doesn't need a palette in the tilemap to associate with the tile. So, cleverly, Nintendo allowed the reuse of those 3 bits in the tilemap, as the lowest bits of the 3:3:2. That means you get (3+1):(3+1):(2+1) => 4:4:3 or 11bit RGB color. You don't get pull from the 32k palette. AND those extra low bits are for the WHOLE 8x8 tile. That's why I said it was "lossy". And yes, you could attempt to mitigate that with a large tilemap, line interleaved on the screen with hDMA, so you have something like a 8x2 tilemap "palette association" to the tile (but instead the palette bits are the color bits) - which means every 8x2 row has the bits fixed. It's coarsely similar/analogous to HAM on the Amiga (but HAM is much superior). Honestly, for unique detailed images (where almost all tiles are unique) - I don't think that's very good for images. And you're limited to just 2048 colors fixed colors - not anything picked from 32k colors, you don't get to chose individually for each pixel for those 2048 colors. And on top of that, 8bpp eats vram for lunch - you won't have enough vram left for the 4bpp layer used to get the extra 128 colors.. or even sprites, for the final 128 colors.

That's why I said mode 4.. and use 256 "indexed" color mode. Start with the base: 256 colors out of 32k colors. Right there, 9.8 times out of 10 that's going to be a better option right there. The granularity of the master palette you're picking colors from.. matters! If I had to pick even against something like 512 colors out of 4k colors, I'd still pick 256 out of 32k colors. Anyway, using the 2bpp layer, and color math, duplicate those base 256 colors, out of 32k colors, as four intensity levels. So 1024 colors out of 32k colors, and it's not lossy and it's a "per pixel" freedom, and you don't need to do a large tilemap reposition with hDMA either. It's a far superior method for display hi color images with unique detail on the SNES.

[iNCEPTIONAL]

Ah, yes, I didn't account for the transparent palette entries with the numbers on either Genesis or SNES. My bad.

So, before worrying about any memory management and the like in an actual end image for now, or indeed any other tricks to increase the colours even further than normal, since, unlike with the other systems, I can't find a single example showing what can and can't actually be achieved here on SNES when pushed to its memory and technical capability limits under these very specific colour-stretching conditions, in terms of useable colours as pretty much standard, it's:

Genesis: 60 (BGs plus sprites) + 1 (backdrop) = 61.

SNES: Either 120 (BG1 and BG2) + 120 (sprites) + 1 (backdrop) = 241 or 2048 (BG1 in direct colour mode) + 120 (BG2) + 120 (sprites) + 1 (backdrop) = 2289.

PC Engine: 240 (BG) + 240 (sprites) + 1 (backdrop) + 1 (border) = 482.

Correct?

Then, it's about how those colours are used on each of those systems and indeed how each system can be exploited in various ways to increase the colours even further than via standard use, be it with colour math (SNES), changing the backdrop colour every scanline (HDMA on SNES), high-res modes that allow some kind of additional blending (PC Engine, and presumably SNES too), highlight/shadow mode (Genesis), raster tricks (all of them), etc.

And, you're saying that using the two backgrounds with the single 256-colour palette [chosen from that 32,768 master palette] in SNES' Mode 3 or 4, with one background in 8bpp and the other in 4bpp or 2bpp (depends on the mode), plus some colour math and the like, would definitely be better than trying to exploit the alternative BG1 2048 direct colour option alongside the other palettes available there and any colour math and so on too?

Also, I still dunno much about the 512x448 mode on SNES either, which has 120 colours for BG1 at 4bpp and BG2 at 2bpp + 120 colours at 4bpp for sprites + 1 backdrop colour for the pretty standard 241 total colours, and if that could be exploited somewhat similarly to the way you have done on PC Engine to increase the colour count greatly there also, even if via that pseudo method or something along the same lines too (and that's still before any actual colour math or HDMA for changing the backdrop colour per scanline).

This is the kind of stuff I'm rather disappointed the SNES development community doesn't seem to be thoroughly testing and indeed trying to push to its limits too, with lots of actual working and great looking examples. I'm thinking there's still a lot of untapped potential there.

PS. Curious: Before any other special colour effects and exploits, does the SNES' 2048 direct colour BG1 [on its own for now] ultimately allow for better or worse colours on-screen than the Genesis' 61 colours at 4bpp in 4 16-colour palettes from a master palette of 512 colours and PC Engine's 482 colours at 4bpp in 32 16-colour palettes from a master palette of 512 colours?

[turboxray]

And, you're saying that using the two backgrounds with the single 256-colour palette [chosen from that 32,768 master palette] in SNES' Mode 3 or 4, with one background in 8bpp and the other in 4bpp or 2bpp (depends on the mode), plus some colour math and the like, would definitely be better than trying to exploit the alternative BG1 2048 direct colour option alongside the other palettes available there and any colour math and so on too?

Definitely! Even just 512 colors (index 8bpp + color math) out of 32k palette would look incredible! I'm not sure why no one has made an app to convert to this. Maybe I'll adapt mine in the coming months to try it out.

PS. Curious: Before any other special colour effects and exploits, does the SNES' 2048 direct colour BG1 [on its own for now] ultimately allow for better or worse colours on-screen than the Genesis' 61 colours at 4bpp in 4 16-colour palettes from a master palette of 512 colours and PC Engine's 482 colours at 4bpp in 32 16-colour palettes from a master palette of 512 colours?

Better for standard games or images?

Better is subjective haha but.. objectively better as in overall total number of colors - yes. Objectively better as in highest color fidelity (most color freedom and most colors in a compacted area) - yes. I mean, just simply by those number - yes.

But the downside is "attribute clash" with that mode on the SNES, to get beyond the 256 color @ 8bit RGB to anything close to 2048 color @ 11bit RGB. That mode wasn't meant as a 2048 color mode. Those bits are "color emphasis" bits, like on the NES. Except.. it's not the whole screen but 8x8 area that you're emphasizing. If you're going use it, it needs clear 8x8 edge boundaries for it to be useful (like just early 8bit systems with attribute clash - c64, NES, Speccy, etc). I can't stress this enough; trying to make it more than an 3:3:2 color mode is going to be a painful exercise. If you set the green bit... EVERY color in that tile is tinted green now... even black.

Because of that limitation, you're not going to be punching much at all above that number of the base 256 color. It's still a "palette selection" system, via a tilemap, just in the sense that it's color "emphasis" instead of a completely new set of colors. IIMO it makes clashing even more noticeable than with normal palettes - when you try to use it as "2048 color mode".

So the better way to look at this is from the lowest effective use-case first - as just a 256 color mode with an 8bit color palette. Is it better than the Genesis? Probably better than the Genesis simply for the fact that a lot of Genesis games don't use a lot of shades/hues but instead try to pack as much "unique colors" into the 4 subpalettes. Would I trade full unrestricted 3:3:2 color with no palette restrictions, and all those colors in a single tile.... over effectively 50 colors max but also restricted by 4 subpalettes (sprites have to use those too!)...?? Yeah, it's better option over all IMO.

Same setup against the PCE? I'd say no, simply because the PCE has 32 subpalettes... well, 16 for the BG layer, really does give a lot of color freedom. It isn't worth the trade off against a worse "palette".

And lastly against it's other modes on the SNES? I'd also say no as well. I mean 4bpp mode have 8 decided subpalettes (and not 4 total, shared with sprites like on the Genesis)... with a 32k master palette. I wouldn't even take it over that mode. And finally, there's 8bpp "indexed" mode, which is 256 colors but now with 32k palette to chose from.

Given all the modes on the snes, I simply can't see a use case for that mode to be honest. I just don't see how you're going to effectively get more than 256 colors out of it without any sort of tile grid clashing. I'd definitely say try to come up with one though if you can. Do we know if any games use it? Maybe...I can see the use for, is that if you're software rendering something that doesn't need a huge palette, but does needs a lot of unrestricted colors, and it doesn't interfere with sprite colors - something polygon related or such. But there are other tricks on the SNES for that sort of thing.

[iNCEPTIONAL]

And, you're saying that using the two backgrounds with the single 256-colour palette [chosen from that 32,768 master palette] in SNES' Mode 3 or 4, with one background in 8bpp and the other in 4bpp or 2bpp (depends on the mode), plus some colour math and the like, would definitely be better than trying to exploit the alternative BG1 2048 direct colour option alongside the other palettes available there and any colour math and so on too?

Definitely! Even just 512 colors (index 8bpp + color math) out of 32k palette would look incredible! I'm not sure why no one has made an app to convert to this. Maybe I'll adapt mine in the coming months to try it out.

PS. Curious: Before any other special colour effects and exploits, does the SNES' 2048 direct colour BG1 [on its own for now] ultimately allow for better or worse colours on-screen than the Genesis' 61 colours at 4bpp in 4 16-colour palettes from a master palette of 512 colours and PC Engine's 482 colours at 4bpp in 32 16-colour palettes from a master palette of 512 colours?

Better for standard games or images?

Better is subjective haha but.. objectively better as in overall total number of colors - yes. Objectively better as in highest color fidelity (most color freedom and most colors in a compacted area) - yes. I mean, just simply by those number - yes.

But the downside is "attribute clash" with that mode on the SNES, to get beyond the 256 color @ 8bit RGB to anything close to 2048 color @ 11bit RGB. That mode wasn't meant as a 2048 color mode. Those bits are "color emphasis" bits, like on the NES. Except.. it's not the whole screen but 8x8 area that you're emphasizing. If you're going use it, it needs clear 8x8 edge boundaries for it to be useful (like just early 8bit systems with attribute clash - c64, NES, Speccy, etc). I can't stress this enough; trying to make it more than an 3:3:2 color mode is going to be a painful exercise. If you set the green bit... EVERY color in that tile is tinted green now... even black.

Because of that limitation, you're not going to be punching much at all above that number of the base 256 color. It's still a "palette selection" system, via a tilemap, just in the sense that it's color "emphasis" instead of a completely new set of colors. IIMO it makes clashing even more noticeable than with normal palettes - when you try to use it as "2048 color mode".

So the better way to look at this is from the lowest effective use-case first - as just a 256 color mode with an 8bit color palette. Is it better than the Genesis? Probably better than the Genesis simply for the fact that a lot of Genesis games don't use a lot of shades/hues but instead try to pack as much "unique colors" into the 4 subpalettes. Would I trade full unrestricted 3:3:2 color with no palette restrictions, and all those colors in a single tile.... over effectively 50 colors max but also restricted by 4 subpalettes (sprites have to use those too!)...?? Yeah, it's better option over all IMO.

Same setup against the PCE? I'd say no, simply because the PCE has 32 subpalettes... well, 16 for the BG layer, really does give a lot of color freedom. It isn't worth the trade off against a worse "palette".

And lastly against it's other modes on the SNES? I'd also say no as well. I mean 4bpp mode have 8 decided subpalettes (and not 4 total, shared with sprites like on the Genesis)... with a 32k master palette. I wouldn't even take it over that mode. And finally, there's 8bpp "indexed" mode, which is 256 colors but now with 32k palette to chose from.

Given all the modes on the snes, I simply can't see a use case for that mode to be honest. I just don't see how you're going to effectively get more than 256 colors out of it without any sort of tile grid clashing. I'd definitely say try to come up with one though if you can. Do we know if any games use it? Maybe...I can see the use for, is that if you're software rendering something that doesn't need a huge palette, but does needs a lot of unrestricted colors, and it doesn't interfere with sprite colors - something polygon related or such. But there are other tricks on the SNES for that sort of thing.

Well, that would be very cool to see you convert your app to work with SNES' 8bpp + colour math and the like too (possibly with the option to output images using the 256-2048 indexed-colour BG1 mode also, just to see what those can look like), and maybe post a few sample images like the ones you used on PC Engine actually showing that in action. You're probably the only person who'd bother doing something like this as well.

Yeah, in this case I was just curious about the direct colour for images, since it's easier to see that working all at once in something that's static, but even normal in-game use would be worth considering. The only use of it in a real game that comes to mind is Actraiser 2 (although I think there's a couple more), which apparently uses it on the map screen or something (not sure if that's the Mode 7 parts as well as the when the pillars and menu stuff appears over the map). But I looked at it just with my eyes and it really doesn't look like anything special, and I can see no reason why it was even necessary there:

https://youtu.be/22SOTDNQvkI?t=270

Edit: It's seems the Mode 7 background can use direct colour mode, so it's possible it's used in the Actraiser 2 map screens as a way to use however many direct colours in the Mode 7 background image and still be able to use 120 separate dedicated colours for the sprites too (not that it visibly shows here imo).

But, yeah, I'd love to see some actual good examples of 8pp + [whatever else] as well as 256-2048-indexed + [whatever else] colour images too on SNES.

[iNCEPTIONAL]

https://www.youtube.com/watch?v=1iq8nQ2Bd80
^ This was dead simple to do. There's no crazy code or optimizations. It's just a simple concept and execution. Lot of cpu resource left over too in the frame.

You know, I just realised something. Having mentioned previously that your parallax demos, the one above and this one too https://youtu.be/kU7myUxemZg, made me think of the demo below on SNES that's also using the sprites to fake an extra foreground scenery layer and characters on top of the SNES' single Mode 7 background:

https://youtu.be/spVwBD6NOVI

Given the sprite sizes you're using in your examples (looks like it's probably 16x16 and 32x32 or maybe 32x32 and 32x64 or something like that), along with the max sprites on-screen and max sprite per scanline limits of the PC Engine (the first is less than SNES, 128 vs 64, and the second is less sprites per scanline on PC engine and just a little less 8x8 tiles per scanline overall too, 32 vs 16 and 34 vs 32), the SNES should actually be able to create exactly the same foreground layer plus other characters and objects using entirely sprites like you have in your excellent example but actually do so along with that Mode 7 fully scaling perspective waterfall effect at the same time.

I previously wasn't sure if the SNES version would be able to get quite as much of the screen covered with sprites over that Mode 7 layer until I understood a bit better how you were doing it. So now I'd actually like to see someone do a really nice example of a Mode 7 scaling waterfall background or whatever alongside a foreground sprite layer and objects that covers just a much screen space as your excellent example. In the right hands, man, I think that could look very cool indeed, especially give the SNES can still have the 4bpp tiles with 240 total colours on-screen from its huge 32,768 master palette alongside additional use of transparency effects and so on. And, if we look at the current Mode 7 demo above on SNES further, we can see that the background section at the top with the clouds could actually look a lot nicer than it currently does on SNES and even use say Mode 0 there for four fully overlapping and line-scrolled parallax layers to really sell the whole effect even more too.

So much potential. I'd even mock this up in GameMaker 8.1 right now if I could only figure out a way to recreate the Mode 7 effect in that program. Still, the idea of it is sound.

[turboxray]

https://www.youtube.com/watch?v=1iq8nQ2Bd80
^ This was dead simple to do. There's no crazy code or optimizations. It's just a simple concept and execution. Lot of cpu resource left over too in the frame.

You know, I just realised something. Having mentioned previously that your parallax demos, the one above and this one too https://youtu.be/kU7myUxemZg, made me think of the demo below on SNES that's also using the sprites to fake an extra foreground scenery layer and characters on top of the SNES' single Mode 7 background:

https://youtu.be/spVwBD6NOVI

Given the sprite sizes you're using in your examples (looks like it's probably 16x16 and 32x32 or maybe 32x32 and 32x64 or something like that), along with the max sprites on-screen and max sprite per scanline limits of the PC Engine (the first is less than SNES, 128 vs 64, and the second is less sprites per scanline on PC engine and just a little less 8x8 tiles per scanline overall too, 32 vs 16 and 34 vs 32), the SNES should actually be able to create exactly the same foreground layer plus other characters and objects using entirely sprites like you have in your excellent example but actually do so along with that Mode 7 fully scaling perspective waterfall effect at the same time.

I previously wasn't sure if the SNES version would be able to get quite as much of the screen covered with sprites over that Mode 7 layer until I understood a bit better how you were doing it. So now I'd actually like to see someone do a really nice example of a Mode 7 scaling waterfall background or whatever alongside a foreground sprite layer and objects that covers just a much screen space as your excellent example. In the right hands, man, I think that could look very cool indeed, especially give the SNES can still have the 4bpp tiles with 240 total colours on-screen from its huge 32,768 master palette alongside additional use of transparency effects and so on. And, if we look at the current Mode 7 demo above on SNES further, we can see that the background section at the top with the clouds could actually look a lot nicer than it currently does on SNES and even use say Mode 0 there for four fully overlapping and line-scrolled parallax layers to really sell the whole effect even more too.

So much potential. I'd even mock this up in GameMaker 8.1 right now if I could only figure out a way to recreate the Mode 7 effect in that program. Still, the idea of it is sound.

All three systems can do this trick; pce, md, and snes. MD actually has the best advantage of all three when do this because you can reload the SAT entries mid screen.. multiple times. MD would only be lacking in color, but you could do it for 3 4bpp layers.

Those PCE demos aren't meant to show off the system being pushed; as I've mentioned previously, this is just a quick demo showing off an "engine".. something that is super easy to use, is resource lite, etc. I.e. a lot of bang for your buck for parallax on a system that was historically challenged in that department, without having to go to any sort of extremes. It's important to point that out, because if you push this approach - then you start to run into technical limitations. But otherwise, the demo was to show that it's simple in design, approach, code, etc - and that it was very accessible design approach BITD for development (not this level of trying to push systems to their max, nowadays attitude). It's actually braindead simple on the PCE. So why didn't they ever use it? That touches on the topic of "developer/development psychology" haha - a related field of "HCI". Which is not this topic.

So first off, just wanted to mention the SMW demo is great in that it shows you can have Mode 7 and a "layer" on top. And that layer isn't simple like a few floating platforms (ala SCIV tunnel). But the SMW demo is pretty simple and not much sprite coverage. Maybe it's because they wanted to show mode 7 as much as possible.. unclear. But the SNES has one advantage, and few limitations - for this approach.

For SNES: it would definitely need to be 16x16 paired with 32x32 sprite mode. I guess 8x8 and 32x32 would also work, but would be much more limited. 128 SAT size would allow more 16x16 objects in the object map. This seems like a "pro", but it's more of a requirement/crutch for the SNES because has limited vram allocation for SPRITE data. I mean, unless you want really simple foregrounds (limited detail) which look repetitious - you're going to need vram for those 32x32 blocks. Having more SAT entries to use more 16x16 arrangements means you can be a little more efficient with your sprite vram allocation (at the expense of more cpu resource tho). If you're pairing it with MODE 7 and trying to exploit mid screen sprite page changing (which in and of itself is very limiting for this approach already, and wasteful on vram), this is even more of an issue because mode 7 eats up vram.

SNES has another issue. For normal sprite rendering in relation dropout, it behaves like you would expect - lower priority "sprites" are dropped when it can't fetch more. No different than PCE and MD. But SNES has a 2nd rule when it comes to sprites; a sprite "cell" is not dropped in the same way the sprite "object" evaluation is dropped. It's the opposite; the highest priority "cell" gets dropped. It's odd. Outside of one extreme edge case, it's not a desired effect (compared to rule #1).

A little explanation; say that you have less than 34 sprite "objects" on a given line - so you meet the requirement that no "objects" will be dropped.. they will all be evaluated and their cells are queued to be fetched. But let's say, on that same line you did blow the pixel fetching limit (i.e. the 272px cell limit in increments of 8px fetches) - when this is the case, the highest priority cells gets thrown out to meet that 272px line limit. If the player is made up of the highest priority cells, the player cells drop out even tho the player sprite itself is the highest priority sprite.

Why is that an issue here? If you're trying to take advantage of priority layering (which.. I don't really show off but is a key feature to this approach in my design documents) - that issue can get in the way of expecting and taking advantage of just the first rule being applicable (and not the 2nd SNES rule). An example of this, would be in the Bonk demo where he goes behind the completely solid wall.. and even that doesn't really demonstrate what I mean. If you have just rule set #1 in place, you can large "layers" behind the sprite layer (that's also a layer made of sprites) - and you would have areas where sprites cells are dropping out, but you don't care because they're already behind something so you can't even witness them dropping out - you could/would run into issues on the SNES where that is not true - where instead part of the foreground breaks up, etc.

Anyway, for mode 7 - I think anything at the level of the SMW demo or better is really nice. You don't have to be technically inclined to know as a gamer, back then, that when mode 7 was used - pretty much all BG layering were removed (I think even magazines pointed out this limitation) - so getting two layers is nice. And I do think you CAN go above what that SMW demo did for the foreground layer. As nice as that demo is, it has really basic/bland/simple foreground design. So like I mentioned, sprite paging/banking limitation is going to get in your way (you'll need to figure out workarounds) of trying to get more detailed sprite foreground layer - you'll need that extra SAT entries in the 128 table to try and help offset that issue. And SNES sprite rule #2 is going to give you issues if you try to take this to the next level (which I plan on showing off).

[iNCEPTIONAL]

Anyway, for mode 7 - I think anything at the level of the SMW demo or better is really nice. You don't have to be technically inclined to know as a gamer, back then, that when mode 7 was used - pretty much all BG layering were removed (I think even magazines pointed out this limitation) - so getting two layers is nice. And I do think you CAN go above what that SMW demo did for the foreground layer. As nice as that demo is, it has really basic/bland/simple foreground design. So like I mentioned, sprite paging/banking limitation is going to get in your way (you'll need to figure out workarounds) of trying to get more detailed sprite foreground layer - you'll need that extra SAT entries in the 128 table to try and help offset that issue. And SNES sprite rule #2 is going to give you issues if you try to take this to the next level (which I plan on showing off).

Aside from all the rest, are you saying that say the Bonk demo I referred to above is using more unique sprite tiles than the SNES could fit in VRAM? It doesn't look like that huge a variety on-screen at any given time, at least not so much the SNES would completely struggle to get basically the same on-screen anyway.

Maybe you can upload a sprite sheet that shows all the unique sprite tiles in VRAM that you are currently using in the foreground on that Bonk example, and I'll actually see if I can fit them into the SNES VRAM space myself (at least on paper), and then maybe think about what could be done to work around it if I can't.

[Muzzy]

I don't think anyone has made a decent converter for images using S/H.. at least not publicly.

That's true

I came across this one - Bitmap MD from Markey Jester https://www.youtube.com/watch?v=BcRDfi2XVMk
But it's not show full MD/Gen (color wise) potential. At least I can't repeat Toy Story's color count.

[iNCEPTIONAL]

I don't think anyone has made a decent converter for images using S/H.. at least not publicly.

That's true

I came across this one - Bitmap MD from Markey Jester https://www.youtube.com/watch?v=BcRDfi2XVMk
But it's not show full MD/Gen (color wise) potential. At least I can't repeat Toy Story's color count.

That's a very interesting tool. It makes me wonder what kind of results you could get on SNES if someone created a similar tool there too. I mean, the SNES has 256 colours on screen normally from a palette of 32,768, but it also has a mode where you can have two layers, one with 2048 direct colours and the other with 120 CGRAM colours, plus another 120 CGRAM colours for the sprites too, along with the ability to then use the likes of colour math on top of that to actually blend colours in one of four different ways for God knows how many total colours also. So I can only imagine what kind of results might be possible if someone could find a way to mix all of those things together in a single image. Also, the SNES even has its 512x448 mode as well (or just 512x224 if the interlacing is simply going to look bad), and I have to imagine some creative stuff could done there as well. Lastly, just imagine if someone actually found a way to do the equivalent of "Blast Processing" on SNES to somehow push all 32,768 colours onto the screen at once for a single image. And I even wonder if the colour window/shape mask feature might be able to be used in some creative way in combination with all of this too. No idea what all the various limits and stuff are there, and I might be wrong about some of this being useable in actual practice, but I just don't think anyone has realised the full potential of SNES when it comes to the highest possible quality of image at all (really in any of these modes).

[turboxray]

I don't think anyone has made a decent converter for images using S/H.. at least not publicly.

That's true

I came across this one - Bitmap MD from Markey Jester https://www.youtube.com/watch?v=BcRDfi2XVMk
But it's not show full MD/Gen (color wise) potential. At least I can't repeat Toy Story's color count.

Yeah. His approach is simple, but still effective - if you use ALL the layers. He limits, IIRC, each "plane" to 16 colors (15 colors) or just one subpalette.. so you don't get any palette "attribute" clashing/artifacts. It doesn't maximize color usage, but you effectively get high density of colors per 8x8 area when all combined, so it works. More of a manual process but you could use Rilden's tool (https://rilden.github.io/tiledpalettequant) to optimize for all 4 subpalettes, and then come back with your own app and apply sh/hl on top of that. Kind of a dirty process. I did port rilden's source code from JS to Python as an experiment.. and I plan to port it to C++ soon. At that point, it's something you easily integrate into a single tool.

one with 2048 direct colours

I know it's a nitpick, but it's not 2048 direct color mode. It's a 256 RGB (3:3:2) direct color mode.. with 8x8 color "emphasis" bits support. That's a HUGE difference. It's super misleading when you present it as "2048 direct color mode". That said, the alternative 8bit palette color mode with 4 levels of intensity that combines with that - is a totally superior approach (and uses less vram). I'm going to add that conversion mode to my app so people can actually see the output for themselves - rather than just talking about theoreticals.

[iNCEPTIONAL]

I know it's a nitpick, but it's not 2048 direct color mode. It's a 256 RGB (3:3:2) direct color mode.. with 8x8 color "emphasis" bits support. That's a HUGE difference. It's super misleading when you present it as "2048 direct color mode". That said, the alternative 8bit palette color mode with 4 levels of intensity that combines with that - is a totally superior approach (and uses less vram). I'm going to add that conversion mode to my app so people can actually see the output for themselves - rather than just talking about theoreticals.

Well, I don't know the exact wording to avoid nitpicking, but I'm really just talking about what this guy describes here:

https://youtu.be/5SBEAZIfDAg?t=275

So, anyone reading my comments can watch that clip for themselves and get what I mean. But it's still basically one background with 2048 direct RGB colours as he describes it (2047 if one of them has to be transparent), the second background with 120 CGRAM colours, the sprites with another 120 CGRAM colours of their own, plus the single backdrop colour that can be changed on every scanline using HDMA, any colour math, and maybe even some window/shape masking stuff too. There's also still the possibility of maybe using pseudo high-res and interlaced modes here to some capacity as well.

My actual point being that there's clearly a whole lot of colours and options to play with on SNES, and until someone genuinely tries to use these to their full capacity, I don't think we've come remotely close to seeing the full potential of SNES in terms of outputting the highest colour/resolution/quality images it's capable of, which is simply something I'd like to see.

Does your app actually work with SNES stuff then?

I mean, please, let us actually see real output of SNES being pushed to its limits here rather than theoreticals. That's literally what I'm even bringing any of this stuff up for in the first place, because I actually want to see some of this stuff on SNES. And I can't code it myself, so I'm taking it to the development community and hoping someone with the ability to directly code for SNES will eventually do just that.

If that's literally what you're doing, which is creating an actual real tool that lets people output the highest colour/resolution/quality image SNES is technically capable of, I welcome it with open arms. . . .