| |
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! |
|
| |
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. |
| |
Oswald
Registered: Apr 2002
Posts: 5095 |
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? |
| |
Bitbreaker
Registered: Oct 2002
Posts: 508 |
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? :-) |
| |
Krill
Registered: Apr 2002
Posts: 2981 |
Quoting cobbpgI'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. =) |
| |
Martin Piper
Registered: Nov 2007
Posts: 726 |
Nunufli |
| |
cobbpg
Registered: Jan 2022
Posts: 36 |
Quoting The Human Code MachineWould 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 Oswaldto 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 BitbreakerWhat 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 BitbreakerWill 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 KrillI immediately thought "NUFLI+", but no idea how search engine friendly that is. =)
Yeah, this would have been my preferred choice too otherwise.
Quoting Martin PiperNunufli
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. |
| |
Jetboy
Registered: Jul 2006
Posts: 338 |
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. |
| |
cobbpg
Registered: Jan 2022
Posts: 36 |
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. |
| |
enthusi
Registered: May 2004
Posts: 677 |
add 'F' for 'flexible'?
FNUFLI or NUFLIF? |
| |
Bitbreaker
Registered: Oct 2002
Posts: 508 |
Quoting cobbpg
Quoting BitbreakerWhat 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. |
| |
Frantic
Registered: Mar 2003
Posts: 1648 |
Quote: add 'F' for 'flexible'?
FNUFLI or NUFLIF?
FNUFLI was a good one, I think. |
| |
PopMilo
Registered: Mar 2004
Posts: 146 |
Looking great imho !
I would love to see that compute shader code :)
Guess we'll have to wait for that article ? |
| |
cobbpg
Registered: Jan 2022
Posts: 36 |
Quoting Bitbreakerafaik 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.
You can define up to 17 colour updates per AFLI block (i.e. two scanlines): 4 for the FLI bug, 2*6 for the underlay in columns 3-38, and the border.
My code generation algorithm starts by making a complete list of register writes to realise the desired picture. Some of these are fixed to a certain scanline, others are what I call deferrable, i.e. they can be issued within a range of scanlines (basically where they are unused, hence their value doesn't matter, or they are the sprite Y updates). Every register write has its address, value and valid cycle interval recorded.
I go line by line from the top of the screen and start generating code such that all the timing and value constraints are met. Each update costs 4 or 6 cycles depending on whether an existing register value can be reused or not. I also take advantage of the fact that only the lower 4 bits matter for colours, so e.g. if we're supposed to write $3c to $d011 and we need to set something mid grey at the same time, we can potentially reuse the value.
It turns out that for a typical picture you can successfully fit the required code into the time budget on most scanlines. When I run out of time, I remove an update or two based on some heuristics (e.g. I start with removing bug updates, then if that's not sufficient, I'll remove some from the middle section as well, and always pick the one whose removal adds the smallest error) and try again until the resulting code fits. I'm always guaranteed to get 6 updates just like plain NUFLI, but typically it's more due to repeated colours.
What matters is that the process is guaranteed to produce an executable, and it gives you feedback about the CPU time used (the green/red bars on the right hand side). This way the artist can easily tell if they are allowed to add more colour in some area or have to cut back on changes in another to guarantee a certain outcome. In practice this system works surprisingly well.
As for update removals affecting subsequent lines, that's pretty much limited to the FLI bug, since with 6 updates you can always make sure to leave the underlays in the middle section in the desired state. Well, unless you change the border colour too, but just don't do that in the most contested areas. :P
Quoting PopMiloI would love to see that compute shader code :)
Guess we'll have to wait for that article ?
The code is just a bunch of exceedingly boring nested loops, so don't have high expectations of brilliance. ;) It's very similar to what Mufflon does: just try all combinations and pick the one with the least overall error for each section. And yeah, I'll document everything first, which should also make the code easier to understand. I'm hoping to be able to release it all later this month. |
| |
Jetboy
Registered: Jul 2006
Posts: 338 |
Quoting cobbpgI'm hoping to be able to release it all later this month.
Christmas is coming early this year :) I just can't wait :) |
| |
Jammer
Registered: Nov 2002
Posts: 1336 |
SNUFLI like Speedcode NUFLI? And has some ring to it ;) |
| |
cobbpg
Registered: Jan 2022
Posts: 36 |
Or RUFLI for Rejuvenated Underlay FLI, pronounced like "roughly". :P |
| |
Jetboy
Registered: Jul 2006
Posts: 338 |
PROFLI?
FLIPROQUO?
COBBPGFLI ?
ONUFLI (Optimised NUFLI, or Oh my god! FLI)? |
| |
sebalozlepsi
Registered: Mar 2010
Posts: 23 |
NUFLIX |
| |
Copyfault
Registered: Dec 2001
Posts: 478 |
The example video link in the first post is really something! Looks VERY promising and the "response time" you have while... "pixelling" is simply next level!
Not meant too serious, but you should maybe keep this for the next Performers-Demo and name the mode 'NextFli' ;)
But ok, joking aside, I get that the core routine that runs on the C64 is... NUFLI. The improvements are more on the preparation side, where it for sure makes a f**kload of sense to presort sprite colour reg writes... so, somehow I tend to think more of a "new Mufflon" to materialize soon, instead of a new "mode", since it's still NUFLI. Ofc, you already threw in the things that have to be implemented in a future version: full VIC register f**kery! THIS would really justify to call for a new mode, and I know at least one person that has this idea since a few years (Ptoing, DO YOU READ?)
Please DO NOT interpret any evil criticism in this text, it's really solely meant constructive, and I bow in deep respect of seeing that this NUFLI-mode-dependencies have been cracked (in a way) so you are able to feed this through shader logics!
Looking forward to reading *that* article you're writing on all of this :)
Cheeeerz
Copyfault |
| |
Martin Piper
Registered: Nov 2007
Posts: 726 |
Quoting CopyfaultBut ok, joking aside, I get that the core routine that runs on the C64 is... NUFLI. The improvements are more on the preparation side, where it for sure makes a f**kload of sense to presort sprite colour reg writes... so, somehow I tend to think more of a "new Mufflon" to materialize soon, instead of a new "mode", since it's still NUFLI.
The question of what to name something when the C64 display mode effect is the same, but the data preparation is what makes it special, is an interesting one.
When I did coding for the video sequences in Hunter's Moon, it just uses multicolour bitmap with sprites over the top. There's nothing special about the display mode. But the algorithm compressing all the data, making it fast enough to decompress while optimising bitmap and sprite data, that's the special part. But does the data processing deserve to get a name? |
| |
WVL
Registered: Mar 2002
Posts: 903 |
Quote: NUFLIX
Winner. NUFLIX sounds good, is a pun to Netflix and can be explained as NUFLI extended (which is wat is is)
Now ehr.. is it possible to modify this to make UFLI max pictures or would a modified MUFFLON work better?
And, where did cobbpg come from? |
| |
Oswald
Registered: Apr 2002
Posts: 5095 |
Quote: Quoting CopyfaultBut ok, joking aside, I get that the core routine that runs on the C64 is... NUFLI. The improvements are more on the preparation side, where it for sure makes a f**kload of sense to presort sprite colour reg writes... so, somehow I tend to think more of a "new Mufflon" to materialize soon, instead of a new "mode", since it's still NUFLI.
The question of what to name something when the C64 display mode effect is the same, but the data preparation is what makes it special, is an interesting one.
When I did coding for the video sequences in Hunter's Moon, it just uses multicolour bitmap with sprites over the top. There's nothing special about the display mode. But the algorithm compressing all the data, making it fast enough to decompress while optimising bitmap and sprite data, that's the special part. But does the data processing deserve to get a name?
no, the difference is not only in data prep, it updates more color registers than NUFLI. |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1409 |
Very cool. Looks like there are a lot of ideas in there I've been meaning to implement for one of the other newfangled modes, but I've been a bit too distracted with crunchers to get around to.
Looking forward to see some new artwork coming out to take advantage of it!
(Oh, and another vote for nufliX btw :D) |
| |
Raistlin
Registered: Mar 2007
Posts: 685 |
Quote: no, the difference is not only in data prep, it updates more color registers than NUFLI.
Yep, I was going to say similar. This does sound like a new mode. Since current NUFLI displayers wouldn't be able to display these new pictures, we can hardly say that they're just NUFLI generated differently. |
| |
uneksija
Registered: Jan 2002
Posts: 45 |
If NUFLI+ would be problematic for search engines, how about NUFLIPLUS?
:) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11390 |
Nu-FLI (Butterfly edition) |
| |
Danzig
Registered: Jun 2002
Posts: 440 |
NXFLI? (Next-FLI) NGFLI? (Next Generation-FLI) |
| |
tlr
Registered: Sep 2003
Posts: 1791 |
NUFLING |
| |
cobbpg
Registered: Jan 2022
Posts: 36 |
I do like NUFLIX actually, it's as close to NUFLI+ as it gets!
Quoting CopyfaultNot 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.
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.
Quoting WVLNow ehr.. is it possible to modify this to make UFLI max pictures or would a modified MUFFLON work better?
No, that's a much simpler use case. Since there's no time to change sprite colours when you perform FLI every line, you can just optimise every 48-pixel column for each of the 16 possible underlay colours separately and pick the best outcome.
In contrast, with NUFLIX I need to check all 256 possible sprite colour combinations within each 48x2 pixel region separately. Thankfully these regions don't overlap, so it's very easy to parallelise the algorithm and run it on the GPU.
Quoting WVLAnd, where did cobbpg come from?
My old login name in some closed systems was cobb, which was obviously not widely available on just about any service on the open internet. :P I simply appended my initials to create a more unique identifier. |
| |
Digger
Registered: Mar 2005
Posts: 438 |
Yeah, I was going to suggest NUFLIx before I read Sebaloz's comment.
Also like SNUFLI – Speedcode Flexible Line Interpretation.
Or NUFLIXBUS ;-) b/c you're unrollingly bussing the registers.
But jokes aside, this is some serious breakthrough. I can imagine such editor not only for NUFLI but for any other gfx mode. Writing optimisers/converters as shaders is super rad. And GX (Graphician's eXperience) is deluxe! With processor budget and choosing prios by error map.
Amazing work man, I look forward to testing this!
PS I had no idea about VICE's binary monitor API, something's worth exploring! |
| |
Copyfault
Registered: Dec 2001
Posts: 478 |
Quoting Oswaldno, 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 cobbpgQuoting CopyfaultNot 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 cobbpgMaking 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. |
| |
cobbpg
Registered: Jan 2022
Posts: 36 |
Quoting CopyfaultNext 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! |
| |
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. :) |
| |
cobbpg
Registered: Jan 2022
Posts: 36 |
Quoting encoreExciting 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! :) |
| |
Jetboy
Registered: Jul 2006
Posts: 338 |
Funny how i refresh this thread every couple of minutes to check if it's released yet :) |
| |
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. ;) |
| |
Jetboy
Registered: Jul 2006
Posts: 338 |
I guess, i can stop refreshing till next weekend again :) |
| |
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! |
| |
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!).. |
| |
cobbpg
Registered: Jan 2022
Posts: 36 |
Quoting DeeKayOh 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 DeeKayWhen 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 DeeKayWhat 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. |
| |
Copyfault
Registered: Dec 2001
Posts: 478 |
Quote: 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!)..
Why not also make the bitmap mode switchable MC + Hires? And suddenly, you're pretty close... no, you end up with arbitrary VIC-reg changes to be permitted for a change.
But I think I got the contra-argument from you, cobbpg. We'd loose the option to parallelize the calculation by means of shader logics. Having never worked with such things, isn't it possible to parallelize it nontheless, and have i.e. several conversion runs with different reg categories each?
Depending on the gfx, it might not even be the best option to have FLI every 2nd line, but to have more lines free for vic-reg changes. It quickly becomes highly arbitrary...
...so, I better shut up and wait for the convertor that already *is* in the pipeline ;) |
| |
cobbpg
Registered: Jan 2022
Posts: 36 |
Yeah, I want to make it clear that I'm not against those ideas at all, they are definitely worth exploring. To me it's especially interesting to think about how far we can push the NUFLIX approach while keeping the desirable properties like rapid feedback to the artist. But in my view it's equally valid to pursue a completely different goal, like allowing the converter to crunch away for hours in search of the best possible representation of an arbitrary input image.
Quoting CopyfaultHaving never worked with such things, isn't it possible to parallelize it nontheless, and have i.e. several conversion runs with different reg categories each?
To some extent yes, you just have to keep in mind that if you are to run a massively parallel computation, then the different branches need to have very similar (if not identical) flows of control. Also, your search space can easily balloon out of control by adding more dimensions to it.
For instance, if we enable multicolor for several sprites, then we introduce a dependency between previously unconnected areas on the picture, since a single register update can affect all of them. At some point you have to give up on using brute force and turn towards more advanced methods to prune the search space. Which is a very exciting technical challenge, I cannot deny. ;) |
| |
Jetboy
Registered: Jul 2006
Posts: 338 |
Once you release we can pararellize development, taking the project into many different directions. |
| |
cobbpg
Registered: Jan 2022
Posts: 36 |
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 |
| |
Digger
Registered: Mar 2005
Posts: 438 |
Wonderful! How to compile it? On a Mac. |
| |
cobbpg
Registered: Jan 2022
Posts: 36 |
This project was made with Unity 6. The easiest way to get started:
1. Clone the project from GitHub.
2. Download and run Unity Hub.
3. Use the Add button and select the NuflixStudio directory.
4. Let the Hub download the correct Unity version (6000.0.3f1). Make sure to include build support for the platforms you need.
5. Open the project.
6. Select File → Build and Run. In case that doesn't work out of the box, check File → Build Profiles.
If somebody makes Linux and Mac builds and confirms that they work, I can add them to the release. Make sure to uncheck the Development Build toggle.
I also added a 32-bit Windows build in the meantime. |
| |
Jetboy
Registered: Jul 2006
Posts: 338 |
Awesome! My ctr+f5 keys are thanking you :)
Will post some feedback after i manage to get me stop playing. |
| |
Jetboy
Registered: Jul 2006
Posts: 338 |
Excellent write up. Pretty clear and well explained (i might be biased as mosty i know what i'm reading about, but i learned some things and got some new ideas too). It was very good read to me, like some top novel.
As for the software itself it is absolutely awesome for a first release. Working with it is so silky smooth performance wise.
However there is a lot of improvements to be made, as some things are making working with it hard or hardly possible.
What would be the way to report bugs/add suggestion that would be most convenient for you? While we are at it here are things that seem important to me:
- Ability to zoom with ctrl mouse scroll wheel, centered on mouse. I have not found a way to move contents of the zoomed windows horizontally, hence no possibility to paint on the right parts of the image while zoomed.
- Ability to force zoom to integer factors - so we do not get unpleasant moire effects, that twist the view of images we are working on.
- Palette mapping could be improved by adding more palette options. Currently if i try to load images exported with PALette Middle Gray is being interpreted as Dark Gray and Light Gray as Middle gray. While it is easy to fix that by either editing the mapping, exporting with the palete you use, or edit vpl in the program data to use palette of choice. It would be great if the program had support for multiple palettes built in.
- I guess colors in the palette while color mapping are sorted by the value, which was confusing to me at first as i'm used to have them ordered by color number. An option to change that ordering would be lovely.
Bugs/strange behaviours:
- when i load indexed color images it works fine, but when i load truecolor images, behaviour is inconsistent. Sometimes it does not update, sometimes it does , i did not find any regularity with it yet. |
| |
Digger
Registered: Mar 2005
Posts: 438 |
Managed to compile it for Mac, the UI seems to be out of scale in places. Will see if I can fix that somewhere in the settings. |
| |
cobbpg
Registered: Jan 2022
Posts: 36 |
Quoting JetboyExcellent write up. Pretty clear and well explained (i might be biased as mosty i know what i'm reading about, but i learned some things and got some new ideas too). It was very good read to me, like some top novel.
Thanks, writing that little article was pretty much all I did over the last two weeks. ;)
Quoting JetboyWhat would be the way to report bugs/add suggestion that would be most convenient for you?
GitHub issues would be the best, but I'll also be monitoring this topic.
Quoting Jetboy- Ability to zoom with ctrl mouse scroll wheel, centered on mouse. I have not found a way to move contents of the zoomed windows horizontally, hence no possibility to paint on the right parts of the image while zoomed.
Yeah, ctrl+wheel sounds like a good alternative to support for zooming, I'll see what I can do about that. As for scrolling horizontally, you already have two options: laptop trackpads (which Unity treats as a two-dimensional wheel input), or dragging with the middle mouse button pressed. Does neither of those work for you?
Quoting Jetboy- Ability to force zoom to integer factors - so we do not get unpleasant moire effects, that twist the view of images we are working on.
Zoom is actually forced to integer factors in the editor, but I wonder if there's some screen scaling magic going on depending on the setup. I haven't tested with a non-100% desktop scaling factor, so I'll have to look into that. In the meantime, you could try setting the DPI factor for the executable to see if you can get rid of the issue.
Quoting Jetboy- Palette mapping could be improved by adding more palette options. Currently if i try to load images exported with PALette Middle Gray is being interpreted as Dark Gray and Light Gray as Middle gray. While it is easy to fix that by either editing the mapping, exporting with the palete you use, or edit vpl in the program data to use palette of choice. It would be great if the program had support for multiple palettes built in.
Yeah, the palette management story is very minimalistic for the time being. :P I generally wouldn't mess with the VPL, since it's tuned to be close to VICE, and those colours are used by the search algorithm. The current recommended way of doing things is to create a conversion profile for a certain palette, then you can just reuse that for many pictures. At the moment the conversion profile is reset when you load a new picture, but I could e.g. add a checkbox to keep it between loads if the colours match.
By the way, I found that pretty much all sensible C64 palettes can be matched by just cranking up the brightness slider to varying extents.
Quoting Jetboy- I guess colors in the palette while color mapping are sorted by the value, which was confusing to me at first as i'm used to have them ordered by color number. An option to change that ordering would be lovely.
Unfortunately the problem is that with Unity's image loader you lose the information about indexed colours, and you just get an array of RGBA pixels. Because of that, I implemented a sorting method that sorts values into a handful of buckets, and sorts by hue within those buckets, just to prevent completely random ordering.
Quoting Jetboy- when i load indexed color images it works fine, but when i load truecolor images, behaviour is inconsistent. Sometimes it does not update, sometimes it does , i did not find any regularity with it yet.
That sounds strange, since it should make no difference at all to the program. If there's a real issue, it would be great to reproduce it reliably.
Quoting DiggerManaged to compile it for Mac, the UI seems to be out of scale in places. Will see if I can fix that somewhere in the settings.
This could be easily related to Jetboy's problem with scaling. I really hope we can get to the bottom of this and make it work nicely out of the box. |
| |
Jetboy
Registered: Jul 2006
Posts: 338 |
Quoting cobbpg
Quoting Jetboy- Ability to zoom with ctrl mouse scroll wheel, centered on mouse. I have not found a way to move contents of the zoomed windows horizontally, hence no possibility to paint on the right parts of the image while zoomed.
Yeah, ctrl+wheel sounds like a good alternative to support for zooming, I'll see what I can do about that. As for scrolling horizontally, you already have two options: laptop trackpads (which Unity treats as a two-dimensional wheel input), or dragging with the middle mouse button pressed. Does neither of those work?
It was not intuitive for me to try. Strange as some application i use daily use middle mouse button to drag.
The scaling was working fine when i first run the editor, but then i put it into fullscreen mode and it is off eversince. That seems like the dpi problem indeed. Game engines are notorious to have problems with UI scalling. I havent worked with unity for like 10 years or so, i thought they come up with solutions for that problem in meantime, but i see they didnt.
I'm installing unity right now so i can build the project myself and investigate the problems deeper.
I will use github for issue reporting, and this thread for discussion. |
| |
cobbpg
Registered: Jan 2022
Posts: 36 |
Quoting JetboyIt was not intuitive for me to try. Strange as some application i use daily use middle mouse button to drag.
This is all written in the manual for what it's worth. ;)
Quoting JetboyThe scaling was working fine when i first run the editor, but then i put it into fullscreen mode and it is off eversince.
Another thing that never even crossed my head to try!
Quoting JetboyI havent worked with unity for like 10 years or so, i thought they come up with solutions for that problem in meantime, but i see they didnt.
It could be that there's a magic setting somewhere, but no matter what, Unity is not exactly aimed at making desktop UI applications... |
| |
Jetboy
Registered: Jul 2006
Posts: 338 |
Quoting cobbpgQuoting JetboyIt was not intuitive for me to try. Strange as some application i use daily use middle mouse button to drag.
This is all written in the manual for what it's worth. ;)
This is one of those rare cases I actually read manual. Somehow i missed that, yet it is in the very last paragraph. I would suggest moving it up, or at least bolding it. Compiling FAQ section wouldn't be bad idea neither.
btw. After building it locally, i have no problem with the scale. I can resize the window and it works fine. |
| |
Jetboy
Registered: Jul 2006
Posts: 338 |
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. |
| |
Copyfault
Registered: Dec 2001
Posts: 478 |
Quoting cobbpgIt'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 |
| |
Jetboy
Registered: Jul 2006
Posts: 338 |
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. |
| |
cobbpg
Registered: Jan 2022
Posts: 36 |
Quoting Jetboysprite 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 JetboyMaybe 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 JetboyIt 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 JetboyYou 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 JetboyInstant 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 JetboyI 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 JetboyMappin 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 JetboyIt 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 JetboyIt 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. |
| |
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! |
| |
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. |
| |
cobbpg
Registered: Jan 2022
Posts: 36 |
Quoting WVLWhat 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 WVLAlso, 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. |
| |
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. |
| |
Jetboy
Registered: Jul 2006
Posts: 338 |
How do we figure out which updates have been skipped? |
| |
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. |
| |
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.
 |
| |
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. |
| |
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. |
| |
cobbpg
Registered: Jan 2022
Posts: 36 |
Just to be clear, what I'm talking about is the difference between the best-case representation you get from the brute-force search and the result of the code generation process where we try to schedule as many register updates as possible to reproduce the best-case image.
Naturally, even the best case is limited, since it defines the boundaries of what's possible (at least with the given sprite configuration). Most of the artifacts come from the reality of reducing a free-form image into sprite and bitmap layers. In the end, the artist has to work within the limitations of the format, and what I'm trying to achieve with NUFLIX is to make that process as convenient and painless as possible. At least when you have a very responsive system, you can start correcting the artifacts manually by incrementally altering the source image, and you'll see immediately how it comes out the other end. |
| |
Digger
Registered: Mar 2005
Posts: 438 |
The cat is probably wired from one of these https://www.freepik.com/premium-ai-image/pop-art-colourful-beau..
But a very good test case, I agree! |
| |
cobbpg
Registered: Jan 2022
Posts: 36 |
It's pretty clear that excessive checkerboard dithering doesn't work well, since it already hogs up the ink layer, and there's no easy way to preserve other edges at the same time. One style I found works pretty well is the cutscenes from the Amiga version of Stunt Car Racer. Here's one of them converted to NUFLIX:
It's a clear style that doesn't use a lot of colours in clusters, so even if it wasn't drawn with attribute block limitations in mind, it translates fairly well even with zero adjustments. The trophy is the most obvious element in need of some tweaking. |
| |
Jetboy
Registered: Jul 2006
Posts: 338 |
When we are in Layer Edit Mode when mouse hovering the image we can see what colors are active in this block. Could we please have color of source pixel also displayed?
Then, could we have that displayed at all time in every mode?
That would make using educated decision what colors can be used easier.
Also when in split screen mode, please highlight pixel in the other window corresponding to the pixel we are at with mouse. |
| |
cobbpg
Registered: Jan 2022
Posts: 36 |
Yeah, those sound reasonable and easy to implement. Added them to my todo list. |
| |
Oswald
Registered: Apr 2002
Posts: 5095 |
wow this last example pic is shockingly good, just drop the clouds near the cup, and it will be ok :) |
| |
cobbpg
Registered: Jan 2022
Posts: 36 |
One idea I'd like to try is to be able to draw an importance mask in the editor, where you could mark certain pixels such that they would be less likely to change during conversion to layers, for instance by multiplying their error metric with a constant. |
| |
Cybortech
Registered: Jan 2009
Posts: 16 |
Please convert this:
https://ibb.co/ZNjf9yW
https://i.ibb.co/vDFc92Z/bonzai-logo.png
Thank you! |
| |
cobbpg
Registered: Jan 2022
Posts: 36 |
You should be able to play with the converter yourself: NUFLIX Studio 1.0. I also recommend checking the manual.
If you're not on Windows, you need to make your own build for now. If you're not familiar with Unity, here are the steps to do so:
1. Clone the project from GitHub (you can also download the source as a zip archive from the above link if you don't want to deal with Git).
2. Download and run Unity Hub.
3. Use the Add button and select the NuflixStudio directory.
4. Let the Hub download the correct Unity version (6000.0.3f1). Make sure to include build support for the platforms you need.
5. Open the project.
6. Select File → Build and Run. In case that doesn't work out of the box, check File → Build Profiles.
That said, this Bonzai logo is a pretty good adversarial example, because the X-expanded underlay really cannot reproduce the edges well in the middle section. |
| |
Digger
Registered: Mar 2005
Posts: 438 |
@Cyborthech: Ah that part from Lethal Display 4, it would be fun if it worked and suddenly the entire logo gets revealed... https://youtu.be/BHWpX-EB8UY?t=7082 |
| |
Oswald
Registered: Apr 2002
Posts: 5095 |
@cobbpg
I am on a 1366x768, and the nuflix window tries to resize itself to this, it seems it resizes all elements inside the window and I get horrible artefacts on the preview window, every 32 or 64 pixel sized quare block the pixels are doubled or not doubled.
Somehow you should tell the gui to never resize the preview windows, make it always 320x200 or double, etc.
also when I try to resize the window it always just wants to stay fullscreen. |
| |
cobbpg
Registered: Jan 2022
Posts: 36 |
Thanks for the report, I'll look into that too for the next version. I set the default window size to 1600x900, and that might be part of the problem. As for the preview images, I can change the logic to ensure that they are only scaled by integer factors. |
| |
Cybortech
Registered: Jan 2009
Posts: 16 |
@Digger: Yes! : ) |
| |
The Sarge
Registered: Aug 2002
Posts: 49 |
I really appreciate you making the effort coding this! Great work.
But after some testing I dont think I will ever be able to use this though. Its too unpredictable for my liking. Too much trial and error to make it work.
However some advice if you want to upgrade it.
- Zoom with scroll wheel on mouse.
- Pan by holding space key+left click on mouse to drag canvas around. Could also be scroll wheel click and hold to pan.
- Primary and secondary colour on left and right mouse buttons.
- A color picker tool. ALT+ left click on a color to set this colour as your primary color, ALT+right click to set secondary.
- Pixcen or Pepto palette. The one in the tool right now has very weird colours.
- Bucket Fill tool. |
| |
cobbpg
Registered: Jan 2022
Posts: 36 |
Quoting The SargeI really appreciate you making the effort coding this! Great work.
But after some testing I dont think I will ever be able to use this though. Its too unpredictable for my liking. Too much trial and error to make it work.
No problem, thanks for checking it out!
Quoting The Sarge- Zoom with scroll wheel on mouse.
- Pan by holding space key+left click on mouse to drag canvas around. Could also be scroll wheel click and hold to pan.
- Primary and secondary colour on left and right mouse buttons.
- A color picker tool. ALT+ left click on a color to set this colour as your primary color, ALT+right click to set secondary.
- Pixcen or Pepto palette. The one in the tool right now has very weird colours.
Yep, these features are all coming in some shape or form in the next version. I'm still thinking about how to make palette management convenient.
Quoting The Sarge- Bucket Fill tool.
This is something I'm not so sure about. My current thinking is that this tool is primarily for adding the last touches where you really need full control, and you'd do most of the work in your preferred editor prior to that. I'd really want to avoid expanding it into a full-fledged drawing application, since there are so many alternatives already.
You can set up NUFLIX Studio to act as a simple pipe that processes your freely drawn image and sends it to VICE without requiring any interaction other than pressing save in your editor. A composable building block you can add to your workflow, if you will. Whether this workflow is actually viable remains to be seen, and it depends on how much feel you can get for the limitations. Having a single sprite colour affect a 48-pixel wide area can certainly be an annoyance... |
| |
cobbpg
Registered: Jan 2022
Posts: 36 |
I'm happy to announce the release of NUFLIX Studio v1.1 just before the holiday season! ;)
The most important change since the previous version is that the exporter will always include all the necessary sprite moves to be able to display the full picture, no matter how many register updates the picture requires. Other than that, the editor was extended with some features requested by various people. For further details, check the full changelog. |
| |
Jetboy
Registered: Jul 2006
Posts: 338 |
Awesome!
Sadly i won't find the time to play with it before christmas :( But then... :) |
| |
CopAss
Registered: Sep 2004
Posts: 22 |
Quote: I'm happy to announce the release of NUFLIX Studio v1.1 just before the holiday season! ;)
The most important change since the previous version is that the exporter will always include all the necessary sprite moves to be able to display the full picture, no matter how many register updates the picture requires. Other than that, the editor was extended with some features requested by various people. For further details, check the full changelog.
cool! |
| |
Monte Carlos
Registered: Jun 2004
Posts: 364 |
I appreciate your work too, but I'm missing a description what the new format enables one to do compared to the nufli reference. Is it just that the sprite positions are customizable or is it about the colors or both? |
| |
cobbpg
Registered: Jan 2022
Posts: 36 |
For the time being only the ability to change the underlay colours outside the bug area in every scanline. Changing the sprite configuration is a possible future improvement, but it would require a rewrite from the ground up. |
