| |
jailbird
Registered: Dec 2001
Posts: 1578 |
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
Registered: May 2002
Posts: 423 |
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
Registered: May 2002
Posts: 423 |
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: 924 |
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: 5129 |
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
Registered: May 2002
Posts: 423 |
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: 5129 |
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. |
... 64 posts hidden. Click here to view all posts....
|
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 - Next |
