Log inRegister an accountBrowse CSDbHelp & documentationFacts & StatisticsThe forumsAvailable RSS-feeds on CSDbSupport CSDb Commodore 64 Scene Database
You are not logged in - nap
CSDb User Forums


Forums > C64 Pixeling > This is the Thread for everything NUFLI!
2009-07-19 23:30
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!
2009-07-20 07:16
Oswald

Registered: Apr 2002
Posts: 5007
"3 colors horizontally in every char -with one fixed for 6 chars"

in some ways better in some ways worse than koala I'd say, and as it was shown troughout the years, koala is hardy limiting ;) most of the pics in the slideshow were drazlace originally.

how come one is fixed for 6 chars ? so arent the sprites multicolor? you could give out details all this mufli nufli, etc makes my head dizzy.
2009-07-20 08:48
DeeKay

Registered: Nov 2002
Posts: 362
os: nopes, in fact the majority of the pics were originally IFLI. Some Drazlace stuff from Leon is in there and the rest is most of Duce's and Electric's portfolio.. And then there are Carrions pics, which were never drazlace, but rather manually extended IFLI-originals, Joe's was also done without ever seeing the drazlace editor!
There really aren't that many ppl that actually do Drazlace! <:-) - Much to our chagrin, because we couldn't show off the FLIbug, hehe! ;-)

As for the specs: Read the scroller, it's all in there. No, we did remove the multicolor option to use the cycles for an eigth sprite, so it's (expanded) hires sprites only again..
2009-07-20 08:55
SIDWAVE
Account closed

Registered: Apr 2002
Posts: 2238
Well, great, a new standard born in 2009..
Tell crossbow to code a 12 voice sid tracker now please!
2009-07-20 09:00
DeeKay

Registered: Nov 2002
Posts: 362
Well, NUFLI isn't that much news really - *all* of the pictures in the collection could have been done in this exact quality with MUFLI (from 2006!) already, only missing the 40th char colum and the FLIbug! 8) Hell, if we were able to use the Multicolor option, it would probably look even better!

It's only thanks to Bitbreaker's converter that we can now finally show the world what we knew all along: that M/N/UFLI can be just as colorful as IFLI - without the flicker! ;-)
2009-07-20 09:45
Cruzer

Registered: Dec 2001
Posts: 1048
Judging from the pics I actually thought the mode was more advanced than this. I've been fantasizing about a completely flexible UFLI mode for a while, where you could change all sprite parameters, e.g. x-positions to concentrate them where they're most needed. But apparently that's not necessary when you got the combination of an amazing converter and some mad pixelling skills.
2009-07-20 09:52
PopMilo

Registered: Mar 2004
Posts: 145
How often are you changing sprite colors ?
Is it possible for whole 7 sprites in every line?
I guess it isn't possible with that few cycles remaining...
So what are options?
2009-07-20 10:09
DeeKay

Registered: Nov 2002
Posts: 362
popmilo: every 2 lines - but it's offset one line from the bitmap color changes! xbow made that so you could have 4 colors in a 8x2 block, but we noticed when working on the pictures that quite often in those lines where a sprite color change occurs, you need to set one of the bitmap colors to the same color as one of the spritecolors in order to avoid ugly lines in that 8x2 block! That leaves you only with one other color in that line...
Xbow said that he can do 5 of the 6 sprites in the same line as the bitmap (only the rightmost would be 1 offset!), and we planned to experiment a little with this to see if it gives better results, so bitbreaker made a version of the converter that did sprite and bitmap-changes in the same line. Apparently it did improve according to the conversion bug percentage, but the whole project was already underway so we didn't want to change it again!
In fixing these bugs (make no mistake - the converter is good, but quite a few of these pictures, especially the more colorful IFLIs, required many many hours of postprocessing to look THIS good, e.g. Carrion's train or Valsary's Wolverine!) i did find occasions where it was useful to have 2 spritecolors in one 8x2 block, but more often i had to fix ugly lines caused by the offset sprite colorchanges (very evil in pictures with outlines!)

To come back to your original question: we actually even have 8 sprites ((M)UFLI had 7 already - 6 in the pic and one to cover the FLIbug!), 6 in the picture and 2 in the FLIbug!
And yeah, i forgot: we can switch colors for the FLIbug sprites, too, depending on how many register changes inside the picture are unused (you hardly ever change the color of all 6 sprites every time!), and that means up to 4 flibug spritecolors every second line, depending on how many colorswitches are "unused"! ;-) plus one FLIbug-Sprite-colorchange in every other line...
2009-07-20 10:30
PopMilo

Registered: Mar 2004
Posts: 145
FLI is then used every two lines ?
So 8x2 hires bitmap blocks in two colors + spritecolors ?

Hats of to Bitbreaker for making converter for this mode! :)
2009-07-20 10:34
Oswald

Registered: Apr 2002
Posts: 5007
I have read the scroller, and this thread but the specs are still not clear :)

so every 2nd line fli 6+2sprites, and every two lines how many registerchanges possible?
2009-07-20 10:58
DeeKay

Registered: Nov 2002
Posts: 362
Okay, I'll sum this up as condensed as I can:

NUFLI-Picture: 1 hires bitmap, FLI every second line (=all even lines) plus 1 spritelayer of 6 expanded hires-sprites over the first 39 chars (last one is plain AFLI) under the bitmap with possible colorchanges for the sprites every 2 lines (=every odd line)
NUFLI-bug: 1 hires bitmap, 6 lines of grey alternating with 2 lines of normal AFLI, plus one Mcol-spritelayer as the bottom layer (well, technically the unset bitmap color is at the very bottom, but in those 6 lines with grey that's grey, which you also have as set pixels in hires *over* the whole thing, so it doesn't make any sense!), one hires-spritelayer over it and set bitmap pixels (that's those 6 lines grey alternating with 2 lines AFLI again!) over that (that's 4 layers instead of 3 like inside the picture). colorchanges are possible for all four sprite colors (five possible switches in total every even line, one every odd line), depending on how many register switches are free (unused) inside the picture!

Yes, nobody said it's simple - that's why we made the converter! ;-D
2009-07-20 11:48
PopMilo

Registered: Mar 2004
Posts: 145
Thanks DeeKay! That is clear enough :)

Excellent job!
2009-07-20 14:04
algorithm

Registered: May 2002
Posts: 702
Great pictures and good conversion.

Aaargh. If only I created the MUFLI converter before this was released.

The majority of the images can look just as good just feeding it through the MUCSU converter (and this is nonfli and mcol sprite underlay with no color changes) Although for the more complex color images a sliced alternative such as bitbreakers would certainly be a requirement.





2009-07-20 17:40
Wile Coyote

Registered: Mar 2004
Posts: 633
whats the 'N' stand for?
whats the 'M' stand for?

From what I know, 'M' is the same as 'N', only 'N' gets to use the 40char, thus making it an upgrade of 'M'

('U' stands for underlay, if I remember correct)

FLI
IFLI
UFLI
UIFLI

I guess, NUIFLI applies to the logo's at the end of CSS
2009-07-20 18:26
DeeKay

Registered: Nov 2002
Posts: 362
M stands for Multicolor (and xbow liked the pronounciation "moo-FLI"! 8)
N (NUFLI - "New FLI") actually came before M (see the helpscreen of the MUFLI editor, xbow found he could still switch one register, Mcol-register to be exact, thus dumping N and creating M!), but was never released. But back then it was not in the form we released it in now - there was no 40th column and no FLIbug.

Yes, "U" is for Underlay (Arriba! Arriba! Ándale! Ándale!! 8)))
Yes, the end-logo''''s are NUIFLI....

Hope that clears up the confusion...
2009-07-20 19:21
Deev

Registered: Feb 2002
Posts: 206
To me this really is the most exciting thing to happen on the C64 in a long time. I know some people like the lo-fi approach of using hires and similar, and hey, I like to experiment every now and again, but most of the time I just want to make what I have in my mind look as good as it can on screen and this should go a long way to making that happen.

I also think it's pretty amazing that so far into the C64's life, such a big leap forward has happened! I've never really had a problem with interlace, but seeing all those pics in a true C64 high resoloution mode, that is possible to create without boring myself to death, blows me away! Thanks to all involved.
2009-07-20 19:47
DeeKay

Registered: Nov 2002
Posts: 362
Thanks, Deev, that's exactly why we made all this! ;-)))
It's funny how Soundemon set a new standard for Digis on x2008, Booze did for Demos - and we did for graphics! Only that nobody knew back then because we didn't release anything! ;-D
The converter was quite advanced back then already (though this was primarily MUIFLI focussed, we did all the FLIbug stuff some time after X!)
2009-07-21 11:54
saehn
Account closed

Registered: Apr 2006
Posts: 44
Any chance of this ever working on NTSC? :-)
2009-07-21 13:01
DeeKay

Registered: Nov 2002
Posts: 362
well, it is technically possible that crossbow makes an NTSC-compatible displayer. but I doubt he will! <:-) Try mailing him about it, thanks to VICE you don't need an actual NTSC machine anymore! ;-D
2009-07-21 13:21
Lubber

Registered: Jan 2002
Posts: 26
I really love these graphics, but one advantage of IFLI/Drazlaze still is mixing colors. (how to do that without flickering?)

Anyway great stuff you did! thumbs up Crossbow/Deekay as always. :)
2009-07-21 13:31
algorithm

Registered: May 2002
Posts: 702
Yes, you get the color mixing via interlaced mcolor but still bear in mind that each pixel is still 2x1 in size. The partial overlap when flicking the two images with the second one a hires pixel apart. creates an intermediate shade between the 2x1. hence hires chequerboard is not really possible in multicolor interlace.
You get the color mixing regardless in pal without interlace.

If you take into account mix colors when converting an image (eg from digitized photo) then clearly interlaced modes offer the advantage.

2009-07-21 13:33
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? <:-)
2009-07-21 13:38
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.
2009-07-21 13:40
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.
2009-07-21 13:49
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 ;)


2009-07-21 14:05
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!)...
2009-07-21 14:06
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.
2009-07-21 16:55
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!!!
2009-07-21 17:14
Burglar

Registered: Dec 2004
Posts: 1027
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.
2009-07-21 17:38
Burglar

Registered: Dec 2004
Posts: 1027
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.
2009-07-21 21:32
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!
2009-07-21 21:40
Skate

Registered: Jul 2003
Posts: 490
converter results are quite acceptable. but of course big respect to master deekay's magic wand touch. :)
2009-07-21 21:56
DeeKay

Registered: Nov 2002
Posts: 362
Skate: thanks! :-)
The converter can still be improved quite a bit, not only through using the multicolor option. Right now what it does (when feeding it a c64 image, not "prepping" a truecolor image, which Bitbreaker also included ofcourse, for the pr0n! 8) is just plain bruteforcing and replacing colors until it's down to three, There's no replace-colors-through-dithering or any deblocking approaches (watching the blocks around it) involved right now, and quite often i've found bugs where I just thought "wtf? why did it do that?", e.g. choosing two colors of the same brightness and replacing another, way more useful color instead!
Nevertheless, it delivers great quality already, huge props to bitbreaker for stepping up to a task that others never got done (hello Mirage, hello Groepaz! 8), but I expect others will even improve it once it's released - And if Algorithm turns his improved version of it into yet another windows-only tool I'm gonna swing by his house to personally piss into his computer! >;-)
2009-07-21 22:21
algorithm

Registered: May 2002
Posts: 702
The example pics below are conversions using my MUCSU converter. This is Standard Hires and multicolor underlay with no sprite color changes I believe many of the pictures in the Crest Demo did not really require a mode such as NUFLI or MUFLI. Apart from images with lots of colors in tight spaces. Eg the Wolverine pic by Valsary looks horrible in MUCSU but not bad considering the limitations of the mode. Even just changing sprite colors per 8 lines or so would create a great image without resorting to FLI modes.

I took the NUFLI pictures and fed them through the converter. There has been no additional touches to the image. Results below would look better if i had the original interlaced to 320x200 conversion rather than the NUFLI'ed quantised version.

I may create a sliced mode converter based on NUFLI when I have the time

A link to one of the pictures (MUCSU mode)-C64 PRG

http://www.sendspace.com/file/j80i2d







2009-07-21 23:35
DeeKay

Registered: Nov 2002
Posts: 362
Algo: That's all nice and dandy, and ofcourse we know not every picture in the collection makes use of the full NUFLI-capabilites (some could have been done with unexpanded sprites (summon elf, hatwave) and most don't even use the FLIbug!), but we really didn't feel like coding a new editor and displayer just because of individual pictures...
Your pics really do look quite nice - a bit blocky, but the train looks quite amazing for such heavy limits. However, I think there's not that much leeway left for fixing bugs in that mode. the limitations are just too much! FLI really does help with the color starvation at least vertically, you know? ;-)
2009-07-21 23:46
algorithm

Registered: May 2002
Posts: 702
The images certainly look blocky in comparison to the FLI version but not surprising considering there are only 2 colors per 8x8 block and three sprite colors identical for the entire span of the image. Certainly for the more complex images particularly those that have more colors in a smaller area, FLI is a requirement. Having a new set of 2 colors per 8x2 and sprite color updates would no doubt increase the image greatly.
Will put together something when I have the time, perhaps different variants to allow processing time for other things. At the moment MUCSU just needs updating once every 20-21 lines or so to multiplex the sprites and nothing else, but quality can be dramatically increased just by changing sprite mcols every 8 lines or so
Would be interested in using the 5 sprites over every line FLI used in demus interruptus as the basis of my next converter. Is there a stand alone displayer for this mode or does crossbow have something in his collection?

2009-07-22 08:05
Jetboy

Registered: Jul 2006
Posts: 208
@DeeKay

Could you please post a few examples of pictures straight after conversion along with handfixed final result? I would love to see untouched converted images.


---
http://colors.collectingsmiles.com

2009-07-22 08:20
DeeKay

Registered: Nov 2002
Posts: 362
Err - Deja vue? <:-) Look above?

P.S: These are aniGIFs, btw!
2009-07-22 08:39
DeeKay

Registered: Nov 2002
Posts: 362
As promised in the original posting, here are a few of the tricks I wrote down while working on this:

Here's what to do if you're starved of colors or you need to get rid of that block:

1) Replace colors of similar brightness. It's quite pointless to have e.g. cyan and lt grey in the same block when you would desperately need some other colors - Though for some reason that escapes me the converter STILL does this sometimes!
2) Use dither insted of inbetween colors, e.g. you have dark and lt. grey, you would need medium grey -> dither dark and lt grey!
3) Use inbetween colors instead of dithering. The reverse of 2), only useful in cases where in this example the whole block would be filled with dithered dark/lt grey -> use medium grey instead! If used wisely, this can enable you to "free up" one color that you might need for something else. This trick is very important vertically to get rid of those hard edges, since you can change color every 2 lines! Got blue forming an ugly horizontal line with light blue vertically? Just use purple inbetween! You have half-FLI - use it!
4) Remove unneeded (mostly background) detail and focus on important stuff. No one's gonna miss that crack that didn't really look like one in the first place!
5) Move stuff. Quite often, it already helps loads to just move stuff one pixel to the left or right, to better match those cursor boundaries. No copy feature in the NUFLI editor, sorry! <:-)
6) Avoid unneeded spritecolor changes. In some cases, it can be a boon to have 2 different spritecolors in one block, but quite often in order to remove blocks or lines, it also means you have to set one of the spritecolors as bitmap color as well (or even both, I've had that, yes!)
7) Black. Teh horror. Be very careful with black, it bleeds A LOT on the real machine, meaning: It tends to "eat" into other pixels. This is most apparent when checkerboard dithering with black, this is a LOT darker than checkerboard mixing with black in IFLI or Drazlace, which uses interlaced horizontal full lines instead!
8) Use color brightness so smooth edges. Quite often it already helps to replace a color with one that's just a wee bit darker or lighter to smooth some blocky edge or something!
9) The star key (Nibble Swap) is your friend. Use it! Quite often merely changing the color priorities can enable you to make something a lot smoother!

These are just a few of the tricks I used, albeit the most important ones. I wanted to do screenshots to illustrate it, but can't be assed right now! ;-) Maybe later!

Some words about using the $d020 rasterbar feature, which you might have noticed in Duce's Iskender and Peacemaker or the end-part:

Three limitations:
1) color gets changed INSIDE the screen, so the left and right are offset one pixel!
2) you can only change color every 2 lines max.
3) you can only change color in odd lines (starting on the right side, remember, so on the left side it shows first in the even lines!), starting from line 3 (in line 1 the register switches are already taken for the FLIbug colors!), 5, 7, 9 up to line 199.
2009-07-22 09:42
Jetboy

Registered: Jul 2006
Posts: 208
Sorry, didn't notice those are anim gifs.
2009-07-22 10:26
Iapetus/Algarbi/Wood

Registered: Dec 2004
Posts: 71
Quote: Sorry, didn't notice those are anim gifs.

I did the same mistake

I can see that the difference is not that big between frames... I thought it would have been much worse before retouching.
2009-07-22 11:21
Carrion

Registered: Feb 2009
Posts: 317
Algarbi:
Maybe it looks easy for the first sight (I also though it'll be easy to fix after the coversion) but belive me the limitations You have with NUFLIs (especialyy Sprite color in my opinion) makes it not so easy work.
Withou help from DK I'd probably stuck with some parts of my images.
Actually most of fixes in my pictures were done by our NUFLI master :)
2009-07-22 13:16
Carrion

Registered: Feb 2009
Posts: 317
OK So here's a example which I think maybe some people were thinking about:
Sorry for different saturations on images but you get the point.

one more saturated is original, second is straight convert without fixing.
enjoy ;)

2009-07-22 13:19
algorithm

Registered: May 2002
Posts: 702

Perceptual Brute force would solve the issue with color selection. The lower the perceptual error, the lower the visible error. Pixels of similar intensity/luma would share the same color freeing the color for a pixel that is different in brightness or luma
2009-07-22 13:31
DeeKay

Registered: Nov 2002
Posts: 362
Algo: Ofcourse we do have luma-weighting in there, do you think we're morons? <:-) the whole thing is computed in YUV, and colors with similar Y are the first to go...

Still, for some reason, the converter still does it sometimes. I think it's a special case in combination with spritecolors or sth...
2009-07-22 14:06
algorithm

Registered: May 2002
Posts: 702
Could just be a bug or how the routine works that is causing the problem.

A brute force routine based on hires with x expanded hires sprite underlay would be something as follows. Using this method. it should solve the problem

spritecol=0
inkcol=0
papercol=0

loop1:

compare inkcol to pixel1 and compare difference
compare papercol to pixel 1 and compare difference
use least different and plot to pixel1 buffer1
compare inkcol to pixel2 and compare difference
compare papercol to pixel 2 and compare difference
use least different and plot to pixel2 buffer1

compare inkcol to pixel1 and compare difference
compare spritecol to pixel 1 and compare difference
use least different and plot to pixel1 buffer2
compare inkcol to pixel2 and compare difference
compare spritecol to pixel 2 and compare difference
use least different and plot to pixel2 buffer2

compare buffer1 and buffer2 to original 2x1 section of c64 16 color image and plot the 2x1 block with least difference to the required area in buffer3

repeat till 8x8 block is complete

compare 8x8 pixel area in buffer3 with 8x8 section of c64 16 color image and note difference

increment papercolor and go to loop1 till papercolor=16
increment ink color and go to loop1 till ink color=16

use ink/paper color that is the least different to original c64 8x8 block and plot to buffer4.

repeat process till all 1000 chars are complete

compare entire image in buffer 4 to c64 16 color image and note error value

increment spritecol by 1 and go to loop1 till spritecol=16

use spritecolor that gives the least error value and then render the image

The above is a very basic example just from the top of my head. ofcourse optimisations can be 10fold. eg no need to have same paper/sprite color as you cant have paper and spritecol together etc etc



2009-07-22 15:17
Jetboy

Registered: Jul 2006
Posts: 208
Wouldnt taking into account all combinations of charcters, sprites and all possible color changes throughout entire image in case of NUFLI make computations long enough to take years for one picture?
2009-07-22 15:38
algorithm

Registered: May 2002
Posts: 702
Not at all. You would only need to work in smaller slices. eg 8x2 rather than 8x8 etc.

The above routine optimised would take a few seconds to complete. The MUCSU routine takes around 20 minutes on a 1.8ghz machine (Brute force) but that goes through every single multicolor sprite combination rather than mono 16.

Ofcourse if you want to involve sprite x shifting, multicolor/hires toggle for individual sprites in specific area's etc to minimize errors et then it would then take an extremely long time
2009-07-22 16:04
doynax
Account closed

Registered: Oct 2004
Posts: 212
Quote: Algo: Ofcourse we do have luma-weighting in there, do you think we're morons? <:-) the whole thing is computed in YUV, and colors with similar Y are the first to go...

Still, for some reason, the converter still does it sometimes. I think it's a special case in combination with spritecolors or sth...


Care you show us (well, me.. ;) the precise formula and coefficients you guys came up with for the RGB (pr0n) images?

I've experimented with fancy color matching methods taking the relative luminance of the channels and gamma correction into account, but no matter how I tweak it a straight RGB mean-square-error comparison always just seems to look better.

I'd love to have a way of automatically generating fades with anything remotely resembling the quality of hand-tweaked tables.
2009-07-22 16:46
Oswald

Registered: Apr 2002
Posts: 5007
p1 goes into HSB space (hue-saturation-brightness)The solution was peeked from Mirage - to give proper credit. then you build your own hue-brightness lookup table by hand, and dither into a gray table if you want to take away saturation.
2009-07-22 17:57
DeeKay

Registered: Nov 2002
Posts: 362
Actually the idea of using different colorspaces (YUV is rather popular, too) and then matching gradients is quite old... That's what the converter does as well when "prepping" a picture. Works quite nicely, let me post an example pic...

Algo: I should tell you from Bitbreaker that he already does what you do, only way more efficiently and sophisticated! ;-)
It's not like he coughed up that converter in one night, there was much much much trial and error involved, for the NUFLI version he even re-did the whole thing to make it colum-based (six picture sprite columns, one AFLI column (40th char), one flibug column) rather than line-based like before!

Depending on the picture, the converter now takes something like a few SECONDS to render it on one Core of my Quad 2.5 GHz G5!...

Conversion-progress:
--------------------
Processing normal colums: Pr0ncessing line #198 on colum 5
Processing colum 39: Pr0ncessing line #198
Processing fli bug: Pr0ncessing line #198 -1 -2 -2 -2
Maxerror per pixel: 255
Overall error: 0.43%
Erroneous pixels 2784
Writing 'train_v1_errormap.bmp'
Writing 'train_v1_result.bmp'
Writing 'train_v1 .nuf'
calc.time: 8.6370s

(This is Carrion's train!)
2009-07-22 19:12
DeeKay

Registered: Nov 2002
Posts: 362
Here's a prepped example pic from a truecolor photograph i took in Cambodia:


Keep in mind that this is in interlaced colors and that it hasn't gone through the converter yet, it's just how it renders a picture in c64 colors!
2009-07-22 19:57
algorithm

Registered: May 2002
Posts: 702
Deekay. The description of the routine was only based on the most basic example (standard hires and multicolor underlay) I admit the converter code was done in an hour or so.
The point i was making was that with such a mode with far less limitations than standard hires (NUFLI, MUFLI), why there was a substantial amount of errors. I am not trying to put anyone down here. just a constructive critism. I have displayed the wolverine picture converted into plain hires and underlay for comparison and ofcourse the MUFLI/NUFLI version is more defined for the very colorful image, but with two colors every 8x2 in the FLI mode combined with sprite color changes i was expecting less errors without the need to touch up the pictures that much

Ofcourse there is more work to convert to the NUFLI/MUFLI mode. but with the color limitation being lifted, the mode has the capability of displaying with less visible errors

Below is the direct conversion in standard hires and underlay (MUCSU) without any touches to the image


And below this is the NUFLI conversion without any touches


With such a mode able to have 2 different colors per 8x2 and sprite color changes but looking very similar to standard hires with underlay, is it wrong for me to not try to give some critism. Like I said, I only discussed that there must be a possible bug in the conversion routine of the NUFLI converter or how the routine works
2009-07-22 20:06
_V_
Account closed

Registered: Jan 2002
Posts: 124
>> The Era of NUFLI has begun - Bye Bye Interlace!

Well, as I posted in the picture demo thread, interlace does have its merits. Not when you're throwing tons of white in there, but you can sure get some nice glows with the darker tints.

>> 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-

What? No total freedom? And I was so looking forward to plotting an eight colour gradient in a single line of each character! Seriously though, thanks for sharing the restrictions, that helps planning the colouring of my Pokémon conversions...

Will say thanks for this new mode. Fullscreen lotsa flexible colours no interlace is always very, very nice.

Cheers,
Vincent.
PS: By the way, DeeKay, how do the fullscreen IFLI pictures from Krestology hold up after conversion? I kinda hoped for/expected them to pop up in the demo...
-- La vie, c'est la guerre des dualités.
2009-07-22 20:39
algorithm

Registered: May 2002
Posts: 702
Quote: >> The Era of NUFLI has begun - Bye Bye Interlace!

Well, as I posted in the picture demo thread, interlace does have its merits. Not when you're throwing tons of white in there, but you can sure get some nice glows with the darker tints.

>> 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-

What? No total freedom? And I was so looking forward to plotting an eight colour gradient in a single line of each character! Seriously though, thanks for sharing the restrictions, that helps planning the colouring of my Pokémon conversions...

Will say thanks for this new mode. Fullscreen lotsa flexible colours no interlace is always very, very nice.

Cheers,
Vincent.
PS: By the way, DeeKay, how do the fullscreen IFLI pictures from Krestology hold up after conversion? I kinda hoped for/expected them to pop up in the demo...
-- La vie, c'est la guerre des dualités.


Further to that. you cant use spritecolor and a papercolor in a 2x1 area at the same time as the spritepixel is 2x1 in size. only the ink color (at 1x1) can appear at any position
2009-07-22 20:43
DeeKay

Registered: Nov 2002
Posts: 362
Algo: There is no "bug". Two things:
1) You're using multicolor sprites, we use Hires. 4 colors in 8 pixel width vs 3. Like I said before, using MCol sprites in NUFLI should improve quality quite a bit more even!
2) Like I also said before: Your result is pretty much it, it doesn't get much better even with manual work, since you can only change color in a whole 8x8 block (fat chance the converter could not get THAT right!), set or unset bitmap pixels or set one of four colors as the background in a quarter char. that is it! With NUFLI I *can* fix the bugs (and I've NEVER encountered a bug I couldn't fix somehow!) because i have FLI in Bitmap and sprites!

Besides, NUFLI works for almost any picture, not just some selected ones...
2009-07-22 20:45
DeeKay

Registered: Nov 2002
Posts: 362
Quote: Further to that. you cant use spritecolor and a papercolor in a 2x1 area at the same time as the spritepixel is 2x1 in size. only the ink color (at 1x1) can appear at any position

well, no shit, sherlock? 8)

UFLI is from 1996, dude...
2009-07-22 21:00
algorithm

Registered: May 2002
Posts: 702
Quote: Algo: There is no "bug". Two things:
1) You're using multicolor sprites, we use Hires. 4 colors in 8 pixel width vs 3. Like I said before, using MCol sprites in NUFLI should improve quality quite a bit more even!
2) Like I also said before: Your result is pretty much it, it doesn't get much better even with manual work, since you can only change color in a whole 8x8 block (fat chance the converter could not get THAT right!), set or unset bitmap pixels or set one of four colors as the background in a quarter char. that is it! With NUFLI I *can* fix the bugs (and I've NEVER encountered a bug I couldn't fix somehow!) because i have FLI in Bitmap and sprites!

Besides, NUFLI works for almost any picture, not just some selected ones...


No. Multicolor sprite underlay is at 4x1 resolution hence can only have three colors per 8 pixel width. eg any sprite/paper color for first half of 4 pixels, any sprite paper color for second half of 4 pixels and then one ink color freely placeable in the 8 pixel width. There are restrictions in multicolor expanded sprites as you may know. only way of getting rid of blockiness is to mask it with the 1x1 ink color. hence restrictions in both hires x expanded sprites and mcol x expanded sprites each with their advantage and disadvantage
NUFLI gives you 2 colors per 8x2 as well as hires x expanded underlay at 2x1 with sprite colors being able to get changed.

The point i am making is that the MUCSU mode does not use FLI at all and only three fixed sprite colors for the entire screen. but in comparison to the example pics of the guitar in the FLI and sprite changing NUFLI mode and other examples it still gives decent results. Yes I agree that because of the limitations in the standard hires MUCSU mode, it would be harder to touch up the conversion.

Perhaps if i create the sliced mode version of the converter that gives me 6 additional colors per charblock as well as changing the sprite colors you will notice the dramatic difference regardless if it uses hires or multicolor underlay as each have their advantages and disadvantages





2009-07-23 05:56
Jetboy

Registered: Jul 2006
Posts: 208
How about doing ultimate converter, that not only tries all color combinations, but also tires different modes on per line (or rather per n-th line) bitmap and sprite mode changes?
2009-07-23 08:07
DeeKay

Registered: Nov 2002
Posts: 362
Jetboy: People have been talking about that like forever, sometimes it goes by the name ILM (Independent Line Manipulation). I've heard of "compilers" that generate timed displayer code depending on the picture. However, nobody has ever done such a thing, so get cracking, guys!
And it'd better be good, meaning: virtually NO errors after conversion. Because there is simply no way you can fix *anything* by hand in this anymore!
2009-07-23 11:17
Oswald

Registered: Apr 2002
Posts: 5007
algo, its easy to speak theoretically. go write an actual better one. :)
2009-07-23 11:42
algorithm

Registered: May 2002
Posts: 702
When I have the time I will :-)) For the FLI part, I would only need to update the mucsu converter to work on blocks of 8x2 rather than 8x8 and give individual ink/paper color for these sections. although i have read briefly on the specs of MUFLI/NUFLI that the sprite color changes are offset from the start of the 8x2 so would be a better idea to just rewrite everything from scratch (including image zoning - working in chunk sprite sections which the mucsu converter does not do

I have other idea's based on dynamically changing mcol/hires sprite toggle, sprite colors and to implement this onto the converter.



2009-07-23 15:54
Cruzer

Registered: Dec 2001
Posts: 1048
I think DeeKay has a point - it's essential that the mode isn't too advanced to fix up the picture afterwards, since a converter will almost never produce a 100% pretty picture. So there needs to be an editor with the converter. I'm putting this on my list of 387 other ideas.
2009-07-23 17:42
_V_
Account closed

Registered: Jan 2002
Posts: 124
Quote: I think DeeKay has a point - it's essential that the mode isn't too advanced to fix up the picture afterwards, since a converter will almost never produce a 100% pretty picture. So there needs to be an editor with the converter. I'm putting this on my list of 387 other ideas.


I second this. Tried MUCSU in the past and most of the time, once the conversion was nice enough, I wished I had an editor to "post-process" the picture and sort out (what I would perceive to be) the remaining colour issues.

Which reminds me (little MUCSU off-topicing): Algorithm, isn't it possible to move the x position of each sprite per sprite line (or one of the three sprite colours)? Have you considered allowing the sprite x position (sprite colour) to vary as well while calculating the "optimal underlayer"? I have a hunch that even slight changes of these factors may further reduce the calculation error (by reasonable amounts, 10%, say) with the picture sucking up just as much rastertime as before.
-- La vie, c'est la guerre des dualités.
2009-07-23 18:11
irwin
Account closed

Registered: Feb 2009
Posts: 6
When i read this, reminded me a scene from Without a Clue movie with M.Caine and B.Kingsley.

"Dr Watson: - I happen to know that you recently recovered from an illness, that you smoke a pipe, probably rosewood, and you spent time in China...

Lord Smithwick: - Doctor, this is no time for parlour games.

(Holmes back)

Sherlock Holmes: - I can tell you've recently recovered from an illness, smoke a pipe, probably rosewood, and have spent some time in...China.

Lord Smithwick: - AMAZING!"

When Algorithm made amazing MUCSU Conventer almost nobody has noticed how powerfull this program is. Now everyone praise NUFLI but MUSCU is first and almost good as NUFLI. Anyway greetings to both, MUCSU and NUFLI authors. Keep it up!

My MUSCU try: (only 600mhz PC, so i turn off brute force)



2009-07-23 19:19
algorithm

Registered: May 2002
Posts: 702
Quote: I second this. Tried MUCSU in the past and most of the time, once the conversion was nice enough, I wished I had an editor to "post-process" the picture and sort out (what I would perceive to be) the remaining colour issues.

Which reminds me (little MUCSU off-topicing): Algorithm, isn't it possible to move the x position of each sprite per sprite line (or one of the three sprite colours)? Have you considered allowing the sprite x position (sprite colour) to vary as well while calculating the "optimal underlayer"? I have a hunch that even slight changes of these factors may further reduce the calculation error (by reasonable amounts, 10%, say) with the picture sucking up just as much rastertime as before.
-- La vie, c'est la guerre des dualités.


It certainly is possible to zone the sprite sections on a seperate basic choosing an individual main color for each of the sprites (with the other two universal for the main screen) and nothing needs to be changed in the mode at all
and changing x position of the layer of sprites can certainly help as well. can try at offset 0,1,2 and 3 and see which creates the least error

When i created the converter it was only for the use for my new video mode where the above would not work well with animation due to how the Vector quantiser worked

Picture quality can be increased tremendously depending on the picture with zoning methods

2009-07-23 19:28
algorithm

Registered: May 2002
Posts: 702
Quote: When i read this, reminded me a scene from Without a Clue movie with M.Caine and B.Kingsley.

"Dr Watson: - I happen to know that you recently recovered from an illness, that you smoke a pipe, probably rosewood, and you spent time in China...

Lord Smithwick: - Doctor, this is no time for parlour games.

(Holmes back)

Sherlock Holmes: - I can tell you've recently recovered from an illness, smoke a pipe, probably rosewood, and have spent some time in...China.

Lord Smithwick: - AMAZING!"

When Algorithm made amazing MUCSU Conventer almost nobody has noticed how powerfull this program is. Now everyone praise NUFLI but MUSCU is first and almost good as NUFLI. Anyway greetings to both, MUCSU and NUFLI authors. Keep it up!

My MUSCU try: (only 600mhz PC, so i turn off brute force)





Debating whether to use MUCSU mode or NUFLI depends on the use

For image candy. NUFLI is a great mode superior to MUCSU obviously because of its 8x2 FLI and sprite color changes every two lines. But as I said in previous posts, The conversion used in the direct convert examples without retouching (NUFLI/MUFLI) could have been more optimum. Main disadvantage of the above modes. barely any CPU time left

MUCSU was originally not developed as a high quality graphic mode. I wanted 320x200 hires video playback and i wanted as much processing time left for the video decode. Decided to use sprite underlays and created a converter out of it.

Hence proportionally i would have more favour towards MUCSU as the quality in comparison to nearly zilch CPU usage is great in comparison as you can see from the examples i had posted
2009-07-23 19:29
DeeKay

Registered: Nov 2002
Posts: 362
Irwin: Dude, MUFLI, which offers the same and more as MCSU (apart from the FLIbug!), is from August 2006, that was 2.5 years before MCSU!... And the NUFLI-converter and editor was pretty much done in December 2007, we just didn't feel like releasing it without the proper fanfare and production to go with it - which takes some time...

Also, last I checked this was the thread about everything NUFLI, so could we please stop with the MCSU-ads? Open your own thread, thank you very much!...
2009-07-23 19:40
_V_
Account closed

Registered: Jan 2002
Posts: 124
Quote: It certainly is possible to zone the sprite sections on a seperate basic choosing an individual main color for each of the sprites (with the other two universal for the main screen) and nothing needs to be changed in the mode at all
and changing x position of the layer of sprites can certainly help as well. can try at offset 0,1,2 and 3 and see which creates the least error

When i created the converter it was only for the use for my new video mode where the above would not work well with animation due to how the Vector quantiser worked

Picture quality can be increased tremendously depending on the picture with zoning methods



Algorithm, thanks for (in a sense) confirming my intuition :).

DeeKay, no worries, didn't try a hijack, just plain curiosity here as I fiddled around with MUCSU in the past and had a few "What if...?" questions back then. Was nice having the chance to pose them.

Incidentally, how do the Krestology IFLIs fare when being put through the converter? I'd love to see the "Unicorn" without all the white flicker, or the "ESI eagle tribute" pic :)
-- La vie, c'est la guerre des dualités.
2009-07-23 19:44
algorithm

Registered: May 2002
Posts: 702
Not debating which mode is more advanced. NUFLI and MUFLI is FAR more advanced. I was just pointing out that conversion can be more optimum in NUFLI/MUFLI. If MUCSU can produce decent results (Look at untouched violin pic in comparison to NUFLI/MUFLI untouched violin pic) then having additional 6 colors per 8x8 and sprite color changes as in NUFLI/MUFLI should give far better results without the need to touch up any picture
2009-07-23 19:46
Copyfault

Registered: Dec 2001
Posts: 466
Quote: Jetboy: People have been talking about that like forever, sometimes it goes by the name ILM (Independent Line Manipulation). I've heard of "compilers" that generate timed displayer code depending on the picture. However, nobody has ever done such a thing, so get cracking, guys!
And it'd better be good, meaning: virtually NO errors after conversion. Because there is simply no way you can fix *anything* by hand in this anymore!


@DK: actually we did release that Independent Line Manipulator at MS97 (well, an old version at least). But without any converter that did some "preparing job" for your gfx ofcourse nobody ever wanted to do a pic with that tool.

Those rumors about "gfx compilers" are new to me, though.

But you got the point: an editor (especially one like this!) is not enough, so we would still have "to get cracking".


Sorry for being offtopic again, I'll stick to NUFLI from now on.
2009-07-23 20:31
Cruzer

Registered: Dec 2001
Posts: 1048
Those MUCSU pics look quite awesome. Doesn't this mode require other CPU time than setting up the sprites? I.e. no color updates? Then it definitely has some potential for logos etc. in demos.
2009-07-23 20:46
algorithm

Registered: May 2002
Posts: 702
Quote: Those MUCSU pics look quite awesome. Doesn't this mode require other CPU time than setting up the sprites? I.e. no color updates? Then it definitely has some potential for logos etc. in demos.


That was the whole point of the mode initially. not as a high quality gfx mode but for my video routine but results look rather nice

Only multiplexing the sprites are required per 21 lines nothing else. no color splits etc
2009-09-29 17:14
Lubber

Registered: Jan 2002
Posts: 26
did i miss something or is the nufli converter still not being released yet?
2009-10-02 15:38
DeeKay

Registered: Nov 2002
Posts: 362
You didn't miss anything. Just yesterday Xbow and Bitbreaker finally worked out the MUIFLI conversion bugs that we found in Beta-Testing! ;-)
Now some more work on the GUI and we're done...
2009-10-02 22:33
LOGAN
Account closed

Registered: Aug 2003
Posts: 71
That's great news Decay. Don't get me wrong or anything, but 'recent' innovations nowadays seem to need 1 year or more to be presented to the public. In case of NUFLI its almost 2 years?

I really love to see more of those old images converted to NUFLI and I hope the next slide show will be released before the year is over. This will (hopefully) be the standard format for compo images and who knows it might turn up on other places as well like demo's.

Keep'em coming!
2009-10-07 19:32
Wile Coyote

Registered: Mar 2004
Posts: 633
Been tempted to create a NUFLI image. As yet I'm lost for ideas. Hmmm..
2009-11-03 18:39
Wile Coyote

Registered: Mar 2004
Posts: 633
Hmmm..
Settled on an idea *normality meets out of place scary monster*
Here’s goes.. time to test out NUFLI :D
2009-11-03 20:06
Wile Coyote

Registered: Mar 2004
Posts: 633
The editor feels weird to use :)
From what I can tell, the limits are: any 3 colours per 8x2 area.

Stabbing away at F1 - F8 for the various combos..
..along with the A-P, A-P + Shift+, A-P + C=+ to select colours would take a lot of getting used to.

-

The colour selection process could have been made much simpler:
Move to desired 8x2 screen area
Keys 1 - 8, Q - I to select a colour

place pixel :D


2009-11-13 19:53
Wile Coyote

Registered: Mar 2004
Posts: 633
I give up / I gave up.. :/

I’d be amazed to see an image created using the NUFLI editor.
Sure Crest Slide Story showed what the editor can display.
Using the editor causes massive brain ache.

The main editor, feels like a puzzle, with the constant options of switching between, paper, ink, sprite, turning pixels on and off. The FLI element, doesn’t feel very FLI. It felt more like a hires bitmap editor with 8x4 chars, with the bonus of being able to use sprites, with the limitations of, the sprite colour spans 6 characters.

The other editor, that allows for the 1st 3 character columns to be accessed, felt like a whole new puzzle.

The good news is:
*normality meets out of place scary monster*
..is almost complete, and makes using of multi colour bitmap 8)

2009-11-13 20:23
Deev

Registered: Feb 2002
Posts: 206
isn't this the point of the conversion tool? :)

I think everyone knows it's no fun to pixel in NUFLI, which is why no-one's been doing it all this time (the MUFLI editor must be about 2-3 years old now?). What's new is that now you can freely pixel in your preferred PC tool at C64 res and in the c64's palette and then use the tool to convert your work into NUFLI. You then just need to use the NUFLI editor to fix the errors, which is still a little time consuming, but is nowhere near as difficult as pixelling the whole thing from scratch.

without this tool I would've just seen NUFLI as another new graphics mode that hardly anyone would use.
2009-11-16 00:38
SIDWAVE
Account closed

Registered: Apr 2002
Posts: 2238
Enough talk.

Make some pics and upload the displayer source code as an asm file.
2009-11-16 10:31
WVL

Registered: Mar 2002
Posts: 885
Would that be the first sourcecode for a stabilised NUFLI displayer on the internet?

j/k..

Anyway, would love to see the converter :) So please dont forget to release it sometime!
2009-11-16 13:50
SIDWAVE
Account closed

Registered: Apr 2002
Posts: 2238
Enough talk.

Its over 3 months ago that the Crest slide show was released, and there wont ever be any converter, coz that guy is a lazy ass :D
2009-11-16 14:07
Mr. SID

Registered: Jan 2003
Posts: 419
Shut up Jan, you have no idea how much work it is. ;)
2009-11-16 14:59
Linus

Registered: Jun 2004
Posts: 637
Quote:
Enough talk.


Pretty rich words coming from you, sir :)
2009-11-16 17:33
SIDWAVE
Account closed

Registered: Apr 2002
Posts: 2238
Quote: Quote:
Enough talk.


Pretty rich words coming from you, sir :)


Paint something in the NUFLI editor, or gtfo this thread ! :D
2009-11-16 18:06
Linus

Registered: Jun 2004
Posts: 637
What Mr.Sid said, dear Jan.

Kisses,
Linus
2009-11-17 03:13
LOGAN
Account closed

Registered: Aug 2003
Posts: 71
I would appreciate an early Alpha/Beta to be published. They always can improve it as they go and get the cool images coming.
The scene has come far from 0 day releases to uber perfectionists that think not only the software but also the source code itself will never be good enough for the general public.
Or is it held back to ensure Crest superiority in the graphic field for time to come? Hehe..
I bet we'll see Crest Slide Story II before the converter :)
2010-01-13 17:07
Digger

Registered: Mar 2005
Posts: 420
I am thinking of using NUFLI for some real-time generative stuff (this is still purely covered on C64 even in 2010), can anybody provide a src code yet?
2010-01-31 12:56
DeeKay

Registered: Nov 2002
Posts: 362
We're waiting for Yago to Finish The Win/Linux GUI. The cli Version Works now and The mac GUI by mrsid has been finished for ages. Tbh, i'd feel a Bit like i made an Ass of myself if we released sth that was MacOS only, it would essentially no better than all The PPL releasing win-only tools.. The cli version Works though in all posix-compliant environments. So if that was sufficient for ppl, we could release it right now! So what is The general opinion? Release cli+mac-GUI or wait for yago?
2010-01-31 13:01
DeeKay

Registered: Nov 2002
Posts: 362
As for displayer Source Code: dudes, this is crossbow Code, He never uses an Assembler! Smon (or These days VICEmon) only, sorry!
2010-01-31 13:04
DeeKay

Registered: Nov 2002
Posts: 362
Quoting DeeKay
The cli version Works though in all posix-compliant environments.


just to make this clear: Yes, that also means Windows cli (via cygwin)...
2010-01-31 14:29
JackAsser

Registered: Jun 2002
Posts: 1987
Quote: We're waiting for Yago to Finish The Win/Linux GUI. The cli Version Works now and The mac GUI by mrsid has been finished for ages. Tbh, i'd feel a Bit like i made an Ass of myself if we released sth that was MacOS only, it would essentially no better than all The PPL releasing win-only tools.. The cli version Works though in all posix-compliant environments. So if that was sufficient for ppl, we could release it right now! So what is The general opinion? Release cli+mac-GUI or wait for yago?

It's quite simple: Release what you have and release more when you have that. No need to put everything into a big package with golden wrapper paper and the whole shit. :)
2010-01-31 14:53
Mr. SID

Registered: Jan 2003
Posts: 419
I agree! :)
2010-02-01 10:06
enthusi

Registered: May 2004
Posts: 674
Well, I'm linux only (by choice, not religion) and wouldnt mind at all if a linux version is late.
Better late than never and its always good not to rush a GUI as well (Go!Go!Go, yaGo!). So when MAC/WIN are done: shoot ;-)
And great initiative to care for the three big ones!
2010-04-05 11:22
Lubber

Registered: Jan 2002
Posts: 26
@Deekay: Now, after BluREU has proven the converter's quality (i cannot imagine you did manual postproduction within the c64-nufli editor on every ~500 nufli animation frames) it is really time to release the converter. PLEASE! :)
2010-04-05 12:02
Isildur

Registered: Sep 2006
Posts: 274
Yeah! It is good time.
2010-04-05 13:43
irwin
Account closed

Registered: Feb 2009
Posts: 6
Yes, i agree. F-word the GUI ;), commad-line is enough.
2010-04-05 19:17
Bizzmo
Account closed

Registered: Mar 2005
Posts: 82
Conspiracy theorists might start to suggest that maybe the editor wasn't likely to be released until after X... of course I would never insinuate such a thing. ;-)
2010-07-05 19:22
WVL

Registered: Mar 2002
Posts: 885
There was an article in a Dutch newspaper today about the c64 and gaming. It was mainly an interview with the guy from Chronosoft, but there was also a mention of NUFLI! (the way it was written it looked like NUFLI was invented by Chronosoft though :D -> So now the truth behind the identity of Crossbow is finally revealed through excellent Dutch journalism!!)

I'll scan it tomorrow and provide a link.
2010-07-05 19:27
chatGPZ

Registered: Dec 2001
Posts: 11088
Quote:
(the way it was written it looked like NUFLI was invented by Chronosoft though :D)

but... they are. and them bastards are still sitting on the converter!
2010-07-05 19:39
WVL

Registered: Mar 2002
Posts: 885
Courtesy of Hein : http://www.depers.nl/cultuur/492331/Retro-nerds-blijven-in-de-8..

And to save the text for eternity (looks like they made a mistake in the publishing time, it should have been 13:37 ofcourse...) :

Quote:
Games Waarom modern doen als je ook van cassette kunt spelen?
Retro-nerds blijven in de 80’s
Door: David Crookes
Gepubliceerd: vandaag 00:37
Update: vandaag 00:37

Consoles als de Commodore 64 stierven decennia geleden al hun commerciële dood. Toch wordt er met hartelust voor geprogrammeerd.



Sommige mensen bewaren oude platen alsof ze op een kist met goud zitten. Anderen laten trots hun VHS-videocassettes zien, van films die ze allang op dvd hebben gekocht. Ze houden er aan vast uit pure nostalgie, met een zolder vol troep en boze partners tot gevolg.

Maar die nostalgie gaat niet op voor gaming, toch? Als er één wereld is waarin mensen de verandering omarmen, is het wel die van videogames. Hield je in de jaren tachtig van Operation Wolf? Pff, wij spelen online Call of Duty. Gamers zijn technofielen, die gelukzalig marcheren op de puls van alleen de allerbeste elektronica.

Gelukkig zit de wereld minder simpel in elkaar. Net zoals muziekliefhebbers aan de keuzes uit hun jeugd vasthouden, zijn er gamers die uit vrije wil in een tijdcapsule wonen. Retro gaming is niet voor niets big business, ook voor de grote jongens. Zet de Wii maar aan, zap naar Virtual Console (de Xbox heeft met de Game Room iets soortgelijks) en je kunt uren spelen op stokoude spellen als de oerversies van Donkey Kong of The Last Ninja, bekend van de Commodore 64.




Oldtimers
Maar er is meer aan de hand. Er is zoveel liefde voor de technologie van weleer – consoles met minder mogelijkheden dan de zwakste mobiele telefoon van vandaag – dat een groep gamebouwers spellen blijft ontwikkelen voor machines die hun hoogtepunt in de jaren tachtig beleefden. Ze bouwen nieuwe titels voor oldtimercomputers als de Spectrum, Commodore 64 en Amstrad CPC. En niet alleen houden ze de eer hoog van de ‘slaapkamerprogrammeurs’ van die tijd, ze gaan echt tot het gaatje. Ze bouwen spellen, slaan ze op een cassette op, maken er prachtige inlegvellen bij en steken ze in kartonnen paketten met superieure vormgeving.

‘Het is zeer bevredigend om een verzameling op te bouwen van mooi verpakte software. De verpakking is vaak extreem belangrijk voor mensen’, zegt Simon Ullyatt, die vanuit zijn huis een retro-label runt met de naam Cronosoft (‘With us, time is on your side’ is de slogan). Het idee voor het bedrijf kreeg hij in 2002. ‘Ik ben altijd fan geweest van uitgevers met een onafhankelijke ‘punk’-ethiek, de do-it- yourself-labels die kwaliteit leveren via fysieke media.’ Overigens zijn de meeste titels ook online te koop, omgezet voor pc of Macs – de schoorsteen moet ook roken.




Aandacht
Ullyatt is een populair figuur in de retro-gaming scene. Zijn label wordt scherp in de gaten gehouden, en aan nieuwe titels heeft Cronosoft nooit tekort. Een paar dagen nadat Ullyatt om spellen vroeg op een online forum, stroomden de aanmeldingen binnen en kon het bedrijf Egghead in Space uitgeven, van programmeur Jonathan Cauldwell. ‘Ik schrijf voor oude machines voor het plezier en het gevoel van vrijheid dat ik heb’, zegt Cauldwell. ‘Of ik nu een voetbal het doel in wil laten vliegen, ruimteschepen wil laten exploderen of varkens in formatie wil laten vliegen: het kan en mag allemaal omdat er geen enkele druk is om er een commercieel succes van te maken. Er is een klein leger van retro-gamers dat standaard de spellen koopt en speelt, en feedback geeft via internet. En dat is het.’

Zoals vele old school-programmeurs begon ook Cauldwell in de jaren tachtig te programmeren. In die tijd werden een paar van zijn spellen uitgegeven. Toen de consoles waarvoor hij schreef hun commerciële dood stierven, bleef Cauldwell programmeren, en nu bereikt hij resultaten die in de jaren tachtig niet voor mogelijk werden gehouden. Voor de Commodore 64 werd bijvoorbeeld een nieuwe code geschreven, NUFLI, waarmee hij de graphics een impuls kon geven: games zien er nu uit zoals ze er in 1980 niet uit kónden zien.

Voor het geld hoeft het overigens niet. Bedrijven als Cronosoft en Psytronik Software komen uit de kosten, daar is alles mee gezegd. ‘De balans bij Cronosoft loopt in de honderden Engelse ponden’, lacht Ullyatt. ‘Niet in de miljoenen.’
2010-07-05 20:21
Steppe

Registered: Jan 2002
Posts: 1509
I thought I'd run this through Babelfish autotranslator to save you all the effort. With a bit of imagination you should be able to understand it. :-)

Consoles such as the commodore 64 died decades suffered already their commercial dead. Toch there with hartelust for is programmed. Some people keep old plates as if they sit on a travelling box with gold. Others show proudly their VHS-videocassettes, of films which they have bought for a long time on dvd. They hold there to from pure nostalgie, with an attic full troop and boze partners to consequence. But that nostalgie does not go up for gaming, nevertheless? If there, is one world in which people embrace the change, it, however, which of videogames, is. Did you love eighty Operation wolves in the years? Pff, we play online Call or Duty. Gamers are technofielen, which march blissfully on the puls of only the very best elektronica. Fortunately the world less sits ly in each other. Just like music devotees to the choices from their youth, are gamers hold there which lives by one's own free will in a time capsule. Retro gaming are not for nothing piglet business, also for the large boys. The Wii beginning but, zap to Virtual console (the Xbox have with the Game Room something similar) and you can hours play on decrepit game such as the oerversies of Donkey Kong or The charge Ninja, confessed of the commodore 64. Old-timers But is there more to the hand. There is so much love for the technology of weleer - consoles with less possibilities than the weakest mobile tel. of today - that a group gamebouwers continues develop game for machines which lived their peak in the years eighty. They build new titles for old-timer computers such as the spectrum, commodore 64 and Amstrad CPC. And they not only love the honour high the `slaapkamerprogrammeurs' that time, they really go to the prick. Them, store them on a cassette, make splendid inlegvellen and put they build game in hamper paketten with superior design. `It is very satisfactorily build a collection of nicely packed software. Packing is frequently extremely important for mensen', says Simon Ullyatt, which manages retro-label from its house with the name Cronosoft (`With US, time are on your side' are the slogan). He got the idea for the company in 2002. `I always supporter has been of editors with independent `punk'- ethics, do-it- the yourself labels which deliver a quality product by means of physical mediums. Moreover the most of titles also online buy have been transposed, for pc. or Macs - the chimney must smoke also. Attention Ullyatt are a popular character in retro-gaming the scene. Its label is watched sharply, and to new titles Cronosoft have never shortage. A couple days after Ullyatt asked to spell on an online forum, streamed in the applications and could the company Egghead in Space spend, of programmer Jonathan Cauldwell. `I write for old machines for the pleasure and the feeling of freedom I heb', say Cauldwell to that. `Or I now a football the aim in wants leave flies, spacecrafts wants let explode or varkens in formation want leave flies: it is possible and can all because there is none busy there a commercial make success. There is a small army of retro-gamers that standard buys the game and plays, and feedback gives by means of Internet. And that is it. Such as a lot of old school-programmeurs also Cauldwell in the years eighty started program. In that time a couple of its game were spent. When the consoles for which he wrote their commercial dead died, program Cauldwell, and now reaches he results which were not kept in the years eighty for possible, continued. For the commodore 64 a new code was for example written, NUFLI, with which he could the graphics give a impetus: games do not see seeing now such as them in 1980, kónden. For the money it does not need moreover. Companies such as Cronosoft and Psytronik software come from the costs, with that everything have been said. `The assessment at Cronosoft runs in the hundreds English ponden', laughs Ullyatt. `Not in the millions.
2010-07-06 00:17
SIDWAVE
Account closed

Registered: Apr 2002
Posts: 2238
no more talk.

release the converter, or there is no future for NUFLI :(
2010-07-06 00:38
Conjuror

Registered: Aug 2004
Posts: 168
And before X PLEASE!!!

I'm sure I'm not the only one with pictures waiting for conversion.

Lets make X the party of NUFLI art.
2010-07-06 07:05
Scout

Registered: Dec 2002
Posts: 1568
This is the original article in English.

"The new wave of retro gaming"

http://www.independent.co.uk/life-style/gadgets-and-tech/gaming..
2010-07-06 08:26
chatGPZ

Registered: Dec 2001
Posts: 11088
Quote:
I'm sure I'm not the only one with pictures waiting for conversion.


*sigh* sander, hein, mermaid, ptoing, saehn .... koala please. thanks.
2010-07-06 12:16
enthusi

Registered: May 2004
Posts: 674
Though I too prefer HiRes and Koala as formats in some way,
I'd love to see that converter out ;-)
Beeing playing some with it and with the beautyful native editor that even I kind of managed after introduction by veto :)
2010-07-06 21:07
Frantic

Registered: Mar 2003
Posts: 1626
Bah.. PETSCII interlace is the ph4tt3z+.
2010-07-07 09:18
DeeKay

Registered: Nov 2002
Posts: 362
Okay, here's a quick status update:
We found a bug in the displayer, so Crossbow fixed that one. The new routine had to be integrated into the converter, and along the way Bitbreaker also improved the FLIbug color rendering quite a bit (it now checks if it can make color switches one line earlier when no switches are free) and also fixed a bug that would cause an ugly grey stripe in the top left (had to remove that manually in every frame of the shark sequence in BluREU!). Crossbow also made a new version of the NUFLI editor (v1.9) which not only integrates the new displayer but also fixes some bugs that would occasionally display grey in the FLIbug editor. Mrsid also made some optimizations on the converter some days ago, so now it is 30% faster. Bitbreaker is improving the color-finding logic right now since Crossbow found that it makes some illogical choices every now and then. I'm waiting for the final okay from Crossbow after that, then we just need to slap on Enthusi's python-GUI and Alih needs to make that Windows-Standalone-EXE of it, and then it'll finally be released! ;-)
2010-07-07 09:38
enthusi

Registered: May 2004
Posts: 674
Ah thanks for the nice update :)
I see its not been on ice at all ;-)
Ok, I am ready for adjustments to the GUI when needed.
2010-07-07 14:27
DeeKay

Registered: Nov 2002
Posts: 362
No, it appears like we're just lazy, but we've been working on it (on and off, depending on vacation, laziness etc! 8) for all this time! ;-D

Good thing we didn't release it before these bugs were fixed, cause they can be a pain in the ass and require manual replacing of the displayer code, which sucks!...
2010-07-07 19:28
PAL

Registered: Mar 2009
Posts: 269
Lets make X the party of NUFLI art.

Let us NOT make the X the party of NUFLI... let us create the native in the best possible fasion? What about that? Let us create koalas and have a real fight inside the pigfarm... put the native to the max? What about it? It would be so much fun to do it like in the old days... the year is 2010 so it is cooler to do it with what was the peak of the graphics scene some 22 years ago, just before fli came out...
2010-07-07 19:41
algorithm

Registered: May 2002
Posts: 702
Well. the NUFLI gfx mode is currently the ultimate full screen graphic mode for the C64 (non interlace) Only improvements would really be to have FLI per line (but that would make the image more narrow) or to have a hybrid interlace method.
Dont want to give much away but hopefully in X10 there will be a demo which displays a new fullscreen gfx mode :-)
2010-07-08 03:29
Conjuror

Registered: Aug 2004
Posts: 168
NUFLI is native to the c64 :D

Push the limits!
2010-07-08 06:10
Perplex

Registered: Feb 2009
Posts: 254
Quote: NUFLI is native to the c64 :D

Push the limits!


Indeed it is native.

The invention of NUFLI and the release of C.S.S. was pushing the limits. Releasing more pictures in that very same graphics mode 1 year later is not pushing any limits, however.

I think NUFLI was *great* as a one-off thing, and if you can do something *new* with it then I can't wait to see it. If you're just drawing a picture, I'm personally much more interested in seeing what you can achieve within the limits of the standard bitmap modes.

Then again, maybe I'm just a grumpy old man.
2010-07-08 07:03
enthusi

Registered: May 2004
Posts: 674
Hehe, well NUFLI started with quite some quality.
And breakpoint presented top notch examples by veto and ragnarok. I think NUFLI is a new platform for 'art' (not my favorite word indeed) on the c64.
We shall see tons of stupid conversions but at least with NUFLI, stupid conversions look nice as well :)
So less disturbing than dithered FLI converted BMPs of the last decade...
This is automatically converted through the yet-to-come converter. Not a single pixel set manually. It's awesome but certainly lacks what makes a good picture that comes from the mind and heart.

Beat that with koala/HiRes (and people here sure can do it) and you beat it all!
So I think NUFLI wont kill the gfx-scene (as if anything ever could) but it will raise the lower limit and make true artists shine even more (by using non-cpu modes or by utilising NUFLI proplerly which aint a piece-of-cake either).
enthusi
2010-07-08 08:28
DeeKay

Registered: Nov 2002
Posts: 362
NUFLI means the death of Koala and Hires - just like IFLI did! ;-)

Face it: NUFLI is an exciting new option, but in no way does it mean that it's a substitute for Koala and Hires!.. The only thing it kills (and was made to kill actually! ;-) is the flickermess that is IFLI (yes, i always loathed it, check my profile!).. And no matter what some people that are hesitant to let go of their beloved IFLI say: There's just no situation in which IFLI is better - i think even on the bigscreen NUFLI looks nicer, since you can actually see the ditherstyle and hence the pixel-craftsmanship! ;-)

NUFLI does make possible new styles and techniques that weren't possible before - but that have yet to be explored, it's just gonna take some time till people adapt to it...

enthusi: isn't that picture MUIFLI? ;-)
2010-07-08 09:03
enthusi

Registered: May 2004
Posts: 674
Deekay: you should think, eh?
Clearly my secret converter skills show, haha.
Nope - pure NUFLI.

edit:
http://enthusi.de/img1.nuf
launch with SYS 12288.
2010-07-08 09:48
Perplex

Registered: Feb 2009
Posts: 254
Quoting DeeKay
...you can actually see the ditherstyle and hence the pixel-craftsmanship! ;-)


The ditherstyle and pixel-craftsmanship of the converter, yes?
2010-07-08 11:36
Carrion

Registered: Feb 2009
Posts: 317
DK
Koala is not dead neither is Hires! Take a look at Joe's latest works they are beter than ever (and pure koala) or Vetos or Deev's hireses... to name a few.

You say:
Quoting DeeKay

NUFLI does make possible new styles and techniques that weren't possible before - but that have yet to be explored, it's just gonna take some time till people adapt to it

Totaly agree, BUT people will not adopt it untill the converter will be released. It's now a year since CSS and I've seen 5 maybe 7 NUFLI pics since then. Mostly done by people who have access to You and/or Myself.
I hate to say it but I stoped to use NUFLI untill the converter will be released and all of us will have the same chances. For now koala is my mode of choice

And I know, I know about the NUFLI editor but using it from scratch is brain dead idea!
2010-07-08 12:04
DeeKay

Registered: Nov 2002
Posts: 362
Perplex: No, YOUR ditherstyle. We made the converter for people that don't wanna worry about limitations (=the crowd that flocked to IFLI) and just do their pics in c64 colors in Timanthes, Photoshop, Pixen, Project1, Promotion or whatever and then simply convert them (and fix them a bit).

Bitbreaker also built in that truecolor convert ability, but that's not what it's about. He just did it for the pr0n basically! ;-) And you can definately tell the stuff that has been converted from truecolor, enthusi's pic looks nice, but not like pixelled! 8)

Carrion: Fair enuff. Shouldn't be much longer! ;-D
2010-07-08 16:06
Sampaguita
Account closed

Registered: Apr 2008
Posts: 29
I'm really looking forward to use it, too. I thought about trying IFLI for my next pixeling attempt, but it would be interesting to see how it works out in NUFLI. :)

Maybe it's a stupid question but is there anything available to create a PRG out of it?
2010-07-08 17:24
enthusi

Registered: May 2004
Posts: 674
You dont need a separate displayer.
(You find technical information on the format in the editor itself).
The file format (see the .nuf-file I linked to) contains a display-code that can be launched via SYS 12288 (or exomize it accordingly, beware, 12288 is NOT the load-adress).
Both, the converter and the native editor use this NUF format for output and i/o, respectively (optionally a packed version).
For such a mem-hungry format, quite genious IMHO.
2010-07-09 10:58
Sampaguita
Account closed

Registered: Apr 2008
Posts: 29
Quoting enthusi
You dont need a separate displayer.
(You find technical information on the format in the editor itself).
The file format (see the .nuf-file I linked to) contains a display-code that can be launched via SYS 12288 (or exomize it accordingly, beware, 12288 is NOT the load-adress).


Very interesting. So I can just put the .nuf file into a .d64 file, load and launch it. Did I get that right?

Are the technical information already available somewhere? I would like to know the possibilities and restrictions of NUFLI in detail. :)
2010-07-09 11:26
Carrion

Registered: Feb 2009
Posts: 317
Sampa:
Yes You can. but then you have to do SYS 12288 or G$3000. It's better to put it through exomizer and make it runnable.
2010-07-09 12:28
Trap

Registered: Jul 2010
Posts: 221
Excuse my ignorance, but what exactly is NUFLI? (From a technical point of view) I understand it's a new graphics mode, but what are the specs and how do you do it?
A link to more info would be appreciated.

Trap
2010-07-09 13:53
Stainless Steel

Registered: Mar 2003
Posts: 966
According to DeeKay, it's the alpha and the omega, the beginning and the end of all GFX modes :-D
2010-07-09 14:34
Perplex

Registered: Feb 2009
Posts: 254
Quote: Excuse my ignorance, but what exactly is NUFLI? (From a technical point of view) I understand it's a new graphics mode, but what are the specs and how do you do it?
A link to more info would be appreciated.

Trap


Hi Trap! Take a look at post #11 by DeeKay in this thread, it gives a brief technical explanation of how the mode works.
2010-07-09 17:38
Cresh

Registered: Jan 2004
Posts: 354
And/or if you possibly speak POLISH, you can check issue no. 5 of C&A FAN magazine. ;)

http://ca-fan.pl/wszystkie-numery.html
2010-07-09 20:22
ptoing

Registered: Sep 2005
Posts: 271
I never use IFLI!
But yeh, my stuff is converted, tho I always make sure it goes in 100% checked so that chars do not get raped by the conversion process.
2010-07-10 20:16
WVL

Registered: Mar 2002
Posts: 885
@Trap :

First you should understand UFLI, it's every 2nd line AFLI with 7 sprites under the bitmap, 6 expanded singlecolor for graphics (36 chars wide), and one to hide the grey area.

After this, Crossbow came up with MUFLI, which is basically the same, but used the free cycles to be able to change all the 6 sprite colors every 2nd line aswell, giving a lot more possibilities.

NUFLI is the 3rd generation, basically very much like MUFLI, but using all 40 chars. NUFLI was introduced in Crest Slide Story.

Oh, and I posted the exact specifications for UFLI somewhere else in the forums. With memory maps and example code.
2010-07-10 22:07
Ksubi
Account closed

Registered: Nov 2007
Posts: 87
I dont know about anyone else, but all these different graphic modes get confusing at times, especially the +fli range. When it comes to coding and pixelling in these modes, a site that covers all the specs would be nice. I know that Groepaz has started this on Codebase64, perhaps an update? (Or at c64pixels.com?) Or even a thread here that ties it all together. Just a thought...
2010-07-11 21:50
algorithm

Registered: May 2002
Posts: 702
There is a brief roundup of gfx modes with examples on my site
http://www.algotechproductions.com/articles/c64gfxmodes/c64gfxm..
2010-07-11 23:34
v3to

Registered: Feb 2005
Posts: 150
ksubi: actually there are plans to implement common c64 graphic related sections like format descriptions. but there are more important issues to deal with first.
2010-07-12 04:53
chatGPZ

Registered: Dec 2001
Posts: 11088
Quote:
Groepaz has started this on Codebase64

not really. this list evolved when i was making my (unreleased) grafik converter 10 years ago or so. it has been in AAY64 for a long time before it went into codebase too :)
2010-07-12 11:36
Frantic

Registered: Mar 2003
Posts: 1626
The list on Codebase has some slight modifications though, made by Magervalp. It is therefore a newer "version". Can't remember if MV actually added information though, or whether he just questioned the accuracy of some info in there. :)
2010-07-12 12:25
Ksubi
Account closed

Registered: Nov 2007
Posts: 87
Ok thanks :) (I made a minor update to the codebase list, hopefully i'll get around to updating some of the basic modes in due course.)
2010-07-12 17:23
WVL

Registered: Mar 2002
Posts: 885
Oh well.. A list like that will never be complete. Do you really need to list every little variation? You could add 3 gfx modes I'm toying with, but none of them are worth adding to the list.

Anyway, the people that can actually use such information don't really need it, they can figure it out for themselves :)
2010-07-13 08:27
DeeKay

Registered: Nov 2002
Posts: 362
WvL: I think gpz criterions for adding formats to the list were:
1) Is there a file format?
2) Is there an editor for it?

A few of the listed formats don't adhere to the second criterion, but all of them to the first...

So who's gonna add NU(I)FLI and MU(I)FLI to the list? ;-)

Dee
2010-07-13 08:39
chatGPZ

Registered: Dec 2001
Posts: 11088
Quote:

WvL: I think gpz criterions for adding formats to the list were:
1) Is there a file format?
2) Is there an editor for it?

A few of the listed formats don't adhere to the second criterion, but all of them to the first...


yes, i basically collected all fullscreen gfx formats for which a native editor exists. (and i dont see the point at all to write specs for gfx formats that dont have an editor - because you can make it however you like)

Quote:

So who's gonna add NU(I)FLI and MU(I)FLI to the list? ;-)


did that long ago, maybe even conversion works =P however, all fli formats that have a sprite layer are a bit pointless to list the way it is done there - because all sprite related info is missing. and if you can make up the sprite related stuff yourself, you dont need any of the info at all =)
2010-07-13 23:13
MagerValp

Registered: Dec 2001
Posts: 1055
Quote: The list on Codebase has some slight modifications though, made by Magervalp. It is therefore a newer "version". Can't remember if MV actually added information though, or whether he just questioned the accuracy of some info in there. :)

No additions, but a bunch of corrections - see wiki editing history.
2010-08-01 12:45
DeeKay

Registered: Nov 2002
Posts: 362
Just a quick update:
The CLI part is finalized now, I have Crossbow's okay to release it. We found one more bug in the editor which has been fixed. Bitbreaker re-worked the FLIbug renderer, it's now much better than before. A release won't hopefully take much longer, now the ball is in the GUI coders' ballpark...
2010-08-01 15:07
Oswald

Registered: Apr 2002
Posts: 5007
I guess people would have been happier with something half usable, than having to wait 2 years for an uber perfect release.
2010-08-01 15:32
DeeKay

Registered: Nov 2002
Posts: 362
maybe. but we wouldn't have been happy! ;-) Best quality is our tradition after all...

besides: two years is a bit extreme. Maybe we've been developing it for two years, but NUFLI itself wasn't done till early last year and CSS was released in August. And believe me: you wouldn't want to have used it two years ago, the quality wasn't nearly where it is today! ;-)
2010-08-14 16:25
DeeKay

Registered: Nov 2002
Posts: 362
It is fiinally done, grab it while it's hot:

Mufflon V1.0
2010-08-15 04:03
Deev

Registered: Feb 2002
Posts: 206
Excellent work with this!

The converter does a great job and is what makes this so good. The mode is very powerful, but to pixel something from scratch in the editor would drive the average person insane!

Even using the editor for fixing seems like some crazy mind-game (especially once you start changing the sprite colours!), but after just a couple of hours it's all starting to fit into place. Even so, the undo option was a very useful addition as a few wrong clicks can make a huge mess of things!

It's easy to become frustrated with when you can't always place a colour exactly where you want it, but most people are never going to notice these minor issues and pal blur does a good job of covering things up anyway!

Once again, great work! I'm looking forward to using the mode some more!
2010-08-15 08:01
Wile Coyote

Registered: Mar 2004
Posts: 633
@Deev I tried and failed some months ago.
After an hour I managed to fill up about 16 pixels in a single char.
The number key combo’s required to select colours is mind boggling.
I printed out a page complete colours + corresponding keys. It didn’t help.
I came away thinking that the editors main purpose is to allow for the cleaning up converted images.

As with SHIF etc I can’t imagine this format showing up during too many non Crest demos.
2010-08-15 14:50
DeeKay

Registered: Nov 2002
Posts: 362
Wile: Well, no, the converter came after the editor, which is pretty much the same as the MUFLI one! :-)
There's just not a whole lot we can do to ease the pixelling in these modes. at least if you want to be able to use the full possibilities! There's simply no way we can just say select color and pixel away, cause the editor would have to determine on the fly how best to render the pixel - and continue to do so when you set further pixels in the same block!
But I'm open to good suggestions if you have them. Please also do keep in mind that we're a bit restricted on the memory side, so there's not very many functions we can include (such as linedraw, fill, copy, multiple pictures etc!).

But yes, you CAN definately learn to work in these modes, it's not that different to UFLI, and quite a few UFLI pictures have been made after all by several artists (including yourself! ;-). Also a NUFLI one by Bimber was done completely in the editor (well, prolly with hires import, but still! ;-) But most gfxians don't want to spend the time to learn how to work in the editors - which is okay, cause that's exactly why we made the converter!

Crossbow sent me the MUIFLI editor back then and while i definately saw the amazing possibilities the mode offered, i was just not willing to pixel something from scratch in it. With UIFLI it has taken me over 200 hours to fill up a whole screen, with the extra spritecolor feature the time needed would just be insane in MUIFLI!... Hence I set out to find someone to do a converter for it, and then use my expertise to fix certain problematic areas only. This was the origin of Mufflon! ;-)
2010-08-29 10:44
Wile Coyote

Registered: Mar 2004
Posts: 633
Apologizes in advance if the features are supported already.

Mufflon v1.0
A save as .d64 image would have been helpful.

NUFLI Editor v1.11
An option to change the border colour and save as executable would have been good.
2010-08-29 11:32
enthusi

Registered: May 2004
Posts: 674
all NUF files can be executed right away after load via SYS 12288. Alternatively run it through your favorite packer such as exomizer to get a RUN-able file. Just be aware: load-adress != start-adress. In _my_ opinion both, the editor + the converter go down as far (towards end-user output) as reasonable already. Also generating an empty d64 and adding the NUF-file is a one-liner in c1541 which comes with vice.
2010-08-29 11:40
chatGPZ

Registered: Dec 2001
Posts: 11088
i demand "submit to graphics compo" and "look up on tineye.com" buttons !
2010-09-19 00:46
Deev

Registered: Feb 2002
Posts: 206
is there a way to change the border colour?
2010-09-19 07:36
v3to

Registered: Feb 2005
Posts: 150
the linked timanthes file contains two transparent layers to show the color matrix of the sprites (cyan area in screenshot). left area is the area marks the fli bug, the right one the afli column.


nufli_spritelayer.pdn
2010-09-20 09:40
DeeKay

Registered: Nov 2002
Posts: 362
Quote: is there a way to change the border colour?

Yes, it's all in the mufflon help how to do it. Why does nobody seem to bother to read it when I spent so much time packing all my knowhow into it? ;-)
2010-10-04 12:12
DeeKay

Registered: Nov 2002
Posts: 362
Okay, X2010 is over, and NUFLI was a massive success. I did a count on the pictures already uploaded (four are still missing, so it might even be more!) and so far 9 of the 38 pictures in that amazing competition are in NUFLI, with NUFLIs on #1, #3 and #4! ;-D

Veto (#1), Bimber (#3), Deev (#4), Electric (#10), Riskej (#15), Zeldin (#18), Miras (#19), Scarab (#20), Grass (#28)

Seeing how there's exactly zero IFLIs or Drazlaces in that amazingly massive compo with 38 entries, I'd say: Mission accomplished! 8))) It was worth all the work after all, hehe...

Thanks to all participants and a special nod to all the people that handed in NUFLIs! ;-D
2010-10-08 04:38
mikme

Registered: Dec 2007
Posts: 5
NUFLI is a great mode! Crossbow, DeeKay, thank you.

BTW, NUFLI Editor also very good editor - I retouch my picture for just a week (and it was my first experience in pixeling on the c=64).
2010-10-08 14:18
The Phantom
Account closed

Registered: Jan 2004
Posts: 358
This NUFLI thing looks incredible. I look forward to playing with it.

I have a particular Dragon I've been working on in Art Studio (multicolor) and would like to know if there is a way to get the pic into NUFLI.

Can I convert scanned PC images for use with NUFLI? I would love to get more of my paper artwork on c64. Actually, it might be easier for me to draw on paper and convert into some c64 format. Most of my future artwork is converted from paper, but the amount of work put into these pieces seemed to take longer than the actual picture did.

There's a particular skull I drew back in the early 90's and used basically every "red" color pencil I could find, I think this skull would look sweet in NUFLI, as well as my Dragon..

Please tell me if there's a way to do this.
2010-10-08 14:20
Frantic

Registered: Mar 2003
Posts: 1626
@Phantom: Use the converter? :) Mufflon, or whatever it was called? :)
2010-10-08 18:22
DeeKay

Registered: Nov 2002
Posts: 362
Quote: This NUFLI thing looks incredible. I look forward to playing with it.

I have a particular Dragon I've been working on in Art Studio (multicolor) and would like to know if there is a way to get the pic into NUFLI.

Can I convert scanned PC images for use with NUFLI? I would love to get more of my paper artwork on c64. Actually, it might be easier for me to draw on paper and convert into some c64 format. Most of my future artwork is converted from paper, but the amount of work put into these pieces seemed to take longer than the actual picture did.

There's a particular skull I drew back in the early 90's and used basically every "red" color pencil I could find, I think this skull would look sweet in NUFLI, as well as my Dragon..

Please tell me if there's a way to do this.


I'd scan it, clean up the image, convert it to c64 palette by whatever means (photoshop indexing sucks, use timanthes or even the auto-prep of mufflon, use the "save pre-convert" button!) and then put it through mufflon and fix the bugs in the editor...
2010-10-21 02:36
Jazzcat

Registered: Feb 2002
Posts: 1044
DeeKay: agreed. Awesome gfx compo (wow, it is one of the best in the last decade for sure) - interesting statistics, IFLI-mode appears truely dead!
2010-11-05 15:08
wrampi
Account closed

Registered: Sep 2010
Posts: 4
i want to make a little slideshow of my nuli pictures. how i make a slideshow on a c64? i must for every picture make a reset.
2010-11-05 15:57
Mace

Registered: May 2002
Posts: 1799
Quoting wrampi
i want to make a little slideshow of my nuli pictures. how i make a slideshow on a c64? i must for every picture make a reset.

You can't.
NUFLI is so incredibly difficult, even for a C64, that you can't do two pictures without a hard reset in between.
Or... wait... Carrion's OLDSCHOOL Pixels 100%

Ah, you just have to code one!
2010-11-05 16:12
wrampi
Account closed

Registered: Sep 2010
Posts: 4
i don´t want load 2 pictures at the same time.i want load picture for picture.
2010-11-05 17:07
DeeKay

Registered: Nov 2002
Posts: 362
Ofcourse you can do 2 NUFLI pictures at the same time, what do you think NUIFLI is? 8)

And loading picture after picture (with double buffering) is no problem, see Crest Slide Story!...
2010-11-05 18:28
wrampi
Account closed

Registered: Sep 2010
Posts: 4
the problem is that the picture never end after start with sys12288.
2010-11-22 18:55
Madhead

Registered: Sep 2004
Posts: 18
maybe i accidentally missed it on csdb, but check this out http://www.youtube.com/user/YouRolandTube

especially chamelon and winter village videos.
2010-11-23 16:59
Isildur

Registered: Sep 2006
Posts: 274
OMG, FIRE!
2012-04-11 19:32
Isildur

Registered: Sep 2006
Posts: 274
Hey,
Does anybody know a file structure of the NUFLI?
I mean where is bitmap and sprites allocated.
2012-04-11 20:01
Bitbreaker

Registered: Oct 2002
Posts: 498
@Isildur
Can't tell you straight out of my head, but reading a bit through the source of mufflon (void convert_nufli(MufflonContext *m) is what you want) should reveal all details about that. There's lots of sprite chunks, 2 Bitmap blocks and some tables (color switches) and values (initial colors, sprite pointers) to be set up.
RefreshSubscribe to this thread:

You need to be logged in to post in the forum.

Search the forum:
Search   for   in  
All times are CET.
Search CSDb
Advanced
Users Online
Didi/Laxity
Nordischsound/Hokuto..
CopAss/Leader
Exile/Anubis
deetsay
Mihai
jmin
Scrap/Genesis Project
Guests online: 328
Top Demos
1 Next Level  (9.8)
2 Mojo  (9.7)
3 Coma Light 13  (9.7)
4 Edge of Disgrace  (9.6)
5 No Bounds  (9.6)
6 Comaland 100%  (9.6)
7 Uncensored  (9.6)
8 The Ghost  (9.6)
9 Wonderland XIV  (9.6)
10 Bromance  (9.6)
Top onefile Demos
1 Party Elk 2  (9.7)
2 Cubic Dream  (9.6)
3 Copper Booze  (9.5)
4 Rainbow Connection  (9.5)
5 TRSAC, Gabber & Pebe..  (9.5)
6 Onscreen 5k  (9.5)
7 Dawnfall V1.1  (9.5)
8 Quadrants  (9.5)
9 Daah, Those Acid Pil..  (9.5)
10 Birth of a Flower  (9.5)
Top Groups
1 Booze Design  (9.3)
2 Nostalgia  (9.3)
3 Oxyron  (9.3)
4 Censor Design  (9.3)
5 Crest  (9.3)
Top Logo Graphicians
1 Sander  (10)
2 Facet  (9.7)
3 Mermaid  (9.4)
4 Pal  (9.4)
5 Shine  (9.3)

Home - Disclaimer
Copyright © No Name 2001-2024
Page generated in: 0.414 sec.