| |
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 |
|
| |
Ed
Registered: May 2004
Posts: 173 |
Looks splendid. (and I can imagine the flicker horror on unstable screens)
I would love to see all the graphic modes/converters you have come up with in the past incorporated into one program. |
| |
ready.
Registered: Feb 2003
Posts: 441 |
yes, could be an idea for a demo, a story-telling demo of your progress through all these years, Algorithm. |
| |
j0x
Registered: Mar 2004
Posts: 215 |
Looks pretty good. Would love to see it "live". Eight hours?! Jeepers!
disC=overy magazine, issue 1, contains an article called "TRI-FLI : A new video mode 'abrewing?". Sounds like colour-mixing on more than two screens to me. :)
Don't know if any examples exist, though.
See http://www.ffd2.com/fridge/discovery/ |
| |
Carrion
Registered: Feb 2009
Posts: 317 |
please provide some binaries so we can check it out.
/me is impatient! |
| |
DeeKay
Registered: Nov 2002
Posts: 362 |
Oh Noes! <:-) I thought mini-animations triple interlace died with Goa Brudbilder 2 <:-)
Didn't the Plasma in Wet Dreams 2 also have triple interlace?
Screenshot looks awesome, granted, but triple interlace is just evil, no matter what! ;-D |
| |
algorithm
Registered: May 2002
Posts: 702 |
Certainly flicking three screens seems an insane idea but by utilising only certain color combo's from the selected 8 mix colors as well as the interleaving (which gives more a shimmering effect) it does not look that bad at all. The additional colors (well additional illusion of colors) also get rid of the requirement for FLI as it allows 8 mixcolors (although as mentioned before, not all useable without insane flicker) per 8x8 block
The additional colors seem to outweigh the additional flicker somewhat. The picture posted here is certainly suboptimal. Does not utilise all the mixcol possibilities. Only tested it based on some hand defined mixcolors.
Yes, I am aware of the Brudbilder series, but this flicked 4 screens, flicked colors of high luma difference, had no interleaving and was entirely in petscii. |
| |
algorithm
Registered: May 2002
Posts: 702 |
The 8 hours of processing time in brute force was due to quick unoptimised coding. The converter is utilising multithreading to use all cores available for extreme speedup. On my dual core athlon kuma 7750 it now takes less than an hour. |
| |
Hermit
Registered: May 2008
Posts: 208 |
This picture is unbelievable. Very good conversion!
Similar to 256 colour mode on an old VGA card..which sounds good on a C64 with 16 given colour!
Please, give an executable, so we could check the flickering..
BTW, I'm thinking about developing a little C64 hardware-tweak to eliminate flicker of ifli. A small delayer circuit could be able to average the VIC's luma signals with the previously displayed frame. This way C64 could produce 256 colours without flicker. And this function could be switched on/off with an unused VIC-register, to keep compatibility, just in case...
Hermit Software Hungary
|
| |
Carrion
Registered: Feb 2009
Posts: 317 |
hermit: Do you need any funding for the flicker-fixer? I'm interested to buy one - seriously :)
algorithm: again, please provide exec binary. i really love to check it on real machine. btw, do you have any special pallete for tri-lace? can we also see it?
deekay: I was almost sure you'll mention pattern dithering on that picture ;) |
| |
Burglar
Registered: Dec 2004
Posts: 1031 |
goa brudbilders rule
but, dont tease, give us a binary already ;) |
| |
Oswald
Registered: Apr 2002
Posts: 5017 |
can you post the original pic too? and show the 3 frames? very nice result, but allow me a little nit picking: too yellowish, is it not possible to produce better skin colors? |
| |
algorithm
Registered: May 2002
Posts: 702 |
The below is the original picture
As mentioned previously. I had entered the color combo's by hand in the example. These color combos would not work too well on other pictures. When I have the time and when i can optimize the routine (inline assembly), I will provide binaries. There is still a lot of improvement to be made. (in particular, the mixcolor selection)
Carrion: There is no predefined palette for Trilace. (at least not how the routine in the converter works) The routine dithers each 8x8 block on the fly and then tries combinations of mix colors (that produce least error and least flicker). To build a color palette based on this its merely the c64s 16x16x16 but bear in mind that many of the color combinations look very similar as well as flickering too much hence the realistic amount of colors is far less
|
| |
FATFrost
Account closed
Registered: Sep 2003
Posts: 211 |
Amazing! Ha! |
| |
Oswald
Registered: Apr 2002
Posts: 5017 |
ah, the original is pretty yellowish aswell. very well done! |
| |
DeeKay
Registered: Nov 2002
Posts: 362 |
Quote: This picture is unbelievable. Very good conversion!
Similar to 256 colour mode on an old VGA card..which sounds good on a C64 with 16 given colour!
Please, give an executable, so we could check the flickering..
BTW, I'm thinking about developing a little C64 hardware-tweak to eliminate flicker of ifli. A small delayer circuit could be able to average the VIC's luma signals with the previously displayed frame. This way C64 could produce 256 colours without flicker. And this function could be switched on/off with an unused VIC-register, to keep compatibility, just in case...
Hermit Software Hungary
There's hardly any need for an IFLI flickerfixer anymore now that we have NUFLI! ;-D
Also, how will you be handling THREE screens? Or even four as in Goa Brudbuilder? 8)
Also: total mixcolors are *not* 256, since blue+green == green+blue. 16+15+14+13+12...+3+2+1 is the way to calculate, so the total number is 136... People get that wrong all the time! ;-)
P.S: Of those 136, our converter only uses 79 (well, it says 81, still trying to figure out where those extra 2 colors come from! ;-) since the rest just flickers too much!
P.P.S: If you consider rastered colors as solid (which they pretty much are thanks to PAL blur!) the total number of possible mix colors is 9316! ;-) |
| |
DeeKay
Registered: Nov 2002
Posts: 362 |
Goddamnit, Algo, post a binary already! <:-)
Posting blended pictures for triple interlace here instead of binarys is really stretching it quite a bit!... I mean: Theoretically you could also "interlace" 20 frames and then post a static truecolor image of that here! ;-D |
| |
Ninja
Registered: Jan 2002
Posts: 404 |
Seconding dk here; discussing the outcome without having a binary seems pretty pointless to me, too. (And to be honest, I am not too optimistic about the outcome. After all these nice hires, koala and NUFLI images, I didn't even like the flickering in the hiddenparts of Carrion's OLDSCHOOL Pixels 100%. YMMV)
And for completeness, Individual Computers promised a flicker-fixer (_slightly_ enhanced with some other functionality).
|
| |
algorithm
Registered: May 2002
Posts: 702 |
Certainly flicking three screens produces immense flicker hence would only recommend displaying it on solid 50hz (or was it 50.12) framerate. But its not as bad as it seems. The effect is more a 'shimmer' rather than flicker due to interleaving.
On a TV set it looks great due to phospor delay. Still have the GUI to complete as well as reducing flicker further in the logic code. (and barely any time due to personal commitments and work) But very soon :-) possibly today :-)
Yes, the total amount of mix colors by flicking two screens is indeed 136 but many of these mix colors produce horrible flicker and wrong colors (eg to a converter black and white should be medium gray) but this is not the case when displayed (as well as headache inducing)
For examples of Hires interlaced and HIFLI modes, can try out my previous converter (MixCol HIfli converter) although this new converter (trilace) is far more accurate in regards to rendering.
Deekay: Great pictures in the MUIFLI hidden parts.
|
| |
DeeKay
Registered: Nov 2002
Posts: 362 |
Algo: thanks! ;-) Wish I had some more time to work on the Sorayama pic a bit more (noticed some areas that could do with a bit of deflickering afterwards when watching it in the emulator for the first time!), but we wanted to release it as a xmas present...
Make sure to also check out alih's a bit more flickering, but also interesting rendition of one of the pics using IAFLI: C- - Must Try Harder
As for the heavy flickering colors of all 136: see the P.S. above! ;-)
As for deflickering: Remember: even distribution among the frames is key! ;-) Which is why MUIFLI flickers so little (i have some more example pics here that we couldn't fit in that hardly flicker AT ALL!), since we can use the extra sprite color to have two bitmap colors... |
| |
Frantic
Registered: Mar 2003
Posts: 1627 |
It is good to see that Goa Brudbilder became an industry standard benchmark in technical discussions of c64 display formats. ;) |
| |
Skate
Registered: Jul 2003
Posts: 490 |
I have an idea.
Tri-lace should be best viewed in 75hz, right? What if we interpolate 75hz to 50hz?
Currently you switch frames like 1,2,3,1,2,3,1,2,3,... right? Instead of switching like that, we can use a table like below;
1,1,2,3,3,1,2,2,3,1,1,2,3,3,1,2,2,3,1,1,2,3,3,1,2,2,3,1,1,2,3,3,1,2,2,3,1,1,2,3, 3,1,2,2,3,1,1,2,3,3
This is the 75hz to 50hz interpolated table. There are sequential duplicated frames but when we check the frequency, 1st frame is shown for 17 times, 2nd is shown for 16 times and 3rd frame is shown for 17 times again. Since 50 is not dividable by 3, this is the best possible result.
I don't expect a perfect result. I expect something like watching interlace graphics on an emulator which runs on other than 50hz. But it may look better than 1,2,3,1,2,3 switching. What do you think? |
| |
Oswald
Registered: Apr 2002
Posts: 5017 |
while its a nice & interesting mode, it will flicker like hell no matter what. also form what I can gather, most people prefer steady screens. including me. |
| |
enthusi
Registered: May 2004
Posts: 675 |
skate, your logical approach will only be reasonable on a screen that blends all frames :)
not having all 3 different frames right after each other will only increase the (quite likely already very noticable) flicker even more.
I pray that no emu will ever feature some frame-add-up.
And there I am, afaik some mac-vice-stuff(?) already has a deflicker-mode? This is the end my friends...
I see hords of people releasing even shittier stuff requiring that very emu-feature...
Ok, I drift off...
The idea of tri-lace is obvious and lame as such IMHO.
Writing a converter to try to get the best result is interessting though and Im looking for a binary to inspect this. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11116 |
Quote:I pray that no emu will ever feature some frame-add-up. And there I am, afaik some mac-vice-stuff(?) already has a deflicker-mode? This is the end my friends...
unfortunately this kind of stuff is pretty much needed to display smooth animation on a non 50hz display ... but indeed, the frame-mixing crap some other emus have to improve the looks of interlace gfx is just...yuck :)
Quote:The idea of tri-lace is obvious and lame as such IMHO.
Writing a converter to try to get the best result is interessting though and Im looking for a binary to inspect this.
yep, that sums it up quite nicely :) i'd like to see the converter, play around with it and inspect the results.....
but please, if you are making a demo, stick to non flickering. (koala ftw) |
| |
Trash
Registered: Jan 2002
Posts: 122 |
The idea of interpolation actually isnt that bad but why not extend it to interpolate to 75hz by rasterrows and not frames? |
| |
Radiant
Registered: Sep 2004
Posts: 639 |
I don't get why most people are against some flickering. If handled properly the results can be very good - with a low price to pay. Of course you wouldn't want to work in a flickering environment, but for single pictures I say go, go, go (but please be sensible about it)! |
| |
Oswald
Registered: Apr 2002
Posts: 5017 |
"If handled properly the results can be very good - with a low price to pay."
no pain - no gain. |
| |
ready.
Registered: Feb 2003
Posts: 441 |
I agree with Radiantx. I the flicker is handled properly it might even add something to the picture. Some interlaced pics look more alive than if they were static. |
| |
Skate
Registered: Jul 2003
Posts: 490 |
@Trash: I think that's a better idea. |
| |
DeeKay
Registered: Nov 2002
Posts: 362 |
Still waiting for that executable... Still wondering what a "shimmering effect" actually is! ;-D So how is it, Algo? 8)
For all the Interlace-haters: Make sure to check out the second hiddenpart in Carrion's Oldskool Pixels 100% with the nekkid chick... And that's not even the least flicker possible, i have other pictures here that do use mix colors but flicker even less! ;-D |
| |
Sander
Registered: Jan 2002
Posts: 487 |
Yeah, imho it can definitely be of added value - depends on how you use it.
E.g. a simple slightly flickering sun (perhaps with subtle beams) in a landscape would already be a nice way of using it. Some experiments with such will pay off for sure. (perhaps not appreciated by all :) |
| |
ready.
Registered: Feb 2003
Posts: 441 |
yes Sander, maybe also a flickering fire would be good for that, like wood burning. |
| |
Skate
Registered: Jul 2003
Posts: 490 |
what about a flickering vibrator pic? :p |
| |
chatGPZ
Registered: Dec 2001
Posts: 11116 |
Quote:And that's not even the least flicker possible, i have other pictures here that do use mix colors but flicker even less! ;-D
executable or it does not exist :) |
| |
Carrion
Registered: Feb 2009
Posts: 317 |
Here are some of my thoughts:
Sander is right and also is somebody who pointed in my latest picture (Prague) that some parts of the pictures when flickered may result in some nice FX. But I just wonder how many graphicians are willing to play with these new gfx formats (MUIFLI, TRI-lace, whatever) to get the effect?
I mean it sure has huge potential, but doing something creative with these formats can be close to imposible when pixeling from scratch. In these days we all use Macs/PCs so it's no problem to use photoshop and then convert with proper pallette. I tried that with our MUIFLI converter and after few tries it really looks good after conversion. We have Photoshop pallete for MUIFLI so I can pixel with Photoshop and then later convert to MUFILI but it's not fun for me - I can tel you! It will always look like converted anyways even I pixeled it from scratch on Photoshop.
I really want to stay creative and stay as close to c64 as possible. Saying that. Tri-lace/MUIFLI/ and every other XYZ-FLI or Quadro-lace is something nice looking but unusable by pixelers - PERIOD. Except DK ;) who has patience for all this new stuff (Daniel forgive me please, but you are incredible with all that ;)
According to what I just said NUFLI looks like it can be the final and ultimate gfx format that we can still use as Pixelers on C64. It's still about 16 colors (no 136/265/whatever), and you have to know the basic rules of c64 pixeling to use it.
To Sum up:
If there's a new gfx format you invent please provide examples and editor to use it. And if it's too hardcore/insane to use we (graphicians) will tell you that we stick to more human readable (traditional) formats. Otherwise new formats are great only for converting the porn. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11116 |
"new formats are great only for converting the porn."
++ :) |
| |
DeeKay
Registered: Nov 2002
Posts: 362 |
I kinda second Carrion in some ways here, but OTOH it is possible to make something even in *UIFLI that looks like pixelled and not converted. Check out my two UIFLI pics, which WERE actually pixelled! ;-) And even though the NUIFLI-End-Logo in CSS started with a conversion, I'd still say it looks rather pixelled (maybe not the VOZ-Logo, but definately the Crest-Logo! ;-)
Totally agree on needing not only a converter and examples, but also an editor on c64 to pixel in. That's something that Algo's gfx formats have been lacking so far sadly! ;-) No editor = no interest from c64-pixellers, it's really as simple as that! Even guys like Cyclone did fix their stuff on c64 after conversion!...
Working in these formats is not black magic, especially when the converter sets most pixels for you already (especially those large, 100% conversion-bugfree areas that would take forever to fill manually!). I could offer to hold some kinda workshop on X2010 for MUIFLI pixelling if there is any interest... 8) |
| |
Lubber
Registered: Jan 2002
Posts: 26 |
@Deekay: Talking about executables...and talking about your nufli converter....uhm....when will it be released again ? :) |
| |
LOGAN
Account closed
Registered: Aug 2003
Posts: 71 |
algorithm did I miss you posting a c64 binary of the example picture? I would have thought you could at least post a binary :) |
| |
algorithm
Registered: May 2002
Posts: 702 |
Barely anytime to finish the converter. A release is imminent. For the time being, A picture preview of the process (split to layers) and a c64 executable.
Do not under any circumstances try to run it on an emulator. Due to the image breaking up the triple screens into slices, even a slight glitch breaks up the entire picture.
First of all bear in mind the following
The gfx mode here (with example c64 exe) uses plain hires (only 2 colors per 8x8 block. FLI once every two lines etc is possible for a huge boost in quality
The additional deflicker methods are not used in this picture. Utilising chequerboard and blending across frames would reduce flicker dramatically at the expense of definition
The mode is only intended for images with high color variety. Most images would look great (with less flicker in Hi-FLI/MUIFLI/NUIFLI modes
The below is an example shot featuring the original picture, converted preview and the three bitmaps that make up the picture
And the c64 executable here
http://www.sendspace.com/file/dd2tnk[url]
Now time for me to go to bed. (Wish me a happy birthday as well :-)) |
| |
enthusi
Registered: May 2004
Posts: 675 |
Running it on 1802 now.
That mon is rather bright (IMHO) even in darkest setting.
So when I almost close my eyes, this example kinda looks nice.
In fact it does not flicker the way I expected but the 'stripes' really bother me. She looks like a movie signal being stopped from VHS player to me.
Not sure what to think of it but Im looking forward for further examples :)
(for the record, I too prefer non-flicker-modes)
PS: Happy Birthday \o/ |
| |
Joe
Registered: Apr 2002
Posts: 224 |
I like the lines.
Made me think of making the image animate with futher interpolated streemed frames...
Happy birthday! |
| |
algorithm
Registered: May 2002
Posts: 702 |
The scrolling lines that are seen are because the picture is not broken up and distributed evenly across frames yet. This can either be done via part of the brute force loop or even easier after the image has been processed. Would greatly reduce the flicker.
The luma avoidance values are also more leniant. (eg allows combo of pink+white etc.
This mode in 2Line FLI would increase quality quite a lot (and more similar luma values can be used in each 8x2 section to reduce flicker further) as using similar luma across 8x8 tends to degrade the structure to a considerable extent particularly if the image has high contrast area's
|
| |
Skate
Registered: Jul 2003
Posts: 490 |
@Joe: Oswald used that idea in a Resource demo and it looked very successful to me. There are some other examples as well. I even used that in a slightly different way for a blur effect in hires mode :) |
| |
Deev
Registered: Feb 2002
Posts: 206 |
I agree with Joe, it's actually quite an interesting "effect"!
Happy birthday Algorithm! (same day as Elvis...and an ex-girlfriend of mine!) |
| |
Oswald
Registered: Apr 2002
Posts: 5017 |
hmm looks much better than expected, I think it could look great if a graphician would invest some time to explore and use it to full potential. |
| |
Carrion
Registered: Feb 2009
Posts: 317 |
oswald:
But then we would need an editor or at least some example pallete say for photoshop to use and later convert it co tri-lace :)
I will use it if there's a converter plus the color pallete (i mean all the mixed colors as separate colors) so I could be sure that the color i use in photoshop after conversion is the one i needed.
|
| |
chatGPZ
Registered: Dec 2001
Posts: 11116 |
"looks much better than expected"
have to agree with that... i thought it'd be worse =) might be interesting to combine this with a static (not interlaced) sprite layer to mask the flickering somewhat. |
| |
algorithm
Registered: May 2002
Posts: 702 |
Relaxing at Gf's house and i still have the cheek to check this user forum :-)
A palette would not really work efficiently as there are over 500 color combinations possible. Also if one color from the mixcol combo is selected, the other 7 color mix combinations in the 8x8 are determined from the single mixcolor palette selected (with some either producing the same color or too much luma difference)
bearing in mind that there are three layers, the total amount of combinations for 3 layers would be calculated similar to the below. The below ensures that no repeated combination is used.
for (mix1=0;mix1<16;mix1++){
for (mix2=mix1;mix2<16;mix2++){
for (mix3=mix2;mix3<16;mix3++){
;write mix1,mix2,mix3 index values
}
}
}
the routine goes through all above combo patterns (obviously taking into account ink/paper combo's as well as ensuring that ink/paper combinations do not repeat in a single cell for speed.
The 8 mix color combinations are created and the analyser will then analyse all possible combinations in ink/paper layers and filter out all those that produce too much luma overload (from hand defined table)
Each pixel is then analysed and nearest mix combo is used for each 8x8 block
What I would advise would be to create the image in photoshop and to render it using the converter. perhaps using the produced mix colors for brighter area's of the image (as there are less mix col combos for brighter pixels - when removing clashing luma combos) I may add an edit feature in there to tweak and change color blocks that stand out.
When i have the time, i will add the deflickering mode to distribute pixels across frames, this should give it a considerable reduction in flicker. As mentioned previously. using FLI mode for the Tri lace would also reduce flicker considerable as the routine can use similar luma mixtures when desired without affecting high contrast area's which may be somewhere else in the block |
| |
Oswald
Registered: Apr 2002
Posts: 5017 |
Quote: "looks much better than expected"
have to agree with that... i thought it'd be worse =) might be interesting to combine this with a static (not interlaced) sprite layer to mask the flickering somewhat.
yep, but that was just a theoretical ramblin, I'd not force anyone to work in this mode, it must be very very hard, but I can imagine there can be great results if someone would invest the time.
we have seen TCH do magic in ufli, or the recent hires revolution :) |
| |
algorithm
Registered: May 2002
Posts: 702 |
Released now :-). Linux version to follow (once i have installed linux on machine!)
Tri-Lace Converter |
| |
chatGPZ
Registered: Dec 2001
Posts: 11116 |
uhm. so. someone on lemon complained the pictures dont work on ntsc. wtf? and then i looked at the displayer code .... to find out its actually plain FLI (yeah sure, one vram per bitmap only, but still, its FLI, and that every line.).
somehow that alone makes the whole thing a lot less attractive to me, the format would be semi-useful if it worked without FLI, but like this its really pointless =P it takes as much cpu as reguler FLI, and it almost takes as much memory as IFLI (but unlike FLI, it needs to be scattered around 3 video banks) |
| |
Street Tuff
Registered: Feb 2002
Posts: 88 |
just wanted to share some tri-lace converted pictures with you. some look quite nice. original gfx (from amiga/pc scene) is included in the archive.
http://www.daupara.de/trilace-results.rar
@algo
i have a little critic. multi-threaded only uses 2 cores of my quadcore. would be nice if you could change it to "threads" and then a selection box with "1,2,3 or 4" threads if possible.
|
| |
algorithm
Registered: May 2002
Posts: 702 |
I am forcing a badline per line in order to interleave the bitmaps to reduce flicker. Ofcourse the bitmaps can just be flicked together (which then would require near 0 cpu usage) and look ok'ish on a tv set (but would flicker like hell on emulators)
As mentioned by someone else in a previous post, even the interleaving looks horrible and breaks up the entire image if not viewed on a solid refresh rate but when it is displayed how it is supposed to be showed on the screen, there are hundreds of colors on screen
|
| |
algorithm
Registered: May 2002
Posts: 702 |
In Gf's house. (Gf is in hospital awaiting labour for birth anytime within the next few hours so on call waiting for the moment)
It is scattered in three sections as its the three layers that give the color increase. As mentioned before, there are some images which would look just as good in interlaced AFLI depending on the color usage. But in order to display hundreds of colors (with less errors) and not resorting to sprite underlays, the three layers are a necessity (there are other methods of utilising horizontal pal blending) but this breaks up the image quite a bit
Yes, the multicore at the moment is only utilising two cores, but can easily be changed to use all available cores.
To come also is the FLI mode of the Tri-Lace (albeit once every two lines) immense quality increase |
| |
chatGPZ
Registered: Dec 2001
Posts: 11116 |
Quote:I am forcing a badline per line in order to interleave the bitmaps to reduce flicker. Ofcourse the bitmaps can just be flicked together (which then would require near 0 cpu usage) and look ok'ish on a tv set
ok'ish? oh well. tried with 2 of the images and it simply looked plain horrible, flicker hell deluxe +++ =) |
| |
algorithm
Registered: May 2002
Posts: 702 |
Did you use real c64 and TV screen? If you read the first note in this forum post. Certainly its flicker hell as i had mentioned myself in comparison to the interleaved method. However the mix colors show through
Certainly completely unusable on non 50hz using standard page flipping. Next version will utilise frame propogation which should reduce the flicker substantially if flicking the pics using just dd00 every raster frame |
| |
chatGPZ
Registered: Dec 2001
Posts: 11116 |
Quote:Did you use real c64 and TV screen?
ofcourse i did |
| |
algorithm
Registered: May 2002
Posts: 702 |
Yes, admittingly flicking just the three bitmaps per frame (Non interleaved) will introduce more visual flicker in the present routine in the converter. (although some methods may be placed to reduce flicker further) However, I think the additional color resolution gained outweighs the flicker (real c64 and tv) The illusion of more colors is still formed. What do other users think of this? eg run one of the example trilace pics then reset and type this into vice monitor etc from $1000
sei
lda #$3b
sta $d011
lda #$08
sta $d018
lda #$00
sta $d020
lp4 ldx #$fc
lp1 cpx $d012
bne lp1
inx
lp2 cpx $d012
bne lp2
lp3 lda #$00
sta $dd00
inc lp3+1
lda lp3+1
cmp #$03
bne lp4
lda #$00
sta $kp3+1
jmp lp4
ONLY try the above on a real c64 and tell me what you think of your findings. Does the immense gain of new 'colors' as well as near 0 cpu usage outweigh the immense flickering or vice versa?
|
| |
j0x
Registered: Mar 2004
Posts: 215 |
I normally object strongly to flicker, but I was surprised at how well this works, flicking through 3, not 2 images. And I didn't even watch it on the real thing yet, just boosted Vice's speed to 120% to match my 60Hz display rate. I know this artifically improves the flickering, but that's what it would look like on an NTSC machine, if only the displayer code was compatible :)
Boosting Vice's speed like that still gives you some interference, but that is more easily ignored.
I must admit that FLI'ing reduces the usability of the format, but I'll try plain piccy flipping when I get home.
|
| |
algorithm
Registered: May 2002
Posts: 702 |
Update coming soon...
Multithread will now use more than two cores if required
NTSC/PAL exe toggle
x2 FLI mode
Super Flicker reduction. 4 shades per 8x8 block (or 8x2 if using fli mode) but colors propagated along all fields.
More accurate color matching (at the expense of taking more processing time)
On another plus note. My son Joshua Jayden born 12/01/10.:-)
|
| |
Ksubi
Account closed
Registered: Nov 2007
Posts: 87 |
algorithm: congratulations!
I actually dont mind the flickering at all, I think the "effect" can definately be used in a well designed demo. (Wonder how it would look on the big screen?)
I'm surprised at the colour quality (especially the Boris pic in the examples given), simply stunning. The richness in colour is outstanding. Great work algorithm!
|
| |
Merman
Registered: Dec 2002
Posts: 140 |
Quote: Update coming soon...
Multithread will now use more than two cores if required
NTSC/PAL exe toggle
x2 FLI mode
Super Flicker reduction. 4 shades per 8x8 block (or 8x2 if using fli mode) but colors propagated along all fields.
More accurate color matching (at the expense of taking more processing time)
On another plus note. My son Joshua Jayden born 12/01/10.:-)
Congratulations on your offspring... and the new baby :) |
| |
algorithm
Registered: May 2002
Posts: 702 |
New version uploaded :-)
http://noname.c64.org/csdb//release/?id=86870 |
| |
Oswald
Registered: Apr 2002
Posts: 5017 |
congratulations on your baby :) |
| |
The Phantom
Registered: Jan 2004
Posts: 360 |
How excited is the father?
"My son Joshua Jayden born 12/01/10"
That day is still 11 months away in Chicago.
Congrats! |
| |
Stingray
Account closed
Registered: Feb 2003
Posts: 117 |
Congratulation Algorithm on the birth of your son, always show him right from wrong because you are his Father, and then maybe, you can teach him "The Way of the 64!". |
| |
algorithm
Registered: May 2002
Posts: 702 |
Updated version
Major Bug fix in luma check flags. Previous version would sometimes discard matches and replace with bad luma combinations.
Some optimisations+ more. Click below
http://noname.c64.org/csdb//release/?id=87089 |
| |
algorithm
Registered: May 2002
Posts: 702 |
Now finally a linux version below (as well as the usual win32)
Tri-Lace Converter. Build 23-01-10
Both Win32 and Linux versions now have an additional option to render according to Brightness only (luma only mode)
|
| |
Carrion
Registered: Feb 2009
Posts: 317 |
which gui toolkit is used on windows/linux? any chance to have it on Mac?
|
| |
algorithm
Registered: May 2002
Posts: 702 |
Most of the main processing code is now written in assembler for the new release (probably the final release of this converter) below
Previously used borland C for the other progreams. GUI creation was total bliss, but was lacking in some other area's
Tri-Lace Converter. Build 25-01-10
|
| |
Copyfault
Registered: Dec 2001
Posts: 466 |
Quite interesting tool indeed. Cheers to Algorithm for reviving a little interlace madness at times non-interlace modes seem to be more fashionable;) It's variety that counts, isn't it?
However I'm wondering if you plan on making a full Tri-Fli-Version one day. This should make colour distribution even more flexible. Another interesting idea would be to mix one Hires FLI screen among two MC FLI screens (which would be equal to Hires FLI + IFLI).
Speaking of TriFli: has such mode been used in any demo before? I have a faint remembrance that someone posted smth about TriFli a while ago - unluckily I don't remember the thread. |
| |
algorithm
Registered: May 2002
Posts: 702 |
There was an article in regards to TriFLI some time ago (I believe it was the Discovery magazine. But this was not realised fully and released
Full TRI FLI is possible (Although probs with $1000 and $9000 4k banks hence duplication of screens required as well as being careful not to overwrite stack area. etc but quality increase would not be as dramatic as the change from standard hires to x2 fli.
MFLI hint hint ;-) (Hires/Mcol mix) would certainly generate less errors than standard IAFLI.
Non interlaced full screen, it would be NUFLI/MUFLI which are the ultimate graphic mode. (But of course if using slightly smaller screen, you can have FLI PER line with sprite underlay which greatly decreases the error. (XFLI etc)
|
| |
Copyfault
Registered: Dec 2001
Posts: 466 |
Quoting algorithmThere was an article in regards to TriFLI some time ago (I believe it was the Discovery magazine. But this was not realised fully and released
Sad that it has not been finalised. Nevertheless I think there was someone in another thread dropping a line like "Nothing beats TriFLI" or alike. This made me think that some TriFLI-Pic might have been released already, but obviously not.
Quoting algorithm Full TRI FLI is possible (Although probs with $1000 and $9000 4k banks hence duplication of screens required as well as being careful not to overwrite stack area. etc but quality increase would not be as dramatic as the change from standard hires to x2 fli.
I agree that Fullscreen TriFLI is tricky but doable;) Is the quality increase really that 'low'? Somehow IFLI plus an additional Hires FLI "layer" feels tempting ;)
Quoting algorithmMFLI hint hint ;-) (Hires/Mcol mix) would certainly generate less errors than standard IAFLI.
So you call it "MFLI" what I call "ILM" :)). Wonder why you didn't release a converter for that mode already. Should be close to no effort with all the converter code that you've done so far...
Quoting algorithmNon interlaced full screen, it would be NUFLI/MUFLI which are the ultimate graphic mode. (But of course if using slightly smaller screen, you can have FLI PER line with sprite underlay which greatly decreases the error. (XFLI etc)
Wasn't someone rambling about an UFLIMAX mode a long time ago? Wouldn't that one be even "better" than NUFLI? Hmm, I should better check all the NUFLI features again in order to sort that out... |
| |
algorithm
Registered: May 2002
Posts: 702 |
Quote: Quoting algorithmThere was an article in regards to TriFLI some time ago (I believe it was the Discovery magazine. But this was not realised fully and released
Sad that it has not been finalised. Nevertheless I think there was someone in another thread dropping a line like "Nothing beats TriFLI" or alike. This made me think that some TriFLI-Pic might have been released already, but obviously not.
Quoting algorithm Full TRI FLI is possible (Although probs with $1000 and $9000 4k banks hence duplication of screens required as well as being careful not to overwrite stack area. etc but quality increase would not be as dramatic as the change from standard hires to x2 fli.
I agree that Fullscreen TriFLI is tricky but doable;) Is the quality increase really that 'low'? Somehow IFLI plus an additional Hires FLI "layer" feels tempting ;)
Quoting algorithmMFLI hint hint ;-) (Hires/Mcol mix) would certainly generate less errors than standard IAFLI.
So you call it "MFLI" what I call "ILM" :)). Wonder why you didn't release a converter for that mode already. Should be close to no effort with all the converter code that you've done so far...
Quoting algorithmNon interlaced full screen, it would be NUFLI/MUFLI which are the ultimate graphic mode. (But of course if using slightly smaller screen, you can have FLI PER line with sprite underlay which greatly decreases the error. (XFLI etc)
Wasn't someone rambling about an UFLIMAX mode a long time ago? Wouldn't that one be even "better" than NUFLI? Hmm, I should better check all the NUFLI features again in order to sort that out...
That article on TriFLI was actually only referring to 4 standard hires bitmap screens. not sure where the FLI came from. I remember someone posting something like this too. As far as I am aware. the only screenmode (apart from the images via my converter) that flicks more than three screens is in the Goa Brudbilder series (but that flicks 4 petscii screens
The huge amount of ram usage in True per line FLI in three screens is a severe disadvantage in comparison with the quality attainable in the x2 fli mode. I may include this feature (planned in one of the forthcoming parts of a production)however. Ofcourse perline FLI would result in a higher definition image.
MFLI is near or enough ready. I am planning on releasing some tools after demo is produced. (including ofcourse the CSAM2 and CAudio tools) 60 bytes per frame video and 60 bytes per second compressed audio :-) hope i have not given that much away :-)
FLI per line in the UFLI etc would certainly result in a dramatic increase in visual quality (ofcourse fully dependant on the converter as well).
|
| |
Repose
Registered: Oct 2010
Posts: 222 |
Quote:There was an article in regards to TriFLI some time ago (I believe it was the Discovery magazine. But this was not realised fully and released
Yeah, that was me who thought of that 12 years ago. The problem was running into the char roms of course. I solved that by using "conserved memory", where the color map was partially inside the bitmap. Of course this reduced screen area (and you can simply crop the stack and not worry about it). Certainly 3xcolor maps is a cheap way to approach it too.
My plan was actually to take a long exposure photo of the screen to see the flicker-free picture (with r/g/b and many frames, you can make 24bit color!). Nowadays I would cap it, untangle the odd-fields only mess, then merge every 3 frames in Avisynth.
http://www.ffd2.com/fridge/discovery/ Discovery, Issue 1
I remember people were bugging me to release it, but I don't care about fame, I just like to experiment. I can't believe it took this long for someone to release it! And I doubt we're the only two people in the world to think of it??
Anyhow I wanted to mention that I also solved the algorithm for instant fli coloring. I can't tell you exactly off the top of my head, but you need *unique* frequency counts of colors per line, per char, and per row.
I remember calculating how long it would take in brute force and wondering how many years before computers were fast enough to do it :) So I find it rather amusing that the nufli editor(?) has a brute force mode.
I do have a BMP converter I could release; I made it in Qbasic and it needs slight modification to compile in FreeBasic.
As for the remaining errors, I found a solution for that too. Just integrate it into your dither algorithm. And remember you can *fudge* the colors on purpose to nearby ones, with a priority on tint for example, and automatically, to fix errors. The least error solution isn't always the best looking! Also for pixelers; save a table of all equal-error possibilities and let the user choose which looks best.
I met an Amiga guy who wrote part of Deluxe Paint(?) where he wrote assembly to optimize the HAM mode to fix the last drawn object; it's a similar type of algorithm. He was quite proud of solving it. |
| |
algorithm
Registered: May 2002
Posts: 702 |
Quote: Quote:There was an article in regards to TriFLI some time ago (I believe it was the Discovery magazine. But this was not realised fully and released
Yeah, that was me who thought of that 12 years ago. The problem was running into the char roms of course. I solved that by using "conserved memory", where the color map was partially inside the bitmap. Of course this reduced screen area (and you can simply crop the stack and not worry about it). Certainly 3xcolor maps is a cheap way to approach it too.
My plan was actually to take a long exposure photo of the screen to see the flicker-free picture (with r/g/b and many frames, you can make 24bit color!). Nowadays I would cap it, untangle the odd-fields only mess, then merge every 3 frames in Avisynth.
http://www.ffd2.com/fridge/discovery/ Discovery, Issue 1
I remember people were bugging me to release it, but I don't care about fame, I just like to experiment. I can't believe it took this long for someone to release it! And I doubt we're the only two people in the world to think of it??
Anyhow I wanted to mention that I also solved the algorithm for instant fli coloring. I can't tell you exactly off the top of my head, but you need *unique* frequency counts of colors per line, per char, and per row.
I remember calculating how long it would take in brute force and wondering how many years before computers were fast enough to do it :) So I find it rather amusing that the nufli editor(?) has a brute force mode.
I do have a BMP converter I could release; I made it in Qbasic and it needs slight modification to compile in FreeBasic.
As for the remaining errors, I found a solution for that too. Just integrate it into your dither algorithm. And remember you can *fudge* the colors on purpose to nearby ones, with a priority on tint for example, and automatically, to fix errors. The least error solution isn't always the best looking! Also for pixelers; save a table of all equal-error possibilities and let the user choose which looks best.
I met an Amiga guy who wrote part of Deluxe Paint(?) where he wrote assembly to optimize the HAM mode to fix the last drawn object; it's a similar type of algorithm. He was quite proud of solving it.
Yes certainly FLI per line in three screens would have restrictions on the screen size hence why I opted to have FLI per two lines instead.
It was just an experiment and only recommended if that to view it on a real c64.
The routine is purely a 'least error' brute force which looks at every single combination of colors in the three fields (with each 8x2 section on each field comprising of two colors. There is an inbuilt luma checker which discards any color combination which would be 'out of range' This would normally take a long time to compute but i have multithreaded the routine and using assembly instructions when needed and still takes a considerable amount of time. The color dither is embedded into the converter too and yes i do agree that the least error method is not always the best method.
Not taking the luma check into account or making it more lenient would give the possibility of many more colors (and colors in theory that would mix well do not at all in practice (eg black+white=not mid grey)
The issue with instant FLI coloring 'on the fly' and different colors per field is that it would result in many color combinations being out of the 'luma similarity' and with the approach of having same ink/paper per field or specific frequency of certain colors would give less flicker (due to evenly distributing pixels across frames) but less color range per block.
|
| |
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. |
