[CSDb] - User Forums - Taking NUFLI one step further

Welcome to our latest new user Northwind ! (Registered 2024-11-20)

You are not logged in - nap

CSDb User Forums

Forums > C64 Coding > Taking NUFLI one step further

2024-11-10 22:46

cobbpg

Registered: Jan 2022
Posts: 15

Taking NUFLI one step further

I'm working on a new converter for creating images the C64 can display with as much freedom as possible: NUFLI Studio preview video.

The images are NUFLI with the sprite colour limitations lifted: all sprite colours outside the FLI bug area can potentially change in every row. While this is impossible in general due to CPU time limitations, the solution is to generate the speedcode that updates the registers ahead of time. The code generator can make informed decisions about dropping the least impactful register changes to fit everything into the available budget. In practice, most pictures don't require all the 10 possible colour updates on every scanline, far from it.

Another big innovation compared to Mufflon is the improvement in conversion speed. Lifting the sprite colour change limitations makes it easy to fully parallelise the brute force colour search step for each 48x2 pixel area (or 24x2 pixels over the FLI bug), and this allowed me to implement it as a compute shader. The whole process takes about 0.25 seconds on my three-year-old gaming laptop. Besides, when using the internal editor, only the affected areas are recomputed, and they can be previewed in VICE right away (note that the video shows some lag that's probably introduced by OBS somehow; it doesn't happen outside recording).

My hope is that making the feedback practically instantaneous (even when using an external image editor) opens the door for pixel artists to develop a much better intuition about this image format. Also, removing the limitation of only changing sprite colours every second row should make it a lot less frustrating to work with.

I'm not sure what to call this image format. This is 95% NUFLI, the only real difference is that the speedcode is also generated ahead of time (when run on NTSC, there's a patching step done by the displayer routine to make it work), so the files are 4096 bytes bigger (they load from $1000 instead of $2000, the rest of the structure is almost identical). I'm leaning towards "NUFLI2" to make it somewhat search engine friendly, but I'm open to ideas.

At the moment I'm in the process of writing a manual for the tool and a deep-dive article about the technical details. Hopefully neither of those will take too long!

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

2024-11-14 19:23

Danzig

Registered: Jun 2002
Posts: 440

NXFLI? (Next-FLI) NGFLI? (Next Generation-FLI)

2024-11-14 20:13

tlr

Registered: Sep 2003
Posts: 1787

NUFLING

2024-11-14 20:55

cobbpg

Registered: Jan 2022
Posts: 15

I do like NUFLIX actually, it's as close to NUFLI+ as it gets!

Quoting Copyfault

Not meant too serious, but you should maybe keep this for the next Performers-Demo and name the mode 'NextFli' ;)

To be fair, the visual improvement over NUFLI is not that obvious, at least in the current incarnation that keeps the same sprite arrangement. I think the real contribution here is (hopefully) to make it much more fun and less frustrating to create such pictures in the first place, and it might encourage more artists to give it a go.

Making the sprite setup customisable would also subsume QCH (i.e. 320x200 hires bitmap with 2 colours every 8x2 pixel block across the whole screen), for instance.

Quoting WVL

Now ehr.. is it possible to modify this to make UFLI max pictures or would a modified MUFFLON work better?

No, that's a much simpler use case. Since there's no time to change sprite colours when you perform FLI every line, you can just optimise every 48-pixel column for each of the 16 possible underlay colours separately and pick the best outcome.

In contrast, with NUFLIX I need to check all 256 possible sprite colour combinations within each 48x2 pixel region separately. Thankfully these regions don't overlap, so it's very easy to parallelise the algorithm and run it on the GPU.

Quoting WVL

And, where did cobbpg come from?

My old login name in some closed systems was cobb, which was obviously not widely available on just about any service on the open internet. :P I simply appended my initials to create a more unique identifier.

2024-11-14 22:30

Digger

Registered: Mar 2005
Posts: 426

Yeah, I was going to suggest NUFLIx before I read Sebaloz's comment.
Also like SNUFLI – Speedcode Flexible Line Interpretation.

Or NUFLIXBUS ;-) b/c you're unrollingly bussing the registers.

But jokes aside, this is some serious breakthrough. I can imagine such editor not only for NUFLI but for any other gfx mode. Writing optimisers/converters as shaders is super rad. And GX (Graphician's eXperience) is deluxe! With processor budget and choosing prios by error map.

Amazing work man, I look forward to testing this!

PS I had no idea about VICE's binary monitor API, something's worth exploring!

2024-11-16 01:33

Copyfault

Registered: Dec 2001
Posts: 472

Quoting Oswald

no, the difference is not only in data prep, it updates more color registers than NUFLI.

Ooooops, good you point me to that fact! Ok, the displayer is capable of throwing in more sprite col register updates, and does this with a certain "bucket logic"... when I read that the sprite layout is still the same as it is with standard NUFLI, I thought this'd also comprise the register updates, but you (and also Raistlin and I guess all others besides silly me :( ) are totally correct. So, new mode, new fun :)

Quoting cobbpg

Quoting Copyfault
Not meant too serious, but you should maybe keep this for the next Performers-Demo and name the mode 'NextFli' ;)

To be fair, the visual improvement over NUFLI is not that obvious, at least in the current incarnation that keeps the same sprite arrangement. I think the real contribution here is (hopefully) to make it much more fun and less frustrating to create such pictures in the first place, and it might encourage more artists to give it a go.

And here we go: sorry for my misinterpretation, and again KUDOS for your efforts rising the no. of col changes per double-line. The response time I already mentioned in my 1st post is for sure the strongest and most shining feature when watching the linked videos, but there's more potential in it!

Quoting cobbpg

Making the sprite setup customisable would also subsume QCH (i.e. 320x200 hires bitmap with 2 colours every 8x2 pixel block across the whole screen), for instance.

Sure, this'd be totally possible! To be honest, I have such least-error-convert function in my Kickass code for QCH, was helpful during the creation so I could check out the gfx outcome... but it was/is definately not fast, takes about a minute depending on the src pic. When the gfxer knows the restrcitions and sticks to them, it's ok and only a matter of seconds again.

But just like also e.g. Digger pointed out, your approach adds more to it: with all 8 sprites active, you can easily create something like "QCH+"... but I dare say that it will turn the resulting restrictions into something complicated again.

Next step must be to allow more(=all?) vic registers for the buckets and to calc through all the permutations of reg changes that will be possible then... No idea if this'd be too complex also when applying this shader logics stuff, but I have a hunch it can be done.

2024-11-16 23:15

cobbpg

Registered: Jan 2022
Posts: 15

Quoting Copyfault

Next step must be to allow more(=all?) vic registers for the buckets and to calc through all the permutations of reg changes that will be possible then... No idea if this'd be too complex also when applying this shader logics stuff, but I have a hunch it can be done.

To be honest, I don't think there's a lot of potential there. Badlines are the most efficient way of getting many colours on the screen, since you can change 80 of them for the price of 40 clock cycles. However, when you have many badlines, you have little time for anything else. NUFLI seems to be in a sweet spot, allowing both the bitmap and the underlay layer to be quite colourful. I don't see what else you could be doing there that would be useful in the general case.

As soon as you allow a completely dynamic structure, the search space turns heterogeneous and you cannot parallelise its traversal as efficiently any more. You can certainly kiss goodbye to algorithms that can run on GPUs. This is why it makes sense to me to have the artist specify the sprite configuration, or even multiple regions with different configurations. If the configuration is fixed over a region, we can easily implement an efficient search. Thereby we can retain a very important property of the system: rapid feedback. It's also easier to understand what's going on.

So yes, while we can theoretically make an even more expressive system with a fully dynamic approach, I don't think we can expect much in the way of artistic benefits from it, and we are likely to trade away other useful properties that matter more in practice. Of course, it is a very fun engineering exercise, and there are some very specific pieces of art that might require such an approach, so I'm not one to discourage anyone from trying. ;) Still, it's good to have realistic expectations for the outcome of such an experiment.

Status update: I'm pretty much done with all the coding for the first release, and I also wrote the (quick and dirty) manual. The next step is the technical deep-dive about how the system works, which I can hopefully finish over the coming week. Then it's all ready for prime time!

2024-11-17 13:45

encore

Registered: Aug 2010
Posts: 67

Exciting progress. :) Would it be possible in the future to generate NUVIEX (NUFLIX movies in REU-format) as well (see NUVIEmaker V0.1e ) using the same new 'mode'? And just to dream even further: Have a REU-based video format that support streaming audio (f.ex. a sample update every other scanline) in exchange of a few cycles less spent on video update. I know it's far from what you're trying to do right now. Just thoughts that comes to my mind when seeing this progress. :)

2024-11-17 20:39

cobbpg

Registered: Jan 2022
Posts: 15

Quoting encore

Exciting progress. :) Would it be possible in the future to generate NUVIEX (NUFLIX movies in REU-format) as well (see NUVIEmaker V0.1e ) using the same new 'mode'? And just to dream even further: Have a REU-based video format that support streaming audio (f.ex. a sample update every other scanline) in exchange of a few cycles less spent on video update. I know it's far from what you're trying to do right now. Just thoughts that comes to my mind when seeing this progress. :)

I don't think the visual improvements would be noticeable in movies, so I'd rather keep the NUFLI format, which uses only 600 bytes per frame for register updates, while NUFLIX reserves 4K (in practice it's usually around 3.5K). However, we could certainly leverage the new implementation to generate the REU images much-much faster. Future work! :)

2024-11-18 20:50

Jetboy

Registered: Jul 2006
Posts: 288

Funny how i refresh this thread every couple of minutes to check if it's released yet :)

2024-11-18 22:03

cobbpg

Registered: Jan 2022
Posts: 15

The best case scenario is that I can get it out this weekend, so you can go easy on the refresh key at least until then. But remember that my self-imposed deadline was the end of the month. ;)

Previous - 1 | 2 | 3 | 4 - Next

Refresh

Subscribe to this thread: