| |
DeeKay
Registered: Nov 2002
Posts: 362 |
This is the Thread for everything NUFLI!
The Era of NUFLI has begun - Bye Bye Interlace!
So what do you guys think? 8)
btw. Until Bitbreaker decides the converter is fit for release, you may send me your pictures and I'll put them through it. No, I won't fix the bugs for you (been doing that for over a hundred hours in the recent months! <:-), you gotta learn your way around the editor eventually if you want that extra edge of perfection - But I will offer some advice on different approaches how to combat teh blockiness or teh color lack, i even prepared some tutorials I will post here later! ;-)
Please do keep in mind that even in NUFLI, you still only have 3 colors horizontally in every char -with one fixed for 6 chars- (5 or 6 in the FLIbug, but that's for all 3 chars!). Considering that IFLI has a maximum of 6 colors in one char, it's quite surprising the pictures in the Slideshow come over so well, but apparently most people don't use IFLIs capabilities to the full extent - and then there's the horizontal PAL colorblur, which means many different colors don't actually make so much sense after all, since you can't distinguish all the colors so well anyway! |
|
... 160 posts hidden. Click here to view all posts....
|
| |
DeeKay
Registered: Nov 2002
Posts: 362 |
Lubber: Like it is done when actually pixelling the picture in whatever program you use: By dithering the colors! ;-)
Besides, all the people that still say "Interlace still has its uses": Yes, it does - As NUIFLI! ;-) In NUIFLI you can do everything you can do in IFLI/Drazlace if you want to - and so much more! Ultra-smooth colorfades, details that are never possible with IFLI/Drazlace etc!...
Seriously: There is exactly ZERO reason left to still do Drazlace or IFLI now! <:-) Nobody can give me just ONE good argument - other than "it's what I'm used to"! ;-D
Or if you actually do gfx for demos in drazlace and need the rastertime!... But as I said in the scrolltext: unfortunately nobody ever did before, so why would they now? <:-) |
| |
algorithm
Registered: May 2002
Posts: 702 |
Pixelling in these modes would certainly be more awkward as you cant just plot any pixel like you can do in koala for example (eg 3 colors per 4x8 block). The sprite underlay is 2x1 pixels - hires expanded and you need to take that into consideration while smoothing out the blockiness by masking it with a hires ink color.
Easiest method is to draw freely in 320x200 with the c64's 16 colors and feed it through the converter and edit the glitches after if required. |
| |
Lubber
Registered: Jan 2002
Posts: 26 |
yes, you are right.
the only workaround would be to use Interlace AFLI (was it spelled that way? i just mean IFLI in hires mode), i can mix 2 colors without that half pixel overlapping limitation. But of course the Hires IFLI Mode has much over drawbacks, so i think NUFLI will probably become a new standard for graphics compos.
|
| |
Lubber
Registered: Jan 2002
Posts: 26 |
Quote: Lubber: Like it is done when actually pixelling the picture in whatever program you use: By dithering the colors! ;-)
Besides, all the people that still say "Interlace still has its uses": Yes, it does - As NUIFLI! ;-) In NUIFLI you can do everything you can do in IFLI/Drazlace if you want to - and so much more! Ultra-smooth colorfades, details that are never possible with IFLI/Drazlace etc!...
Seriously: There is exactly ZERO reason left to still do Drazlace or IFLI now! <:-) Nobody can give me just ONE good argument - other than "it's what I'm used to"! ;-D
Or if you actually do gfx for demos in drazlace and need the rastertime!... But as I said in the scrolltext: unfortunately nobody ever did before, so why would they now? <:-)
Well, the only reason to NOT use NUFLI would be creating games or demoparts that needs the sprites or the used rastertime. Thats where drazlace _could_ be more usable (in fact i won't play a game if it will flicker all day long, its just ok for title-screens or demoparts...)
in case of slideshows/compos i think you're right: NUFLI will be (technically and eye-friendly) better be used in the future instead of flickering modes. But algorithm is also right: i guess its very hard for a graphician to draw in that mode, as any kind of convertion is not allowed in compos right?. anyway, for me it would be even harder on koala, hehe ;)
|
| |
DeeKay
Registered: Nov 2002
Posts: 362 |
well, converted stuff is frowned upon, but allowed. these days it primarily matters that you made it yourself, nobody cares anymore if it's been wired or not! <:-)
So the approach now is: draw 320x200x16 picture in paintprogram of your choice, feed through converter, fix bugs in editor - Basically that's ALREADY how very many people have been doing it with IFLI for ages! ;-) Rayden, Cyclone, Ptoing, Ragnarok, Deev too I think (not 100% sure though!)... |
| |
algorithm
Registered: May 2002
Posts: 702 |
If non-interlaced and full screen and not minding the near full processor usage, then modes such as NUFLI are possibly one of the greatest modes. Although a converter taking into account x position, multicolor/hires toggle for individual sprites in area's to minimize conversion error would give greater quality
In regards to interlace color mixing. Hybrid multicolor/hires switching in FLI (one image hires, the other multicolor - interleaved ofcourse to prevent flicker) can generate pictures with far less errors in comparison with IAFLI and no need for sprite underlay due to the choice of having 2 freely available colors each 4x1 block and third one to cover each 4x8 block
This combined with the interlacing of the hires bitmap will generate a hifidelity interlaced hires image in many colors and less errors in comparison to interlaced AFLI. |
| |
Copyfault
Registered: Dec 2001
Posts: 466 |
One can take the interlace-possibilities even further:
Hires/MCol-FLI mixture as Algorithm said, or
Hires/Hires-FLI but with variable $d016-shift per Line (changes col-distribution within that line),
same with MCol/Mcol-FLI with variable $d016-shift per Line (up to now, I've seen no pic that really makes use of different $d016-values) and
shift of second frame by variable amount of pixels (changes $d800-col distribution of the whole pic).
For these features we aimed when doing that ILM-editor ages ago. Unfortunatly, no one ever made a gfx in that mode. No wonder either, as the editor we hacked together was made to torture people badly.
As of now, I have not come up with an idea to do any clever conversions that takes every possibility into consideration. Maybe someone here's up for that (Algo)?
---
About NU(I)FLI: all my hats off! Deep respect to the CREST-posse and ofcourse to Bitbreaker. The two things that amaze me most is the GFX-2-NUFLI-Converter-algorithm, which must be really insane and the effort that went into all that "pixel bug fixing", which was most probably the hardest part! Thank you so much for those gfx!!! |
| |
Burglar
Registered: Dec 2004
Posts: 1031 |
Quote: Any chance of this ever working on NTSC? :-)
should be dead easy, just add a NOP (2 cycles) every rasterline and time the stable raster properly. |
| |
Burglar
Registered: Dec 2004
Posts: 1031 |
dk, could you post a screenshot (yes its really called...meh) of an untouched ifli -> nufli pic that went through the converter? preferably one that's in CSS. interested to see how much the converter really handles, or how much fixing is required. |
| |
DeeKay
Registered: Nov 2002
Posts: 362 |
Burglar: actually, i had already planned that! ;-
)
So here you go:
Those are three examples that required a lot of fixing. Other stuff, like Iskender for example, required merely 2-3 hours of fixing or so. Quite often I ended up improving parts of pictures, adding antialiasing here and there, in Carrions Train and Joe's pic i also had a good look at the original pictures etc, so it's not just all about fixing conversion bugs! :-)
Please zoom in yourself, i don't know how to resize pictures in BBcode! |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | ... | 17 - Next |
