Log inRegister an accountBrowse CSDbHelp & documentationFacts & StatisticsThe forumsAvailable RSS-feeds on CSDbSupport CSDb Commodore 64 Scene Database
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-11-16 01:33
Copyfault

Registered: Dec 2001
Posts: 478
Quoting Oswald
no, the difference is not only in data prep, it updates more color registers than NUFLI.
Ooooops, good you point me to that fact! Ok, the displayer is capable of throwing in more sprite col register updates, and does this with a certain "bucket logic"... when I read that the sprite layout is still the same as it is with standard NUFLI, I thought this'd also comprise the register updates, but you (and also Raistlin and I guess all others besides silly me :( ) are totally correct. So, new mode, new fun :)

Quoting cobbpg
Quoting Copyfault
Not meant too serious, but you should maybe keep this for the next Performers-Demo and name the mode 'NextFli' ;)

To be fair, the visual improvement over NUFLI is not that obvious, at least in the current incarnation that keeps the same sprite arrangement. I think the real contribution here is (hopefully) to make it much more fun and less frustrating to create such pictures in the first place, and it might encourage more artists to give it a go.
And here we go: sorry for my misinterpretation, and again KUDOS for your efforts rising the no. of col changes per double-line. The response time I already mentioned in my 1st post is for sure the strongest and most shining feature when watching the linked videos, but there's more potential in it!

Quoting cobbpg
Making the sprite setup customisable would also subsume QCH (i.e. 320x200 hires bitmap with 2 colours every 8x2 pixel block across the whole screen), for instance.
Sure, this'd be totally possible! To be honest, I have such least-error-convert function in my Kickass code for QCH, was helpful during the creation so I could check out the gfx outcome... but it was/is definately not fast, takes about a minute depending on the src pic. When the gfxer knows the restrcitions and sticks to them, it's ok and only a matter of seconds again.

But just like also e.g. Digger pointed out, your approach adds more to it: with all 8 sprites active, you can easily create something like "QCH+"... but I dare say that it will turn the resulting restrictions into something complicated again.

Next step must be to allow more(=all?) vic registers for the buckets and to calc through all the permutations of reg changes that will be possible then... No idea if this'd be too complex also when applying this shader logics stuff, but I have a hunch it can be done.
2024-11-16 23:15
cobbpg

Registered: Jan 2022
Posts: 36
Quoting Copyfault
Next step must be to allow more(=all?) vic registers for the buckets and to calc through all the permutations of reg changes that will be possible then... No idea if this'd be too complex also when applying this shader logics stuff, but I have a hunch it can be done.

To be honest, I don't think there's a lot of potential there. Badlines are the most efficient way of getting many colours on the screen, since you can change 80 of them for the price of 40 clock cycles. However, when you have many badlines, you have little time for anything else. NUFLI seems to be in a sweet spot, allowing both the bitmap and the underlay layer to be quite colourful. I don't see what else you could be doing there that would be useful in the general case.

As soon as you allow a completely dynamic structure, the search space turns heterogeneous and you cannot parallelise its traversal as efficiently any more. You can certainly kiss goodbye to algorithms that can run on GPUs. This is why it makes sense to me to have the artist specify the sprite configuration, or even multiple regions with different configurations. If the configuration is fixed over a region, we can easily implement an efficient search. Thereby we can retain a very important property of the system: rapid feedback. It's also easier to understand what's going on.

So yes, while we can theoretically make an even more expressive system with a fully dynamic approach, I don't think we can expect much in the way of artistic benefits from it, and we are likely to trade away other useful properties that matter more in practice. Of course, it is a very fun engineering exercise, and there are some very specific pieces of art that might require such an approach, so I'm not one to discourage anyone from trying. ;) Still, it's good to have realistic expectations for the outcome of such an experiment.

Status update: I'm pretty much done with all the coding for the first release, and I also wrote the (quick and dirty) manual. The next step is the technical deep-dive about how the system works, which I can hopefully finish over the coming week. Then it's all ready for prime time!
2024-11-17 13:45
encore

Registered: Aug 2010
Posts: 67
Exciting progress. :) Would it be possible in the future to generate NUVIEX (NUFLIX movies in REU-format) as well (see NUVIEmaker V0.1e ) using the same new 'mode'? And just to dream even further: Have a REU-based video format that support streaming audio (f.ex. a sample update every other scanline) in exchange of a few cycles less spent on video update. I know it's far from what you're trying to do right now. Just thoughts that comes to my mind when seeing this progress. :)
2024-11-17 20:39
cobbpg

Registered: Jan 2022
Posts: 36
Quoting encore
Exciting progress. :) Would it be possible in the future to generate NUVIEX (NUFLIX movies in REU-format) as well (see NUVIEmaker V0.1e ) using the same new 'mode'? And just to dream even further: Have a REU-based video format that support streaming audio (f.ex. a sample update every other scanline) in exchange of a few cycles less spent on video update. I know it's far from what you're trying to do right now. Just thoughts that comes to my mind when seeing this progress. :)

I don't think the visual improvements would be noticeable in movies, so I'd rather keep the NUFLI format, which uses only 600 bytes per frame for register updates, while NUFLIX reserves 4K (in practice it's usually around 3.5K). However, we could certainly leverage the new implementation to generate the REU images much-much faster. Future work! :)
2024-11-18 20:50
Jetboy

Registered: Jul 2006
Posts: 338
Funny how i refresh this thread every couple of minutes to check if it's released yet :)
2024-11-18 22:03
cobbpg

Registered: Jan 2022
Posts: 36
The best case scenario is that I can get it out this weekend, so you can go easy on the refresh key at least until then. But remember that my self-imposed deadline was the end of the month. ;)
2024-11-25 11:47
Jetboy

Registered: Jul 2006
Posts: 338
I guess, i can stop refreshing till next weekend again :)
2024-11-25 15:38
cobbpg

Registered: Jan 2022
Posts: 36
Yeah, no hurry! ;) I'm the kind of idiot that always feels the burning need to do a proper write-up for a general technical audience whenever I release something, and that means I kind of have to explain how NUFLI works before I can get to my contributions.

Anyway, I'm over 5000 words in, and also implemented direct NUFLI import in the tool as a side-effect. Getting there!
2024-11-25 18:27
DeeKay

Registered: Nov 2002
Posts: 363
Oh wow, that's some awesome feat, I'm loving the editor already, in spite of being one of maybe 20 people that ever used our c64 based ones! ;-D
When we made NUFLI I asked Crossbow if it were possible to have the sprite color change at the same height as the bitmap, and he did make a version of the displayer and Bitbreaker changed Mufflon to try out and compare, but the Error difference was insignificant, so we stuck with the even/odd layout..
What I would suggest exploring to make this a true new mode is to bring back the Multicolor option that we took out coming from MU(I)FLI and that Mufflon never suported (even whennused for MUIFLI!). Since you have sprite register writes galore, you could use one of them (preferrably the first in each line) to switch any of the six sprites between Mcol and hires in that line. Plus you could also change sprite multicolors! Having the option of four colors in a char instead of two, even when they are 4px wide, can help a lot in areas with much detail, as can be seen when you put unrestricted hires images through Algo's MUCSU converter, which uses Mcol expanded sprites exclusively (but no FLI!)..
2024-11-25 20:40
cobbpg

Registered: Jan 2022
Posts: 36
Quoting DeeKay
Oh wow, that's some awesome feat, I'm loving the editor already, in spite of being one of maybe 20 people that ever used our c64 based ones! ;-D

I'm also one of the few! ;) It's truly an amazing tool given all the limitations it needs to go up against.

Quoting DeeKay
When we made NUFLI I asked Crossbow if it were possible to have the sprite color change at the same height as the bitmap, and he did make a version of the displayer and Bitbreaker changed Mufflon to try out and compare, but the Error difference was insignificant, so we stuck with the even/odd layout..

The irony is that the displayer code does support doing colour changes on even lines as is (except for the last two columns), so technically it would be possible to make a converter that emits the same exact same format but relaxes some of the constraints. My converter could be modified to do it with fairly little work while still keeping the quick response time. That might still be useful for making NUVIEs, for instance.

Quoting DeeKay
What I would suggest exploring to make this a true new mode is to bring back the Multicolor option that we took out coming from MU(I)FLI and that Mufflon never suported (even whennused for MUIFLI!). Since you have sprite register writes galore, you could use one of them (preferrably the first in each line) to switch any of the six sprites between Mcol and hires in that line. Plus you could also change sprite multicolors! Having the option of four colors in a char instead of two, even when they are 4px wide, can help a lot in areas with much detail, as can be seen when you put unrestricted hires images through Algo's MUCSU converter, which uses Mcol expanded sprites exclusively (but no FLI!)..

Yeah, that would be an interesting avenue to look into in the future. It would be nice to be able to come up with even more ways to improve the expressiveness of the system without breaking locality completely, so the search process could remain fast. Exploiting multicolour definitely feels within reach.

The idea does go a bit against the spirit of my project in a sense that my primary goal was to give pixel artists as much freedom and control at the same time as possible. You could say that the final result doesn't need to be editable when the converter is smart enough, so it's always a trade-off. The current design is in a pretty sweet spot with regards to this goal.
Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 - 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
Mason/Unicess
REBEL 1/HF
A3/AFL
johny
v3to/OXY^TRSI^PriorArt
Jazzcat/Onslaught
Matt
TheEnemy/TREX🦖/THD
radius75
Fred/Channel 4
BlackJack/Civitas
Guests online: 126
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 What Is The Matrix 2  (9.6)
10 Wonderland XIV  (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 Triad  (9.3)
5 Censor Design  (9.3)
Top Logo Graphicians
1 t0m3000  (10)
2 Sander  (9.8)
3 Mermaid  (9.5)
4 Shine  (9.4)
5 Pal  (9.4)

Home - Disclaimer
Copyright © No Name 2001-2025
Page generated in: 0.045 sec.