Direct color vs "mega color", What he says about the difference?

Discussion of hardware and software development for Super NES and Super Famicom.

Moderator: Moderators

Forum rules
  • For making cartridges of your Super NES games, see Reproduction.
Post Reply
User avatar
Señor Ventura
Posts: 113
Joined: Sat Aug 20, 2016 3:58 am

Direct color vs "mega color", What he says about the difference?

Post by Señor Ventura » Thu Jul 16, 2020 2:37 am

Recently has been unleashed an "MSU type" card for megadrive, and some videos running on it. The author says that "mega color" has better display options, Do it this true?.

"The tricks are a bit similar: intensive usage of DMA and similar sync. The rest is different. "Direct color DMA" displays 35k "2x1" pixels and MegaColor displays 55k normal "1x1" pixels".
https://twitter.com/GamesUniq/status/12 ... 9706812416


What we have here?.



This is the video:
https://youtu.be/waGd-spd1Eg

User avatar
TmEE
Posts: 753
Joined: Wed Feb 13, 2008 9:10 am
Location: Estonia, Rapla city (50 and 60Hz compatible :P)
Contact:

Re: Direct color vs "mega color", What he says about the difference?

Post by TmEE » Thu Jul 16, 2020 5:01 am

This method is basically relying on ability to change most of the palette each line, by turning off rendering during offscreen parts in a way that results in just enough disruption to be able to show what is necessary. All sprites are lost, one BG layer won't work and most of the other BG layer is left. A fancy preprocessor that downconverts input data and generates the palettes for each line is the other major component.
Greatkreator on this forum is the guy who made this stuff.

User avatar
tokumaru
Posts: 11766
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: Direct color vs "mega color", What he says about the difference?

Post by tokumaru » Thu Jul 16, 2020 9:09 am

Looks better than SEGA CD FMV, but I still wouldn't want to watch long videos with this much banding.

User avatar
Nikku4211
Posts: 67
Joined: Sun Dec 15, 2019 1:28 pm
Location: Bronx, New York
Contact:

Re: Direct color vs "mega color", What he says about the difference?

Post by Nikku4211 » Thu Jul 16, 2020 12:26 pm

tokumaru wrote:
Thu Jul 16, 2020 9:09 am
Looks better than SEGA CD FMV, but I still wouldn't want to watch long videos with this much banding.
Dithering, GOOOOO!!!!!
I have an ASD, so empathy is not natural for me. If I hurt you, I apologise.

User avatar
Señor Ventura
Posts: 113
Joined: Sat Aug 20, 2016 3:58 am

Re: Direct color vs "mega color", What he says about the difference?

Post by Señor Ventura » Fri Jul 17, 2020 4:05 am

TmEE wrote:
Thu Jul 16, 2020 5:01 am
This method is basically relying on ability to change most of the palette each line, by turning off rendering during offscreen parts in a way that results in just enough disruption to be able to show what is necessary. All sprites are lost, one BG layer won't work and most of the other BG layer is left. A fancy preprocessor that downconverts input data and generates the palettes for each line is the other major component.
Greatkreator on this forum is the guy who made this stuff.
Snes can do hdma for each scanline to sum one color in every one of these, achieving more or less 400 different colors.

The question is about the differences... What is "2x1 pixels"?... and, What about 512 colors on screen with the genesis/megadrive?, snes can show 32768 colors on screen, but i don't think it can be due to bandwidth reasons.



32768 colors on screen:
https://www.youtube.com/watch?v=sV1w_H8WxUI

User avatar
TmEE
Posts: 753
Joined: Wed Feb 13, 2008 9:10 am
Location: Estonia, Rapla city (50 and 60Hz compatible :P)
Contact:

Re: Direct color vs "mega color", What he says about the difference?

Post by TmEE » Fri Jul 17, 2020 4:31 am

There's a method to display an arbitrary bitmap on MD in full 9bit RGB color by disabling rendering and doing a large DMA to first color of the palette, but since there's one access slot every 2 pixels you get double wide pixels and also 4x wide ones 5 times per line due to refresh slots using up one slot every 64 pixels. This is the "direct color" method, also known as CRAM bitmap and Fantom bitmap.

The "mega color" method won't allow arbitrary bitmap to be shown since it still relies on a normal tilemap to show everything, and is subject to 4x 15 color palette limitation, but the difference is than most of the colors in the palettes are changed every line according to needs of the frame being shown and it allows for reasonable color fidelity to be achieved. The method can work for any machine capable of changing substantial amount of their palette per line.

User avatar
Señor Ventura
Posts: 113
Joined: Sat Aug 20, 2016 3:58 am

Re: Direct color vs "mega color", What he says about the difference?

Post by Señor Ventura » Sat Jul 18, 2020 5:04 am

TmEE wrote:
Fri Jul 17, 2020 4:31 am
There's a method to display an arbitrary bitmap on MD in full 9bit RGB color by disabling rendering and doing a large DMA to first color of the palette, but since there's one access slot every 2 pixels you get double wide pixels and also 4x wide ones 5 times per line due to refresh slots using up one slot every 64 pixels. This is the "direct color" method, also known as CRAM bitmap and Fantom bitmap.

The "mega color" method won't allow arbitrary bitmap to be shown since it still relies on a normal tilemap to show everything, and is subject to 4x 15 color palette limitation, but the difference is than most of the colors in the palettes are changed every line according to needs of the frame being shown and it allows for reasonable color fidelity to be achieved. The method can work for any machine capable of changing substantial amount of their palette per line.
So, that thing about "55k normal 1x1 pixels" is not right?.

P.D: Having in mind that the 65816 is an "interrupt machine", could be possible at 3,58mhz to interrupt the scanline drawing many times in everyone of them to unlock thousands of colors?.

93143
Posts: 1194
Joined: Fri Jul 04, 2014 9:31 pm

Re: Direct color vs "mega color", What he says about the difference?

Post by 93143 » Sat Jul 18, 2020 2:59 pm

Señor Ventura wrote:
Sat Jul 18, 2020 5:04 am
So, that thing about "55k normal 1x1 pixels" is not right?.
It's right. Where did you get that idea?

They've trimmed (I'm guessing) 16 pixels off all four sides of the display, resulting in a 288x192 image in H40 mode. That's 55296 pixels. They can't use a completely arbitrary 9-bit RGB colour for every pixel like with Fantom Bitmap, but that has nothing to do with the resolution.

The SNES equivalent would be 224x192 in normal mode. It works at 30 fps without needing to write to VRAM between active scanlines (which is possible but disruptive), and I believe (don't quote me on this) that I've devised a way to write up to three 8-colour half-palettes per line in this context. This is probably not as many as the "mega color" technique manages, but the SNES has twice as many BG palettes available, and this extra colour reserve may help offset the slower update speed. I haven't tested this method, so don't celebrate yet...

(The SNES is capable of higher resolution than the Mega Drive. Unfortunately high-resolution mode (512-wide) on SNES does not speed up the PPU and DMA clocks proportionately like H40 mode (320-wide) does on Mega Drive, and there's still only 64 KB of VRAM, so 448x192 can't be done without tearing and would cap at 20 fps in any case, or 15 fps if you want lots of colour updates between lines.)
Having in mind that the 65816 is an "interrupt machine", could be possible at 3,58mhz to interrupt the scanline drawing many times in everyone of them to unlock thousands of colors?.
No. It's faster than the 68000 but nowhere near fast enough for that. Remember, the pixel clock is 5.37 MHz, and the PPU is drawing directly to the TV so you can't stop it in the middle of a line without a visible gap. To write a colour in CGRAM, either a) you have to be in HBlank, VBlank, or forced blank, or b) the colour being fetched right now for the pixel being drawn by the PPU has to be the colour you want to overwrite, because the PPU takes over the CGRAM address while rendering. Interrupts take several pixels just to save state and start the IRQ routine and several more to return, and there are no instructions that take fewer than three pixels to execute. An interrupt in the middle of a line, involving turning rendering off, writing to CGRAM and turning rendering back on, would show up as a horizontal black streak.

You can absolutely write to CGRAM between display lines. In fact, the first serious SNES program I wrote was a program to display a fullscreen image in 8bpp using all 8 HDMA channels to overwrite up to 8 colours during each HBlank, and I've gotten close to 600 colours in test images using this method. Others have gotten over a thousand colours, but the method they used didn't produce results as good-looking as mine - clearly both encoding methods are suboptimal, and there's an opportunity for anybody who can come up with a superior method...

There's also the fact that with a single-palette 4bpp image, it should be possible to overwrite the whole palette in one line without trimming the screen at all. This is basically equivalent to the DreamGrafix 3200-colour mode on the Apple IIGS - each line only gets 16 colours, but there's no carry-over between lines so each line can use a totally separate palette, and the whole picture can have thousands of colours.

...

Also, Fantom Bitmap (DMA direct colour) does work on the SNES, by exploiting the fact that the PPU controls the CGRAM address during active display. It's somewhat fiddly to get working because of DMA timing subtleties, particularly if you want straight columns, but you can have as many colours as there are pixels on the screen. The trouble is that since the DMA is 8-bit regardless of target (while on MD the DMA is only 8-bit when targeting VRAM and 16-bit otherwise), the pixels are 4x1 rather than 2x1, which is unfortunately on the far side of nice to look at...

Since the SNES version of Fantom Bitmap doesn't use forced blank, the other layers still work. As a result, it may be possible to use a similar technique to obtain a fullscreen 60 fps video mode using colour math to apply a full-resolution luminance mask. However, this has not yet been tried, and there would inevitably be both spatial and temporal compression artifacts. It remains to be seen how bad the artifacting would be...

Post Reply