[CSDb] - User Forums - This is the Thread for everything NUFLI!

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!

... 160 posts hidden. Click here to view all posts....

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.