Direct Color Demo using DMA

Announce (tech) demos or games releases

Moderator: Mask of Destiny

Stef
Very interested
Posts: 3131
Joined: Thu Nov 30, 2006 9:46 pm
Location: France - Sevres
Contact:

Post by Stef » Mon Jul 23, 2012 10:52 am

Oerg866 wrote:
Stef wrote:Neat ! As you said i really wonder why this had never been used for Sega CD FMV, maybe simply because no one though about it :p
The sub CPU could decompress and prepare the 192x224 9 bits (word) buffer then send it to main CPU in word ram at VBlank time.
Also we can use border to extends the vertical resolution, i don't remember exactly how many scanlines can be colored by background color but i think it's more than 224...
It's *exactly* 224 on PAL IIRC
I was speaking about top and bottom border lines, as we just use the background color with blanked state, we could normally use more scanlines than 224 (which is the number of *actives* scanlines for NTSC mode).
As TmEE said we could do 240 in 60 Hz and 288 in 50 Hz, but i'm not sure that is a nice idea to spent extra vblank lines for more verticals lines when the horizontal resolution is limited to 160 ;)

TmEE co.(TM)
Very interested
Posts: 2440
Joined: Tue Dec 05, 2006 1:37 pm
Location: Estonia, Rapla City
Contact:

Post by TmEE co.(TM) » Mon Jul 23, 2012 11:10 am

There is still 22 (in 60Hz) and 25 (50Hz) lines left, and you can do your controller reads and stuff during those.
Mida sa loed ? Nagunii aru ei saa ;)
http://www.tmeeco.eu
Files of all broken links and images of mine are found here : http://www.tmeeco.eu/FileDen

bgvanbur
Interested
Posts: 46
Joined: Fri Jun 22, 2012 11:13 pm

Post by bgvanbur » Mon Jul 23, 2012 12:37 pm

I am doubtful this would be that great for FMV. The biggest factor in Sega CD FMV is the 1x CD data speed. By going from 4 bits (single palette) or 6 bits (four palettes) to 9 bits, it makes the pixel data much larger. Larger pixel data means you need to sacrifice something else to stay within the 1x CD data speed (such as smaller framerate, smaller video size, or lower quality audio rate).

That isn't to say it wouldn't be good for certain videos though.

Stef
Very interested
Posts: 3131
Joined: Thu Nov 30, 2006 9:46 pm
Location: France - Sevres
Contact:

Post by Stef » Mon Jul 23, 2012 1:36 pm

The idea is to be able to display 160x224 direct color (9 bits) image.
That opens doors to new compression algo which are not limited with the 4x16 colors palette and 8x8 pixels tile :)

Chilly Willy
Very interested
Posts: 2984
Joined: Fri Aug 17, 2007 9:33 pm

Post by Chilly Willy » Mon Jul 23, 2012 3:41 pm

Stef wrote:The idea is to be able to display 160x224 direct color (9 bits) image.
That opens doors to new compression algo which are not limited with the 4x16 colors palette and 8x8 pixels tile :)
Exactly. It's not a magic fix as various folks have mentioned problems... like the CD being 1X or the need to watch for posterization on 9 bits, but it should be more flexible and it gives as much color as is possible without counting hilite/shadow.

If you look at video compression schemes like RoQ that target low end systems with direct color, it stores the codebook as YUV data: each entry has four Y, one U, and one V, or six bytes per entry. Switching that into values this mode can use without processing (because YUV->RGB is expensive), you would have four BGR values, or eight bytes per entry. So there is some increase in storage size, but it's not that much (6 to 8 ). You COULD store the values as 12 bits each since that fits the BGR color value the MD uses, and it goes back to 6 bytes per entry with only a little time needed to decode the color values. RoQ is probably a good format to try on this mode for FMV. It's like direct color cinepak, but better.

Oerg866
Very interested
Posts: 211
Joined: Sat Apr 19, 2008 10:58 am
Location: Frankfurt, Germany
Contact:

Post by Oerg866 » Mon Jul 23, 2012 4:43 pm

I like the idea of using it on the MD much more rewarding than on the Sega CD tbh... sure it seems predestined for it, but exploiting such things on the original system is where the fun is ;)

djcouchycouch
Very interested
Posts: 710
Joined: Sat Feb 18, 2012 2:44 am

Post by djcouchycouch » Mon Jul 23, 2012 5:02 pm

Any idea if this trick would work across all hardware models?

Chilly Willy
Very interested
Posts: 2984
Joined: Fri Aug 17, 2007 9:33 pm

Post by Chilly Willy » Mon Jul 23, 2012 5:05 pm

djcouchycouch wrote:Any idea if this trick would work across all hardware models?
I've tried it on (all NTSC) a Model 2, CDX, and a Nomad. If someone else can report on Model 1 and PAL, I'd say it's universal. 8)

TmEE co.(TM)
Very interested
Posts: 2440
Joined: Tue Dec 05, 2006 1:37 pm
Location: Estonia, Rapla City
Contact:

Post by TmEE co.(TM) » Mon Jul 23, 2012 5:27 pm

It works fine in 50Hz :P
Mida sa loed ? Nagunii aru ei saa ;)
http://www.tmeeco.eu
Files of all broken links and images of mine are found here : http://www.tmeeco.eu/FileDen

Stef
Very interested
Posts: 3131
Joined: Thu Nov 30, 2006 9:46 pm
Location: France - Sevres
Contact:

Post by Stef » Mon Jul 23, 2012 5:36 pm

Tested on a Japanese model 1, worked perfectly.

Chilly Willy
Very interested
Posts: 2984
Joined: Fri Aug 17, 2007 9:33 pm

Post by Chilly Willy » Mon Jul 23, 2012 5:40 pm

It doesn't do anything illegal or "tricky" other than maybe how it times when to start the dma, so I'd expect it to work on anything that's based on "real" MD hardware.

sega16
Very interested
Posts: 251
Joined: Sat Jan 29, 2011 3:16 pm
Location: U.S.A.

Post by sega16 » Mon Jul 23, 2012 5:46 pm

Chilly Willy wrote:the need to watch for posterization on 9 bits
If you need dithering for the 9bit conversion you could use the Free Photoshop-compatible (meaning it runs on anything that takes the format e.g. gimp inview and adobe Photoshop jasc and more) plugin called ximagic http://www.ximagic.com/q_index.html
Just click on fixed palette and 9-bit just keep in mind that it uses rgb values in steps of 32 but the genesis uses color values in steps of 36 the difference should not be too huge but at least you use a few different dither algorithms to see which one is best. It is also good for 16 color reduction I get better results than the built in image editor algorithms.
I am hoping to write a more proper converter for 9bit genesis colors but until then I use ximagic quantizer. I hope this helps the quality
Also for an FMV player how about 332 rgb that would be displayable with direct color and would only take one byte vs two bytes but at the cost of one 1 of blue but it is still better than most of the stuff we saw on the sega cd.

Chilly Willy
Very interested
Posts: 2984
Joined: Fri Aug 17, 2007 9:33 pm

Post by Chilly Willy » Mon Jul 23, 2012 6:28 pm

sega16 wrote:
Chilly Willy wrote:the need to watch for posterization on 9 bits
If you need dithering for the 9bit conversion you could use the Free Photoshop-compatible (meaning it runs on anything that takes the format e.g. gimp inview and adobe Photoshop jasc and more) plugin called ximagic http://www.ximagic.com/q_index.html
Just click on fixed palette and 9-bit just keep in mind that it uses rgb values in steps of 32 but the genesis uses color values in steps of 36 the difference should not be too huge but at least you use a few different dither algorithms to see which one is best. It is also good for 16 color reduction I get better results than the built in image editor algorithms.
I am hoping to write a more proper converter for 9bit genesis colors but until then I use ximagic quantizer. I hope this helps the quality
Nifty! I'll give that a try.
Also for an FMV player how about 332 rgb that would be displayable with direct color and would only take one byte vs two bytes but at the cost of one 1 of blue but it is still better than most of the stuff we saw on the sega cd.
That would be interesting to try. A lookup table can be used to convert that into a BGR444 value rather quickly. That would only use 512 bytes of memory.

Oerg866
Very interested
Posts: 211
Joined: Sat Apr 19, 2008 10:58 am
Location: Frankfurt, Germany
Contact:

Post by Oerg866 » Mon Jul 23, 2012 6:48 pm

Let me get this straight, I posted the source to my implementation only to have some person reuse the code even if the readme kinda forbids it and in turn bash my proof of concept demo and accept 2 pages of praise in return...?

nice going, spritesmind

I know, I might sound like being an asshole, but come on at least pretend that you care.

And no, I'm not really mad, I'm just sad :( I wasn't gonna say anything about it but seeing this thread explode like that... makes me sad. Meh, I guess I learned my lesson to keep things to me from now on.

Chilly Willy
Very interested
Posts: 2984
Joined: Fri Aug 17, 2007 9:33 pm

Post by Chilly Willy » Mon Jul 23, 2012 7:51 pm

First, the only thing from your demo is the loop that sets up the dma, and even that had to be rewritten for GAS syntax. Second, from what's been said and the comments, this is about the only way to get the timing, which means that whole loop is a FUNCTIONAL dependency, and thus not eligible for copyright in any case. Third, the only negative thing I had to say about the original demo was concerning the choice of image... and EVERYONE agrees that was a bad choice of image. Fourth, the praise is for the MODE, not me. Finally, you didn't originate the mode - from your own words, you merely fixed someone else's code.

SHEESH! You need to grow a thicker skin if this thread bothers you in the least.

Post Reply