** New Frontiers in VIC-Hires-Graphics, Part 10

[tokra]

Have a look at something new: FLI-graphics mode for the VIC:



These are three different pics in a 72x256 pixel graphics mode with 8x1 color resolution in Hires (or 4x1 in Multicolor) with freely chooseable border, background and multicolor-auxiliary color per line working on a PAL-VIC with at least 16K expansion.

You can also try this with some more pics in VICE or on a real VIC by downloading this package:

FLI-mode demonstration (not safe for work)

Why "not safe for work"? Well the aspect ratio of the graphics mode lends itself to some very "special" sort of picture, nothing too naughty though

To get this working you will have to copy the four files bitmap.prg, colour.bin, 900e.bin and 900f.bin from one of the subdirectories to the main directory. Then just drag and drop boot.prg into your VICE window - making sure it's set to at least 16K expansion - and let it do it's magic (or just go to Warp Mode by pressing ALT+W to speed things up). Et voila!

Huge thanks go to Mike for creating the conversion program to create those images. It is included with the package called fli_quant.exe - it expects a file called 'input.ppm' with a resolution of exactly 72x256 pxiels (24-Bit-RGB) and will create a file result.ppm and the 4 files to be used by the VIC mentioned before.

How does this graphics mode work?

Some weeks ago after finishing the MAXIGRAFIK-mode I had a new idea: Why not use the processor-time that's used to create a larger bitmap to create a better color resolution? tlr's FCBPAINT already uses some neat tricks to increase color resolution, like switching the color-RAM between $9400 and $9600 every 4 lines and being able to switch the border & background color ($900f) and multicolor-auxiliary color ($900e) each line or even within a line.

My idea combines this with on-the-fly color-ram updates by always writing color information for the next line while displaying the current one. I'm heavily limited by the number of bytes that can be updated per line because a raster line only has 71 cycles in PAL and updating one byte takes at least 6 cycles and I also want to be able to switch $900f and $900e in each line. Plus another 4 cycles are needed to switch the color-RAM after each line. This leads to a maximum line width of 72 pixel. Here's the math:

72 pixels = 9 byte = 54 cycles to update
$900e, $900f = 2 byte = 12 cycles to update
$9005 update = 1 byte = 6 cycles to update (4 cycles if using pre-set register to store)

So, one line takes 72 cycles to update and switch and the next one 70 cycles. Perfect

Comments are welcome as always!

[Kananga]

Nice cats

After watching the images on VICE I tried it on the real VIC, because I thought the images could look better there.

On (my) real hardware the screen flickeres horribly. My first guess was, that it is not best to run it with SJLOAD present, so I hit the reset button and tried it without SJLOAD. This time the program ended with a black screen after drawing the first few lines. (Tried it a couple of times)

With SJLOAD the flickering stops, when the image is complete. (Launched from VIN, of course )

Great work! Keep pushing the limits!

[Mike]

On (my) real hardware the screen flickeres horribly, [but it] stops, when the image is complete. (Launched from VIN, of course )

Generally data transfers disable interrupts at least for a short time, which then affects the display routine, which is synchronised to the raster beam with a VIA interrupt.

Obviously the standard IEC routines can't cope with such a "big" interrupt routine, I didn't test that.

(I just thought in the meantime a proposed bug-fix wouldn't work - but indeed it works well enough ... ): delete line 16 (with SYS 7056), and place that in line 105 instead.

Great work! Keep pushing the limits!

Thanks!

And ... indeed the end of the flagpole is still not reached at all!

Cheers,

Michael

[tokra]

I just updated the archive linked about with two new files "bootfast.prg" and "mainfast.prg" that load the graphics data without displaying it at the same time. Also added a counter to see how far the data has been loaded. Not as pretty as watching the graphics being loaded but more practical for a real VIC.

[nbla000]

wow, that's incredible !

[orion70]

Really, really AMAZING. You know what's next? We're ready for the International VIC-20 Strip Poker Challenge game, sold on two DSDD disks, at the incredible price of $ 19.99 (€ 14.99 for European countries) .

All jokes apart guys, you - and the humble VIC - keep surprising me every time. Thanks because you showed that not every secret was unveiled.

I tried to produce an image myself with fli_quant.exe, but couldn't. I run the exe file with a double-click or from the CMD window (in windows XP), and nothing happens. The file I put in the same dir is a 24-bit RGB image 72x256 pixels. What's wrong with that? Is there a way to produce the image via a VIC executable, just like PPM to VIC conversion in Minigrafik?

[FD22]

Once more I bow before you; this last decade has seen some staggering feats performed on our humble little breadbin, and there seems no slowing of progress.

[Mike]

I tried to produce an image myself with fli_quant.exe [...] What's wrong with that?

PM sent.

this last decade has seen some staggering feats performed on our humble little breadbin, and there seems no slowing of progress.

Though one needs to realise that many of these achievements would not have been possible without cross-developing, and advances in computer technology in the years in-between. The algorithm used to convert the picture is very compute intensive and would have appeared infeasible in those times.

[orion70]

I tried to produce an image myself with fli_quant.exe [...] What's wrong with that?

PM sent.

..and problem solved, as you can see from my new avatar* .
Cheers!

*EDIT: the original elaboration was:

[tlr]

Nice work!

You could consider other variants like new colors every 2 lines. That way you might be able to optimize stores of equal values enough to achieve more width.

Code: Select all

lda #$0f
sta $9400
sta $9402
sta $9404
lda #$02
sta $9401
sta $9403
...

There are only 16 values (8 if only MC is used) so for your current 9 stores (which would be 18 if done every second line) you should safely get a few doubles.

Note that for an all MC screen you will already get one double per line.
Combine that with preloaded $9005 values and you have one more store.

[Mike]

You could consider other variants like new colors every 2 lines. That way you might be able to optimize stores of equal values enough to achieve more width. [...]

It's not as if tokra and I hadn't discussed suchalike variants of the FLI mode in e-mail beforehand.

However, pre-compiling the code would only be useful for static images. Contrary to MAXIGRAFIK, this FLI mode allows the CPU to continue work on the user program while displaying the image - even though there are currently some difficulties with drive access.

The converter can "hold" the three global colours for each line, while varying the 9 attribute bytes (and, of course, the bitmap data) in a way to minimize the quantization error. If the FLI mode is again restricted more in the sense that the 3 global colours still can be exchanged on each line, but the attributes are 8x2 pixels, then the converter would need to optimize for actually 6 global colours per double-line, not only 3 for a single line as it does now.

Note that for an all MC screen you will already get one double per line.

Including hires allows to use the upper 8 colours even with single-width pixels, the background colour is used for that! Also, the apparent impression of sharpness is judged by eye with the highest frequencies present in the image - and those are higher if I allow for hires pixels.

I *do* have ideas for extending the horizontal width and still keeping 8x1 attributes, but they will work in other ways ...

[tlr]

However, pre-compiling the code would only be useful for static images. Contrary to MAXIGRAFIK, this FLI mode allows the CPU to continue work on the user program while displaying the image - even though there are currently some difficulties with drive access.

This is obviously a killer point. I assumed the graphics could be static.

The converter can "hold" the three global colours for each line, while varying the 9 attribute bytes (and, of course, the bitmap data) in a way to minimize the quantization error. If the FLI mode is again restricted more in the sense that the 3 global colours still can be exchanged on each line, but the attributes are 8x2 pixels, then the converter would need to optimize for actually 6 global colours per double-line, not only 3 for a single line as it does now.

For someone drawing rather than converting it would be less limiting.
The mode should be flexible enough for most graphicians to draw directly in.

I *do* have ideas for extending the horizontal width and still keeping 8x1 attributes, but they will work in other ways ...

Interesting.

[Wilson]

Nice avatar, orion70!

For someone drawing rather than converting it would be less limiting.
The mode should be flexible enough for most graphicians to draw directly in.

Agreed, which is why I would find this mode more attractive if there was some sort of graphics editor for it. Of course I understand that this is bleeding edge work, so I'm not holding my breath for such tools.

I never feel I contribute much to these advanced discussions by saying so but amazing work as always!

And ... indeed the end of the flagpole is still not reached at all!

That's the spirit!

[Mike]

For someone drawing rather than converting it would be less limiting. The mode should be flexible enough for most graphicians to draw directly in.

Agreed, which is why I would find this mode more attractive if there was some sort of graphics editor for it. Of course I understand that this is bleeding edge work, so I'm not holding my breath for such tools.

Guys, this is just a proof of concept for a FLI mode. At the time being, there isn't even a BASIC extension available for it, like it is for MAXIGRAFIK, and the bog-standard pure-hardware mode of MINIGRAFIK. I wrote the converter to see what kind of pictures could be displayed with this mode nonetheless.

Coding the BASIC extension and an editor for this mode is not inherently more difficult, but at least I need to ask myself whether there is any demand for them both to put further time into this project. At least the current number of third-party programs for MAXIGRAFIK (0, read: zero), and the pictures done in MINIPAINT - not by myself -, which also have been published (those I can count by the fingers of one hand) does speak another language.

...

The converter can be modified for different screen sizes, so I could easily test the results of a hypothetical 208x256 full-screen, 8x1 FLI mode.

Here's an example:



This still uses "only" 3 global colours (no in-line splits) in each line, which are displayed on the right as debug output: background, border, and auxiliary colour. I'd find it very hard to believe a graphician would be able to select those colours to produce a similar result.

[Wilson]

Guys, this is just a proof of concept for a FLI mode. At the time being, there isn't even a BASIC extension available for it, like it is for MAXIGRAFIK, and the bog-standard pure-hardware mode of MINIGRAFIK. I wrote the converter to see what kind of pictures could be displayed with this mode nonetheless.

Yep, that's what I meant by "... I understand that this is bleeding edge work ..."

Coding the BASIC extension and an editor for this mode is not inherently more difficult, but at least I need to ask myself whether there is any demand for them both to put further time into this project. At least the current number of third-party programs for MAXIGRAFIK (0, read: zero), and the pictures done in MINIPAINT - not by myself -, which also have been published (those I can count by the fingers of one hand) does speak another language.

I was thinking the same thing in regards to a BASIC extension. It's really cool to see pictures in this mode, but I can't wrap my head around too many uses for a FLI mode outside of demo effects and, again, pictures. Don't get me wrong, having pictures is certainly a great achievement itself.
As for an editor, I agree that it wouldn't be utilized enough to warrant the time investment to create it. It'd be cool to see one in a few years, but it's definitely not a pressing matter and I'm not implying you'd be responsible for making it.

Maybe a lot of MINIGRAFIK pictures haven't been published, but MINIPAINT is easily my most used Commodore program and I am very grateful for your work on it. I even have an icon for it on my desktop! And I don't have many icons. If anything I made was any good there would be a great deal more pictures published. I have to believe the same goes for other people.

Pretty fruit! I think that's my favorite of the pictures I've seen so far despite the omission of inline splits. So colorful!

I'd find it very hard to believe a graphician would be able to select those colours to produce a similar result.

More likely would be the case where the graphician would convert an image drawn in the VIC's palette and finish by touching up by hand.