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

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

2024-12-01 20:08

cobbpg

Registered: Jan 2022
Posts: 36

Quoting Jetboy

sprite multiplexing pains

The current solution was never meant to be final. I definitely want to make the code generator work without failure states like this. I mostly tested with screenshots from various 16-bit games and demos, and there were few enough cases of triggering this behaviour that I thought we can live with it for now. The reason I left it like this for the initial release was that solving it requires two new mechanisms:

1. Deferred updates that are actually mandatory to include within a certain deadline.

2. Dealing with cases where an underlay column cannot be updated at all in a section. The current algorithm works such that all 6 columns will have at least one colour change left. This is already shaky when there are border colour updates.

My current thinking is that whenever we detect that sprite moves couldn't all make it, we'd backtrack and modify the updates such that the sprite moves would have stricter deadlines for inclusion. We have about 20 snippets to distribute them in, so it could be something like emitting at least two Y updates every 5 snippets.

And at the same time we'd probably need the ability to push some underlay updates to the next section like we do with the FLI bug updates.

If you have some test cases you could share, please do! It would help me fix the problem faster.

Quoting Jetboy

Maybe a way to freeze parts of the image be solution to avoid "surprises"?

That would be nice, but I don't think it's really practical. You'd have to ensure that the preceding part leaves all registers in the correct state, and that sounds quite tricky to implement.

Quoting Jetboy

It would help to have guides on the right side and bottom, except top and left one. When editing bottom and right parts of image top and left guides are too far away to be useful.

Good idea, finally something easy to implement! ;)

Quoting Jetboy

You should make propper CSDb entry i guess. "Other Platform c64 tool"

I'm conflicted about this, because each build is much bigger than the typical CSDb entry (the two Windows builds are 175M together), so if we follow the spirit of this site being "a detailed database of scene history", we just end up with useless artifacts nobody wants hogging up space. Maybe when it reaches the first stable point it could make sense to add an entry for that version.

Quoting Jetboy

Instant VICE preview is super awesome! I will steal this feature :)

If the only thing this project achieves is teaching others about the binary monitor, it's already a success. ;)

Quoting Jetboy

I miss, and i miss a lot: Using RMB as secondary color, Ctrl+LMB = pick color, Ctrl+RMB = pick secondary color.

For the free pixelling mode those sound reasonable, yes.

Quoting Jetboy

Mappin color 0 to 1, color 1 to 2 etc. Makes me want to scream :)

That's literally how the C64 does it! Ctrl+1 is black etc. I chose this mostly because not all keyboards have the 0 to the left of 1.

Quoting Jetboy

It might be other c64 tools have the same mapping, if it is so, please make the key mapping reasignable. Unity has component that makes it easy AFAIK.

There are no useful components for UI Toolkit, but it doesn't matter, I can trivially implement a system based on an easy to edit config file. The fixed system is rather annoying with QWERTZ and AZERTY layouts anyway.

Quoting Jetboy

It would be nice to add some example images.

I agree! But they should really be the kinds of images that cannot be done in plain NUFLI. The difference is really not that big when you dither some photo and convert it. I'd love to see some hand-crafted pixel art that wouldn't have been possible to do otherwise.

2024-12-02 18:11

Dane

Registered: May 2002
Posts: 423

Congratulations on taking this further. It's almost nostalgic to see the technique again of changing spritecolours/positions of underlay sprites (combined with FLI) since I did that like 20 years ago. But that involved a lot of manual headscratching...nice to see it implemented in a smart editor!

2024-12-02 22:02

WVL

Registered: Mar 2002
Posts: 903

What a great writeup! Have you thought about using spritecrunching to expand the sprites so there's less need for multiplexing? You can cover 166 lines without multiplexing in the Fli area, like in Halloweed 3.

Also, if you're doing code generation, you might have a look at using the SAX opcode to prevent the need to load a register. SAX is just the best illegal opcode ever.

2024-12-02 23:07

cobbpg

Registered: Jan 2022
Posts: 36

Quoting WVL

What a great writeup! Have you thought about using spritecrunching to expand the sprites so there's less need for multiplexing? You can cover 166 lines without multiplexing in the Fli area, like in Halloweed 3.

But I am! :) I just took what NUFLI was already doing, i.e. covering the first 165 lines, then multiplexing once. It has to start one line earlier so all of them have a unique combination with only every other line being FLI.

Quoting WVL

Also, if you're doing code generation, you might have a look at using the SAX opcode to prevent the need to load a register. SAX is just the best illegal opcode ever.

Yes, I also considered that, since it could probably be used to squeeze in one or two extra updates in some special situations. I figured that I had to keep things simple for now, otherwise I'd never get to a release. :P It's something for the future.

2024-12-05 16:15

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.

2024-12-05 17:37

Jetboy

Registered: Jul 2006
Posts: 338

How do we figure out which updates have been skipped?

2024-12-05 18:47

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.

2024-12-05 19:40

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.

2024-12-05 20:13

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.

2024-12-05 21:02

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.

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

Refresh

Subscribe to this thread:

You need to be logged in to post in the forum.

Search the forum:
Search for in
All times are CET.

Search CSDb

Advanced

Users Online

Devia/Ancients
j0x
CA$H/TRiAD
psych
syntaxerror
iAN CooG/HVSC
map/Plush
Guests online: 139

Top Demos

1 Next Level  (9.7)
2 13:37  (9.7)
3 Coma Light 13  (9.6)
4 Edge of Disgrace  (9.6)
5 Mojo  (9.6)
6 Uncensored  (9.6)
7 The Demo Coder  (9.6)
8 Comaland 100%  (9.6)
9 Wonderland XIV  (9.6)
10 What Is The Matrix 2  (9.6)

Top onefile Demos

1 Layers  (9.7)
2 Cubic Dream  (9.6)
3 Party Elk 2  (9.6)
4 Copper Booze  (9.6)
5 Rainbow Connection  (9.5)
6 Morph  (9.5)
7 Dawnfall V1.1  (9.5)
8 Libertongo  (9.5)
9 Katzen-Video.mp4  (9.5)
10 Onscreen 5k  (9.5)

Top Groups

1 Booze Design  (9.3)
2 Oxyron  (9.3)
3 Performers  (9.3)
4 Fairlight  (9.3)
5 Triad  (9.3)

Top Musicians

1 Mutetus  (9.7)
2 Jeroen Tel  (9.6)
3 Rob Hubbard  (9.6)
4 Linus  (9.6)
5 Jammer  (9.6)

Page generated in: 0.092 sec.