| |
Dragnet
Registered: Nov 2006
Posts: 16 |
FLI explained, please...
Hola,
I'm looking for an easy-understandable-for-a-novice description, preferably with a *documented* example to go along with it, of how FLI actually works, including a description of how the colordata is stored (so i'll know how to manipulate it). My C64 skills are very novice/rusty indeed, so the more documentation, the better...
I have already been searching this forum and the C64 codebase for the sorts, but found what seems like a trillion different FLI formats (FLI, AFLI, XFLI, IFLI, MUFLI, etc) with different resolutions... But, I'm merely thinking of "normal fli" (if there is such a thing) capable of handling a width of 40 chars (and at least a height of 10 chars), no sprites involved, and 16 colours per char, running as part of the normal IRQ. Make sense?
Furthermore, a reference to a drawing-program that can save in the explained format, or at least in a format that can be converted into it, would be very nice!
That's not much to ask for, is it? :)
Any help will be greatly appreciated...!
Regards /Dragnet |
|
| |
MagerValp
Registered: Dec 2001
Posts: 1078 |
http://www.ffd2.com/fridge/chacking/c=hacking4.txt |
| |
Mace
Registered: May 2002
Posts: 1799 |
FLI with a width of 40 chars is only possible if you allow for some chars to the left to only have light grey or background colour.
This is know as the 'FLI bug' and it's ALWAYS there. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
technically FLI _is_ possible in all 40 chars... you just have to stretch the videoram and use a fpp like routine. |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
I always considered FLI a forced DMA with VIC line pointer _advance_ though, not a forced DMA with VIC line pointer _reset_ (= forced bad line). That difference is exactly why both are 3 cycles apart and one has this 3-chars bug to the left.. :)
Anyways, yes, you can emulate FLI by using forced bad lines, but you'll quickly run out of unique lines.. |
| |
Graham
Account closed
Registered: Dec 2002
Posts: 990 |
8 rasterlines to be exact.
|
| |
Krill
Registered: Apr 2002
Posts: 2980 |
Well, yes, FLI also updates the $d800 colours every 8 lines, while forced bad lines (FPP) doesn't. |
| |
Mace
Registered: May 2002
Posts: 1799 |
Stretch videoram, FPP routine, forced bad lines... this is why FLI never has been my thing.
I've never been a 'hardware' coder. |
| |
MagerValp
Registered: Dec 2001
Posts: 1078 |
I'd just like to point out that in the FLI bug area you have background color, light gray, and one color that depends on the CPU instruction following the FLI code. Using illegals you can select any of the 16 colors. The next version of Executable Image supports changing the FLI bug color to any color on every line, but unfortunately I don't think there are any tools that let you save an image with that information. FLI Profi is the only editor that lets you edit the area, but it saves an executable program...
|
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
Quote: I'd just like to point out that in the FLI bug area you have background color, light gray, and one color that depends on the CPU instruction following the FLI code. Using illegals you can select any of the 16 colors. The next version of Executable Image supports changing the FLI bug color to any color on every line, but unfortunately I don't think there are any tools that let you save an image with that information. FLI Profi is the only editor that lets you edit the area, but it saves an executable program...
Timanthes has that option, or at least hidden. |
| |
Mace
Registered: May 2002
Posts: 1799 |
Quote:one color that depends on the CPU instruction following the FLI code Cool, didn't know that :) |
| |
Dragnet
Registered: Nov 2006
Posts: 16 |
Hola,
Well, I thought the FLI bug had been fixed years ago, cause I seem to remember several demos using what to me seemed like 40 chars of FLI (last I used FLI, merely as a fixed image, was in 1993 using Black Mails old editor, I think... :) ). That's way I asked for 40 chars, but must have been cleverly designed images or just me not understanding what I was looking at... 37 chars will do just fine for me; well, actually 34 to make it nice and symetrical! :)
Anyways - thanks for the replies, and especially the link to the explanation, MagerValp! Would still like some actual documented code examples, though. The discussion here quickly turned way too technical for me - I guess there is no way around me doing some serious homework regarding the technical side of the beloved breadbox!
Regards /Dragnet |
| |
Frantic
Registered: Mar 2003
Posts: 1648 |
There is some stuff on codebase on FLI:
http://codebase64.org/doku.php?id=base:vic#custom_graphics_modes
Maybe of interest for you? |
| |
Graham
Account closed
Registered: Dec 2002
Posts: 990 |
Atleast every 8th rasterline of an FLI picture can have full 40 chars width. And then you can always use the FLI-bug colors + sprites + rasterbars to make the bug area more useful.
|
| |
MagerValp
Registered: Dec 2001
Posts: 1078 |
Quote: Hola,
Well, I thought the FLI bug had been fixed years ago, cause I seem to remember several demos using what to me seemed like 40 chars of FLI (last I used FLI, merely as a fixed image, was in 1993 using Black Mails old editor, I think... :) ). That's way I asked for 40 chars, but must have been cleverly designed images or just me not understanding what I was looking at... 37 chars will do just fine for me; well, actually 34 to make it nice and symetrical! :)
Anyways - thanks for the replies, and especially the link to the explanation, MagerValp! Would still like some actual documented code examples, though. The discussion here quickly turned way too technical for me - I guess there is no way around me doing some serious homework regarding the technical side of the beloved breadbox!
Regards /Dragnet
If the picture is designed with the limitations of the FLI bug area in mind, the casual viewer will not know that it's there. The undisputed master of this is Mirage:
Oh Noes, They Be Stealing My Bench
Ms. Pac Man
Fundamentals of Icosahedral Symmetry
Donkey Kong -1LIFE/PAL
Space Invaders
...so how do you get Timanthes to save FLI bug colors?
|
| |
Hein
Registered: Apr 2004
Posts: 954 |
Quote: If the picture is designed with the limitations of the FLI bug area in mind, the casual viewer will not know that it's there. The undisputed master of this is Mirage:
Oh Noes, They Be Stealing My Bench
Ms. Pac Man
Fundamentals of Icosahedral Symmetry
Donkey Kong -1LIFE/PAL
Space Invaders
...so how do you get Timanthes to save FLI bug colors?
By pressing 'save' |
| |
Mace
Registered: May 2002
Posts: 1799 |
...I think he meant "in what format is the FLI bug colour stored inside the file" :-)
No he doesn't... |
| |
MagerValp
Registered: Dec 2001
Posts: 1078 |
I don't remember seeing that in the Export As dialog, and I can't test it as Timanthes has decided to crash every damn time I click save or export...
|
| |
Scout
Registered: Dec 2002
Posts: 1570 |
Quote: I don't remember seeing that in the Export As dialog, and I can't test it as Timanthes has decided to crash every damn time I click save or export...
Mirage uploaded a more recent executable not so long ago. Tried that? |
| |
MagerValp
Registered: Dec 2001
Posts: 1078 |
The executable is date stamped 2009-02-20, and the About box says Final Debug Build 3.0.3338.37500. I think that's the latest.
|
| |
Scout
Registered: Dec 2002
Posts: 1570 |
Quote: The executable is date stamped 2009-02-20, and the About box says Final Debug Build 3.0.3338.37500. I think that's the latest.
Yup, it is. |
| |
Dragnet
Registered: Nov 2006
Posts: 16 |
Hola,
Hmm - can't believe I missed Graham's code posted at codebase64, since it is nice and neat - and very well documented! Thanks for the link, Frantic!
I think I have got the basics of FLI right by now, though one thing still puzzles me; quoting the text accompagning Graham's code at codebase64:
"You also can use this for hires FLI, however the first 3 char columns will only show a light grey area. To remove this area, a sprite would be required which takes 5 extra clock cycles per rasterline. This is possible if you unroll the main FLI display loop."
So - what is the alternative to using hires (same as bitmap, right?)? How else can you set the colours individually for each char?
Regards /Dragnet |
| |
MagerValp
Registered: Dec 2001
Posts: 1078 |
Hires, as opposed to multicolor. Not bitmap vs char mode.
|
| |
HCL
Registered: Feb 2003
Posts: 728 |
Hmm.. just to be picky: I'd say Hires(320x200) <> Lores(160x200). MultiColor(~4 colors per char) <> SingleColor (~2 colors per char). Bitmap <> Char.
VIC only allows Hires together with SingleColor, if you want MultiColor you have to go Lores. Then there are all kinds of software tweeks to get *multiple colors* in Hires of course :). I just think that "Hires, as opposed to multicolor" only helps to make the c64-world less understandable :P.
SC-Hires/MC-Lores you set with $d016 bit4.
Bitmap/Char is set with $d011 bit5,6.
|
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
Quote: Hmm.. just to be picky: I'd say Hires(320x200) <> Lores(160x200). MultiColor(~4 colors per char) <> SingleColor (~2 colors per char). Bitmap <> Char.
VIC only allows Hires together with SingleColor, if you want MultiColor you have to go Lores. Then there are all kinds of software tweeks to get *multiple colors* in Hires of course :). I just think that "Hires, as opposed to multicolor" only helps to make the c64-world less understandable :P.
SC-Hires/MC-Lores you set with $d016 bit4.
Bitmap/Char is set with $d011 bit5,6.
I fully agree with HCL - but that's just my way of licking his ass for potential future favours I might ask him. :) |
| |
Ninja
Registered: Jan 2002
Posts: 411 |
To be _extremly_ nutpicky (while I generally agree): calling it SingleColor and having 2 colors/char in bitmap mode has its odds, too ;) (It will do, though...) |
| |
enthusi
Registered: May 2004
Posts: 677 |
I *think* some people use the term "HiRes" to actually describe that standard hires mode. I like to call it TRUE hires (when in fact colors are used per char-block).
Calling the beautyful hires "singlecolor" is indeed a bad idea. There are enough confusing names for modes. WRONG names wont help much and also wont do justice to the awesome HiRes art performed especially during the last months...
So maybe 'HiRes' or 'TrueHires' is an idea? ;-) |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
"VIC only allows Hires together with SingleColor"
"I like to call it TRUE hires"
o_O
Singlecolor = lda #0 sta d011.
true hires = WTF?!
Multicolor Bitmap
Hires Bitmap
Multicolor Charmode
Hires Charmode
ECM Charmode
done. |
| |
MagerValp
Registered: Dec 2001
Posts: 1078 |
/me agrees with bogár.
|
| |
HCL
Registered: Feb 2003
Posts: 728 |
I don't know.. is there a problem with the terms MultiColor and SingleColor!? Yes, if you're weirdo enough you may claim that SingleColor === lda#0 sta$d011. Tho i'm fairly ok with SingleColor meaning that you only have one color except for teh background. No?
Perhaps the term SingleColor is more applicable on sprites, which indeed only have one color plus transparent. I always used the same term for chars..
So.. my list is:
MultiColor Bitmap
SingleColor Bitmap
MultiColor Charmode
SingleColor Charmode
ECM Charmode
..just to be bogár me also :).
|
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
in singlecolor you have more than 1 color+the background. thats only true for one char cell. if on irc we would chat about coding, and you would say "singlecolor" I would surely ask back "you mean hires?". but if I would say "hires chars" or "hires bitmap" you wouldnt need to ask back what do I mean. :)
anyway use it if you like it. :)
btw still dont get what do you mean with "VIC only allows Hires together with SingleColor" ? that shows how confusing and misleading is this term. There's Hires and Multicolor, Singlecolor is confusing. You use 2 terms on the same thing in one sentence and claim one of them is prequisite of the other...
|
| |
Frantic
Registered: Mar 2003
Posts: 1648 |
"Singlecolor" is for cp-mongos. It is called hires! |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
Ok, and while we're at choosing some sane names for C64 stuff, let's fight weirdo terms like flexible line distance, flexible pixel position, IFFL (sorry, too lazy to look up what that crud means), crunching, etc.pp. :D |
| |
Dragnet
Registered: Nov 2006
Posts: 16 |
Quote: in singlecolor you have more than 1 color+the background. thats only true for one char cell. if on irc we would chat about coding, and you would say "singlecolor" I would surely ask back "you mean hires?". but if I would say "hires chars" or "hires bitmap" you wouldnt need to ask back what do I mean. :)
anyway use it if you like it. :)
btw still dont get what do you mean with "VIC only allows Hires together with SingleColor" ? that shows how confusing and misleading is this term. There's Hires and Multicolor, Singlecolor is confusing. You use 2 terms on the same thing in one sentence and claim one of them is prequisite of the other...
Surprise, surprise - I'm still confused.
I understand the terms listed above, e.g. hires vs. multicoler, bitmap vs chars, but do not understand how hires goes together with FLI!? And I still have no clue as to what ECM is, but nevermind...
Anyways, if I read Grahams FLI code correctly from codebase64 (see link somewhere above), colours stored in $d800 are fixed, set on init. Does this (per char) correspond to the background colour or the individual colour per char? Point is, if its the individual colour per char, then how can the FLI technique offer more colours per char, eventhough we split per rasterline? Hence, it must be what is referred to as the background colour of the char, and additional colour ram (for hires bitmap, must be what corresponds to $4000 in Grahams example code) is what constitutes individual char colours. Ergo, this means that hires FLI gives you a total of 1+8 colours per char (plus $d020 value), allowing for two colours per rasterline per char, where one of the two is always the same for the entire char!? Is this correct, or did I just make an arse of myself as usual...? :)
Also, my initial question concerning the colour ram was actually more on how the colour ram is laid out in memory (not the fixed $d800 colours) for "normal" FLI (lores multicolour!). Say, if the colourram starts at $4000, then what is the memory location of the colour ram for the first line in the first char (ok, $4000 I guess for that one... hehe), for the 2nd line in the first char, etc, then for the first line in the second char, etc. Point is, the exact locations must naturally be known to manipulate the colours of a given char. I know this information can probably be deduced from the values stored in $d011 and $d018 in Grahams example, but damn if I know how...
Regards /Dragnet
|
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
Quote: Surprise, surprise - I'm still confused.
I understand the terms listed above, e.g. hires vs. multicoler, bitmap vs chars, but do not understand how hires goes together with FLI!? And I still have no clue as to what ECM is, but nevermind...
Anyways, if I read Grahams FLI code correctly from codebase64 (see link somewhere above), colours stored in $d800 are fixed, set on init. Does this (per char) correspond to the background colour or the individual colour per char? Point is, if its the individual colour per char, then how can the FLI technique offer more colours per char, eventhough we split per rasterline? Hence, it must be what is referred to as the background colour of the char, and additional colour ram (for hires bitmap, must be what corresponds to $4000 in Grahams example code) is what constitutes individual char colours. Ergo, this means that hires FLI gives you a total of 1+8 colours per char (plus $d020 value), allowing for two colours per rasterline per char, where one of the two is always the same for the entire char!? Is this correct, or did I just make an arse of myself as usual...? :)
Also, my initial question concerning the colour ram was actually more on how the colour ram is laid out in memory (not the fixed $d800 colours) for "normal" FLI (lores multicolour!). Say, if the colourram starts at $4000, then what is the memory location of the colour ram for the first line in the first char (ok, $4000 I guess for that one... hehe), for the 2nd line in the first char, etc, then for the first line in the second char, etc. Point is, the exact locations must naturally be known to manipulate the colours of a given char. I know this information can probably be deduced from the values stored in $d011 and $d018 in Grahams example, but damn if I know how...
Regards /Dragnet
Hires FLI, more known as AFLI gives you two unique colors per char and raster line.
Normal FLI gives you one common background color. the $d800 colors per char. and two extra unique colors per char and raster line.
FLI simply fetches new color data from screen memory each rasterline. So the memory layout is simple, each color-screen corresponds to the current raster line within a char. Other than that the screens are access like normal.
screen-index: y & 7
screen-pos: (x/8)+(y/8)*40
0<=x<=319 0<=y<=199
|
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
ok, FLI explained:
make sure you understand how multicolor/hires bitmaps works:
http://codebase64.org/doku.php?id=base:built_in_screen_modes
multicolor fli:
same as multicolor bitmap, except:
you change the location of the screen memory on every rasterline. using 8 screen memory to have a unique scr mem for each 8 lines of each chars.
hires fli:
same as hires bitmap, except:
see above.
naturally $d021 and & d800 doesnt come to play in here. (see the hires bitmap on the link again if you dont get this) |
| |
MagerValp
Registered: Dec 2001
Posts: 1078 |
Quote: Ok, and while we're at choosing some sane names for C64 stuff, let's fight weirdo terms like flexible line distance, flexible pixel position, IFFL (sorry, too lazy to look up what that crud means), crunching, etc.pp. :D
Flexible Line Distance makes perfect sense, IMHO. FPP not so much, and IFFL doesn't even really mean anything :) |
| |
Dragnet
Registered: Nov 2006
Posts: 16 |
Hola,
I get it... Finally... :)
What got me confused, I guess, was that I had forgotten that the screen can reside in numerous memory locations, e.g. $0400 or $4000, which makes the concept of FLI a bit hard to grasp concerning memory layout. Hence, the memory location (layout) *is* the screen colour data, not some arbitrary format stored to the screen...
Thanks for all the replies...!
Regards /Dragnet
|
| |
Skate
Registered: Jul 2003
Posts: 494 |
About naming the graphic modes, why don't we give animal names to graphic modes? We wouldn't have any problems by choosing names like hires/single color/almost square (makes sense actually ;)) gfx mode. I vote on Kangaroo and Koala :D
Koala
Kangaroo
Koala Char
Kangaroo Char
<write any Australian animal name here for ECM> Char
Case is closed... |
| |
Ksubi
Account closed
Registered: Nov 2007
Posts: 87 |
ECM=Echidna Character Mode :)
|
| |
Jetboy
Registered: Jul 2006
Posts: 337 |
Quote: Flexible Line Distance makes perfect sense, IMHO. FPP not so much, and IFFL doesn't even really mean anything :)
IFFL means Interleaved File Fast Loader |
| |
Mace
Registered: May 2002
Posts: 1799 |
IFFL = InterFlexible File Loader, according to Snacky.
Or Integrated File Flexible Loader according to Cadaver and Soci.
I can hardly imagine one of the Fs ever stood for 'fast' as IFFL was anything but fast when it was invented.
But we digress... |
| |
HCL
Registered: Feb 2003
Posts: 728 |
..continue: I don't know if you guys read some C=64-manual from 1980 or something to get the understanding that "Hires" is the exact opposite to "MultiColor". The two words are totally orthogonal.
That's why i like the less VIC-dependant terms Hires vs Lores, MultiColor vs singleColor etc..
|
| |
MagerValp
Registered: Dec 2001
Posts: 1078 |
Digression FTW.
IFFL is a bit of a retronym though... What we mean by IFFL today (loading files from within an archive, fast T/S scan at startup) isn't what was meant 20 years ago.
But the worst effect name must be tech-tech.
|
| |
Mace
Registered: May 2002
Posts: 1799 |
Quote:But the worst effect name must be tech-tech. Haha, true! :D |
| |
Skate
Registered: Jul 2003
Posts: 494 |
No! Tech-Tech is an incredible effect name, but only for Turkish people :) Tech is pronounced as "tek" in Turkish which means one, mono, single etc. So, when it comes to tech-tech, "tek tek" means "one by one" in Turkish. Since raster lines make horizontal moves one by one, it's a very self-explanatory name for us. :D |
| |
HCL
Registered: Feb 2003
Posts: 728 |
@skate: Changing "tech-tech" to "one-by-one" wouldn't make any sense to me :/, "tech-tech" neither :P. |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
Quote: @skate: Changing "tech-tech" to "one-by-one" wouldn't make any sense to me :/, "tech-tech" neither :P.
The name tech-tech comes from this demo iirc: http://www.pouet.net/prod.php?which=4445 |
| |
Skate
Registered: Jul 2003
Posts: 494 |
@HCL: We can rename it to (H)armonically (C)reeping (L)ines if you prefer ;) |
| |
LOGAN
Account closed
Registered: Aug 2003
Posts: |
Retrofitting new names to old techniques seems pretty useless because it will render old documentation/references pretty useless and will add to the confusion.
So FLI AFLI HFLI WhateverFLI would be good. I still hope to find the memory layout and display routine for every graphic format around (and every graphic editor) to have a neat tight code library for them all. |
| |
MagerValp
Registered: Dec 2001
Posts: 1078 |
Quote: Retrofitting new names to old techniques seems pretty useless because it will render old documentation/references pretty useless and will add to the confusion.
So FLI AFLI HFLI WhateverFLI would be good. I still hope to find the memory layout and display routine for every graphic format around (and every graphic editor) to have a neat tight code library for them all.
Executable Image has viewers for the most popular formats, and source is included. Release 3 will include Hires, Multicolor, MCI/Drazlace, AFLI, FLI, and IFLI.
You can find a comprehensive list of file formats on codebase: http://codebase64.org/doku.php?id=base:c64_grafix_files_specs_l.. |
