| |
jailbird
Registered: Dec 2001
Posts: 1576 |
UFLI - Behind the scenes
I thought about opening this topic to have a sensible discussion about C64 pixelling for a change. UFLI in this case. I'm still testing the editor and basically like it very much. So first of all, I'd also like to encourage other graphicians to have a try - noone said yet that it's a smooth, well designed editor with a surface that could bring a of lot of fun, even for the beginners. The tehnique is actually not die hard to learn as it looks at the first sight, and as I see, with a lot of practice a good skill level could be achieved. Secondly, I'd like to discuss the different UFLI tehniques, to share the experiences. And I'd especially like to hear some tricks from the UFLI-master himself, Tch! ;) Anyone into this? Tch, Deev, others? :)
|
|
| |
MRT
Account closed
Registered: Sep 2005
Posts: 149 |
Just to check...
UFLI uses a badline every two lines on a hires screen (not multicolor) and uses (hires) sprites to give extra color depth to certain points of the image (sprites are not every where over the image but possitioned in different places)
Is this correct?
And if so, are sprite colors changed every line (or two lines) and is the sprite x-pos also changed every (two) lines?
|
| |
Dane
Account closed
Registered: May 2002
Posts: 421 |
No, UFLI uses a layer of expanded hires-sprites UNDERNEATH the hires, meaning the 2x1 pixels place themselves between foreground and background colour.
There are no sprite-colour or x-pos changes in standard UFLI. |
| |
MRT
Account closed
Registered: Sep 2005
Posts: 149 |
Ok, so the sprites have one color each or all the same color?
XUFLI = Extended UFLI!!!!
Lets see, would it be possible to change the sprite colors every 2 rasterlines?
(on PAL)
63 cc per rasterline = 126 cc
1 badline = 40 cc
126 cc - 40 cc = 86 cc
7 sprites per rasterline = 1(or 2?) + (2 * 7) = 15 cc
15 cc * 2 rasterlines = 30 cc
86 cc - 30 cc = 56 cc
to update screen and badline per 2 rasterlines:
at least 12 cc (hard coded: lda #xx sta $xxxx)
56 cc - 12 cc = 44 cc
to update 7 sprite colors per 2 rasterlines:
at least 6 cc * 7 sprites = 42 cc
44 cc - 42 cc = 2 cc
One nop to spare...
Edit:
Oh no... We also need to move the y-pos of the sprites and update the sprite pointers...
:-(
Can prolly be done when creating one badline every three rasterlines... That gives 63 cc - 15 cc extra time
|
| |
Dane
Account closed
Registered: May 2002
Posts: 421 |
When painting you won't REALLY need to change all spritecolors every 2nd line. So just make an editor with some flexibility where colorchanges are concerned.
Oh wait, I already did that. Oops! |
| |
WVL
Registered: Mar 2002
Posts: 886 |
MRT : see my posting in this topic : http://noname.c64.org/csdb/forums/?roomid=11&topicid=18053&show.. |
| |
Tch
Account closed
Registered: Sep 2004
Posts: 512 |
Yes, finally there is the increased interest for UFLI that I hoped for. 8D
Oh,and MRT,there is no need to change y-pos,the sprites are `stretched´ from top to bottom. ;)
As for some tricks that I use..
Use a sprite-colour that is somewhere in the middle of the colours you are going to use.
That´s also the main reason why V2 was released,you won´t be stuck with one sprite-colour for the entire screen.
Another very useful option is NIBBLE.
This does an EOR #$FF in the little 8x2 block and allows you to make better use of the sprite-overlapping pixels.
For the rest it is the same as any AFLI editor,I guess.
Totally agree with Jailbird that the editor is easy to use.
First time I saw it,it looked impossible to work with,but it turned out to be simple as hell! 8D |
| |
Oswald
Registered: Apr 2002
Posts: 5018 |
just playing with ideas...
1. ufli with 5 sprites and fli every line is possible according to hcl, well IMHO a 30 char pic in that style would be neat
2. or we can go for 168 lines and 36 chars width, this is the other side of the compromise.
3. I smell that in "normal" ufli there's space for changing the sprite colors, am I right ? this could raise the quality of normal UFLI pics a lot, and I strongly think that this would give more flexibility than any of the 2 options above and UFLI MAX. Think AFLI... every 2 or every line doesnt makes a huge difference in the limitations, but being able to stick there the desired color from the sprites with more freedom in the sprite color gives more freedom imho. (what's the gfxer opinion ?
4. to mix things up even more, what do u (gfxers) think of a mode wich is like ufli, but with x expanded multicolor sprites ?
6. coming back to ufli max, anyone thought of the memory layout ? If I'm correct there wont be enough ram to store them. |
| |
Dane
Account closed
Registered: May 2002
Posts: 421 |
Good to see the scene catching up. ;) |
| |
Deev
Registered: Feb 2002
Posts: 206 |
Oswald,
The possibility of changing individual sprite colours, rather than just the columns would be good. Obviously the columns took it that step further, but individual sprite colours would increase the flexibility all the more. Whilst FLI every line would be good, I would prefer being able to change sprite colours if it were one or the other.
I've thought about the usefulness of multicolour sprites before. The "pixels" would then be 4x1 which is pretty large, though it may have it's uses. It would be good if you could switch individual sprites between multicolour and single colour (sorry, I'm getting carried away now :p) |
| |
Oswald
Registered: Apr 2002
Posts: 5018 |
Deev: IIRC Dane's editor makes it possible for the user to select each xth rasterline, a value and a register to write to. Tho one has to really know what he does when messing with this, and I'm not talking about writing random values into random places, but playing with this possibility introduces kinda an editing horror, when you change such a setting to another. |
| |
MRT
Account closed
Registered: Sep 2005
Posts: 149 |
@WVL: That's in German dude, and I totally suck at German... Go eat some Hutspot :-)
@TCH: Why are sprites stretched? That way it isn't possible to have a 1x2 pixel, is it? only a ?x2 pixel...
So, updating y-pos every line, takes more time, but gives more flexibility.
@Oswald:
UFLI every rasterline with 5 sprites?
63 cc - 40 cc = 23 cc
(5 * 2) + 2 = 12 cc
23 cc - 12 cc = 11 cc
Code needed to update $d011 and $d016 takes at least 12 cc???
lda #$xx
sta $d011
lda #$xx
sta $d016
And then you still have to update those sprites...
The Dane method is prolly the best and the most flexible way... ...but not all gfx artists are also coders... :-)
|
| |
Oswald
Registered: Apr 2002
Posts: 5018 |
MRT, I'm not a Vic magician but as I know you can steal back up to 3 cycles with an RMW instruction. |
| |
Cruzer
Registered: Dec 2001
Posts: 1048 |
Anyone knows how it's going with the UFLI MAX mode NoiseEHC was bragging about in this thread from last fall?... http://noname.c64.org/csdb/forums/?roomid=11&topicid=18053&show..
|
| |
HCL
Registered: Feb 2003
Posts: 716 |
Until i see something, i assume it's a fake :). |
| |
MRT
Account closed
Registered: Sep 2005
Posts: 149 |
@Oswald:
Then still... You won't have enough cycles left to update the sprites i.m.o. :-( |
| |
WVL
Registered: Mar 2002
Posts: 886 |
Quote: @Oswald:
Then still... You won't have enough cycles left to update the sprites i.m.o. :-(
you get 2x1 sprite resolution because the double-pixel-high sprite pixels are mismatched with the d018 switch.
so the first pixel of the double-high sprite pixel will get its sprite images from $63f8 (f.e.), then d018 gets switched, and the bottom pixel of the double-high sprite pixel will read the sprite image data from $67f8 (f.e.)
It's the same trick you can use in FLI modes, so you can use y-expanded sprites and still have normal resolution. |
| |
Cruzer
Registered: Dec 2001
Posts: 1048 |
But the sprite crunching/stretching trick can't produce 200 lines, so you still need to update the Y's somewhere, right? |
| |
Tch
Account closed
Registered: Sep 2004
Posts: 512 |
@MRT: What do you need $D016 for? ;) |
| |
WVL
Registered: Mar 2002
Posts: 886 |
Quote: But the sprite crunching/stretching trick can't produce 200 lines, so you still need to update the Y's somewhere, right?
ofcourse this only stretches the sprites up to 42 pixels. Then you have to multiplex them, but there's enough time if you change d018 in a order like this
#$08
#$18
#$28
#$38
;end of first row
#$38 (ie, no change!, so 6 cycles left here!!)
#$28
#$18
#$08
;end of 2nd row
#$08 (no change again)
etc |
| |
Cruzer
Registered: Dec 2001
Posts: 1048 |
@WWL: That's right, I had completely forgotten about that kewl trick. Thanks for reminding me, I gotta remember that now. I bet it can come in handy for something. |
| |
DeeKay
Registered: Nov 2002
Posts: 362 |
Tch:
Quote:
For the rest it is the same as any AFLI editor,I guess.
Totally agree with Jailbird that the editor is easy to use.
First time I saw it,it looked impossible to work with,but it turned out to be simple as hell! 8D
Finally people realize that i didn't tell Crossbow to make this extra complicated, it is actually pretty straightforward! ;-) This one was built for pixellers, and we did spend a considerable time on usability and visualizing the complex mode most easily (look at how the F-Keys are assigned f.ex.!)
I realized just HOW simple it actually is when i explained the whole editor to DCMP on Breakpoint - in about 5 minutes! 8)
Dane:
Quote:
Good to see the scene catching up. ;)
Ah come on, Stellan, stop with the arrogance already! <:-)
I dislike the idea of using expanded multicolor sprites. That would probably only be useful when interlaced. The 4x1 pixels (that's HALF a char!) kill the reason i came up with the idea of UFLI in the first place ('twas on some campsite in France IIRC, just incase you wondered! ;-): I wanted to have a mode that i could do arbitrary single-pixel hires-outlines around a logo with one color and the background in another color! We did have SHF already back then that could do this, but it was just too small... I had been working _alot_ in AFLI before, and this 2-color per 8-pixel limitation was one of the things that really did piss me off! ;-)
Well, have a guess what i made first with the Editor! ;-) See Krestology Endpart, hehe... |
| |
Oswald
Registered: Apr 2002
Posts: 5018 |
hmm the main problem with 4x1 sized sprite pixels is not the resolution though but the priority. only the '01' pixels can be underlayed if I'm not wrong, and there's nothing you can put behind the '10' / '11' combos. That must be quite a problem in XFLI that I wasnt aware of, you must use the color for most clash fixing for the '01' pixels, and '10'/'11' cannot be masked to look hires... |
| |
WVL
Registered: Mar 2002
Posts: 886 |
Quote: hmm the main problem with 4x1 sized sprite pixels is not the resolution though but the priority. only the '01' pixels can be underlayed if I'm not wrong, and there's nothing you can put behind the '10' / '11' combos. That must be quite a problem in XFLI that I wasnt aware of, you must use the color for most clash fixing for the '01' pixels, and '10'/'11' cannot be masked to look hires...
you are grossly mistaken. You can put ANY multicolor sprite pixel in the background. It depends on the bitmap!!
You can't put sprites behind a _bitmap_ 00 or 01 pixel, but you can behind a 10 or 11 pixel (and that means any kind of sprite pixel, be it hires or multicolor)
You are mistaken between multicolor sprite, and multicolor bitmap pixels! |
| |
Oswald
Registered: Apr 2002
Posts: 5018 |
WVL \o/ then 4x1 pixels but more colors could be usable.
this mode could be looked at like:
3 overall background colors that can be used/unused in 4x1 resolution.
1 individual background color for each 8x2 cell
1 individual drawing color for each 8x2 cell
not that bad at all. higher color resolution for bigger pixels.
|
| |
Deev
Registered: Feb 2002
Posts: 206 |
I have to say that after spending some hours using the editor over the last few of days, I am starting to like this format more.
If we're talking tips, I find that setting the outline colour of the 'ink' pixels to something that really stands out makes it much easier to instantly recognise these pixels over the background pixels.
As Tch has mentioned, the nibble tool is also very useful and I've been using it quite a lot. I find the ability to import Art Studio files quite helpful as this format makes planning and doing outlines a little easier.
I don't think anyone should be put off by the fact that UFLI initially seems quite technical. I think if you spend some time becoming familiar with it, it is quite a simple concept.
|
| |
DeeKay
Registered: Nov 2002
Posts: 362 |
Yeah, the EOR-Nibbleswap-Key is there for a good reason! ;-))
For other interested people: This key is used when you notice that the sprite-pixels are one hires pixel off, by swapping the priority you can cover the half of the 2x1 spritepixel that you intend to.
It's the only command that saves you setting pixels manually besides clear and fill sprites, so the editor really is very very basic, hehe! ;-)
The nibbleswap-tool is even way more important in UIFLI, because there it quite often helps avoiding some problems through using alternate priorities but identical colors in both pictures!
Crossbow also added a key to swap the colors only in the UIFLI editor, he really insisted on this, don't ask me why, I've never actually used it! ;-)
I did insist on the Adv.Artstudio import function (my hires paintprogram of choice!), because not even I was willing to do EVERYTHING in UFLI like TCH does! ;-) So i did my outlines in Art Studio until i was satisfied with the layout and then continued in the UFLI editor. This saves you alot of work when you realize halfway through the picture that something is just way off! You do NOT want to change this in UFLI! ;-)
I've always found it most easy to explain UFLI to outsiders when you tell them that the picture is basically made up out of three layers (8x2 paper pixels 2x1 spritepixels and 1x1 ink-pixels), and that you can use the editor to paint on the individual layers! |
| |
Oswald
Registered: Apr 2002
Posts: 5018 |
I'm getting more and more the impression that ufli with expanded multicolor sprites could be of use :) |
| |
DeeKay
Registered: Nov 2002
Posts: 362 |
Quote: I'm getting more and more the impression that ufli with expanded multicolor sprites could be of use :)
What for? you would have awfully huge 4x1 pixels, this would totally clash with the high resolution used on the ink pixels!
You couldn't use the Sprites for Antialiasing, because there are only two pixel-boundaries in one char! You also couldn't do the single-pixel hires outlines with different color inside and outside that i was talking about above, because the pixels are too fat!
With Interlace there may be some use in it, but with one frame only? Na-ah, atleast not for me! <:-) |
| |
Deev
Registered: Feb 2002
Posts: 206 |
After thinking about it a little, I agree with Deekay.
There may be ocassions where it would be of use, but mostly I think those 4x1 pixels would be too large. The graphician would regularly have to use the 1x1 ink pixels to stop the sprite pixels looking so blocky, but as there would still be a limit of 1 colour per 8x2 for the ink, it would be difficult to do this with more than one sprite colour, making the increased selection mostly useless. |
| |
Oswald
Registered: Apr 2002
Posts: 5018 |
look at those ugly 4x1 pixels :P ;)
 |
| |
Melkor
Registered: Apr 2006
Posts: 11 |
The mixed layer would not look like that.
The diagonal blue line would have two cyan pixels in it.
And the black diagonal line would have two gray pixels in it.
Or am i missing something? |
| |
Oswald
Registered: Apr 2002
Posts: 5018 |
aw yes I've fucked it up :D |
| |
DeeKay
Registered: Nov 2002
Posts: 362 |
Besides: The "mixed layer" could be done in UFLI with only the exception of the cyan pixels being 2-pixel wide! <:-) If you leave out the one cyan pixel in row 3 you could even get the black dithering all the way up to row 3!
 |
| |
ptoing
Registered: Sep 2005
Posts: 271 |
I have been looking into this mode because i find it quite intruiging. My question is, and this might sound daft (excuse me i am no coder), but why can't each sprite have a different colour, why are they arranged in columns?
My only guess is memory issues? |
| |
WVL
Registered: Mar 2002
Posts: 886 |
Quote: I have been looking into this mode because i find it quite intruiging. My question is, and this might sound daft (excuse me i am no coder), but why can't each sprite have a different colour, why are they arranged in columns?
My only guess is memory issues?
simple. there are no more cycles left to move them around.
or better : you could move them around (at least sometimes, but not often), but that would make a horrible editor (not only to code, but also to pixel in) |
| |
Oswald
Registered: Apr 2002
Posts: 5018 |
btw, just watched the polish super hires collection, ammazing quality :D I thought this mode sucks without fli, but I was quite wrong. if only we could get 2 different colors into that spritelayer in ufli , pics would be a real wonder :) someone invent horizontal multiplexing pleez :) |
| |
Copyfault
Registered: Dec 2001
Posts: 466 |
Quote: WVL \o/ then 4x1 pixels but more colors could be usable.
this mode could be looked at like:
3 overall background colors that can be used/unused in 4x1 resolution.
1 individual background color for each 8x2 cell
1 individual drawing color for each 8x2 cell
not that bad at all. higher color resolution for bigger pixels.
Somehow I also like this idea of using mc_sprites... but then again, I'm no painter at all...
At least 2 of these overall Background_colours would deserve to be called background_colours; the third one is individual for every 6 char wide column. So I'd look at such a mode like this:
2 overall bgr colours in 4x1-res
1 individual bgr_col for each 8x2 cell
1 individual ink_col for each 8x2 cell
1 bgr_colour in 4x1-res for every 6-char-wide column
The free cycles tch used for changing a column-colour could be used to change a "real" bgr-colour.
Also a mc/hires-mode-change for the sprites is possible, but just like Werner said: such an editor would be painful for both the coder and the pixeler.
Guess "horizontal plexing" really stays on top of the wish_list ;))
Copyfault |
| |
HCL
Registered: Feb 2003
Posts: 716 |
Well, the problem remains: You have several background colors in 4x1-res, but you still *only* have one ink color to cover the background with. I trust our graphicians when they prefer UFLI as it is. |
| |
Cruzer
Registered: Dec 2001
Posts: 1048 |
Wouldn't it be possible to use 8 sprites for UFLI? Then 4 of them could be unexpanded multicolor (4*3 + 4*6 = 36 chars wide) which would mean the same resolution, but more colors on some of the pic. |
| |
HCL
Registered: Feb 2003
Posts: 716 |
One sprite is always used to cover the fli-bug, and one is not used at all. I think it would be better to put the last sprite on the 37:th char.. should be no problem. Perhaps it will be harder to do a looped timing then, but so what? :). |
| |
WVL
Registered: Mar 2002
Posts: 886 |
Quote: One sprite is always used to cover the fli-bug, and one is not used at all. I think it would be better to put the last sprite on the 37:th char.. should be no problem. Perhaps it will be harder to do a looped timing then, but so what? :).
or simply allow the user to chose where he positions the sprites himself.. but then here comes the editor pain again.. argh |
| |
Copyfault
Registered: Dec 2001
Posts: 466 |
Quote: One sprite is always used to cover the fli-bug, and one is not used at all. I think it would be better to put the last sprite on the 37:th char.. should be no problem. Perhaps it will be harder to do a looped timing then, but so what? :).
Yes, speedcode would give the most flexibility for linewise sprite_col-changes anyway;))
Instead of placing the Sprite_layer on char_columns 3-38 it might be better to cover the whole screen (including the FLI_bug) with 7 expanded Hiressprites and placing the 8th sprite such that the first char directly after the FLI_bug is covered! Choosing unexpanded mutlicolour mode for this 8th sprite it should be easily possible to cover the FLI-Bug with a colour of choice while having all 37 char_columns in UFLI as a bonus;)
CF |
| |
Cruzer
Registered: Dec 2001
Posts: 1048 |
@HCL: If the screen was in 38 columns mode, and the leftmost sprite was expanded, its two first chars of six could be used to cover the FLI bug. Then there would be 4 chars left in this sprite. And if the pic was centered, the 3 rightmost chars should be empty, so the pic would only be 34 chars wide. This means that we have 7 sprites left to cover 30 chars, and that way 4 of the sprites could be unexpanded multicolor. |
| |
Copyfault
Registered: Dec 2001
Posts: 466 |
Oops, sorry for my last post! Didn't really care about the sprite priorities >:
Making this 37th column UFLI is no real prob; but nevertheless: using the 8th sprite as unexpanded mc to cover the FLI-bug would give nice possibilities for painting within the FLI-bug_area! This feature would at least be one without pain (for coder to make it and for the gfx'er to use;)) One still has to care for all the sprite data, but this can be solved with bank_switching.
@Cruzer: having 4 unexpanded mc_sprites might result in some x postitioning issues, wouldn't it? |
| |
Tch
Account closed
Registered: Sep 2004
Posts: 512 |
I like Cruzers idea about using 4 unexpanded multicolour sprites.
It would be cool if it were possible to select which sprites are MC and which Hires.
But wouldn´t that be a hassle to make into an editor?
The idea about covering the FLI-bug doesn´t seem too realistic.
You´ll end up with MC-resolution and it will definately show.
Unless you can place a Hires-sprite there aswell. ;)
Still,the amount of colours there will be too limited for most pictures. |
| |
Cruzer
Registered: Dec 2001
Posts: 1048 |
@copyfault: I'm not sure what you mean by "x postitioning issues". But maybe I just haven't explained what I mean properly, so here's a little illustration that might help:
Ideally it should of course be up to the user to set multicolor, x-expansion, color, x-position, etc. for each sprite. Having a bit of overlapping between some normal x-expanded single color sprites might also be an idea, since that might make the transition from one sprite color to another easier.
The editor will of course be a challenge to code, but how about Timanthes - can't it handle all of this already? :o) |
| |
DeeKay
Registered: Nov 2002
Posts: 362 |
Guys, keep the GFXers in mind! ;-)
They don't want to wrap their head around which sprite they want multicolor and which hires and they most certainly won't be happy to work in a mode that allows one color in column x and three in column y! It's very hard to do natural looking pictures in that way! Just because you can use more colors in a certain area doesn't mean the picture will look better, you'll have a hard time using it in a way that you can't actually *see* these pretty different columns (because they're more colorful!)
It took ten years for someone to come along that showed that you can do awfully nice gfx in a mode that just works a little DIFFERENT than what people were used to! ;-) Don't spoil this interest now by going haywire about "we can have one color more in even lines when Jupiter is in the third house"! Most GFXers hate working under limitations they need to wrap their head around (i just love it, but that's my masochistic side showing i guess! Or the fact that i prefer doing logos to fullscreen pictures! ;-). Ever wondered why there are just no really colorful pictures in parts that supress badlines? I'll tell you why, because it's DAMN HARD to make a proper colorful picture where the colors are the same in vertical colums! ;-) It's certainly POSSIBLE, but you have a *very* hard time to make it look like a proper picture, which is why most people just use 4 colors throughout the whole picture, even though it's bitmap...
Ofcourse, UFLI already is different and has its limitations. But atleast you're only limited *very locally* in your color usage (8x2 block, that's it!)! ;-)
Keep in mind why IFLI was/is so popular: Because it's the nearest you can get to "direct adressing". So i'd say that's a clear vote GFXians don't want to wrap their head around technical issues too much! ;-D
Keep brainstorming though, I'm the last person that'd hate if new nice gfxmodes came from this brainstorming! 8) I'm just saying keep the GFXians in mind, don't get too "codey"! ;-D |
| |
Cruzer
Registered: Dec 2001
Posts: 1048 |
I'm just trying to help the GFXers. :)
As far as I understand, TCH has already added different sprite colors to the UFLI editor, and my idea would just be an extension of this concept. Of course GFXers shouldn't abuse it and make it too obvious that some columns are more colorful than others, but maybe it could come in handy for a few details here and there. |
| |
Oswald
Registered: Apr 2002
Posts: 5018 |
actually cruzer's idea is a good one, and if ppl can deal with ufli with different sprite colors / column, then ppl can deal with varied color density ufli :)actually it makes things easyer then harder, at some areas you have more colors and less restriction than the original format and at some areas you have the same amount of colors as in the old format. |
| |
WVL
Registered: Mar 2002
Posts: 886 |
I really don't like the idea of making it only 34 chars wide, I rather have 37 chars wide UFLI instead of the 36 one we have now..
maybe I should tweak the UFLI editor so it also allows the draw AFLI in the last char-column.. then again, it should be so much easier in Timanthes.. |
| |
Deev
Registered: Feb 2002
Posts: 206 |
I really like Cruzer's idea about multicolour sprites :) with every picture there will always be areas that require more detail than others, and it's these detailed areas where ufli often starts to fall a little short and I end up wishing I had more colours to pick from. As long as the user could select which sprites are multicolour and which aren't, I think it would be helpful.
I think the more control that can be given over the sprites, the better. Even if the multicolour idea wasn't implemented , if possible it would be great to have control over individual sprite colours, rather than just columns.
Whilst I agree IFLI's popularity is because of it's simplicity to pixel in, when using UFLI you'll have to use the 3 "layers" no matter what, and anything that improves the amount of colours possible is a bonus to me (says the man who just released a 3 colour only UFLI :) ). |
| |
Copyfault
Registered: Dec 2001
Posts: 466 |
@Cruzer: with "x positioning issues" i basically meant what DeeKay said: as there are no "perfect" x-positions for the mc_sprites, I don't know how long it'd take for a gfx'er to find good x-pos for his pic. To some extend it is possible to change the x-pos of the sprites every second rasline, but... here comes the pain again;)
One more thing: keep in mind that the sprites have to lie under the bitmap; your sprite0 would either cover the FLI_bug (and thus also cover the columns3-6) or give the UFLI-effect for columns 3-6 but not cover the FLI_bug.
Btw, what happens if the priority of sprite0 (which lies over sprite1) is set to be beneath bitmap and both sprite0 and sprite1 are placed on the FLI_bug? |
| |
Cruzer
Registered: Dec 2001
Posts: 1048 |
@copyfault: If the gfx in the FLI bug, is all 0's, then the sprite can cover it while being behind the gfx in column 3-6.
Yeah, it will probably be quite hard to figure out the sprite layout from the start. At least it will require some meticulous planning before starting to pixel. But the editor could also include some tools that made it easier to rearrange the sprites, e.g. "convert one expanded single color sprite to two unexpanded multicolor ones" and "rotate sprite gfx" where it was possible to select any group of sprites to include in the rotation.
So it's probably not that hard. The real pain starts if it should also be possible to change the sprite parameters on different rasterlines, but OTOH, that would also give the GFXers some additional possibilities. |
| |
WVL
Registered: Mar 2002
Posts: 886 |
Quote: @Cruzer: with "x positioning issues" i basically meant what DeeKay said: as there are no "perfect" x-positions for the mc_sprites, I don't know how long it'd take for a gfx'er to find good x-pos for his pic. To some extend it is possible to change the x-pos of the sprites every second rasline, but... here comes the pain again;)
One more thing: keep in mind that the sprites have to lie under the bitmap; your sprite0 would either cover the FLI_bug (and thus also cover the columns3-6) or give the UFLI-effect for columns 3-6 but not cover the FLI_bug.
Btw, what happens if the priority of sprite0 (which lies over sprite1) is set to be beneath bitmap and both sprite0 and sprite1 are placed on the FLI_bug?
the VICII first considers priority between sprites, and only later considers priority between sprite + normal graphics.
So if you have sprite 0 and sprite 1 overlapping, sprite 0 will win and only then will the VIC look at the other gfx, in this case the sprite will go beneath the bitmap (and sprite 1 will never be seen).
|
| |
Tch
Account closed
Registered: Sep 2004
Posts: 512 |
Quote: I'm just trying to help the GFXers. :)
As far as I understand, TCH has already added different sprite colors to the UFLI editor, and my idea would just be an extension of this concept. Of course GFXers shouldn't abuse it and make it too obvious that some columns are more colorful than others, but maybe it could come in handy for a few details here and there.
And your thoughts on this are highly appreciated! 8)
Your idea will take things a lot further than my simple little improvement.
When you check out my workdisks,you´ll see that the usage of different spritecolours is hardly used. ;)
UNEXPANDED MC-sprites will solve the problem in a much better way. |
| |
jailbird
Registered: Dec 2001
Posts: 1576 |
Um, finally I found some time to read the whole thread. So just to drop my few nickles into the discussion...
First of all, I'm fine with the way UFLI works at the moment, however, if the color usage could be expanded - Cruzer's solutions seems to me like a good idea. Go for it, I think it might be more than useful.
And one thing I miss just too much from the editor: an option to pick up ink+paper values from a 2x8 area. That would be such a revelation! I often tap on the wrong color keys, as I usually work in a dark room and don't see the keyboard - so it's more like a wild guessing of the correct key or a trial&error kind of color picking. Especially as colors are distributed in ABC order rather than a lot more logical 12345.../QWERTY...-like state.
It would save a lot of time when filling areas where fast changing of colors is important for not losing too much from the flow of constant pixelling (and to spare some of my nerve receptors from dying too early). So if one of you decides to update the editor, keep in mind that Jailbird was desperate to have a color picker :) |
| |
Cruzer
Registered: Dec 2001
Posts: 1048 |
Damn, guess I have no choice but to improve the editor now. Anyone has the source code? |
| |
Spinball
Registered: Sep 2002
Posts: 87 |
cruzer: as fare as i know crossbow uses s-mon(aka crest demomaker) for coding, so no sources. |
| |
Deev
Registered: Feb 2002
Posts: 206 |
Following on from Jailbird slightly, I think it would be very useful to be able to copy/paste the contents of each 8x2 area, or at least an option to fill an 8x2 with the ink and fill 8x2 with alternate ink pixles for dithering. |
| |
Cruzer
Registered: Dec 2001
Posts: 1048 |
No sources, guess I'll have to start from scratch then. But since the memory layout will be quite different in "my" UFLI mode, because all the sprites can't be fitted into one VIC bank, the amount of work would probably be about the same. |
| |
Tch
Account closed
Registered: Sep 2004
Posts: 512 |
Quote: No sources, guess I'll have to start from scratch then. But since the memory layout will be quite different in "my" UFLI mode, because all the sprites can't be fitted into one VIC bank, the amount of work would probably be about the same.
Why not jump into the Monitor?
Even I managed to change the original editor. ;)
It is pretty logical,actually.
Start is at $3080! ;)
|
| |
Oswald
Registered: Apr 2002
Posts: 5018 |
hmm cruzer, could you post a memory map of the current editor and yours ? You would use more sprites than the original ? why do you need an extra bank ? |
| |
Cruzer
Registered: Dec 2001
Posts: 1048 |
For normal UFLI I guess it looks something like:
4000-5f3f: bitmap
5f40-5fff: 3 sprites
6000-6fff: 4 screens
7000-7fff: 64 sprites
So max 67 sprites, which is enough if you only use 6 sprites, since you need 10 in height to cover 200 lines => 60 total. But I intend to use all 8 sprites, so I would need 80 sprites. |
| |
Copyfault
Registered: Dec 2001
Posts: 466 |
Finally I take the time to post a reply here...
Why does the standard UFLI-routine change the sprite_pointers every 40 lines? When trying to solve the FLI_sudoku that arose in the UFLI_MAX-thread, I found out that it is possible to do normal UFLI with fixed sprite_pointers. The drawback is a "certain" scattering of all the gfx_data over several banks... Guess the original UFLI_routine had to be some loop.
Using sprite_crunching and all of this techniques discussed for UFLI_MAX, we could save quite some cycles in most of the free(=non badline) rasline and do a lot of colour_changes... this should be an extremly nice feature when using MC_sprites as Cruzer planned in "his" UFLI.
@Cruzer: most probably you're already coding this new UFLI-"flavor", so I think you took all this into consideration. Looking forward to see pics in that mode :)=) |
| |
HCL
Registered: Feb 2003
Posts: 716 |
@copyfault: The problem with fixed sprite pointers is that you only get 4*21 = 84 lines of graphics that way. With FLI every line you gat 8*21 = 168 lines, still not full screen.
With sprite crunching things get even worse, of course :). But i think you can get 168 lines there as well, in one bank. Think i made such a thing once.. |
| |
Copyfault
Registered: Dec 2001
Posts: 466 |
@HCL:yes, with spritecrunching "things"(which means mem_layout) get really confusing, but who says that we have to stick to one VIC_bank?
Even with spritecrunching we can handle 40 lines of spritedata when using 4 VRams (which is the case with UFLI). Now we change the used VRams every 40 lines; this need to be done 5 times, and we're lucky that there is enough mem for that, no matter how many sprites are used;)) Furthermore, the data can be stored "interlacefriendly", so that even for interlace no change of spr_pointers is needed...
...but, whom do I tell that;)?
CF |
| |
Cruzer
Registered: Dec 2001
Posts: 1048 |
@copyfault: No, I haven't started yet. I'm currently in quite an inactive period C64-wise. |
| |
Mirage
Registered: Jan 2003
Posts: 113 |
Quote: @copyfault: I'm not sure what you mean by "x postitioning issues". But maybe I just haven't explained what I mean properly, so here's a little illustration that might help:
Ideally it should of course be up to the user to set multicolor, x-expansion, color, x-position, etc. for each sprite. Having a bit of overlapping between some normal x-expanded single color sprites might also be an idea, since that might make the transition from one sprite color to another easier.
The editor will of course be a challenge to code, but how about Timanthes - can't it handle all of this already? :o)
Yes, Timanthes can handle all of this already (well, the version i've got here can ;)
I've already made a picture in UFLI with non-x-expanded multicolour sprites just to test it (can't show that yet, it'll be in one of our new demos) and it works quite nice :)
Problem is I still had to set up the code and sprite-pointers tables myself, as timanthes doesn't spit those out yet :/ |
| |
WVL
Registered: Mar 2002
Posts: 886 |
Quote: Yes, Timanthes can handle all of this already (well, the version i've got here can ;)
I've already made a picture in UFLI with non-x-expanded multicolour sprites just to test it (can't show that yet, it'll be in one of our new demos) and it works quite nice :)
Problem is I still had to set up the code and sprite-pointers tables myself, as timanthes doesn't spit those out yet :/
Are there also Dragons and stuff? |
| |
Dane
Account closed
Registered: May 2002
Posts: 421 |
Quote: Yes, Timanthes can handle all of this already (well, the version i've got here can ;)
I've already made a picture in UFLI with non-x-expanded multicolour sprites just to test it (can't show that yet, it'll be in one of our new demos) and it works quite nice :)
Problem is I still had to set up the code and sprite-pointers tables myself, as timanthes doesn't spit those out yet :/
Bumping this thread just because I made a picture with flexible sprite X-positioning for X2006. The influence definitely came from this discussion.
And UFLI with non-expanded sprites was done already in Phases and Bextor, my picture for Floppy 2003. I can send the editor if anyone wants - though it doesn't have any disk options. |
| |
Helm
Account closed
Registered: Jul 2006
Posts: 25 |
If I can wrap my head around UFLI, I intend to do another triangle piece in that format. Probably not on c64 emulation as a) I'd rather not pixel in a 320x200 window b) because emulation colors are awful.
I guess I'll wait for Timanthes to do the format. *nudge* *nudge* *Mirage-nudge*
while we're at it, as it can be seen in the Dawnrazor video, I'd really like Timanthes to have a preview window. Or does it and I'm just missing it? |
| |
Bizzmo
Account closed
Registered: Mar 2005
Posts: 82 |
Yeah, There's no preview window in Timanthes (yet) - It's something that I've been nagging Mirage for, (and I know Deev has been nagging too!)
Mirage keeps moaning about some fictional to-do list that's as long as his arm - or some excuse like that... |
| |
Wile Coyote
Registered: Mar 2004
Posts: 640 |
Some years ago, possibly over 7 years ago i had ago at using the Ufli editor and ended up making a Crest logo. I decided to make a Crest logo as i thought, who else would ever attempt to use Ufli in their demos other than Crest. Maybe one day it'll show up :) |
| |
algorithm
Registered: May 2002
Posts: 702 |
Quote: I'm getting more and more the impression that ufli with expanded multicolor sprites could be of use :)
Yes, Even standard Hires with multicolor underlay can suffice ;-}
 |
