| |
cobbpg
Registered: Jan 2022
Posts: 31 |
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! |
|
... 63 posts hidden. Click here to view all posts....
|
| |
Burglar
Registered: Dec 2004
Posts: 1093 |
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: 31 |
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: 1093 |
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: 31 |
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: 435 |
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: 31 |
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: 333 |
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. |
| |
cobbpg
Registered: Jan 2022
Posts: 31 |
Yeah, those sound reasonable and easy to implement. Added them to my todo list. |
| |
Oswald
Registered: Apr 2002
Posts: 5087 |
wow this last example pic is shockingly good, just drop the clouds near the cup, and it will be ok :) |
| |
cobbpg
Registered: Jan 2022
Posts: 31 |
One idea I'd like to try is to be able to draw an importance mask in the editor, where you could mark certain pixels such that they would be less likely to change during conversion to layers, for instance by multiplying their error metric with a constant. |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 - Next |
