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

Welcome to our latest new user IcePic ! (Registered 2024-12-03)

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

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!

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

2024-11-17 20:39

cobbpg

Registered: Jan 2022
Posts: 24

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

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

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. ;)

2024-11-25 11:47

Jetboy

Registered: Jul 2006
Posts: 329

I guess, i can stop refreshing till next weekend again :)

2024-11-25 15:38

cobbpg

Registered: Jan 2022
Posts: 24

Yeah, no hurry! ;) I'm the kind of idiot that always feels the burning need to do a proper write-up for a general technical audience whenever I release something, and that means I kind of have to explain how NUFLI works before I can get to my contributions.

Anyway, I'm over 5000 words in, and also implemented direct NUFLI import in the tool as a side-effect. Getting there!

2024-11-25 18:27

DeeKay

Registered: Nov 2002
Posts: 363

Oh wow, that's some awesome feat, I'm loving the editor already, in spite of being one of maybe 20 people that ever used our c64 based ones! ;-D
When we made NUFLI I asked Crossbow if it were possible to have the sprite color change at the same height as the bitmap, and he did make a version of the displayer and Bitbreaker changed Mufflon to try out and compare, but the Error difference was insignificant, so we stuck with the even/odd layout..
What I would suggest exploring to make this a true new mode is to bring back the Multicolor option that we took out coming from MU(I)FLI and that Mufflon never suported (even whennused for MUIFLI!). Since you have sprite register writes galore, you could use one of them (preferrably the first in each line) to switch any of the six sprites between Mcol and hires in that line. Plus you could also change sprite multicolors! Having the option of four colors in a char instead of two, even when they are 4px wide, can help a lot in areas with much detail, as can be seen when you put unrestricted hires images through Algo's MUCSU converter, which uses Mcol expanded sprites exclusively (but no FLI!)..

2024-11-25 20:40

cobbpg

Registered: Jan 2022
Posts: 24

Quoting DeeKay

Oh wow, that's some awesome feat, I'm loving the editor already, in spite of being one of maybe 20 people that ever used our c64 based ones! ;-D

I'm also one of the few! ;) It's truly an amazing tool given all the limitations it needs to go up against.

Quoting DeeKay

When we made NUFLI I asked Crossbow if it were possible to have the sprite color change at the same height as the bitmap, and he did make a version of the displayer and Bitbreaker changed Mufflon to try out and compare, but the Error difference was insignificant, so we stuck with the even/odd layout..

The irony is that the displayer code does support doing colour changes on even lines as is (except for the last two columns), so technically it would be possible to make a converter that emits the same exact same format but relaxes some of the constraints. My converter could be modified to do it with fairly little work while still keeping the quick response time. That might still be useful for making NUVIEs, for instance.

Quoting DeeKay

What I would suggest exploring to make this a true new mode is to bring back the Multicolor option that we took out coming from MU(I)FLI and that Mufflon never suported (even whennused for MUIFLI!). Since you have sprite register writes galore, you could use one of them (preferrably the first in each line) to switch any of the six sprites between Mcol and hires in that line. Plus you could also change sprite multicolors! Having the option of four colors in a char instead of two, even when they are 4px wide, can help a lot in areas with much detail, as can be seen when you put unrestricted hires images through Algo's MUCSU converter, which uses Mcol expanded sprites exclusively (but no FLI!)..

Yeah, that would be an interesting avenue to look into in the future. It would be nice to be able to come up with even more ways to improve the expressiveness of the system without breaking locality completely, so the search process could remain fast. Exploiting multicolour definitely feels within reach.

The idea does go a bit against the spirit of my project in a sense that my primary goal was to give pixel artists as much freedom and control at the same time as possible. You could say that the final result doesn't need to be editable when the converter is smart enough, so it's always a trade-off. The current design is in a pretty sweet spot with regards to this goal.

2024-11-25 21:50

Copyfault

Registered: Dec 2001
Posts: 476

Quote: Oh wow, that's some awesome feat, I'm loving the editor already, in spite of being one of maybe 20 people that ever used our c64 based ones! ;-D
When we made NUFLI I asked Crossbow if it were possible to have the sprite color change at the same height as the bitmap, and he did make a version of the displayer and Bitbreaker changed Mufflon to try out and compare, but the Error difference was insignificant, so we stuck with the even/odd layout..
What I would suggest exploring to make this a true new mode is to bring back the Multicolor option that we took out coming from MU(I)FLI and that Mufflon never suported (even whennused for MUIFLI!). Since you have sprite register writes galore, you could use one of them (preferrably the first in each line) to switch any of the six sprites between Mcol and hires in that line. Plus you could also change sprite multicolors! Having the option of four colors in a char instead of two, even when they are 4px wide, can help a lot in areas with much detail, as can be seen when you put unrestricted hires images through Algo's MUCSU converter, which uses Mcol expanded sprites exclusively (but no FLI!)..

Why not also make the bitmap mode switchable MC + Hires? And suddenly, you're pretty close... no, you end up with arbitrary VIC-reg changes to be permitted for a change.

But I think I got the contra-argument from you, cobbpg. We'd loose the option to parallelize the calculation by means of shader logics. Having never worked with such things, isn't it possible to parallelize it nontheless, and have i.e. several conversion runs with different reg categories each?

Depending on the gfx, it might not even be the best option to have FLI every 2nd line, but to have more lines free for vic-reg changes. It quickly becomes highly arbitrary...
...so, I better shut up and wait for the convertor that already *is* in the pipeline ;)

2024-11-25 22:16

cobbpg

Registered: Jan 2022
Posts: 24

Yeah, I want to make it clear that I'm not against those ideas at all, they are definitely worth exploring. To me it's especially interesting to think about how far we can push the NUFLIX approach while keeping the desirable properties like rapid feedback to the artist. But in my view it's equally valid to pursue a completely different goal, like allowing the converter to crunch away for hours in search of the best possible representation of an arbitrary input image.

Quoting Copyfault

Having never worked with such things, isn't it possible to parallelize it nontheless, and have i.e. several conversion runs with different reg categories each?

To some extent yes, you just have to keep in mind that if you are to run a massively parallel computation, then the different branches need to have very similar (if not identical) flows of control. Also, your search space can easily balloon out of control by adding more dimensions to it.

For instance, if we enable multicolor for several sprites, then we introduce a dependency between previously unconnected areas on the picture, since a single register update can affect all of them. At some point you have to give up on using brute force and turn towards more advanced methods to prune the search space. Which is a very exciting technical challenge, I cannot deny. ;)

2024-11-26 12:48

Jetboy

Registered: Jul 2006
Posts: 329

Once you release we can pararellize development, taking the project into many different directions.

Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 - Next

Refresh

Subscribe to this thread: