Vic McKracken - fcbpaint-image released at Revision 2017

Discuss anything related to the VIC
User avatar
tokra
Vic 20 Scientist
Posts: 1120
Joined: Tue Apr 27, 2010 5:32 pm
Location: Scheessel, Germany

Vic McKracken - fcbpaint-image released at Revision 2017

Post by tokra »

Name: Vic McKracken
Author: tokra
Released: Apr, 16th 2017 at the Oldskool Graphics Competition at Revision 2017 (got 7th place out of 10)
Requirements: PAL VIC-20 with at least 8K RAM-expansion to view the image (+32K for using fcbpaint)

Description: A hand-pixelled conversion of the starting-picture of Zak McKracken. Using fcbpaint I was able to make use of raster-splits for more colour-flexibility within the image without which this would not have been possible.

103%-version with some very minor fixes to the party-release as well as Exomizer-crunched standalone-viewer at just 2834 bytes (first file on disk).

Screenshot:
Image

Download: http://www.tokra.de/vic/vicmckracken/vi ... racken.d64

This took about 50 hours to pixel, I learned a lot about using fcbpaint. Luckily I could use a new beta 0.8-version that averts the crashes you often got in 0.7 when using raster-splits.
User avatar
Ola H
Vic 20 Enthusiast
Posts: 170
Joined: Thu Aug 20, 2015 6:08 pm
Website: http://www.athleticdesign.se/
Location: Sweden

Re: Vic McKracken - fcbpaint-image released at Revision 2017

Post by Ola H »

Absolutely gorgeous :D
User avatar
joshuadenmark
Big Mover
Posts: 1217
Joined: Sat Oct 23, 2010 11:32 am
Location: Fr-Havn, Denmark
Occupation: Service engineer

Re: Vic McKracken - fcbpaint-image released at Revision 2017

Post by joshuadenmark »

A masterpiece!
Kind regards, Peter.
____________________________________________________
In need of a wiki logon - PM me
hasseapa
Vic 20 Devotee
Posts: 264
Joined: Thu Oct 12, 2006 4:09 am

Re: Vic McKracken - fcbpaint-image released at Revision 2017

Post by hasseapa »

Great work. I am very tempted to start on something similar. Like background graphics for games like Track & Field, Ghosts & Goblins or other games that happened while VIC was past its prime.
User avatar
Misfit
Vic 20 Devotee
Posts: 207
Joined: Thu Nov 28, 2013 9:09 am

Re: Vic McKracken - fcbpaint-image released at Revision 2017

Post by Misfit »

Great work,
Now we have the first screen. Few more and we can play it. :wink:
User avatar
Muzz73
Vic 20 Hobbyist
Posts: 141
Joined: Thu May 03, 2012 12:12 pm
Location: Farmersville, CA,
Occupation: Consultant

Re: Vic McKracken - fcbpaint-image released at Revision 2017

Post by Muzz73 »

Awesome! Sure as heck wouldn't have expected that from a VIC with only an 8K expander...

Great job!
BCNU,
Louis
User avatar
Mike
Herr VC
Posts: 4808
Joined: Wed Dec 01, 2004 1:57 pm
Location: Munich, Germany
Occupation: electrical engineer

Re: Vic McKracken - fcbpaint-image released at Revision 2017

Post by Mike »

Muzz73 wrote:Sure as heck wouldn't have expected that from a VIC with only an 8K expander ...
Adding another +8K in BLK2 or +16K in BLK2 and BLK3 wouldn't add anything to the capabilities of the VIC chip.

Just to remind you: when it comes to graphics data, the VIC chip can only access the internal RAM of the VIC-20. With this picture, the internal RAM (including the colour RAM) is fully used - the expansion RAM then contains a small routine to set up the graphics mode and the rest employs the CPU to do raster effects. It's just the case here, that this raster code happened to fit into +8K, other pictures might need +16K. This is however just a quantitative issue (i.e. how many raster effects are used in the whole picture), and not a qualitative one (i.e. more RAM does not allow for any "better" raster effects, like more narrowly spaced colour splits).

If you want to make any sensible use out of an bitmapped screen of this size (160x192 or 168x192) you'll have to add at least some kind of RAM expansion anyhow. Otherwise you'd be hard pressed to put anything else (of own code, etc.) besides this into memory.

So much for (boring) tech talk.

...

I gladly admit that this picture also came as nice surprise to me on the Revision party. Tokra also talked with two pixel artists (Exin and veto) to remind them, that there still is some undiscovered country on the VIC-20 to explore. :mrgreen:

As a side note to tlr - please release the 0.8 beta of fcbpaint.
tonyrocks
Vic 20 Hobbyist
Posts: 118
Joined: Mon Jan 04, 2016 10:17 pm
Website: http://www.tonyrocks.com
Location: Pittsburgh
Occupation: IBM Watson Engr

Re: Vic McKracken - fcbpaint-image released at Revision 2017

Post by tonyrocks »

Man, still very cool. Looking at it in person really distracts me though, like I'm forgetting it is actually running on a Vic-20!
User avatar
Muzz73
Vic 20 Hobbyist
Posts: 141
Joined: Thu May 03, 2012 12:12 pm
Location: Farmersville, CA,
Occupation: Consultant

Re: Vic McKracken - fcbpaint-image released at Revision 2017

Post by Muzz73 »

I didn't know that the VIC chip could only access the internal memory. Thanks for the info.

It still looks really neat and not something I might have expected from a VIC-20. Nice!
BCNU,
Louis
tlr
Vic 20 Nerd
Posts: 567
Joined: Mon Oct 04, 2004 10:53 am

Re: Vic McKracken - fcbpaint-image released at Revision 2017

Post by tlr »

Wow, awesome!

Was quite a while since I worked on it but will get the beta out some way or another.
User avatar
Mike
Herr VC
Posts: 4808
Joined: Wed Dec 01, 2004 1:57 pm
Location: Munich, Germany
Occupation: electrical engineer

Re: Vic McKracken - fcbpaint-image released at Revision 2017

Post by Mike »

tlr wrote:I [...] will get the beta out some way or another.
Much appreciated!

While you're at it, a function to copy the splits of a raster line would also come in handy. :)

Cheers,

Michael
User avatar
rgrocha
Vic 20 Amateur
Posts: 55
Joined: Fri Dec 06, 2013 7:19 pm

Re: Vic McKracken - fcbpaint-image released at Revision 2017

Post by rgrocha »

Awasome!
Thanks for sharing
groepaz
Vic 20 Scientist
Posts: 1180
Joined: Wed Aug 25, 2010 5:30 pm

Re: Vic McKracken - fcbpaint-image released at Revision 2017

Post by groepaz »

now code the game! :o)
I'm just a Software Guy who has no Idea how the Hardware works. Don't listen to me.
User avatar
beamrider
Vic 20 Scientist
Posts: 1444
Joined: Sun Oct 17, 2010 2:28 pm
Location: UK

Re: Vic McKracken - fcbpaint-image released at Revision 2017

Post by beamrider »

Very impressive!

Excuse my ignorance but do images such as this *have* to be hand pixxeled or would it be possible to write some code to convert from higher fidelity source images programmatically and generate the necessary raster splits?
User avatar
Mike
Herr VC
Posts: 4808
Joined: Wed Dec 01, 2004 1:57 pm
Location: Munich, Germany
Occupation: electrical engineer

Re: Vic McKracken - fcbpaint-image released at Revision 2017

Post by Mike »

beamrider wrote:Excuse my ignorance but do images such as this *have* to be hand pixeled or would it be possible to write some code to convert from higher fidelity source images programmatically and generate the necessary raster splits?
An advice to you: just try it out and write that converter. :twisted:

...

My credentials include the implementations of converters for several of the newly constructed graphic modes by tokra and me:

- for MFLI (208x256, 8x8 foreground attributes, background/border/aux. colour on every raster line, strictly multi-colour)
- for VFLI (208x256, 8x1(!) foreground attributes, background/border/aux. colour on every raster line, mixed hires/multi-colour)
- for MINIGRAFIK (160x192, 8x16 foreground, global background/border/aux. colour, mixed hires/multi-colour)

... which all take a full-colour image (24 bit colour) in the correct size as input (resizing can be done on the PC side). Implementations of VFLI also refer to the software-only implementations of Wide-FLI (104x256) and the original FLI mode (72x256).

On the C128, I did comparable converters for tokra's new VDC modes.

What needs to be taken into account is a usable palette, colour spaces (RGB <-> YUV, et alii), colour distance functions, linear vs. gamma-corrected channel intensities, error distribution of any kind (dithering, etc.), applying hardware restrictions in the right way during dithering, and knowing what leads to big combinatorial problems (when attributes are 'coupled') which ultimately decide if such a converter is feasible or not.

In short: you're grossly underestimating the problems one faces when he goes to write such a converter.

I have discussed this kind of problems with tokra quite often when he came up with a new mode. For several modes (or uses of those modes) I needed to decline his requests because a converter would have to put up with BIG combinatorial expenses - it's no use if a converter runs for weeks, months or years on a current PC to find an 'optimal' distribution of attributes before dithering the picture to that attribute setting.

Attributes in that sense include the determination of foreground colour and multi-colour enable for each attribute cell, or either the global setting of background/border/aux. colour, their determination for each raster line, or any conceivable distribution of splits on a single raster line.

With FCB, the 8x4 foreground attribute introduces an unpleasant coupling across 4 rasterlines, for every split that goes across that attribute cell. In principle, for every foreground cell, you have to optimize for at least 4 settings of combinations of brd/bck/aux - if you're unlucky, there could be a split to another four register settings (aux. or brd/bck) each of which multiplies the search space by the factor 16 (aux.) or 128 (brd/bck). So, for each attribute cell, you have to optimize for at least this number of cases: 16 (foreground) x 2048 (globals) x 2048 (globals) x 2048 (globals) x 2048 (globals) combinations = 281474976710656 combinations; in the worst case, 16 x 2048^4 x 128^4 combinations = 75557863725914323419136 combinations - and that has to be done for all 1008 attribute cells. Not all those combinations are actually realisable (splits must be at least 16 pixels wide but could be done every 24 pixels), so this number decreases a bit.

With MFLI (8x8 attribute cells), I faced a similar problem and could only about handle it by applying a heuristic to the foreground colour attribute cells and restricting the picture to strictly multi-colour. That decoupled the 8 raster lines and I could then optimize the 'globals' for a complete raster line each, i.e. 2048 combinations only for each raster.

I did actually apply the same method to FCB, with a foreground heuristic to its 8x4 cells, but of course this converter does not handle hires attributes (again, only strictly multi-colour), and it does not produce any splits at all; i.e. it misses out on any of FCB advanced features.

The MG converter does 2048 tries for all combinations of global colours (really, global to the whole screen), then - for each of the 2048 settings! - does a first pass with simple 1D dithering to work out all foreground colours (hires or multicolour), and then a second pass where it dithers 2D with the best one of the 2048 settings it found to produce the result. As the restrictions of that mode are so severe, it often cannot find any good combination of background/border/aux. colour at all and then the result is a wild colour soup where the dither algorithm helplessly meanders around to find good approximations to the colours in the image.

The converter for VFLI maybe was the 'simplest' of the lot to write. Here, the problems decouples into 256 'screens' where their globals can be optimized independently, and the foreground attribute cells also can be optimized on their own. There is a minimal coupling from one attribute cell to the next and from one raster to the next, but that is easily handled by the error distribution. Even though, it incured a full 2 days headache when I had finished the first working prototype. The MG converter was derived mostly from the VFLI converter, without that preparation I couldn't have implemented the MG converter at all.

...

So much for even more boring tech-talk, but now you know why I refrained from starting out writing a converter for the FCB mode in the first place.
Post Reply