My first demo: a 64 color image

[Brunni]

Hello,
I know this demo is probably something you have already seen 10 times or more, but I still wanted to post it ^^
That's my first program ever for genesis, I wanted to try using the wonderful devkit from the no less wonderful Stef
Download: http://brunni.dev-fr.org/dl/smd/Test01.rar

The bottom tiles being null is something strange, I haven't yet figured out why.
Image taken from DigitalBlasphemy.

[Fonzie]

Hi brunni
No, its the first time I see a demo playing with flicker, maybe its the first one for md
It is always very exciting to see megadrive demos around colors and sound (lot of challenges there)!!!

You use flicker to increase the color precision (so you can do #111 dark gray flickering between #000 and #222), right?
If so, it might work even better using megadrive interlaced mode (so you can flick even and odd lines in interlace) !!!


Its really nice, I've been playing a lot with image conversion for a FMV player... Converting a pic to 4 palettes + shadow (8 palettes total) reducing the blocky effect to the max)

The best I could get is that :


This is done using neuquant to generate palettes (3d color reduction) and a floyd dithering... I couldn't do better :/
I really recommend those algorithms... Neuquant smell really superior to the other algorithms around, can almost replace the human to choose colors! (was for FMV, I can't choose colors for each frame, haha!)

Your flickering gave me some ideas ^^...

Good luck man!

[Brunni]

Thank you for your answer
Neuquant... interesting
I've been searching for software to convert a true color image to a set of palettes (here: 4), each tile only being able to use one palette, but found none. So I wrote mine, it was very hard and certainly doesn't give an optimal result I quickly looked at Neuquant but I can't find whether it does that or not?
I didn't include dithering, because colors that are found in the resulting palettes will most likely always differ from the colors of the tiles assigned to them, as it's a compromise (find the best colors that will make most tiles happy, so they are an "average"). In this case there wouldn't be any "plain" non-dithered surface.
Anyway I don't think that it would really be needed for a FMV. Sometimes converting to a plain 46-color image (instead of 16x3) gives even better results than 16x4.
What method are you using? If my calculs are right, using your current resolution you do have enough memory to use the A plane for a 16 color bitmap, the B plane for another overlayed 15 color bitmap and sprites for another 15 color bitmap, giving you a full 46 color bitmap, which is quite good for FMV But the former method (16x4) is a lot better in terms of bandwidth.

You use flicker to increase the color precision (so you can do #111 dark gray flickering between #000 and #222), right?
If so, it might work even better using megadrive interlaced mode (so you can flick even and odd lines in interlace) !!!

Yes, you can do that, but it's not easy (in terms of processor of course ). If you make sure your palette colors never exceed #eee you can simply add #111 to each color every odd frame and use the normal colors in even frames.
Interlacing is probably a good idea, I hope the DMA is fast enough to copy a new palette each line, but I kinda doubt it (I don't have a flash cardridge Genesis so I will not be able to try this).

Its really nice, I've been playing a lot with image conversion for a FMV player... Converting a pic to 4 palettes + shadow (8 palettes total) reducing the blocky effect to the max)

I don't know how to use shadow but it seems interesting.

[Fonzie]

Yeah, I started making my own algorithms too... But I got ashamed when I saw neuquant results ^^.

Neuquant but I can't find whether it does that or not?

My trick was to generate one palette out of the full picture, and the three other ones generated from part of the picture only.

(0 = not scanned for colors, 1 = scanned for colors)

1111
1111 : pal0

1110
1000 : pal1

0011
0011 : pal2

0001
1110 : pal3

For each neuquant shot, I extract +-20 colors... Then, after the megadrive color reduction, only 14-15 colors remain (after having removed the clones)...

Scanning the picture for colors like that have the fallowing advantages :
- The main colors are present in the 4 palettes (the blocky effect is reduced).
The disadvantages :
- It is not very clever to do this, especially for a moving footage (FMV)...

you do have enough memory to use the A plane for a 16 color bitmap, the B plane for another overlayed 15 color bitmap

Yeah, sure... however, the CDROM bandwidth is 150KB/second... And the megacd's flipflop ram is 128KB only (so at 10 fps, that's 12,8KB per frame, +-320 tiles, need to use a lot more tricks to increase screen size! ^^).

Anyway I don't think that it would really be needed for a FMV. Sometimes converting to a plain 46-color image (instead of 16x3) gives even better results than 16x4.

I don't get what you mean

Interlacing is probably a good idea, I hope the DMA is fast enough to copy a new palette each line, but I kinda doubt it (I don't have a flash cardridge Genesis so I will not be able to try this).

Ho, don't worry, in Interlace mode, the VDP outputs to the TV even lines (first frame), then odd lines (next frame)... You have all the time to DMA your new colors during VBLANK (well, I hope i'm right)...

I think you can DMA 96-128 tiles per VBLANK... that's 4KB of data

I don't know how to use shadow Sad but it seems interesting.

Haha, you may learn about all the tiles/sprites priorities before... then shadow is for some people the "cherry on the cake"... or for some others "le cheveu sur la soupe" HAHAHA!

Good luck!

[tomaitheous]

Brunni, are you using a single BG plane and just 4 palettes for you image conversion? Or are you using two BG layers and one sprite layer?

Anyway, if you're going to alternate between to colors it might be a better idea to not use solid colors/areas. If you alternate between to dithered patterns, the human eye doesn't pick up on it as much. Here's a demo from a system that uses 16 colors onscreen with a palette of 64 fixed colors - http://www.youtube.com/watch?v=wL6g7Avb ... re=related.



If you're using a single plane for the image, there's another way to convert a scanline bitmap format to a tile/tilemap/palette system. Here's how it works:

If you set the display to 32H mode, you can get 4 individual tilemaps for each 256x224 screen. If you change the screen position to one of 4 tilemaps sections every 2 scanlines, you can effectively have a 8x2 tile display.

This means every two rows of 8 pixels in a tile can access a different palette. This also helps when you have a tile that contains more than 16 colors. If you use two BG planes on the same tile set, you can get a 8x1 tile setup. Using the 8x2 for one plane setup is great for FMV too, since the bandwidth is also smaller(for VDC and CDROM xfer) than using multiple planes.

You'll have to alter you conversion program of course, to handle the tiles as 8x2 and such.

Like you guys, I have an bitmap to tile conversion app too. Writing the palette sort logic was a real pain in the ass. I plan to re-write the app from scratch soon. Were putting out an old school demo for another system for this coming up summer

[Brunni]

Wow, impressive video!
I'm not sure I understood your explanation, but my lack of knowledge about the MD hardware combined with my rather bad english is probably the reason
I'm using a single plane (B) and 4 palettes, the palette is selected individually for each tile. The plane A is used for text and sprites are not used at all.
The advantage of this method is that less memory is needed; you can display a full screen image with 40x28 tiles (a bit more than half the VRAM). And if you only use 3 palettes, you can even do a game over that image. And it wouldn't look that bad:


The other method I was talking about (I did not tested it) means simulating a full 46 color bitmap by overlaying both planes and sprites.
For a pixel of color:
- 0 .. 15: write the value on PLANE B. Value on PLANE A and SPRITES is 0 (transparent).
- 16 .. 30: write the value on plane A. Value on plane B and sprites is 0.
- 31 .. 46: write the value on sprites. Values on plane A and B are both 0.
The advantage of the second method is that we can use ALL 46 colors ANYWHERE on the screen, while with the first method we must always keep some colors that are used on a lot of places in all the palettes, and if in a tile we need a color that is in another palette we must include it in the current palette or decide whether it's better to use another one.
So with a full 46-color bitmap you'll be able to get much better results than with 3 palettes of 16 (method #1), as you will not waste any color and have no "blocky effect". It will be particularily better when it comes to dithering, as finding 46 "good" colors for the whole image is quite easy, you just have to dither to create intermediate colors then
The problem is that with the second method you would need 3360 tiles for a fullscreen image, and that's not possible. You would have to revert to a resolution like 224x168, 240x150 or 256x144 at best

I don't know how to use shadow Sad but it seems interesting.

Haha, you may learn about all the tiles/sprites priorities before... then shadow is for some people the "cherry on the cake"... or for some others "le cheveu sur la soupe" HAHAHA!

Good luck!

Thanks. But for now I'm learning without a good document, I'm only reading through Stef's library; that's not very smart I guess =)

[tomaitheous]

I'm not sure I understood your explanation, but my lack of knowledge about the MD hardware combined with my rather bad english is probably the reason Wink

For the 8x2 tile method?

Okay, it goes like this:

In a normal 8x8 tile, any one of those 64 pixels can access one of 16 colors from a single palette, righ? Because each tile map allows you to set one palette per tile or 8x8 pixels.

(normal setup)

00000000 <- an 8x8 tile with one 16 color palette for all 8 rows of pixels
11111111
00000000
11111111
00000000
11111111
00000000
11111111

(8x2 tile setup)

00000000 <- uses a palette assignment from tile map section 1
11111111
00000000 <- uses a palette assignment from tile map section 2
11111111
00000000 <- uses a palette assignment from tile map section 3
11111111
00000000 <- uses a palette assignment from tile map section 4
11111111

So every 2 scanlines you change the screen position to one of four areas of the 64x64 tilemap.

If your image is 256x224, then you can divide the 64x64 tilemap of plane A into 4 parts. The advantage of having a 8x2 tile setup is that you still have VRAM left for plane B and sprites. Note: having a 8x2 tile setup *doesn't* decrease your vertical resolution, it's still what it is normally (like 224 lines or whatever). That's 896 tiles for the pic, and four 32x28 tile maps organized into one 64x64 tilemap, or 28k tiles + 8k for single plane tilemap.

If you were to use 40H mode, then you'd only be able to do a 8x4 tile setup because you can't fit four 320x224 tilemaps into a single 64x64 tilemap.

[Brunni]

Sorry for the late reply
In fact I'm not sure I see what you mean; but if I did, with this you can have 16 colors per 16 pixels, but you still aren't free to select them; in fact every tile's first and second row use the first palette.
So let's say pixel (1, 0) wants to use color #6 (located in palette #0) and pixel (2, 0) (just nearby in the same tile) wants to use color #17 (located in palette #1) this isn't possible, right?
Sorry if I'm completely wrong...

[tomaitheous]

Sorry for the late reply
In fact I'm not sure I see what you mean; but if I did, with this you can have 16 colors per 16 pixels, but you still aren't free to select them; in fact every tile's first and second row use the first palette.

Yes, every group of 16 pixels will have access to any 16 colors in 1 of 4 palettes. Your not locked to the same palette for every two rows of pixels. You can assign a different palette to every 16 pixels (two rows of 8 pixels) - if needed.

So for instance if you had a tile that use 10 colors from palette one, but there were some pixels on one or two rows that needed colors from from another palette index, they now have access to another palette to use those colors.

This would *help* reduce those "block" artifacts you get when you can't represent certain pixels in an 8x8 tile from any of the selected palettes.

If you just think of it as the hardware having an 8x2 tile format, I'm sure you could see that it offers less restriction than an 8x8 tile format for the conversion process.

I admit this concept does works better when you have more sub palettes, as you could have palettes that contain more redundant color selections. On the MD you're more limited to how much color slots you want to allocate for redundant colors across the four 16color sub palettes, so things get tricky.

[TmEE co.(TM)]

This is a really nice demo, but doesn't look too good on PAL.

[LocalH]

An idea I'd thought about in the past to get more colors was to split a pallet line into two halves, on odd lines update one half and on even lines update the other (DMA to CRAM). While this would be quite bus intensive, with proper tile data you can have 8 colors on each scanline that also came from the scanline before, and then 8 new colors, using a single pallet line (basically, each half of the pallet line would have it's 8x2 cells offset one scanline from the other half). It would especially be useful for, say, a logo at the top of a demopart, since the less tall the image is, the more CPU time you'll have in the rest of the frame. This basic technique was used to great success on the Amiga to get many more colors on a hires screenmode (this method became known as "Sliced HAM" even though it uses no real hold-and-modify capabilities).

Another variation on this would be to skip every other scanline (by disabling display) and overlay both planes to gain 31 new colors on every other scanline (with the inbetween scanlines being filled with backdrop of course). I've seen demos on the C64 use the general "skip every other scanline" method to create some nice graphics while not having to worry about hitting the video chip on every single scanline. With the display disabled on every other scanline you'd easily have time to update two full pallet lines (hell, you'd probably have time to do it with the 68k if you really wanted to).

[Chilly Willy]

No, Sliced HAM was precisely because you used HAM modes. What you described was called Dynamic HiRes. It also reloaded all sixteen color regs.

[LocalH]

Ah, perhaps the info I was reading was wrong. Wouldn't be the first time Wikipedia misled me. Still, the fact remains, reloading pallet entries on successive scanlines is a well-known technique, and while we might not be able to update all 16 colors of a pallet line unless we disable the display, it can still be used to great effect.

[Mask of Destiny]

I had decent results using a slightly simplified version of that technique. I didn't alternate which 8 palette entries I replaced. I just always replaced the last 8. It made my palette choosing algorithm a bit simpler that way. I picked the 8 most common colors across the entire image for the "fixed" half of the palette and then the "dynamic" half was chosen based on the 8 most common colors on the line that weren't in the "fixed" half.

Biggest problem is that in order to avoid artifacts you need to turn the display off during HBLANK and the only way to do that and still have enough time to DMA 8 colors is to poll the status register for HBLANK. HINTs occur too late. So you basically end up burning 100% of your CPU time on the color changes outside of HBLANK. With some clever coding I suppose you could probably break up other processing in to chunks that would fit in the active display period, but it would be somewhat awkard to do.

[Chilly Willy]

Too bad the Genesis didn't have a simple coprocessor that could load the regs based on the video timing. That was why the Amiga could do those dynamic/sliced color modes so well. You don't have to busy-loop the CPU when the COPPER would do that automatically. Reloading the palette with the COPPER list was very common in many games/picture viewers. Those gradient backgrounds were really simple and made the game appear more colorful.

Seems to me that you might be able to do something like this:
HINT runs 68000 routine which loads up a DMA to the color regs, then delays via nops until it knows the VDP is busy, THEN starts the DMA and exit the int code. The DMA should be held off until the line is done, so this would affect the color of the NEXT line, not the line getting ready to be drawn.