| |
algorithm
Registered: May 2002
Posts: 702 |
Introducing Tri-Lace
Coming soon..
Yes, It does flicker but this is reduced somewhat with interleaving of fields (as well as not mixing combo's which produce high flicker.) This gives a shimmer effect.
Each 8x8 block can have up to 8 mix colors. Image above utilises non brute force and partial flicker reduction (with hand selected color combo's.) Still optimising the routine. (Brute force takes over 8 hours!) but managed to reduce it down to around 2.
Non interleaving allows full 320x200 view with virtually no CPU usage (but looks horrendous on non stable refresh displays)
Using new compiler (Now can build x86/x64 linux /windows executables
As far as i am aware, there only seems to be one demonstration (which utilises 4 screens - but in petscii). If there are any which use more than two screens for colormixing etc. let me know |
|
... 77 posts hidden. Click here to view all posts....
|
| |
Copyfault
Registered: Dec 2001
Posts: 466 |
Great to read smth new concerning interlace modes!
Somehow I'm a bit confused about that "reduced screen size" for full TriFLI. I'm quite sure that full 200 lines TriFLI is possible (with or without stack hijacking, depending on personal flavor;)).
What exactly does "instant FLI coloring" mean? Is this about finding the best colour/pixel settings for a given source picture?
@Repose: I'd be more than happy to see some example pictures of your TriFLI experiments - we need more interlace in this nu' FLI-world;) |
| |
Oswald
Registered: Apr 2002
Posts: 5017 |
well you have 2 banks for fulsreen fli at 4000 and c000, then you can put a top half bitmap to 8000-a000, screens to a000-c000, and a bottom half bitmap to $0000-2000 & screens to 2000-4000. stack and zp are free to use this way |
| |
Copyfault
Registered: Dec 2001
Posts: 466 |
@Oswald: it IS a little bit trickier since VIC only sees CharROM at $1000-$1fff and $9000-$9fff. Guess you'll not get around mixing the Bitmap- and VRAM-areas at appropriate places. |
| |
algorithm
Registered: May 2002
Posts: 702 |
Per line FLI in TRI-lace is doable in a way but the additional memory usage (12k extra for color data) is not justifiable in comparison to the quality increase (which would not be a huge one) in comparison to non interlace FLI. A quick memory map would be something like the below.
Top of bitmap would be $2000-$2eff
color data $3000-$4000 - 4banks
color data $0000-$1000 - 4banks
bottom of bitmap would be $af00-$bf3f
color data $8000-$9000 - 4banks
color data $a000-$aeff - close to 4 banks
The issue is the $1000 and $9000 area's which have the charrom mapped to them. the above mem map would result in not being able to fit all the color ram in (and the same if it was the other way around (eg top of bitmap $0000-$0f00 etc) |
| |
Oswald
Registered: Apr 2002
Posts: 5017 |
I was wrong, I wanted to have top & bottom half bitmaps where the char rom overlaps, but it always overlaps to the bottom half :( not doable.
.. and one more edit: nice solution algo
|
| |
Repose
Registered: Oct 2010
Posts: 222 |
Hi,
I found the solution to flickering also, temporal-spatial dither. For example imagine a checkerboard and it's reverse, alternating. On a real c64/monitor at least, there is no flicker - except on the edges of the pattern.
*.
.* flashed with
.*
*.
You can take a much deeper view of dither. Eliminating flickering is something like constraining a 3d choice such that 1/(spatial frequency*temporal frequency) < limit.
I have a binary showing a hires (320x200) fractal plot in 3 colors and it looks fantastic, with no flicker. It makes very nice anti-aliased lines as well.
If you read my article in Discovery I explain it further (and I'm sorry the writing gets poor towards the end). In fact I've done 4 screens interlace with no flicker, and a huge amount of colors - so many in fact, that you can hardly tell them apart. So in a sense, while cool it's pointless.
As for instant FLI coloring, I mean I found an algorithm to find least-error coloring for any FLI, as opposed to brute-force which tries all color combinations.
Combined with spatial-temporal dither, you should be able to solve IFLI least-error coloring instantly.
Personally I see no reason why we can't make the ultimate display, very close to no restrictions and every noticeable color combination possible, with no flicker. It would simply have a strange, non-saturated color look to it.
ps as a matter of fact, I can say that I did release this - the fractal demo made it to some BBS's 14 years ago. |
| |
Copyfault
Registered: Dec 2001
Posts: 466 |
Quote: Per line FLI in TRI-lace is doable in a way but the additional memory usage (12k extra for color data) is not justifiable in comparison to the quality increase (which would not be a huge one) in comparison to non interlace FLI. A quick memory map would be something like the below.
Top of bitmap would be $2000-$2eff
color data $3000-$4000 - 4banks
color data $0000-$1000 - 4banks
bottom of bitmap would be $af00-$bf3f
color data $8000-$9000 - 4banks
color data $a000-$aeff - close to 4 banks
The issue is the $1000 and $9000 area's which have the charrom mapped to them. the above mem map would result in not being able to fit all the color ram in (and the same if it was the other way around (eg top of bitmap $0000-$0f00 etc)
Nice idea indeed, though unfortunatly not all the needed colour data will fit.
I don't know if you can get full 3 frames of 200 FLI-lines by only switching between banks/Vrams/Bitmaps. But it would be possible to do it like this:
frame1:
$6000-$703f bitmap, upper part
$3040-$3f3f bitmap, lower part
$4000-$4207
...
$5c00-$5e07 vrams for upper part
$0208-$03e7,...,$0e08-$0fe7
$2208-$23e7,...,$2e08-$2fe7 vrams for lower part
frame2:
$c000-$dfef bitmap
$e000-$e3e7 etc vrams
frame3:
$a000-$af00 bitmap, upper part
$6f00-$7f3f bitmap. lower part
$8000-$81df,...,$8c00-$8ddf
$b000-$b1df,...,$bc00-$bddf vrams upper part
$41e0-$43e7
...
$5de0-$5fe7 vrams for lower part
This way we completely avoid touching the stack area. However, some memory space is used twice: $6f00-$703f for bitmap data in frame1 _and_ frame3, and the same with the vram data @ $41e0-$4207 etc. But using a copy loop in the lower border area, we can make sure that we have the correct gfx data in the appropriate memory places for each frame.
Even more bizzare would be to directly connect the two banks with CHARROM:
frame1:
$a000-$b03f Bitmap, upper part
$3040-$3f3f Bitmap, lower part
$8000-$8207,...
$b000-$b207,... vrams upper part
$0208-$03e7,...
$2208-$23e7,... vrams lower part
frame2/3: "regular" FLI memory layout at $4000ff and $c000ff
This solution has a somewhat "smaller" problem: the memory $b000-$b03f. But as the Bitmap data for the upper screen part is needed not before the 13th charline, we can swap the vram data (which should be there first) during the FLI-loop.
So, I'm still quite sure 200lines full Tri-FLI _are_ possible;)) |
| |
algorithm
Registered: May 2002
Posts: 702 |
The above type of methods (copying data on the fly) is what would make trilace fli perline possible and there is not much data to copy. The main issue however is the ram usage (48k+ for one image alone)
Using the non-copy methods as i described previously, the color ram would not fit fully. ($ac00-$aeff) instead of ($ac00-$afe7) However, the converter can take into account the gfx data (at $af00-afe7) and use that as the color data for conversion. If there are any empty gfx area's at that place, then it can have ink/paper set to the same color and any gfx data within it (which would translate to ink/paper color) when this is overlapped to the FLI color.
Experiments have however showed that FLI perline in Trilace does not give dramatic quality increase in comparison to non-lace or laced images considering the 12k+ additional requirement |
| |
Copyfault
Registered: Dec 2001
Posts: 466 |
@Algo: the experiment pics would be interesting...
Did you mix only hires bitmaps or did you also try hybrid modes like e.g. mixing two mc-fli screens with one screen of hires fli?
@Repose: what exactly do you mean with your "ultimate display"? Do you still have TriFli in mind when you write this or does your imagination go beyond this? |
| |
algorithm
Registered: May 2002
Posts: 702 |
When i was coding the converter, I tried the converter using 8x1 pixels and then changed it to 8x2 and saw that there was not a huge amount of improvement in the previous incarnation for most images. I may perhaps release a final version of the Tri-FLI with FLI per line. The increase in quality would be higher (fli per line in comparison to x2) if i was more strict in regards to the luma overload detection (additionally reducing extra flicker in the process)
I find the mixing of three screens rather painful on anything but a real c64 and tv set with delayed phosphor. Most images would look great in just the hybrid mcol/hires fli) and flicker less
All three images are in Hires. |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 - Next |
