| |
ChristopherJam
Registered: Aug 2004
Posts: 1380 |
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 |
|
... 25 posts hidden. Click here to view all posts....
|
| |
Joe
Registered: Apr 2002
Posts: 224 |
I'd still prefer someone would make editors of the underlay/overlay sprites+bitmap mode Algorithm introduced some years back. Could be really useful in ordinary demos (loading time etc).
But.. I support all and every attempt in breaking the boundaries as long as the final result doesn't become interlaced or too small... |
| |
Oswald
Registered: Apr 2002
Posts: 5022 |
I mean it could make a loaderpart or something if Y stretched :) |
| |
Jammer
Registered: Nov 2002
Posts: 1289 |
This thing loosely reminded me of my idea for Lemmings port for C64, this time without reversed background/sprite use and narrow playfield ;) Mostly about writing more Lemmings into single sprites and distributing sprites wisely around with multiplexing. Maybe even a bitmap background could be possible in this case? :D Of course there would be some flickering on characters, but NES games also suffered similar problems and they passed anyway :D |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1380 |
@Dane - I'm mostly posting here rather than in the pixeling forum because it doesn't seem like a very practical result at all :)
Could perhaps have multiple rows separated by black lines or stretch, but it would still only be three chars wide. |
| |
Ninja
Registered: Jan 2002
Posts: 406 |
This calls for Copyfault as the problem should please his interest in GFX modes and mathmatical problems :) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11127 |
you forgot "practically useless" =) |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1380 |
@Groepaz - I got as far as "pretty impractical" in the OP, but concur that that was something of an understatement :D |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1380 |
@Jammer I've had related thoughts myself.. The reversal in the official port's still a brilliant idea, mind. |
| |
Digger
Registered: Mar 2005
Posts: 421 |
I can imagine having restrictionless twister upscroller using this mode if combined with FLI. Should be enough rastertime to push all the pixels, providing you'll somehow solve your LUTs ChristopherJam :) |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1380 |
@DGGR, pushing the pixels should be fine, however the palette is a different issue.
I've just implemented a solution finder, and I've discovered that while it's almost certainly safe to have a constant background colour and four constant hires sprite colours, I would still need to be able to change three hires sprite colours and all three sprite multicolours every line for complete freedom, and probably some $d800 colours as well - a minimum of 36 cycles, probably more like 42 or 48. Seeing as the sprite DMA alone would be taking 19 cycles per line, I can't see that working.
Enough 'difficult' colours in common between all the candidate lines for the upscroller and perhaps something could be done - it's getting a little far away from the original unrestricted concept, but would certainly make for a more interesting effect :)
ps - python 3's "yield from" is magical! |
| Previous - 1 | 2 | 3 | 4 - Next |
