| |
cobbpg
Registered: Jan 2022
Posts: 52 |
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! |
|
... 96 posts hidden. Click here to view all posts....
|
| |
cobbpg
Registered: Jan 2022
Posts: 52 |
By the way, I also made an experimental Linux build of v1.2, if somebody wants to test it. No idea if it works, since I'm on Windows at the moment. |
| |
zzarko
Registered: Feb 2003
Posts: 82 |
@cobbpg: I just tried a quick convert on Ubuntu 24.04, also plotted a few pixels here and there in Editor mode, and that's it, but I can say that it works! Thanks for Linux support! |
| |
cobbpg
Registered: Jan 2022
Posts: 52 |
Good to hear! In this case I can add the build to the release page later this week when I’m back at my computer. |
| |
Guinea_pig
Registered: Feb 2024
Posts: 5 |
Quote: This mode is not very game friendly. It uses a lot of memory and rastertime, plus screen organisation is extremely inconvenient. Making a game using it for gameplay would be something that even top coders would struggle with, but i’m willing to hold your beer ;)
Yeah, I can see that. I just thought the last ninja examples indicated someone was using it in bitmap mode. |
| |
cobbpg
Registered: Jan 2022
Posts: 52 |
The only practical in-game use I can think of would be to make fancy illustrations for text adventures with this approach. E.g. you could fill the top 15 char rows with a NUFLIX picture, which would leave enough processing time to run the parser. Similarly, you could also put a nice logo above your main menu as long as you don’t want to animate it.
If enough people expressed demand for such uses, I could offer the option to make less tall images that hand the CPU back to you earlier. |
| |
TSM
Registered: Jan 2007
Posts: 45 |
Quote: The only practical in-game use I can think of would be to make fancy illustrations for text adventures with this approach. E.g. you could fill the top 15 char rows with a NUFLIX picture, which would leave enough processing time to run the parser. Similarly, you could also put a nice logo above your main menu as long as you don’t want to animate it.
If enough people expressed demand for such uses, I could offer the option to make less tall images that hand the CPU back to you earlier.
That would be cool. And having the option for less wide images as well would be awesome. |
| |
cobbpg
Registered: Jan 2022
Posts: 52 |
What exactly would you want to gain from less wide options? Some possible ideas:
• Freeing up some sprites, e.g. to add a bit of animation
• Being able to use non-X-expanded sprites in the main section
• Adjusting the horizontal position at runtime (at least when showing the image, not necessarily animating)
Do you have specific use cases in mind? |
| |
TSM
Registered: Jan 2007
Posts: 45 |
Just smaller images that take less RAM. Then again, I guess I can just have black rectangles on the sides and crunch the data. |
| |
cobbpg
Registered: Jan 2022
Posts: 52 |
Making them shorter horizontally won't really help with that, because these images have rather nonlinear memory layouts. Crunching is indeed the answer there. For the vertical size options it's possible to make their memory footprint a bit more compact depending on the specifics. For instance, if they are at most 16 character rows tall, then they can fit into a single VIC bank excluding the displayer code, but that can be located anywhere. |
| |
TSM
Registered: Jan 2007
Posts: 45 |
I would definitely use pictures shorter than 16 characters vertically. |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 - Next |
