So, Direct Colour . . .

[jeffythedragonslayer]

2 minutes ago, TrekkiesUnite118 said:

You're not helping, you're just making this situation worse.

So sue me.

[KulorXL]

49 minutes ago, Kirk_Johnston said:

A simple but effective example image right there imo (even though it's literally only using 56 unique colours across the whole image), because it's showing an actually pretty nice direct colour picture

Not to disparage the artist, but I don't think that image really makes a compelling case for direct color mode over just using an 8bpp indexed or even 4bpp layer instead. That's a ton of dithering in the sky to attempt to convey a gradient, which is not a problem you usually saw on the SNES, and the rest of it really looks like it would work perfectly fine on a 4bpp layer instead, which would halve the VRAM consumption. You're gonna have to do better than that if you really want to show us the potential with this mode.

[jeffythedragonslayer]

circling back to what I was saying about how expensive these PPU features are on the first page of this thread, Nintendo tells us we get about 63.5 microseconds per scanline:

 

https://archive.org/details/SNESDevManual/book1/page/n214

[Cris1997XX]

Honestly, sometimes I think I really wanna pick Kirk's brain apart and analyze it closely...to see his line of reasoning, of course

[KulorXL]

1 hour ago, jeffythedragonslayer said:

circling back to what I was saying about how expensive these PPU features are on the first page of this thread, Nintendo tells us we get about 63.5 microseconds per scanline:

 

https://archive.org/details/SNESDevManual/book1/page/n214

That's nothing specific to the SNES, that's actually just the NTSC spec for a scanline:

 

The idea of measuring how expensive PPU features are is a bit fallacious, because the whole point of the PPU is that it takes the burden of drawing graphics off the CPU -- the SNES doesn't draw graphics like a modern programmable GPU or a software-driven bitmap buffer system. Most PPU features are "free", aside from the overhead of DMA transfers or HDMA, and even then, those are going to highly depend on what you're trying to do. What's more useful is knowing how many cycles you have each scanline, which you can do some pretty simple math to get an approximation for:

262 scanlines times 60 frames per second = 15720 scanlines per second

SNES slowrom CPU speed is 2.68 MHz, or  2,680,000 cycles per second

2,680,000 cycles/sec ÷ 15720 scanlines/sec = ~170.48 cycles per scanline

SNES fastrom CPU speed is 3.58 MHz, or 3,580,000 cycles per second

3,580,000 cycles/sec ÷ 15720 scanlines/sec = ~227.74 cycles per scanline

Since the SNES CPU is changing clock speed on a per-cycle basis, that means you have somewhere between 170ish and 227ish clock cycles per scanline to work with. I usually use an estimate of about 200 for trying to figure out how much raster time something might take.

[turboxray]

2 hours ago, Kirk_Johnston said:

Here's the Direct Colour image from the article for anyone who can't be bothered clicking the link:

 

A simple but effective example image right there imo (even though it's literally only using 56 unique colours across the whole image), because it's showing

It's using 56 colors because it would look more like a frikkin rainbow if you push for more color with such a small palette. Aren't you an artist or something? Anyone who's done any sort of pixel artwork can tell you that. How can you not understand this.. and at the same time pretend to be soo proficient in graphics??

 

2 hours ago, Kirk_Johnston said:

an actually pretty nice direct colour picture (although trust me when I say you could draw way more impressive images on the direct colour layer, especially if you consider how to use far more colours and multiple palettes across the full image), and, as we all know, that's still in addition to the separate 120

 

I don't trust you. You know why? Because you can't even define "impressive". Look, here's your logic: "8bpp indexed color images from a 32k palette look impressive".. "better than anything PCE or MD can do"... then you turn around and say the same thing for images that have HALF the palette range of the PCE/MD.. and somehow they're equally as impressive? I'm sorry, but you don't get both and still superior to the PCE/MD. If 8bpp direct color mode is awesome and impressive, and then by the same logic PCE/MD have to be just as impressive (if not more so).

 

 You can't even image convert without rildens tool. You don't even know what bits and ranges of depth actually mean (apparently.. if you think 3:3:2 range is so godly haha). Is it because it's on the SNES? Is that why? Is that why it's the bewilderment of wonders? "Just imagine...".

 

2 hours ago, Kirk_Johnston said:

visible 15-bit CGRAM colours of BG2 and the additional again 120 visible 15-bit CGRAM colours for all the sprites (for a potential total of well over 2200 colours on screen there, before any colour math 

Come on. You have to be touched in the head if you don't get it by this point. It's not 2048 color mode. And it's definitely not before any color math, that's for sure haha. I honestly cannot understand how you haven't connected the dots yet. You're either a troll, or you're not even trying. It's one or the other.

 

2 hours ago, Kirk_Johnston said:

I like to think of the possibilities there. . . .

I didn't just think of the possibilities.. I actually added 3:3:2 mode (with offset bits) into my conversion app about an hour ago.

Here you go:

Left is direct 3:3:2 (with all offset bits set to help brighten in the image), right is you're own 8bpp indirect color image.

 

Let's take a closer look tho...

Oh yes... wow.. soo impressive. If you can't guess, top is direct color bottom is indexed color.

 

 Ohh by the way do you know how many colors are in the direct color 3:3:2 image? 42. 42. 42 colors. Bet you can't even guess why.

Edited December 29, 2023 by turboxray

[Austin]

3 hours ago, Kirk_Johnston said:

That's fugly as hell.

[KulorXL]

26 minutes ago, Austin said:

That's fugly as hell.

See, this is the ugly side-effect of Kirk console warring with other peoples' shit. I've seen similar comments pointed at my WIP GIFs that he's been sharing around which were not meant to be widely seen. That's a drawing by probably some kid who was just interested in some obscure SNES hardware feature, he doesn't deserve to get dragged for it. I agree that it doesn't at all prove what Kirk is trying to prove with it though.

[Austin]

1 hour ago, KulorXL said:

See, this is the ugly side-effect of Kirk console warring with other peoples' shit. I've seen similar comments pointed at my WIP GIFs that he's been sharing around which were not meant to be widely seen. That's a drawing by probably some kid who was just interested in some obscure SNES hardware feature, he doesn't deserve to get dragged for it. I agree that it doesn't at all prove what Kirk is trying to prove with it though.

Oh yeah, I totally get it. I don't mean to slight the original artist or anything. My blunt comments are typically responding to Kirk hyping up some oddball feature, expecting us to be impressed by whatever he mocks up, but the end result in the eyes of others is basically something like, "Cool, so you just confirmed the SNES can replicate what the Master System can do. Great." I appreciate enthusiasm for retro console development, but the way he goes about it doesn't seem particularly useful.

Edited December 29, 2023 by Austin

[WavyGravy]

Again, we have a problem in search of a solution. Kulor and turboxray are right, you could make a nicer looking image using Mode 1 or the 8bpp mode. I've brought it up a few times, but I'll say it again: Bahamut Lagoon regularly has thousands of colours onscreen, and it uses plain old Mode 1 and some damn good art to do it. The limitations on Direct Colour are pretty severe. Would it be a better use of time and resources to make a good DC image or a good Mode 1 image? Mode 1 will be a lot easier to create with less restrictions and caveats, and likely take less time and be easier to implement. An 8bpp still screen is even easier. The 32k colours in the SNES master palette are the crux of the machine's look. Colours onscreen aren't the end of the discussion, it's also about the subtlety of those colours, and that's a huge benefit that the SNES allowed artists to take advantage of.

Why did this feature rarely (never?) get used? Well, when most people design a game, they start with a concept, figure out what they need to convey it, and then evaluate the hardware they have available to them and use the features that will get them as close as possible to their idea while making the fewest compromises. I would like to see an example of something where Direct Colour is the least compromised way of doing something on the machine, but I've got a feeling that it's going to be something wildly niche and contrived. Giving up the huge master palette is a pretty grievous blow to take. Sometimes a feature just isn't all that useful in practice.

These discussions would be so much more interesting and (gasp!) perhaps even productive if the questions were more like, "I have an idea for a game where XYZ happens, what would be the best way to do that?" Like, look at how much more positive the discussion on the sound novel idea was, which is a pretty sad state of affairs since most of that discussion is just memes, but there's a lot less piling on what you presented because that's actually a reasonable idea and a good use of that capability. Most of that thread is people fucking around with each other, and there's not a lot of negativity around your actual idea, because you presented an actual idea that's workable and reasonable.

We've all watched the same RGME videos you have. We know all of this stuff, Kulor and turboxray know way more, and you're not presenting good use cases. If all your thread has is "HEY! The SNES can do this thing and I think it should be used more," then that's a thought, not the basis for a good thread.  You're doing lot of telling and very little showing when you're talking about how amazing these things are and the "potential" of them. Much like the Mode 0 stuff, I'm looking at what you're posting and thinking, "Oh, there's a good reason that nobody used this." You should follow Kulor's example from that saga, because despite you saying nobody was using it, he showed that there was somebody using it and it looked pretty neat.

And you're making poor Jeffy work so hard in the spin room. Give him a break by posting some original ideas with room for discussion.

[jeffythedragonslayer]

7 hours ago, KulorXL said:

That's nothing specific to the SNES, that's actually just the NTSC spec for a scanline:

 

The idea of measuring how expensive PPU features are is a bit fallacious, because the whole point of the PPU is that it takes the burden of drawing graphics off the CPU -- the SNES doesn't draw graphics like a modern programmable GPU or a software-driven bitmap buffer system. Most PPU features are "free", aside from the overhead of DMA transfers or HDMA, and even then, those are going to highly depend on what you're trying to do. What's more useful is knowing how many cycles you have each scanline, which you can do some pretty simple math to get an approximation for:

262 scanlines times 60 frames per second = 15720 scanlines per second

SNES slowrom CPU speed is 2.68 MHz, or  2,680,000 cycles per second

2,680,000 cycles/sec ÷ 15720 scanlines/sec = ~170.48 cycles per scanline

SNES fastrom CPU speed is 3.58 MHz, or 3,580,000 cycles per second

3,580,000 cycles/sec ÷ 15720 scanlines/sec = ~227.74 cycles per scanline

Since the SNES CPU is changing clock speed on a per-cycle basis, that means you have somewhere between 170ish and 227ish clock cycles per scanline to work with. I usually use an estimate of about 200 for trying to figure out how much raster time something might take.

That diagram is pain to read.  But the reason I want to know more about PPU timing is that its largely unexplored terroritory.

[Kirk_Johnston]

Good to see the discussion around the SNES' Direct Colour's full potential continuing while I was away, and to know that in general it is slowly seeping in, being debated more, considered further, and maybe even awakening some people to at least considering just a little more the possibilities there than they were previously. Because, when more people start even just asking questions, showing some form of curiosity and interest, when the genie is out of the bottle so to speak, it's a step in the right direction imo. For now, at least as a starting point, I'm happy with that. And who knows what the future will bring. 

Edited December 29, 2023 by Kirk_Johnston

[Wayler]

[Mittens0407]

18 minutes ago, Kirk_Johnston said:

Good to see the discussion around the SNES' Direct Colour potential continuing while I was away, and to know that in general it is slowly seeping in, being debated more, considered further, and maybe even awakening some people to at least considering just a little more the possibilities there than they were previously. Because, when more people start even just asking questions, showing some form of curiosity and interest, when the genie is out of the bottle so to speak, it's a step in the right direction imo. For now, at least as a starting point, I'm happy with that. And who knows what the future will bring. 

Kirk: Love it when people ask questions!

 

Also Kirk: *refuses to answer any questions he's been asked*

[Kirk_Johnston]

i also updated my SNES Background Modes page with some extra details on Direct Color for Modes 3, 4 and 7:

 

https://inceptionalnews.wordpress.com/2022/08/26/snes-background-modes/

 

I think the two resources together below have really given me the best understanding of Direct Colour to date:

The video above should start at the correct place.

 

https://sneslab.net/wiki/Direct_Color

 

So, major thanks and kudos to the people who made any resources that I've learned a lot from, such that I can even write anything about the stuff in my own blog post linked above.

Edited December 29, 2023 by Kirk_Johnston

[jeffythedragonslayer]

1 hour ago, Kirk_Johnston said:

i also updated my SNES Background Modes page with some extra details on Direct Color for Modes 3, 4 and 7:

 

https://inceptionalnews.wordpress.com/2022/08/26/snes-background-modes/

 

I think the two resources together below have really given me the best understanding of Direct Colour to date:

The video above should start at the correct place.

 

https://sneslab.net/wiki/Direct_Color

 

So, major thanks and kudos to the people who made any resources that I've learned a lot from, such that I can even write anything about the stuff in my own blog post linked above.

I have also added that video and smwc thread to the SnesLab page.

[Kirk_Johnston]

50 minutes ago, jeffythedragonslayer said:

I have also added that video and smwc thread to the SnesLab page.

Great.

[jeffythedragonslayer]

3 hours ago, Wayler said:

https://www.britannica.com/science/projection-psychology

[KulorXL]

4 hours ago, Kirk_Johnston said:

Good to see the discussion around the SNES' Direct Colour's full potential continuing

Seems more like a discussion of a lack of potential than anything, if you read the thread. You haven't drawn any cool art that would uniquely show what the mode can do like I suggested, so nobody is convinced yet. Like before, what you're doing is having the exact opposite effect compared to what you wanted.

[jeffythedragonslayer]

Ok @KulorXL now that I am back at my desktop, that NTSC timing GIF is rendering correctly.  Thanks, it's very helpful.

[Tanooki]

6 hours ago, Kirk_Johnston said:

Good to see the discussion around the SNES' Direct Colour's full potential continuing while I was away, and to know that in general it is slowly seeping in, being debated more, considered further, and maybe even awakening some people to at least considering just a little more the possibilities there than they were previously. Because, when more people start even just asking questions, showing some form of curiosity and interest, when the genie is out of the bottle so to speak, it's a step in the right direction imo. For now, at least as a starting point, I'm happy with that. And who knows what the future will bring. 

How high are you on your own farts?  This forum, this section, it is not your personal space that all centers around you as the nexus of information.  Of course people will talk and work stuff out without your presence.  Your presence isn't even required as you can't even give a smattering of actual intelligent debate on this since you seem to revolve your entire existence around game maker, photoshop, harassing actual coders to DO STUFF!!! for you, won't read, won't try, won't even put as much as a half assed effort in.  Seriously, just stop.  I used to enjoy talking with you, but even the quoting of obnoxious isn't even on par with your behavior at this rate.

[turboxray]

I went through a lot of my own stuff/pics and while it's not hand drawn art, it gave a pretty good test sample in the range and capability of direct color mode. Now, I want to pre-face this with that you CAN draw art with just a fixed 256 color "palette". Matter of fact, the lack of a precision in the blue element makes it less painful than say if it was only four shades of red or green (again, all things being relative here.. direct color vs 512 color PCE/MD.. which is where it fits into). I don't have any doubt that you could drawn something decent in it, for what it is. You could port some PCE/MD art over to it.

 

 The real question is; can you use direct color images that at least equal or approach the capability of the alternative hi-color mode; indexed mode images?

 

Before even attempting to answer that question, you need to ask yourself, "When would I be in a predicament where I really need to look at using direct color support".

 

 Here's the use case for that scenario: when you need ALL 8 sprite palettes (as in no high color mode images take away from the sprite palette CGRAM), you need ALL 8 4bpp palettes (as in no high color images take away from this layer's palette CGRAM), and finally you need some sort of hi "color-density" pixel support for a layer.

 

 For clarity, hi color-density means more colors in a packed area (like 8x8) than you can get with normal 4bpp layers (15 color max per 'block'). Hi color-density also meaning that you have more color fidelity freedom than "subpalette" type system; i.e. you've got 256 colors and you can use them anywhere you like on the said BG layer (4bpp and 2bpp layers don't have this type of freedom/support).

 

 So in our hypothetical scenario, we are using mode 3.. which is 1 4bpp layer (normal layer) and 1 8bpp layer ("hi color" layer). Even though that combination of layers can put an impossible strain on vram usage, lets ignore that for now and say we already have that figured out.

 

 If the statement above where I said all 8 BG palettes and all 8 sprite palettes are absolutely needed and cannot be shared with a hi-color layer... well, then we're done. You have no other choice but to use direct color mode. You have a direct (pun intended) use-case for this mode 3 combination.

 

 Given that we're stuck with this scenario, let's look at some the strengths and drawbacks, and ways to mitigate having been stuck with this option. First off, we know 3:3:2.. or at least I know from going through over 200 files with my app converting them to direct color mode, that direct color mode images are very rough in the color department for doing any sort of realistic art or high color converted art. So maybe you can relegate the 8bpp layer to the back and have the focus on the foreground layer (4bpp layer.. with ALL those 8 needed palettes.. surely they want to be seen!). That's one option. Using the "supplemental" bits from the tilemap for direct color mode, you have a brighter mode (all bits set) and a darker mode (all bits cleared).. so you have some control as to how pronounced the direct color image is; this control is actually kind of useful and it would have been better if there was a proper "dimming" mechanism.. but at least we got this as it's better than nothing. I would treat this brighter/darker setting for the entire image and not try to do it in sections (blocks, tiles, etc).. you'll get "clashing" artifacts otherwise - but if you have a flat/clean transition line you can make it work with both (i.e. mirror the tiles and create a water reflection that is slightly darker, erc). It's also quite possible that maybe the 8bpp layer is going to be use for a very specific translucency effect. It's a bit difficult to imagine where this would be a benefit over a 4bpp layer (given the vram cost between the two)... mostly because visual acuity beyond using a 4bpp for this effect seems to have a sharp fall in the results department (law of diminishing returns) - at least with the color math capabilities of the sPPU. But it's possible that you can find that edge-case scenario where it does work out and does give you more than a 4bpp option. Maybe on top of that you do slow-realtime pixel modifications on the 8bpp translucent layer for some mixed effect. Again, the above is based on the need to have all reserved palettes for BG and sprites and there's no compromising. That is thee use case for this. 

 

 

 So in the above scenario, I said no compromising on the palettes. But let's say that you convinced yourself that you could spare some CGRAM for an indexed image. Now, given that direct color pixels and indexed color pixels take up the same space in vram - we can then look at that in the perspective that 8bpp (regardless of the mode) is an expensive implemented when it comes to vram. Again, not going into picking 4bpp over 8bpp... let's just assume we have the need and that we figured out the vram issues. 

 

 Rather than thinking this as an all or nothing thing - you use DC and get 8 BG palettes, or you use IC and sacrifice all 8 palettes, we can look at this as a sliding scale or spectrum. For every BG palette, or sprite palette, that I decided to give up.. I can give that free space back to IC (indexed color). Here's an example; I've decided that I only need 6 palettes for the 4bpp BG layer and I only need 6 palettes for sprites. That leaves four 16 color entry palettes in the CGRAM block.

 

 Here's a like diagram to show what that looks like:

^ Here's a diagram showing all 8 BG palettes and all 8 Sprite palettes are reserved. Since IC pixels use colors 0 to 255, it uses the same CGRAM slots. But in the above example they're all be used.

^ And here's the example where I freed two slots from each group. The placing doesn't really matter - only that the slots are free and that the IC pixels use those free CGRAM slot areas.

 

Here's an example of a "151" color DC image (left) vs a 48 color IC image (right)

I know in the example above I reserved 64 color slots, but in this example I decided to use only 48.. to prove a point. For one, even though DC supports "256" colors.. the range in that fixed palette (regardless of the offset bits) is pretty small.. which translates into not have colors from the 256 selection that fits any "needs" for this image. This is pretty common. The only images I could convert that got the color count up in the 200's for DC, where images that basically looked like a rainbow (which is why I reference that from time to time). IMO, the IC 48 colors looks vastly superior to the DC 151 colors. And this isn't even a fair comparison because for the IC one.. I only used a very simple 'xor' pattern dither on the IC image. Had I used the same error-distribution dither on the IC image - it would be amazing.

 Just to note; I picked an image that looked pretty decent for DC conversion. I didn't pick the best, because those were rare.. and I didn't pick the worse because I'm trying to show objectively how they compare. But most images for DC fall below this example in image quality.

 

 So for the same vram space, I can get much better quality images with IC even with low color counts simply because the large 32k master palette that I pick those 48 or whatever colors from.. matters! I mean, you can throw around color counts like it's something to impressive people.. but the cold reality is that color counts by themselves don't give you the whole picture. And unlike direct color, with indexed color images I can modify the CGRAM entries on the fly to brighten, darken, tint, etc the image. You could do a slow-glow fade up and down.. partially, wholly, etc. Lot's of stuff you can do by direct manipulating the CGRAM entries for the IC colors. I can completely fade in and out the image as well! You cannot do this with DC, outside the coarse two options I spoke for DC images. IC gives you more abilities, beside just better color and detail, than DC. If all you cared about was color counts, you'd complete miss this.

 

 This is thinking outside the box; rather than shoe horning in DC just to put a check on a box, and/or forcing yourself only have that option.. think of ways not to be forced into using DC. If DC is a compromise, and it is, then look at making the compromise somewhere else (like I showed above) so that you can use IC. Because like I said, it gives you abilities that DC simply cannot. 

 

 Kulor, myself, and others have been and are the type of people that have looked into features of the SNES sPPU and tried to come up with unique ways to use them. This has been going on for decades. Kirk thinks this doesn't happen.. mostly because he pissed in all the pools and other devs don't want anything to do with him. But also, he wasn't around for the past decade or so. A lot of this stuff, experiments, figuring out use cases, etc - have been done in private. Sure, that probably upsets some people.. but that's just how it is. Not everyone is interested in writing up docs/tutorials/wikis simply because that's not the fun side of it. So it's kept local, to smaller groups. But make no mistake, people (retro devs) have been looking into this stuff for a long time, and long before Kirk came along and proclaimed himself official inspirer of the snes dev community. I also find that ironic, but a lot of effects go way deep on a technical level.. an area that Kirk has no experience or understanding. His stuff is very surface level.. anyone can watch videos. It seems Jeffy wants the snes dev community to be all inclusive.. including Kirk. It's that whole, "no child left behind" approach. (if you grew up in the US you'll get the reference).

 

 I honestly DO like discussions on things like this, etc. And I love it when I'm challenged on things/ideas/perspective - prove me wrong! This isn't a right or wrong thing, or thou art less knowledgeable or something. I'm motivated to speak factually on things and to give them context. Kirk isn't interested in a discussion. This thread isn't a discussion. And Jeffy seems to be the only one with a perky-gleeful mood in all of this. 

 

 

 

 

 That was a wall of text; I'm sure there will be typos. I'll try to catch them in a few edits.

 

Edit: Apparently I don't know left from right haha.

 

 

 

Edited December 29, 2023 by turboxray

[jeffythedragonslayer]

58 minutes ago, turboxray said:

Not everyone is interested in writing up docs/tutorials/wikis simply because that's not the fun side of it. So it's kept local, to smaller groups.

Yeah, because although that is better for preservation, it's a sure-fire way to get a lot of criticism from people who don't appreciate that people have different priorities and different learning styles.  If I had a dollar for every time I've already been accused of wasting my time trying to figure out some tiny detail...

Edited December 29, 2023 by jeffythedragonslayer

[Kirk_Johnston]

Interestingly, the rather cool demo below by lidnariq showing seven of the eight SNES' backgrounds modes on screen all at one time actually uses Direct Colour too "so that the demonstrations of modes 3 and 4 didn't have [to] share the same pastels I was using in the rest of the screen":

 

All SNES BG Modes.7z

 

Edit: By the way, not sure if it was due to a technical limitation or whatever, but it would have been kinda awesome if he'd also managed to squeeze a Mode 7 background in there at the bottom too for the complete set. Haha

Edited December 30, 2023 by Kirk_Johnston

[KulorXL]

5 hours ago, jeffythedragonslayer said:

If I had a dollar for every time I've already been accused of wasting my time trying to figure out some tiny detail...

Not trying to be rude or anything, but when I read this I kinda think it sounds like a "junior engineer mindset". I think when people are telling you something is a "waste of time", it's probably usually in the context that what you're looking into doesn't really matter in the grander scheme of trying to learn SNES coding, which is certainly where I'd categorize things like NTSC timings. Something you learn as you become a more experienced programmer in general is that you don't really need or even want to know every little detail on what something is doing, because a lot of it isn't really that important on the layer that you have to deal with in everyday coding. Ask me about exact SNES chip timings or the NTSC signal's color subcarrier or why they used a resistor with *exactly* that value in that spot on the board, and I don't know shit...but I'd never need to care about that stuff when making a game, it's just not useful information to burden myself with. I think people are telling you certain things are a "waste of time" in an effort to steer you more towards things that could help you learn coding more effectively, that's all.