Quantcast

Page 2 of 3 FirstFirst 123 LastLast
Results 16 to 30 of 34

Thread: Direct Color DMA video demos

  1. #16
    ESWAT Veteran Chilly Willy's Avatar
    Join Date
    Feb 2009
    Posts
    6,744
    Rep Power
    75

    Default

    Quote Originally Posted by Barone View Post
    So, uh, this "new" mode means that, with a Sega CD attached, the Genesis is actually capable of 512 on screen colors (with the resolution restrictions, of course)?
    You can use it with just a plain Genesis, too, it's just that the mode limits the free cpu time for the game since DMA halts the MD cpu. You also don't have much ram in the Genesis, so you'd have to keep the screen size small, like the main display area in Zero Tolerance.

    As an example, the screen size in the demo is 128x128, which consumes 161*128*2 bytes of ram. That's roughly 40KB of ram for the bitmap. You only have 64KB of ram in the Genesis for everything, so the bitmap (which isn't double buffered) would take much of the ram. It would also halt the 68000 for 128 lines of the display, or over half the frame.

    So using this mode with the SCD alliviates the worst problems - the word ram gives plenty of ram for the bitmap, the word ram is double buffered, and the SCD 68000 isn't halted by the mode... not the mention the SCD 68000 is almost twice as fast as the Genesis 68000. So this mode is more useful for SCD games, but COULD be used with Genesis games with the right design.

  2. #17
    Hard Road! ESWAT Veteran Barone's Avatar
    Join Date
    Aug 2010
    Location
    Brazil
    Posts
    6,977
    Rep Power
    148

    Default

    Thanks for the explanation, Chilly.
    This is a good use for the Sega CD's hardware IMO.

    With the Sega CD's extra RAM (I saw your lines about the Genesis side of things but I'm not sure what to conclude about the screen size using the Sega CD), how big the screen can get?

  3. #18
    ESWAT Veteran Chilly Willy's Avatar
    Join Date
    Feb 2009
    Posts
    6,744
    Rep Power
    75

    Default

    Given V28 mode as opposed to V30 (which is PAL only), you can do 160x224 in H40 mode and 128x224 in H32 mode. The width is wider in both modes, but all other pixels on the line are in the overscan region and not visible. However, by making your bitmap wider and/or taller, you can implement scrolling by changing the start address of the DMA. If you use the CD word ram in 1M mode (which gives two banks of 128KB of ram), you can go up to 198x330 in H40 mode, or 161x407 in H32 mode. Remember that only 160x224/128x224 will be visible, but you could scroll around in the larger bitmap area.

  4. #19
    Hero of Algol kool kitty89's Avatar
    Join Date
    Mar 2009
    Location
    San Jose, CA
    Age
    28
    Posts
    9,713
    Rep Power
    60

    Default

    Quote Originally Posted by Barone View Post
    With the Sega CD's extra RAM (I saw your lines about the Genesis side of things but I'm not sure what to conclude about the screen size using the Sega CD), how big the screen can get?
    It can be full screen, for NTSC at least (not sure what the line limit is for the PAL display). You could do 160x224 or 128x224 and fill the same space as typical MD games, just with pixels being 2x as wide as normal.



    Quote Originally Posted by Chilly Willy View Post
    Correct. It's a simple demo to show other devs how you can make a simple SCD game that uses the mode for bitmapped direct color graphics. Wolf3D is notorious for low color counts (but still more than you'd get with the paletted MD graphics without a lot of tricks).
    Plus it's a pretty basic conversion down to 9-bit RGB vs Wolf3D's own 18-bit 256 color palette. Games specifically optimized around the advantages and limitations of 9-bit RGB's 512 colors. Actually, since it's organized with R G and B elements aligned at 4-bit boundaries, that should also make direct color alpha blending a possibility as well. (still needing bit manipulation or look-up tables, but at least a lot easier/faster to do in software than 15-bit RGB or such)
    Plus, you might be able to employ the "unused" nybble for added pixel information as well.

    Overall though, there's still probably many situations where the approximated 12-bit colors using dithered full-res tile graphics as a pseudo-bitmap would be more useful too, especially cases where blended paired pixels to create a pseudo 8bpp paletted pseudo 12-bit color display would be preferable. (up to 136 colors per tile by blending 16 colors -or less if using 15 colors+transparent) Using h-scroll to blur things (for effective 30/25 Hz output) would make that more solid than composite video blur and work for both PAL and NTSC equally and in RGB or S-video.
    This sort of rendering would be about as fast as software rendering DMA color pixels for cases where you'd render 1 pixel at a time mostly, and potentially much faster for cases where you'd handle more than 1 pixel. (pseudo pixels being 8-bits wide, so 16-bit accesses could move things 2x as fast as dealing with 16-bit pixels)
    --This sort of pseudo colorspace rendering was also underutilized, and it's a shame the Sega CD ASIC can't render 8bpp for doing dithering like that. (dithered textures artifact horrible when scaled, so that's not a good option either)

    Well, I suppose there'd still be some cases where DMA color mode could actually be faster than moving 8-bit data around (pixel pairs) on actual tiles, mostly relating to max framerates (where rendering speed is not a bottleneck) and possible overhead from rendering pixels in cell order rather than linear bitmap order. (I don't think you'd want to use the ASIC's bitmap to tile conversion mode since that won't allow 1M bank word RAM and will also require rendering unpacked 16 color pixels -ASIC converts 8-bit pixels to 4-bit- rather than actually directly rendering 4-bit pixels as byte aligned pairs)

    One other advantage of DMA color mode would be the potential to do that sort of flickering on a full-screen basis without the issues of VRAM size and DMA bandwidth seen with actual tiles, though you'd either have to keep flipping word RAM each frame or you'd have to settle for not quite full screen to fit 2 frames in 128k (like 160x200). In this case, you'd get pseudo 12-bit direct color instead of 9-bit and 4,096 colors on screen at 30 Hz (or 25 Hz).
    However, this would take 2x the rendering bandwidth, so only really attractive in cases where that's not already a bottleneck. (or where reducing screen size or rendering speed to allow for it is preferable to using 9-bit color -or pseudo paletted 12-bit color via normal dithered/blended tiles)
    6 days older than SEGA Genesis
    -------------
    Quote Originally Posted by evilevoix View Post
    Dude it’s the bios that marries the 16 bit and the 8 bit that makes it 24 bit. If SNK released their double speed bios revision SNK would have had the world’s first 48 bit machine, IDK how you keep ignoring this.
    Quote Originally Posted by evilevoix View Post
    the PCE, that system has no extra silicone for music, how many resources are used to make music and it has less sprites than the MD on screen at once but a larger sprite area?

  5. #20
    ESWAT Veteran Chilly Willy's Avatar
    Join Date
    Feb 2009
    Posts
    6,744
    Rep Power
    75

    Default

    Quote Originally Posted by kool kitty89 View Post
    Plus it's a pretty basic conversion down to 9-bit RGB vs Wolf3D's own 18-bit 256 color palette. Games specifically optimized around the advantages and limitations of 9-bit RGB's 512 colors. Actually, since it's organized with R G and B elements aligned at 4-bit boundaries, that should also make direct color alpha blending a possibility as well. (still needing bit manipulation or look-up tables, but at least a lot easier/faster to do in software than 15-bit RGB or such)
    Plus, you might be able to employ the "unused" nybble for added pixel information as well.
    Yes, you can MAKE that "unused" nibble be useful if you want. Maybe a limited form of Z value for 3D. Maybe an alpha value as you mention. Maybe it could hold extra flags in the bits for things like collision detection or special object handling. Lots of things you can do with 4 (or 7 if you count the unused rgb bits) bits.

    Overall though, there's still probably many situations where the approximated 12-bit colors using dithered full-res tile graphics as a pseudo-bitmap would be more useful too, especially cases where blended paired pixels to create a pseudo 8bpp paletted pseudo 12-bit color display would be preferable. (up to 136 colors per tile by blending 16 colors -or less if using 15 colors+transparent) Using h-scroll to blur things (for effective 30/25 Hz output) would make that more solid than composite video blur and work for both PAL and NTSC equally and in RGB or S-video.
    This sort of rendering would be about as fast as software rendering DMA color pixels for cases where you'd render 1 pixel at a time mostly, and potentially much faster for cases where you'd handle more than 1 pixel. (pseudo pixels being 8-bits wide, so 16-bit accesses could move things 2x as fast as dealing with 16-bit pixels)
    --This sort of pseudo colorspace rendering was also underutilized, and it's a shame the Sega CD ASIC can't render 8bpp for doing dithering like that. (dithered textures artifact horrible when scaled, so that's not a good option either)

    Well, I suppose there'd still be some cases where DMA color mode could actually be faster than moving 8-bit data around (pixel pairs) on actual tiles, mostly relating to max framerates (where rendering speed is not a bottleneck) and possible overhead from rendering pixels in cell order rather than linear bitmap order. (I don't think you'd want to use the ASIC's bitmap to tile conversion mode since that won't allow 1M bank word RAM and will also require rendering unpacked 16 color pixels -ASIC converts 8-bit pixels to 4-bit- rather than actually directly rendering 4-bit pixels as byte aligned pairs)
    Definitely - pseudo-8-bit graphics will clearly be better for some things... where you have limited memory, or where bytes are better to deal with than words, or where having a palette is better than redrawing for changes in color. Direct Color DMA is merely one more mode the dev can consider when making a game.

    One other advantage of DMA color mode would be the potential to do that sort of flickering on a full-screen basis without the issues of VRAM size and DMA bandwidth seen with actual tiles, though you'd either have to keep flipping word RAM each frame or you'd have to settle for not quite full screen to fit 2 frames in 128k (like 160x200). In this case, you'd get pseudo 12-bit direct color instead of 9-bit and 4,096 colors on screen at 30 Hz (or 25 Hz).
    However, this would take 2x the rendering bandwidth, so only really attractive in cases where that's not already a bottleneck. (or where reducing screen size or rendering speed to allow for it is preferable to using 9-bit color -or pseudo paletted 12-bit color via normal dithered/blended tiles)
    I want to work on a video player demo that uses the "flicker" method of increasing the colors. Since video is never (for older systems in particular) faster than 30 Hz (NTSC) or 25 Hz (PAL), being able to show two frames in that time allows you to increase the color resolution by changing the two frames slightly and allowing the eye to blend them together. This could be very useful for FMV.

  6. #21
    Hero of Algol kool kitty89's Avatar
    Join Date
    Mar 2009
    Location
    San Jose, CA
    Age
    28
    Posts
    9,713
    Rep Power
    60

    Default

    Quote Originally Posted by Chilly Willy View Post
    Definitely - pseudo-8-bit graphics will clearly be better for some things... where you have limited memory, or where bytes are better to deal with than words, or where having a palette is better than redrawing for changes in color. Direct Color DMA is merely one more mode the dev can consider when making a game.
    Honestly, I wonder why that method wasn't used on the MD at all . . . similar dithering was used (relying on composite video blur), and Mortal Kombat's FMV did v-blur (oddly enough), but no cases using h-scroll blur. -Dithering is a lot more obvious than the DMA color trick and that flicker effect was already in use on some home computer demos. (usually full-frame stuff, but the blending aspect is similar . . . it's actually more straightforward if you think about it)

    That's probably the better option for many 256 color PC games that would have worked reasonably well via software rendering, not to mention some FMV formats that could benefit from that. (including RLE based formats, which normally wouldn't cater to dithering)

    And again, it's also a shame the ASIC can't render on bytes for paired pixels . . . or even a little more to flip order of pixel pairs each raster line if checkerboard dithering is preferred. (ie for full res non-blurred stuff) Support for dithered 1/2 transparent meshes could work the same way.

    I want to work on a video player demo that uses the "flicker" method of increasing the colors. Since video is never (for older systems in particular) faster than 30 Hz (NTSC) or 25 Hz (PAL), being able to show two frames in that time allows you to increase the color resolution by changing the two frames slightly and allowing the eye to blend them together. This could be very useful for FMV.
    For a simple demo you could probably work around using 8-bit paletted uncompressed frames and have the 68k do conversion via look-up table mapping to appropriate values for the 2 16-bit (9-bit unpacked) frames.
    6 days older than SEGA Genesis
    -------------
    Quote Originally Posted by evilevoix View Post
    Dude it’s the bios that marries the 16 bit and the 8 bit that makes it 24 bit. If SNK released their double speed bios revision SNK would have had the world’s first 48 bit machine, IDK how you keep ignoring this.
    Quote Originally Posted by evilevoix View Post
    the PCE, that system has no extra silicone for music, how many resources are used to make music and it has less sprites than the MD on screen at once but a larger sprite area?

  7. #22
    Mastering your Systems Shining Hero TmEE's Avatar
    Join Date
    Oct 2007
    Location
    Estonia, Rapla City
    Age
    27
    Posts
    10,003
    Rep Power
    105

    Default

    Dithering looks like shit in PAL land, and guess where Probe who made the MK1 and 2 on MD is coming from. All you get is funky discoloration at color dependent intervals.
    Death To MP3, :3
    Mida sa loed ? Nagunii aru ei saa "Gnirts test is a shit" New and growing website of total jawusumness !
    If any of my images in my posts no longer work you can find them in "FileDen Dump" on my site ^

  8. #23
    Hero of Algol kool kitty89's Avatar
    Join Date
    Mar 2009
    Location
    San Jose, CA
    Age
    28
    Posts
    9,713
    Rep Power
    60

    Default

    Quote Originally Posted by TmEE View Post
    Dithering looks like shit in PAL land, and guess where Probe who made the MK1 and 2 on MD is coming from. All you get is funky discoloration at color dependent intervals.
    It looks worse than RGB? (tasteful use of checkerboard dithering and error diffused dithering looks reasonable in RGB IMO)
    From the screenshots you showed me before, it looks like there's less artifacts than NTSC (ie the rainbow chroma moire issue), and I'd assume H32 artifacts less than H40 too. (dither is almost as obvious in H32 NTSC as RGB . . . and there's very little chroma artifacting)

    In any case, that sort of inconsistent artifacting should have been smoothed out by the h-scroll h-blur for the cases where that sort of dither and blending is attractive. (ie game where effectively lower horizontal res and 25/30 FPS or less is attractive -ie certain ASIC/software rendered games and FMV)
    It would work best in RGB due to lack of chroma artifacts (just pure flicker blending), and it would allow solid blending in H32 in general. (where dither is pretty much always visible, even in NTSC on a KA2195D)
    6 days older than SEGA Genesis
    -------------
    Quote Originally Posted by evilevoix View Post
    Dude it’s the bios that marries the 16 bit and the 8 bit that makes it 24 bit. If SNK released their double speed bios revision SNK would have had the world’s first 48 bit machine, IDK how you keep ignoring this.
    Quote Originally Posted by evilevoix View Post
    the PCE, that system has no extra silicone for music, how many resources are used to make music and it has less sprites than the MD on screen at once but a larger sprite area?

  9. #24
    Mastering your Systems Shining Hero TmEE's Avatar
    Join Date
    Oct 2007
    Location
    Estonia, Rapla City
    Age
    27
    Posts
    10,003
    Rep Power
    105

    Default

    I talk about composhit and RF, that is what everyone used except French, they could not :P
    I'll have to take some photos of the nice color artifacts sometime.
    Death To MP3, :3
    Mida sa loed ? Nagunii aru ei saa "Gnirts test is a shit" New and growing website of total jawusumness !
    If any of my images in my posts no longer work you can find them in "FileDen Dump" on my site ^

  10. #25
    Outrunner Stef's Avatar
    Join Date
    Aug 2011
    Location
    France
    Posts
    602
    Rep Power
    25

    Default

    Quote Originally Posted by TmEE View Post
    I talk about composhit and RF, that is what everyone used except French, they could not :P
    We actually can... but we don't

  11. #26
    Mastering your Systems Shining Hero TmEE's Avatar
    Join Date
    Oct 2007
    Location
    Estonia, Rapla City
    Age
    27
    Posts
    10,003
    Rep Power
    105

    Default

    You had to get another cable for that... MD came with SCART over there...? At least all manuals and stuff suggest so.
    Death To MP3, :3
    Mida sa loed ? Nagunii aru ei saa "Gnirts test is a shit" New and growing website of total jawusumness !
    If any of my images in my posts no longer work you can find them in "FileDen Dump" on my site ^

  12. #27
    Outrunner Stef's Avatar
    Join Date
    Aug 2011
    Location
    France
    Posts
    602
    Rep Power
    25

    Default

    Ah yeah you speak about the case of Sega system, indeed they all come with true RGB scart but later Sony and Nintendo sold their system with composhit scart cable :-/
    Scart contains composite, s-video and rgb connexion... You can connect whatever you want in, of course composite is the less expensive solution with the worst quality.

  13. #28
    Hero of Algol kool kitty89's Avatar
    Join Date
    Mar 2009
    Location
    San Jose, CA
    Age
    28
    Posts
    9,713
    Rep Power
    60

    Default

    Quote Originally Posted by TmEE View Post
    I talk about composhit and RF, that is what everyone used except French, they could not :P
    I'll have to take some photos of the nice color artifacts sometime.
    Doesn't PAL also have the color phase artifacting in the vertical direction (leading to horizontal bars on some old/cheap TVs without proper filtering and 1/2 vertical chroma resolution for those with filtering). I forget the specific term that refers to this, but it's the same thing that NTSC achieves via manual hue tuning.

    It's a separate issue from the colorburst frequency . . . or the colorspace used. (YIQ vs YUV)

    On a side-note, that quirk of PAL video allows for some interesting vertical dithering effects . . . that only work in PAL.
    6 days older than SEGA Genesis
    -------------
    Quote Originally Posted by evilevoix View Post
    Dude it’s the bios that marries the 16 bit and the 8 bit that makes it 24 bit. If SNK released their double speed bios revision SNK would have had the world’s first 48 bit machine, IDK how you keep ignoring this.
    Quote Originally Posted by evilevoix View Post
    the PCE, that system has no extra silicone for music, how many resources are used to make music and it has less sprites than the MD on screen at once but a larger sprite area?

  14. #29
    Mastering your Systems Shining Hero TmEE's Avatar
    Join Date
    Oct 2007
    Location
    Estonia, Rapla City
    Age
    27
    Posts
    10,003
    Rep Power
    105

    Default

    You can see some extremely faint horizontal lines on super old TVs similiar to "scanlines" but that is about it. No funky color bleeding or blending.

    Perfect blend : http://www.tmeeco.eu/BitShit/DukeNTSC.jpg
    Near no blend : http://www.tmeeco.eu/BitShit/DukePAL.jpg <- Looks like NTSC S-video :P
    No blending : http://www.tmeeco.eu/BitShit/DukeRGB.jpg

    These all came from PAL and NTSC machines with CXA1645. My 1145 machines behaved similar but with massive rainbowing...
    Last edited by TmEE; 03-01-2013 at 03:02 AM.
    Death To MP3, :3
    Mida sa loed ? Nagunii aru ei saa "Gnirts test is a shit" New and growing website of total jawusumness !
    If any of my images in my posts no longer work you can find them in "FileDen Dump" on my site ^

  15. #30
    Hero of Algol kool kitty89's Avatar
    Join Date
    Mar 2009
    Location
    San Jose, CA
    Age
    28
    Posts
    9,713
    Rep Power
    60

    Default

    OK, so that's about what I'd originally thought.

    This makes the h-scroll blur technique for blending 1/2 res pseudo 8-bit pixels even more useful for PAL than NTSC . . . though the rainbow moire artifacts would still be an issue with doing that with complete consistency. (it'd be interesting to see how 30 Hz scroll/blend/flicker effects the rainbow patterns -ie will it look like odd shimmering like normal horizontal scrolling on such artifacts, or will it be different since it's a matter of rapid shifting one pixel left or right each frame)
    Plus it works for H32, which doesn't blend well even in NTSC.

    Again, this obviously won't be useful for typical games, but it is useful for cases where you'd want that sort of pseudo colorspace for software rendering (including FMV), or even for static splash screens.

    It technically isn't limited to strict 1/2 resolution double width pixels, but you could use it to blend checkerboard dithered "full" res images (be it framebuffer rendered stuff -including Virtua Racing- or FMV, etc). As such, you'd blurry "filtered" looking video with greater detail in some areas than pure 1/2 res stuff could do. (pure half res is easier to deal with for CPU rendering, since it's working on byte boundaries)
    This full-res checkerboard dithered technique is the one Tomaitheous suggested using specifically, initially on the context of Huvideo formats for PC Engine FMV. (specifically posterizing video frames down to 12-bit RGB and then checkerboard dithering to paletted 16 color 9-bit RGB)

    And, on a separate note, that sort of image conversion is probably a better compromise than most FMV on the Sega CD. You've got a fair amount of super posterized 16 color stuff, a few examples of posterized dual-layer (31 color tile) stuff, and a ton of heavily dithered stuff either trying to approximate much higher color depth (most cinepak style stuff) or apparently using posterized 15-bit RGB dithered down to paletted 9-bit in the case of early Segafilm formats usually used for Digital Pictures games. (it blends completely with a single pass of H-blur and v-blur to 15-bit color)
    There's a handful of games that actually opt to go with lots of checkerboard dither but lock the threshold there. Keio Flying Squadron comes to mind for this (actually dual-layer in that case with 31 colors per tile), but AFIK there's no live action stuff showing that off.

    If you think about it more, it's actually weird that that sort of image conversion wasn't more common. It's a reasonable compromise between super posterized 16 color stuff and much coarser dithering, while also making compression a lot easier for the most part. (larger areas of posterization making many compression schemes more practical, from Sega's "Cinepak" vector quantization format to similar pixel block/tile quantization formats, to LZ style lossless schemes, to RLE based formats -in the latter case, namely if runs of paired pixels are encoded, since doing RLE on normal 4-bit pixel data would be terrible with heavy checkerboard dithering -more complex dither patterns wouldn't work with RLE like that though)
    6 days older than SEGA Genesis
    -------------
    Quote Originally Posted by evilevoix View Post
    Dude it’s the bios that marries the 16 bit and the 8 bit that makes it 24 bit. If SNK released their double speed bios revision SNK would have had the world’s first 48 bit machine, IDK how you keep ignoring this.
    Quote Originally Posted by evilevoix View Post
    the PCE, that system has no extra silicone for music, how many resources are used to make music and it has less sprites than the MD on screen at once but a larger sprite area?

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •