[CSDb] - User Forums - Unrestricted hires colour mode! (albeit just a *tiny* bit letterboxed..)

You are not logged in - nap

CSDb User Forums

Forums > C64 Coding > Unrestricted hires colour mode! (albeit just a *tiny* bit letterboxed..)

2015-01-23 07:59

ChristopherJam

Registered: Aug 2004
Posts: 1409

Unrestricted hires colour mode! (albeit just a *tiny* bit letterboxed..)

I've been spending a few weeks on and off experimenting with how sequences of hires pixels behave, and as something of a side effect I've reached a startling conclusion.

If you layer seven hires sprites over a multicolour sprite over a multicolour bitmap, with the just that final sprite set to a lower priority than the bitmap foreground colours, I'm pretty sure you can have a 24x1 pixel area of any pixel any colour.

It's easily done for a palette of 11 colours as so:

BBbbbbbbbbbbbbbbbbbbBBbb # background layer: two pixels from $d800 & $d802, rest from $d021
 00112233445566778899    # MCM sprite layer. Note odd x-position -> half pixels peek out from under fg
  ff  ff  ff  ff  ff  ff # bitmap fg layer
  s   s   s   s   s   s  # hires sprite layer. 's' where layer's always opaque, space where it is optional

So, any of the pixels whose x%4 is 0 or 1 can be any of the 7 hires colours or any of the three MCM sprite colours, or $d021
any pixels where x%4==2 can be any one of the 7 hires sprite colours (so ensure those 7 include the up to six represented here)
any pixels where x%4==3 are unrestricted

For 16 colours it's more complex. I have a algorithm that will deal with any sequence for which all sixteen colours are present in the first 16 pixels (ie the first 16 are just a permutation), which chooses from about 50 different layouts depending on the last 8 colours and where they can be found in the first 16.

I've yet to generalise to all 16^24 possibilities, but have also yet to find a sequence that cannot be represented. lp_solve and gprolog have both failed me, as they grind to a halt if I try to describe the general problem.

Would anyone care to prove me right or wrong about the general case being solvable (preferably with either an algorithm or a counter example)? I'm having trouble concentrating on anything else while this is still an open question.

Not sure whether this belongs in Coding or Pixeling; posting here because it's pretty impractical for artwork. Still, it's trivially stretchable to full screen height, so perhaps it would be good for a narrow area of vertical 'raster bars' :D

... 30 posts hidden. Click here to view all posts....

2015-01-29 10:45

ChristopherJam

Registered: Aug 2004
Posts: 1409

Dane, I did some experiments with an offset-by-one MCM sprite layer under the foreground of an MCM character mode layer a year or two ago. I was getting very nice results from a mode-aware dither routine, but all of my sources were photographs - I didn't really want to release anything that was just a conversion of someone else's 24 bit or greyscale artwork.

If I get my shit together I'll hopefully release some real artwork of my own later this year.

Glad this thread's provoked some thought, in any case :)

2015-02-22 23:38

Copyfault

Registered: Dec 2001
Posts: 478

Quoting ChristopherJam

Excellent, that works.
The seven l0 colours would have to have at least one duplicate across any pair of characters, but my one concern would be that it might be a different duplicate shared between a different pair. Perhaps this could be worked around by swapping a colour between l1 and l0? Six hires sprites certainly fits with my experimental results with a brute force allocator, but I've yet to prove it covers all bases.

...

I think I can prove the "hard version" now, i.e. that 24 pixels can be individually coloured by using max. 7 sprites; furhtermore, the sprite layers can be aligned with the char boundaries which gives room for furhter improvement of this "mode" ;)

The rules I already proposed seem to work quite well for showing this. I'll list the final version of them here for sake of completeness:
1. check all cells if both colours are identical
-> If they are, ignore the cell in step 2&3
2.a. Sort colours by occurance (in the remaining cells)
2.b. choose (one of) the most often occuring colour and move the corresponding pixels to l1
2.c. ignore the cells with this colour for step 2&3
2.d. as long as there are colours occuring more than once, repeat step 2
3. the remaining cells have different colours -> choose one in each cell and move it to l1
4. Check all cells (including the ones that were ignored in the steps before) for colours that are in l1 already and move the corresponding pixels to l1
5. in case of less than nine colours in l1, move pixels to l1 until there are nine colours in l1
6. move the remaining pixels to l0

That's it! Now note the following facts:
- every cell with two different colours has at least one colour in l1
- there are seven colours in l0

The first fact ensures that l1 suffices to create a real hires resolution. The second fact helps to argue why l0 can be constructed within normal multi-colour-gfx restrictions. How? For this, we distinguish between two situations:
1. assume that there is at least one cell with both colours in l1
-> in this case the l0-pixels of this very cell are hidden
-> thus, three colours (which can be handled by vram and d8xx) suffice for l0 in this char as there are always only four cells per char
-> the other two chars give eight cells in total; as there are only seven colours in l0, at least one of these colours MUST repeat
-> this colour can be handled by the bgr-colour

2. all cells (with different colours) have only one pixel in l1
-> the other pixel must be in l0
-> choose such a cell and move the l1-pixel to l0
-> move all pixels of the same colours to l0
-> move all pixels of another l1-colour to l0
-> now swap the roles of l0 and l1, i.e. let l0 be the new "foreground layer" and l1 the new "background layer"
-> after this, the new fg layer l0 has nine colours and there is at least one cell with both colours in l0
-> we now have the same situation as described under 1.

Next step would be implement a test code for this (or even for more fancy stuff like 200 lines of the mode;))

@Digger, Oswald: I doubt it will be possible to do some lookup-table stuff with a 24x200-windowed version of this mode; I'd be happy to see a logo done with it, though;)

2015-02-22 23:44

Copyfault

Registered: Dec 2001
Posts: 478

Quoting ChristopherJam

Dane, I did some experiments with an offset-by-one MCM sprite layer under the foreground of an MCM character mode layer a year or two ago. I was getting very nice results from a mode-aware dither routine, but all of my sources were photographs - I didn't really want to release anything that was just a conversion of someone else's 24 bit or greyscale artwork.

If I get my shit together I'll hopefully release some real artwork of my own later this year.

Glad this thread's provoked some thought, in any case :)

I'd sure like to see these experiments from both of you, Dane and Christopher Jam ;) Back in the days (when "IFLI-Convertors and friends" were new) a series of converted photos was a good reason to release a GFX Collection.

But it was all about this saying "good things come to those who wait", no ;) ?

2015-02-22 23:48

Copyfault

Registered: Dec 2001
Posts: 478

Quoting algorithm

...
However, I feel that even with some restrictions in place, the difference in output at a wider width would be negligible dependant on how the converter creates the image and sprite definitions.

Have a look at the mucsu-fli mode for example, having full width FLI with sprites over 240 pixel range (albeit blocky) but underlaid with hires masking. Copyfault I believe updated the routine to work at full 200 vertical lines.

Yes, thanks for advertising! It can be seen in The Other Lines.

2015-02-23 21:05

ChristopherJam

Registered: Aug 2004
Posts: 1409

Hi Copyfault.

I mostly follow.

Certainly that an L1 with nine colours over a MC res L0 follows from the first section of one of my earlier comments in this thread (#27)

And I can see that any pixel of L0 containing colours from L1 can be promoted to an L1 pixel, leaving only seven colours required for L0.

Your case 1 logic makes sense, assuming we can freely position the nine colours in L1.

However, there are some odd restrictions on L1 to allow it to contain nine colours, namely that two of them are sourced from a multicolour sprite - hence, those colours need to be paired either with another L1 colour, or with a FG colour from L0

I covered that in comment #27 by only using those colours in even pairs.

I think that the odd-pair exclusion might sometimes be broken if we apply your rule of always promoting l0 pixels to l1 if they are one of the nine l1 colours, so it looks like a different way of allocating the MC colours might be required.

As for case 2, I'm struggling to track the invariants across the layer inversion at the moment; will have to ponder that one further!

Definitely interested in test code for this one. My brute-force search has yet to fail, but it's probably too slow to use in a native editor.

Previous - 1 | 2 | 3 | 4 - Next

Refresh

Subscribe to this thread:

You need to be logged in to post in the forum.

Search the forum:
Search for in
All times are CET.

Search CSDb

Advanced

Users Online

X-Raffi/X-Rated
Guests online: 86

Top Demos

1 Next Level  (9.7)
2 13:37  (9.7)
3 Mojo  (9.7)
4 Coma Light 13  (9.6)
5 Edge of Disgrace  (9.6)
6 What Is The Matrix 2  (9.6)
7 The Demo Coder  (9.6)
8 Uncensored  (9.6)
9 Comaland 100%  (9.6)
10 Wonderland XIV  (9.6)

Top onefile Demos

1 No Listen  (9.6)
2 Layers  (9.6)
3 Cubic Dream  (9.6)
4 Party Elk 2  (9.6)
5 Copper Booze  (9.6)
6 Dawnfall V1.1  (9.5)
7 Rainbow Connection  (9.5)
8 Onscreen 5k  (9.5)
9 Morph  (9.5)
10 Libertongo  (9.5)

Top Groups

1 Performers  (9.3)
2 Booze Design  (9.3)
3 Oxyron  (9.3)
4 Triad  (9.3)
5 Censor Design  (9.3)

Top NTSC-Fixers

1 Pudwerx  (10)
2 Booze  (9.7)
3 Stormbringer  (9.7)
4 Fungus  (9.6)
5 Grim Reaper  (9.3)

Page generated in: 0.041 sec.