| |
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....
|
| |
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: 1051 |
@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: 364 |
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: 1051 |
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: 5127 |
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: 924 |
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: 487 |
@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: 1051 |
@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: 924 |
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).
|
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 - Next |
