| |
algorithm
Registered: May 2002
Posts: 702 |
MUCSU-FLI - PAL MIX MODE
MUCSU has now had the FLI treatment. FLI every line with sprite overlay. Some basic specs below
296x160 HI-Res FLI per line. Underlaid on the FLI display is a Multicolor sprite underlay at 240x160 resolution
Due to the FLI per line combined with the underlay, The PAL blending can be used to a great advantage.
Converted pic below (With pal blending - Although on real pal emulation, would look better)16 pixels are not included on the right so that the image will be centered.
And the image below consists (from left to right, top to bottom. Converted image without restrictions. Final converted image. Sprite underlay, FLI overlay
|
|
| |
DeeKay
Registered: Nov 2002
Posts: 362 |
Najs. So you're using five expanded sprites with full FLI? That's no easy feat, seeing how not too long ago that would warrant an own mini-demo from Crossbow! ;-)
but do you actually need full FLI? wouldn't the quality improve if you used more sprites and did FLI every second line (=NUFLI minus the spritecolorchanges but with multicolor)? |
| |
algorithm
Registered: May 2002
Posts: 702 |
Quote: Najs. So you're using five expanded sprites with full FLI? That's no easy feat, seeing how not too long ago that would warrant an own mini-demo from Crossbow! ;-)
but do you actually need full FLI? wouldn't the quality improve if you used more sprites and did FLI every second line (=NUFLI minus the spritecolorchanges but with multicolor)?
Yes. Its 5 full expanded sprites with full FLI. :-) And certainly i did get that idea from the Demo 'Demus Interruptus' Some nifty illegal opcodes and vic trickery.
NUFLI has the benefit of being full screen (and covering FLI bug area) This FLI variant of MUCSU mode works well with color changes vertically (eg to take into account the vertical pal mixing)
I have tried it on c64 ifli converts and even the non-fli variant (standard mucsu) seems to convert it rather well but does not do a good job when there are a huge amount of colors in tight area's for example. the below picture is another converted example. notice the pal mixing on area's where colors alternate (blue/brown) etc
and below is the original converted image but without the pal blending
There are still some things to iron out. For example the color matching. (at the moment using MMX opcodes to speed up process significantly) but this is RGB sum of absolute differences only which is a definate no-no.
The selection routine for the 5 sprite column colors is also very archaic. At the moment using histogram based approach which is another negative point. But coded the basis of the routine just to test the quality of what can be achieved
|
| |
Oswald
Registered: Apr 2002
Posts: 5017 |
nice but pointless without an editor. |
| |
algorithm
Registered: May 2002
Posts: 702 |
Quote: nice but pointless without an editor.
It was only planned for an upcoming demo and an hour of coding.
Planning a very basic pixel editor for the mode. (for touching up converts) For other modes such as tri-lace/mfli etc it would be pointless however unless someone has the time to delve into mixcolor hell |
| |
Oswald
Registered: Apr 2002
Posts: 5017 |
yes, a basic editor to retouch sketches, like the nufli workflow would be nice. |
| |
DeeKay
Registered: Nov 2002
Posts: 362 |
I second Oswald. No pixler will ever use these quite nice modes if there is no way to lay hand on it after conversion! ;-) How about if you made (or ripped from somewhere else) your basic editor framework and then just adapted it slightly to all your modes? They share a lot of common traits from what i see, so it should be able to at least cover a few modes with a framework that is general enough... Not the trilace stuff, but to be honest i was a bit underwhelmed when checking it on the real machine, it did look like scrolling lines most of the time and flickered quite badly (not AS bad, but not as little as i hoped either!) - with the exception of the diagonal line modes, but these had quite a bit more blockiness than the horizontal lines, due to obvious reasons (diagonal = color killer!). So I don't think pixlers would want to use trilace... and even if they would, I can't think of a way to make such an editor actually usable! So the need for a trilace-capable editor is not really there. MUCSU and the new FLI variant? More likely! ;-) |
| |
algorithm
Registered: May 2002
Posts: 702 |
Quote: I second Oswald. No pixler will ever use these quite nice modes if there is no way to lay hand on it after conversion! ;-) How about if you made (or ripped from somewhere else) your basic editor framework and then just adapted it slightly to all your modes? They share a lot of common traits from what i see, so it should be able to at least cover a few modes with a framework that is general enough... Not the trilace stuff, but to be honest i was a bit underwhelmed when checking it on the real machine, it did look like scrolling lines most of the time and flickered quite badly (not AS bad, but not as little as i hoped either!) - with the exception of the diagonal line modes, but these had quite a bit more blockiness than the horizontal lines, due to obvious reasons (diagonal = color killer!). So I don't think pixlers would want to use trilace... and even if they would, I can't think of a way to make such an editor actually usable! So the need for a trilace-capable editor is not really there. MUCSU and the new FLI variant? More likely! ;-)
They are rather different from each other. The MFLI mode for example utilises mcol/hires alternating. this would be a great nightmare. to pixel in, although i know if anyone (like you) pixeled in SHIFLI, then it would be easier for you no doubt ;-)
The trilace mode only really works well for some images and as for the trilace mode which uses same color banks, in most cases MFLI would give better results (and less flickering)
I agree with the non interlaced modes that an editor is essential however. I need to get to grips with the input system however as all the routines at the moment are in x86 ASM and event handling seems more a boredom for me instead of pure processing code
|
