[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!

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

2024-12-01 17:24

Jetboy

Registered: Jul 2006
Posts: 329

I'm not sure about my workflow, but let me explain:

I loaded an image and it is showing all lines in red, plus "Not enough time to multiplex sprites".

*By talking line is green or red i mean the indicator of free cycles.

Ok. I get it. There is so many color changes needed that there is no time to multiplex sprites. So i started painting every second line black. Doing so at some point - that, and previous line got green, but when i continued painting it got red again. Then i noticed that on the result image, those lines are not fully black. Apparently backgrounds and ink were not black, and the sprites also not black. It is a little bit complicated , but i think it should be possible to make the result work with the source colors being set up as they were. I might be mistaken though. So i fixed it adding black in the sibling line, so it could be chosen as sprite colors. I managed to fix a couple lines like that, so they were green, and even had some free time. Destroying every second line by painting it black, on the way. Not the solution i would agree to, but i'm learning now.

I have questions, that should rather be discussed than put as issues on github.

1. How would be best workflow in such cases? If there were just few lines red, it would be fairly straightforward to identify culprits and make the image displayable, but when it is all red it is hard to guess where to start. ANd it would be nice to do it in less destructive way.

2. Are you sure current algorithm is working properly? It might be, and i'm mistaken. But i think that it would be much easier for artists if sprite multiplexing got higher priorities than color changes and converter always generates displayable image. It is much easier to notice where sacrifices in colors had to be made and fix them manually, than have image that look semi decent, but not displayable, and identify (no idea how) where we need to make changes so there will be enough time to multiplex sprites. Maybe some additional markers are needed? When we get "Not enough time to multiplex sprites" error it is too vague. I have no idea how many sprites fail to be multiplexed and in which spots, so it is hard to fix it.

3. Don't get me wrong it is still much more convenient than working with Mufflon, but fixing image seems like a never ending whack a mole. It happens sometime that changing something in one place changes pixels in an area many columns earlier. I guess that's because of reorganizing write order? Or rather changing of sacrifice priority? Maybe a way to freeze parts of the image be solution to avoid "surprises"?

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

2024-12-01 18:30

Copyfault

Registered: Dec 2001
Posts: 476

Quoting cobbpg

It's out now, grab it while it's hot!

Source and release: https://github.com/cobbpg/nuflix-studio
Write-up: https://cobbpg.github.io/articles/nuflix.html

WHAT A F***ING GREAT WRITE-UP!!!!

Thank you. And the idea to "abstractify" the colour-change structure and just assume sprite cols can be changed line-wise is a major key to your "bucket-approach".

Let's see where this leads us to. But improvements are already made, that's for sure :)

CF

2024-12-01 19:16

Jetboy

Registered: Jul 2006
Posts: 329

Some extra thoughts:

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

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

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

4. Mappin color 0 to 1, color 1 to 2 etc. Makes me want to scream :) 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.

5. It would be nice to add some example images.

2024-12-01 20:08

cobbpg

Registered: Jan 2022
Posts: 24

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

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

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.

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

Refresh

Subscribe to this thread: