| |
Eyeth
Account closed
Registered: Apr 2002
Posts: 98 |
Drazlace/Interlacing Theory
Hello.
I'm trying to create a simple tool that will convert an ordinary 256-color BMP file into a Drazlace graphics format.
I already know how to code a Drazlace routine; It's just two MCM screens that are interlaced and one screen is offset by one hi-res pixel.
What I would like to know is the theory behind constructing a Drazlace or an interlaced screen. Apart from the background value, in a 8x8 pixel block, I can use three colors;
one for videoram high nybble
one for videoram low nybble
one for color ram
However, each color value can be interlaced and that creates more color possibilities. I'm guessing that up to 6 color combinations can be achieved? What about the screen-shifting? How do I compensate for that? How do I know which color values, when interlaced, become this specific color?
If someone has programmed a 256-color to drazlace conversion routine, I'd like to know more. I sure could use such an existing utility rather than programming a new one.
Thanks,
-Todd Elliott |
|
| |
Dane
Registered: May 2002
Posts: 423 |
Actually, up to 10 colour combinations can be achieved, taken the background colour into account. However, all of these might not look very good. :) |
| |
MagerValp
Registered: Dec 2001
Posts: 1078 |
Just treat the screen as a 320x200 bitmap, and disregard the fact that colours are blended. If you think about it, this is exactly what the interlace does.
|
| |
QuasaR
Registered: Dec 2001
Posts: 145 |
There are two mode: One with around 136 colours (theoretically...) with a resolution of 160x200 and one with the "standard" 16 colours and a resolution of 320x200 by altering the bit0 of $d016 each frame. Just try S or R in Drazlaces' show-mode. |
| |
algorithm
Registered: May 2002
Posts: 705 |
If you want an interlace mode which can display over 100 theoritical colors, you simply have to flick two FLI pics and the combination of two different colored pixels will give you a huge amount of colors.
However you can use the screen shifting trick to have a resolution of 320x200 in 16 colors. (Luckily you get far more than that due to overlapping pixels and it looks better than expected.
I have created an application which converts truecolor images to 320x200 FLI interlace. Give it a try
www.algotech.co.uk
|
| |
QuasaR
Registered: Dec 2001
Posts: 145 |
ähm... sorry, but FLI only helps to "break" the limit of 4 different colours in one 4x8 pixel-area to bring it down to 4x1. INTERLACE makes it possible to have either more colours (without $d016-wanking) or higher-resolution (8 instead of 4 pixel width...) |
| |
algorithm
Registered: May 2002
Posts: 705 |
Firstly converting an image to 16 C64 colors at 320x200 resolution and then finally converting it to IFLI will not just result in a 320x200 image in 16 colors. This is due to overlapping pixels (When using $d016) An approximate amount of colors will be 80+
Secondly, Using FLI mode is necessary when displaying quality interlaced images due to less attribute block limitations.
Yes, Interlacing can be just flicking two images together, but in C64 terms the following would apply
160x200 interlace (no $d016 tweaking) = Color interlace
160x200 interlace ($d016 adjustment) = 320x200 resolution (sort of) + semi color interlace |
| |
MagerValp
Registered: Dec 2001
Posts: 1078 |
$d016 interlace is not just "sort of" interlace, it's the same effect as e.g. Amiga video modes or what you get out of your VCR. There's a certain amount of overlap in these two, based on the screen's dot pitch. You get the same kind of colour blends if you make every other line a different colour on an Amiga.
Making an image converter that takes $d016 interlaced colour blends into the calculation would be really difficult, as (potentially) all the pixels on a line are interdependent. Just treating the screen as 320x200 and applying dithering gives you the same effect, and is much easier to work with.
On the other hand, a skilled gfx artist working directly with the interlaced mode can of course use it to his or her advantage. Hand drawn graphics will always be superior to converted graphics.
PS: Todd, there's a BMP2MCI converter in the tools dir in serial slave. The source is GPL:d.
|
| |
Eyeth
Account closed
Registered: Apr 2002
Posts: 98 |
Hello, MagerValp-
Thanks for the tips regarding conversion. I did find myself scratching my head as to how to deal with color blending; your approach sounds more simpler and realstic. I did find jpg2mci converter on your website and will try to check it out. Hopefully it's easy to understand.
Enjoy.
-Todd Elliott |
| |
Eyeth
Account closed
Registered: Apr 2002
Posts: 98 |
Hello, MagerValp-
Your utility did the job very well. I couldn't understand the source code very much. At least, I know some C to be a little bit dangerous and will be able to modify the utility to create standalone MCI files w/o the executable portion.
One other question; I noticed in the source code that you optimized the background color. That is a good thing. But what about optimizing the background color for every 8 scanlines, i.e. a cardrow? This would result in 25 such values and an IRQ would be used to insert them appropriately onscreen. Would that improve the MCI conversion results?
-Todd Elliott |
