| |
cobbpg
Registered: Jan 2022
Posts: 36 |
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! |
|
... 76 posts hidden. Click here to view all posts....
|
| |
cobbpg
Registered: Jan 2022
Posts: 36 |
Yesterday I came across this picture from Mysdata 2024, which happens to use the C64 palette. Here's what it looks like after cropping to 320x200 and converting to the default palette of NUFLIX Studio:
I figured this would be an interesting test case to compare NUFLI and NUFLIX. I fed it to Mufflon, then loaded the resulting .nuf file into the NUFLIX editor to see how much CPU time it actually needs:
Afterwards, I converted it to NUFLIX:
I didn't like some of the artifacts, so I figured I could use the same weighted RGB distance metric that Mufflon does instead of Oklab:
It's interesting to see the differences! NUFLI does a pretty good job already, but NUFLIX can clearly enable more detail. NUFLIX, at least using the Oklab distance metric, actually misses a lot of detail above the whiskers in the bug area, since it is busy updating colours in the main section. It does better with the weighted RGB distance metrics, but that's probably just a random outcome.
Based on this, it might be worth adding an option to switch between various distance metrics on the fly. Also, it's probably too simplistic to just blindly prefer updates in the main section to FLI bug updates, since the latter can affect big areas on the left side by just dropping one or two of them. |
| |
Jetboy
Registered: Jul 2006
Posts: 338 |
How do we figure out which updates have been skipped? |
| |
cobbpg
Registered: Jan 2022
Posts: 36 |
At the moment there are two features to help with that. In the editor you can turn on the error comparison overlay, which shows on the Layers and Result views, and highlights the pixels that differ between the two. Also, when you export the image, one of the artifacts generated is a text file called <image-name>-speedcode.txt, which contains the generated code with some context using a shorthand notation, plus all the necessary changes to the updates at the end. To make sense of the latter, you probably need to read the code that generates it (follow the variable I highlighted).
I've actually been thinking about visualising the changes to the register updates between the authoring side and the final result, but it's tricky. When you're editing, every update can occur over an interval, and many of these intervals overlap. When the final code is generated, that's when the timings get concretised. I have some ideas about this, but the devil is always in the details. |
| |
Burglar
Registered: Dec 2004
Posts: 1105 |
awesome thread this, and thanks for open sourcing! \o/
Tiger could be a nice testcase too, since the original gif is included.
 |
| |
cobbpg
Registered: Jan 2022
Posts: 36 |
This is a fairly easy case. There are so few updates needed that only one of them needs to be dropped, resulting in the change of a single pixel. :P This was done using the weighted RGB distance metric.
This might be just the kind of image that would benefit from a more customised sprite configuration. |
| |
Burglar
Registered: Dec 2004
Posts: 1105 |
hmm, I see a lot more pixels dropped though, check the right side of the image, around the dark-grey whisker. |
| |
cobbpg
Registered: Jan 2022
Posts: 36 |
Just to be clear, what I'm talking about is the difference between the best-case representation you get from the brute-force search and the result of the code generation process where we try to schedule as many register updates as possible to reproduce the best-case image.
Naturally, even the best case is limited, since it defines the boundaries of what's possible (at least with the given sprite configuration). Most of the artifacts come from the reality of reducing a free-form image into sprite and bitmap layers. In the end, the artist has to work within the limitations of the format, and what I'm trying to achieve with NUFLIX is to make that process as convenient and painless as possible. At least when you have a very responsive system, you can start correcting the artifacts manually by incrementally altering the source image, and you'll see immediately how it comes out the other end. |
| |
Digger
Registered: Mar 2005
Posts: 438 |
The cat is probably wired from one of these https://www.freepik.com/premium-ai-image/pop-art-colourful-beau..
But a very good test case, I agree! |
| |
cobbpg
Registered: Jan 2022
Posts: 36 |
It's pretty clear that excessive checkerboard dithering doesn't work well, since it already hogs up the ink layer, and there's no easy way to preserve other edges at the same time. One style I found works pretty well is the cutscenes from the Amiga version of Stunt Car Racer. Here's one of them converted to NUFLIX:
It's a clear style that doesn't use a lot of colours in clusters, so even if it wasn't drawn with attribute block limitations in mind, it translates fairly well even with zero adjustments. The trophy is the most obvious element in need of some tweaking. |
| |
Jetboy
Registered: Jul 2006
Posts: 338 |
When we are in Layer Edit Mode when mouse hovering the image we can see what colors are active in this block. Could we please have color of source pixel also displayed?
Then, could we have that displayed at all time in every mode?
That would make using educated decision what colors can be used easier.
Also when in split screen mode, please highlight pixel in the other window corresponding to the pixel we are at with mouse. |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 - Next |
