| |
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? :)
|
|
... 64 posts hidden. Click here to view all posts....
|
| |
WVL
Registered: Mar 2002
Posts: 924 |
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: 5129 |
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: 499 |
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: 731 |
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: 1051 |
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: 731 |
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: 924 |
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: 499 |
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: 1051 |
@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: 499 |
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? |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 - Next |
