Log inRegister an accountBrowse CSDbHelp & documentationFacts & StatisticsThe forumsAvailable RSS-feeds on CSDbSupport CSDb Commodore 64 Scene Database
 Welcome to our latest new user Northwind ! (Registered 2024-11-20) 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: 15
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!
2024-11-11 11:15
The Human Code Machine

Registered: Sep 2005
Posts: 112
Looks good! Would be nice to have an option to limit the color updates to less than 10 to make space for border color, background color or sample writes.
2024-11-11 11:40
Oswald

Registered: Apr 2002
Posts: 5086
this is the most impressive gfx editor I have ever seen, the improvement over NUFLI is super cool too. "lookis good" is not doing it justice. :) awesome job man!

NUFLI2 would work for me.

to bring this further how about putting gfx on the sideborder, like albert, but now in hires?
2024-11-11 11:47
Bitbreaker

Registered: Oct 2002
Posts: 504
Cool to see that someone dared to touch that topic after so many years and doing even inmprovements to the format. Having the full aount of writes available at any time simplifies things a lot.
What still remains is the dependencies that AFLI Blcoks drag into the next sprite block and vice versa? As sprite colors are updated in odd and AFLI is updated in even lines, the decisions on colors made for either AFLI or sprite has always an impact on the decisions on the next lines, as one sprite block overlaps 2 AFLI blocks and one AFLI blopck overlaps witrh 2 sprite blocks.
Will there be a linux port? :-)
2024-11-11 11:49
Krill

Registered: Apr 2002
Posts: 2968
Quoting cobbpg
I'm leaning towards "NUFLI2" to make it somewhat search engine friendly, but I'm open to ideas.
I immediately thought "NUFLI+", but no idea how search engine friendly that is. =)
2024-11-11 13:46
Martin Piper

Registered: Nov 2007
Posts: 716
Nunufli
2024-11-11 14:27
cobbpg

Registered: Jan 2022
Posts: 15
Quoting The Human Code Machine
Would be nice to have an option to limit the color updates to less than 10 to make space for border color, background color or sample writes.

This is kind of tricky. The system works by determining all the necessary register writes with timing constraints, then generating code to satisfy all the constraints as efficiently as possible, using all registers. When it runs out of time on a given scanline, it tries to drop as few updates as possible to be able to keep going. We could maybe introduce the notion of high-priority writes (that are never allowed to be dropped) with unknown values that cannot be reused for other registers, that would at least make this possible.

Quoting Oswald
to bring this further how about putting gfx on the sideborder, like albert, but now in hires?

Very cool idea, but also very much out of scope for the first release. That said, this will be all open source and I'm more than happy to accept PRs. ;) One future extension that would make sense to me would be to allow customising the sprite setup, e.g. have just one sprite over the FLI bug, and 7 unexpanded ones over the main area with custom X positions. Or even fewer sprites to free up time for other tricks. But this would mean implementing a proper model for VIC timings and making the colour search step more flexible; the current implementation is very much hardcoded for the usual NUFLI arrangement.

Quoting Bitbreaker
What still remains is the dependencies that AFLI Blcoks drag into the next sprite block and vice versa? As sprite colors are updated in odd and AFLI is updated in even lines, the decisions on colors made for either AFLI or sprite has always an impact on the decisions on the next lines, as one sprite block overlaps 2 AFLI blocks and one AFLI blopck overlaps witrh 2 sprite blocks.

No, this is solved, as this tool allows you to change underlay colours (outside the FLI bug) on every one of the 200 scanlines. There's one caveat: the rightmost 8 pixels of the rightmost column (i.e. between pixels 304 and 311 in each row) can only change on odd lines due to VIC timing limitations. They could be changed fully on NTSC, but not on PAL, sadly.

Quoting Bitbreaker
Will there be a linux port? :-)

This is written in Unity (I know, shame on me!), so it should be trivial to make builds for both Mac and Linux.

Quoting Krill
I immediately thought "NUFLI+", but no idea how search engine friendly that is. =)

Yeah, this would have been my preferred choice too otherwise.

Quoting Martin Piper
Nunufli

I see absolutely no scaling issues with this convention!

For a hot moment I also considered GNUFLI for "Generalised NUFLI". :P It would even be pronounced exactly like NUFLI as an added bonus. But honestly, this is such a small change technically speaking, that it doesn't feel like deserving a name of its own.
2024-11-11 21:14
Jetboy

Registered: Jul 2006
Posts: 288
WOW! That is AMAZING!
Will need to take a closer look when you make it available.

Unity seems like a little bit overkill for converter, but i understand it provides a lot of foundations and lets you concentrate on the process of conversion more than when you would need to write all from scratch.

Then if i think about it, i'm using some tools that are written in Unity on a daily basis, ie. Stud.io - software to build Lego digitally.

I was thinking in about moving my converter to the shaders too, but i would have to skip error diffusion as simple implementation requires for the image to be processed sequentially. (there is some hope, as there are possible solutions i'm investigating right now, but there are too many distractions so i have no ETA).

Then maybe i should follow that mantra i learned from a friend -"better done than perfect". But i digress.

If you need beta testers, i'm up for it. Can also help with beta testing manual.
2024-11-11 22:00
cobbpg

Registered: Jan 2022
Posts: 15
Unity is absolutely overkill for this purpose, and ideally I'd rewrite this in C++ with some IMGUI solution if I had more time. But there's a bunch of advantages to using Unity even for a tool like this:

• can build for all major platforms with minimal effort, without having to deal with build systems directly
• can use a single shader language for all builds
• can use C# both for the UI and parts of the algorithm that aren't worth pushing through the GPU
• the latter bits can be compiled to native code and potentially vectorised thanks to the Burst compiler, again with very little additional effort
• decent profiling tools available out of the box
• hot reload system so application state can be retained through recompiles during development (although this has been getting too slow lately)

The downside is that the builds are unnecessarily huge, and due to the startup time overhead they are also less useful as command line tools, even if they can be run in headless mode.
2024-11-12 08:31
enthusi

Registered: May 2004
Posts: 677
add 'F' for 'flexible'?
FNUFLI or NUFLIF?
2024-11-12 10:08
Bitbreaker

Registered: Oct 2002
Posts: 504
Quoting cobbpg

Quoting Bitbreaker
What still remains is the dependencies that AFLI Blcoks drag into the next sprite block and vice versa? As sprite colors are updated in odd and AFLI is updated in even lines, the decisions on colors made for either AFLI or sprite has always an impact on the decisions on the next lines, as one sprite block overlaps 2 AFLI blocks and one AFLI blopck overlaps witrh 2 sprite blocks.

No, this is solved, as this tool allows you to change underlay colours (outside the FLI bug) on every one of the 200 scanlines. There's one caveat: the rightmost 8 pixels of the rightmost column (i.e. between pixels 304 and 311 in each row) can only change on odd lines due to VIC timing limitations. They could be changed fully on NTSC, but not on PAL, sadly.


afaik the last column (39) was plain second line AFLI anyway in NUFLI, as there's no underlay. I wonder how you manage to squeeze in 7 color updates per line, as the AFLI line consumes 40 DMA cycles, also the sprites consume pretty much DMA cycles. If you need to cut down on color update writes in one line for the sake of saving, this restrictions nevertheless carries on onto the upcoming lines and thus again building dependencies outside the current AFLI block and sprite block boundaries? Decisions made in a prior line inflict the amount of colour choice on the current line and so on.
Curious on the outcome and a first release to play around. If the sprite/afli-block overlap stuff drops, the format is also way better to draw by hand, still painful with different pixel sizes regarding underlay and hires.
 
... 26 posts hidden. Click here to view all posts....
 
Previous - 1 | 2 | 3 | 4 - Next
RefreshSubscribe 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
MWR/Visdom
Moderators/CSDb Staff
Zephyr/Elysium
Brittle/Dentifrice^(?)
JosSs
Low Spirit
Case/Padua
Guests online: 97
Top Demos
1 Next Level  (9.7)
2 13:37  (9.7)
3 Coma Light 13  (9.7)
4 Edge of Disgrace  (9.6)
5 Mojo  (9.6)
6 Uncensored  (9.6)
7 Wonderland XIV  (9.6)
8 Comaland 100%  (9.6)
9 No Bounds  (9.6)
10 Christmas Megademo  (9.5)
Top onefile Demos
1 Layers  (9.6)
2 Party Elk 2  (9.6)
3 Cubic Dream  (9.6)
4 Copper Booze  (9.6)
5 Libertongo  (9.5)
6 Rainbow Connection  (9.5)
7 Onscreen 5k  (9.5)
8 Morph  (9.5)
9 Dawnfall V1.1  (9.5)
10 It's More Fun to Com..  (9.5)
Top Groups
1 Performers  (9.3)
2 Booze Design  (9.3)
3 Oxyron  (9.3)
4 Nostalgia  (9.3)
5 Censor Design  (9.3)
Top Original Suppliers
1 Derbyshire Ram  (9.7)
2 Fungus  (9.3)
3 Black Beard  (9.2)
4 Baracuda  (9.2)
5 hedning  (9.1)

Home - Disclaimer
Copyright © No Name 2001-2024
Page generated in: 0.047 sec.