AuthorTopic: Commodore VIC-20 Pixel Art Guide.  (Read 17540 times)

Offline BladeJunker

  • 0001
  • *
  • Posts: 84
  • Karma: +0/-0
  • Know your limits, then break them.
    • View Profile

Commodore VIC-20 Pixel Art Guide.

on: April 18, 2012, 11:04:08 pm
I already have my hands full with 3 guides to craft & maintain so I was wondering if anyone had tackled the VIC-20 for a restriction guide? I've found some information on how it operates, another unique specimen that lies somewhere in between other systems in terms of graphics and performance. I'd be willing to give it a go eventually if no one has seen one. :)

Slim pickings for pixel art examples but here is what I found.
ptoing

http://www.pixeljoint.com/pixelart/18563.htm

saehn

http://www.pixeljoint.com/pixelart/47201.htm

Lackey

http://www.pixeljoint.com/pixelart/24958.htm

saehn

http://www.pixeljoint.com/pixelart/47200.htm
« Last Edit: May 21, 2012, 06:28:34 pm by BladeJunker »

Offline BladeJunker

  • 0001
  • *
  • Posts: 84
  • Karma: +0/-0
  • Know your limits, then break them.
    • View Profile

Re: Commodore VIC-20 Pixel Art Guide.

Reply #1 on: April 26, 2012, 12:08:46 am
Alright the VIC-20 was the precursor to the C64 which was both affordable for the time and had Captain Kirk AKA William Shatner as their spokesman. Has a single DE-9 game controller port so all Commodore, Genesis/Megadrive, Master System, and Atari controllers will work with it but only one button unmodified.

Okay so there are 2 lines in the Joystick port normally used by paddles which can be utilized as button lines for a custom controller. So a 3 button controller for one player is possible, I'm going to mod a Genesis/Mega Drive controller for this purpose. I can't use the Start button but maybe I could use it for a mode switch or a Turbo setting depending on the level of circuit alteration. :-\

Mike72 informs me there are 8 available I/Os supported through the User port which would allow for the following custom made gamepad options.
-D-pad+4 action buttons for 1 player.(Genesis/Mega Drive would be a good choice.)
-L&R+2 action buttons for 2 players.(Platforming.)

*Unfortunately paddles won't work through the I/O port so 2 paddles maximum through the DE-9 joystick port, darn. :(

I'd say in general the easiest approach would be to give Player1 the joystick and Player2 the keyboard with Space as Fire most likely. Also you could have both players share the keyboard but you'll have to keep it simple since its not very wide. ;)

*While one button will work with a variety of 9-pin controllers it will require an internal modification of the controllers circuits to get the maximum.
http://sleepingelephant.com/ipw-web/bulletin/bb/viewtopic.php?t=3312

The VIC-20 is similar to the C64 being from the same company Commodore so it has many of the same features of the C64 but lower in pixel and color resolution by a fair amount.

System Color Palette:
A big thanks to Mike72 and everybody at the Denial forum for taking the time to make an RGB equivalent of the displayed colors seen on actual VIC-20s.
NTSC


PAL

As you can see it differs per region to a high enough degree that you'll have to palette swap and adjust your art to reflect these differences. Depending on the results of a palette swap its possible actual alteration of the pixels will be necessary in some cases for the best results.

Okay I actually sat down and tried to figure this out, this is better since I don't speak "Stereo Instruction".  Honestly how does one take something so simple and complicate it with a lot of extraneous words. :)

In multicolor mode each character cell (4X16) can have 4 colors. Maximum of 10 on screen colors total.
1:One background color used by all sprites, any color from the palette.
2:One fixed color used in every single sprite, any color from the palette.
3:The Overscan border color, any of the first 8 colors(0-7).
4:And one free color per sprite, any of the first 8 colors(0-7).

In high-res mode each character cell (8X16) can have 2 colors. Maximum of 8 on screen colors total.
1:One background color used by all sprites and entire screen, any of the first 8 colors(0-7).
2:And one free color per sprite, any of the first 8 colors(0-7).

Screen Resolution:I know the shape is weird but I work at correcting that further down. You can always use this as is and resample it to 800X600 to see what the final result will likely look like on an old CRT. :)

NTSC

First we have the NTSC standard which is 208X232 at 26X29 8 by 8 pixel characters but by default only 176X84 or 22X23 8 by 8 pixel characters is actually used most of the time. This option only works as a terminal or ANSI mode with custom graphics requiring its own set of screen restrictions, I only mention it as it has the highest potential for actually using the border character space since its RAM needs are so low.
PAL

And then we have the PAL standard which is 232X280 at 29x65 8 by 8 pixel characters with a default of 22X23 of actual screen space used most of the time.

Speaking of ANSI mode it has the highest potential for color output from a raster line standpoint as any available system RAM can aid the CPU in producing software based effects.

NTSC


PAL


This is based on a color test program I came across on the Denial VIC-20 forum by a guy named Mike used to test his S-video mod. Even though this example shows all possible combinations there are fewer graphics rendering setups where this will actually occur, instead the default standard of one shared background color is much more common to game rendering. Still despite the technical restrictions its nice to see how well each color mixes with others.
http://sleepingelephant.com/ipw-web/bulletin/bb/viewtopic.php?t=5164


Here's the built in character set for ANSI/ASCII/based game constructs. While Text mode is visually limited I've seen some interesting games come out in this format EG. Dwarf Fortress. ;D

While the VIC doesn't have a default Bitmap mode like the C64 you can make 5K full VRAM bitmaps but you're limited to 256 tiles total which have to be 8X16 character blocks to fill the screen height which works out to 22X11 or 242 tiles. The use of 8X16 characters is optional but without it under this standard the game screen will only be 88 pixels tall IE. 8X11.

However Mike72 informs me the 256 tile limit was broken by him & Torsten Kracke as of 2010 through a dynamic bitmap update technique so that's good news, best to read his excellent addition to this posting about the many, many screen modes and resolutions possible on the VIC-20. :)

8X16 character mode is split between 2 color resolutions of 8 by 16 pixels at 2 colors as in foreground & background or the Multicolor option of 4 by 16 pixels at 4 colors but one is always the background color so 3 in reality much like a Nes sprite. The lowres 4x16 character is roughly quadruple pixel width compared to a highres 8X16 character which is close to double wide pixels not unlike the C64 but only one color.

Much like the C64 both hires and lowres characters can be on the same screen but there specific color limits still apply, this is good for text versus game sprite resolution requirements.

NTSC(8X16 characters.):

PAL:



Sprites?
The VIC-20 doesn't support Sprites so by default characters jump 8 pixels at a time but coding will allow for a proper smooth panning sprite, unfortunately as a result I can't really specify a sprites per scanline limit. The best I can do is suggest that you only use the minimum number of sprites required for your game and try to keep as much set in the tile grid as you can.

Mike72 says its entirely possible to get a true sprite mask instead of the attribute clash I was seeing in Which Way and other early VIC games. So that's great news since that was one of things I didn't like to deal with.

Scrolling?
This is another feature that is possible but its software based so you'd need programmer backing to even formulate the kinds of restrictions that will be put on your graphics design as it will vary based on the particular code base.

Performance?
It varies between stock unexpanded systems and those with RAM cartridges that expand system memory further, I got one 3K and a bunch of 8Ks. The use of RAM carts does occupy the only slot so game programs either have to be on cassette or load from another external drive, also there is the VC 1020 Extension Box which gives you more cart slots for use.
Actually the PAL( 1.108404 MHz )models have a different CPU than the NTSC ( 1.02 MHz ) which is a little bit faster but it also uses more character space so it kind of balances out on average.

Here's the Wiki page of the system which has pictures of the VIC-20 accessories near the bottom of the page you can click on to get a better look.
http://en.wikipedia.org/wiki/Commodore_VIC-20

I have a VC 1020 Extension Box and it is quite heavy & bulky so here's a lighter option.


And another lighter option for multiple carts.



While the VIC-20 can only hold and display a set number of character graphics at one time it is flexible in terms of game screen shape since you can concentrate them vertically and make a pillar shaped screen as in this example game Vicolumn. The author of this game said he also managed to reduce the play area to a single 256 byte page freeing a little extra screen RAM for use. Conversely you could letterbox the default size and fill the sides in more also.

Here's some more examples, sorry some are JPG but what are you going to do?:










Here's a recent homebrew called BlueStar.



In my research VIC-20 screenshots varied wildly as different sources and emulators spat out different image resolution and I'm sure the NTSC & PAL difference was not helping things either. After getting the actual native resolutions I had to stretch it without distorting the pixel units for the best possible approximation of the real thing.

I settled on a 3:2 pixel unit for NTSC which made for moderately large canvas sizes but was as close to the actual 4:3 display result as I could get. I included multiple canvas options as not all paint programs are fully featured enough to allow composition at analog stretched standards.

For PAL 5:3 pixel units is the most accurate approximation which resulted in a larger canvas size after stretching that I decided to trim off the border to get it down to 800X576 or the standard supported in MINIPAINT which made the most sense being almost 4:3 and that the PAL stretch was elongating the pixel units more so anyway. Actually you could trim the border off the NTSC canvas as well, I just included it to be authentic and demonstrate the potential character space.

Just to confuse you more lol you can actually offset the X and Y in the register too, so the VIC-20 has lots of screen altering options to say the least. :lol: I actually got to see this first hand in Garden Wars as they use it to shake the screen about to simulate an earthquake or explosion effect.

NTSC & PAL differ enough after analog screen stretching that the graphics will differ based on region standards. Overall I'd say PAL is slightly shorter and smaller too on the actual screen since it has more border space included than NTSC.

Canvas stretch:

NTSC ANSI mode.


PAL ANSI mode.



NTSC 8X16 mode.


PAL 8X16 mode.


Observations(Multicolor mode):
*These examples are just tests of color combinations and resolution, I have used proper colors allowed but haven't accounted for shared colors for the screen as a whole. They can work individually but not on screen at one time mostly jsyk. This is just a splash page of doodles, in the event of an actual game mockup or art piece there would be fewer colors total using a single set palette.

I really liked this Viking warrior by Laje which I should credit along with ptoing's edits which I used for this shading & color test sprite, cool stuff check it out.
http://www.wayofthepixel.net/pixelation/index.php?topic=14047.0


-I'm thinking Black & White could be the go to colors for the colors shared by all sprites.
-I tend to lean on Nes standards with color choice as in trying to highlight and shadow elegantly with the 3 colors allowed.
-Total palette homogeneity is certainly challenging given that the colors aren't well balanced to each other but stronger color groups reveal themselves quite quickly with so few colors making your options apparent.
-The highest potential for shading will be very monochromatic, even more so than C64 or the Nes.
-It's hard to make game sprites in less than 8 pixels of width, more colors is nice but its difficult to inject personality into Multicolor sprites.
-Characters at realistic proportions come out kind of blank or anonymous like Castlevania sprites even though they are much larger than those.
-Outlines are hit & miss mostly, sometimes they work other times its too great a sacrifice in resolution to use them.
-If the 2 Cyans were darker they could have been like a grey to bridge & ramp but alas this isn't so.
-If your image scale is mostly large and can be integrated into a single layer(Postcard Slides) you can get some good pixel art done in multicolor mode but it takes at least 2X2 or 3X3 sprite blocks to get similar detail levels in game sprites.

Observations(High-res mode):

-High-res is very limited in colors but the resolution per sprite is more compatible with the average game sprite size most people are comfortable with and the VIC-20's ability to move them given that sprites are software based. Wasn't much I could do to increase the High-res sprite color count besides using sprite block seams to get a unique color per block, I think layering isn't possible since I haven't found any examples thus far.
-Despite Black being an easy universal background color to work with I gave Green a go. The best I could do with terrain transitions was to switch to "hole sprites" letting the Green color the object while the actual opaque pixels define the terrain color.
Although basic terrain transitions can be handled this way I think I'd like to switch Background color for areas with greater dominance of terrain type EG. climb a snowy mountain it switches to Cyan for rock and then White for snow the higher you go. Easy to achieve with Page Flipping from screen to screen but in a scrolling engine I'd have to define terrain as gross quad zones to define when the background color should switch over.
-At 1 color per sprite block dithering was the only option to get shading in. While game sprites are served better with deep shadows that outline the form, the low resolution of the screen as a whole confines most dither work to moderately large sprites like the level construction tiles.
-Despite the additional ending tile I think "tiling outline completion" is the way to go with such low resolution which is especially true with dithering, it just looks more organic with a centering pixel instead of a blunt flop.
-I definitely want to use High-res zones in any VIC-20 pixel work for text despite the drop in color resolution since the screen confines don't leave much room for text. Probably a mixture of 2 scales of font with the larger being Multi-color as in topic:Multi-color & bulk info:High-res. I recommend using 2 scales of font regardless of the game system you're working on as one scale of text looks very antiquated in a bad way, the same can be said about a lack of uppercase characters.

The best examples of pixel art that plays to the VIC-20s strengths in High-res mode were on ZX Spectrum or to be more specific those that used Black as the background color and all other system mode compliant colors as sprite block colors. Although the ZX Spectrum can use 2 independent colors per block and the VIC can't without a software based solution I did find examples of single color background use on the Spectrum. Much like the C64 any VIC relevant software based screen modes are less reliable in practice that they work better for art slides rather than game graphics which have sprites, scrolling, and other demands.




White or Cyan works well too as a background color. ;)



Grid Scale/Proportion:

I would definitely say the multicolor mode is a hard resolution to work with in terms of sprite to sprite scale and detail level but I definitely like more colors per character. The biggest thing that is bugging me is the height compression in the tiles, just looks wrong to me despite being normal.
Definitely with outlines at such low resolution its better to use "tiling outline completion" even if it requires an ending tile, it just works better in regards to center based details like letters or icons so they actually end up looking decent. Also I 'm having doubts on how prudent it is to include vertical outlines, perhaps its better to have them only run horizontally since there is not very much resolution per block.

I tried equalizing the tile height to the width, this below is NTSC specific as PAL requires a different amount of extra added height.

Equalizing Grid Scale, 16X16-ish:

Here I tried for equal height to width which worked out the 3 tiles vertically for every 2 tiles visually speaking. This dropped things from 11 tiles tall down to 7.5, stuck to power of 2 height adjustments to reduce the amount of tile inefficiency this creates.

Equalizing Grid Scale, 12X12-ish:

This worked out to 3 by 6 tiles for every 2 by 5 tiles visually speaking. Not nearly as nice in regards to the actual gridded division of character blocks. I think if I used this the fake grid would be used for overall scale structuring but it would be hard to create an efficient tile set like this so adventure style backdrops rather than linear level construction from the usual perspectives.

Equalizing Grid Scale, 8X8-ish:

For every 3 tiles tall you get 4 tiles visually speaking. Not as bad as the middle scale but it still creates tile set inefficiency and space waste. You can see here I tried skipping some lines for vertical lines since it was starting to look dense and color dominant at this small tile scale, don't know how good it looks. :-\
« Last Edit: June 09, 2012, 01:48:19 am by BladeJunker »

Offline Mike72

  • 0001
  • *
  • Posts: 6
  • Karma: +0/-0
    • View Profile

Re: Commodore VIC-20 Pixel Art Guide.

Reply #2 on: May 14, 2012, 10:15:38 pm
Hi, BladeJunker,

Quote from: BladeJunker
Speaking of ANSI mode it doesn't appear to have any color restrictions as all colors can be displayed at once.

This is based on a color test program I came across on the Denial VIC-20 forum a guy named Mike made to test his S-video mod. Despite that not all combinations are supported in the 2 graphic modes you can see the ones that do in this chart.
http://sleepingelephant.com/ipw-web/bulletin/bb/viewtopic.php?t=5164

I wrote this program, so I thought I'd should comment on this a bit:

Regardless whether the VIC chip fetches pixel data from the built-in character ROM, or from user defined graphics in RAM, there's - in principle - only one background colour. The display is tiled in 8x8 or 8x16 'attribute cells' which can have one of 8 different foreground colours, and can be switched between high-res and multi-colour mode. The latter mode combines two bits horizontally to twice-wide pixels in either background (%00), exterior border (%01), foreground (%10) or auxiliary colour (%11) to form 4x8 or 4x16 pixel tiles. The exterior border colour can be chosen from the first 8 colours (like the foreground colour), while for the auxiliary colour all 16 colours are available (like for the background colour).

For the test program above, the different background colours in each line were achieved by changing the background register with the raster beam. This can be done by polling the raster line counter register and/or synchronizing a timer to the VIC chip. Thus, this is a software-assisted 'mode', even if it only displays pixel data from the character ROM.

Another restriction of the VIC chip is, that it only can access the character ROM, and the built-in RAM (5K)! 1K of the RAM is used for the system. In search for a bitmapped graphics mode, which does not use that 1K system area (but rather contents itself with the remaining other 4K RAM), and which also does not use interrupts, I came up with a 160x192 resolution. That one is built from 20x12 attribute cell tiles, each with 8x16 (high-res) or 4x16 (multi-colour) pixels, each one again with a different foreground colour. Background, exterior border and auxiliary colour are global.

I wrote a pixel-oriented editor for this resolution, MINIPAINT, which I published in 2009 on Denial VIC-20. It is hosted on the VIC-20 itself (runs fine under VICE) and produces picture files, that are actually executable programs. Furthermore, it is backed up by a BASIC extension, so the pictures can easily be loaded and used (and even changed!) in own programs. Saehn pixeled the title screen of 'Realms of Quest 3' with MINIPAINT.

With interrupts, cycle exact coding and the CPU shuffling bitmap data around in RAM the restrictions mentioned above can be lifted A LOT (say, 208x256 pixels resolution and/or 8x1 or 4x1 attribute cells), but these enhancements come at the expense of nearly monopolising the CPU to assist the VIC chip for display, so their use is limited to still images.

Greetings,

Michael

P.S.: This is my first post on wayofthepixel.net, so please bear with me. :)

Offline BladeJunker

  • 0001
  • *
  • Posts: 84
  • Karma: +0/-0
  • Know your limits, then break them.
    • View Profile

Re: Commodore VIC-20 Pixel Art Guide.

Reply #3 on: May 15, 2012, 12:08:25 am
Hi, BladeJunker,

Quote from: BladeJunker
Speaking of ANSI mode it doesn't appear to have any color restrictions as all colors can be displayed at once.

This is based on a color test program I came across on the Denial VIC-20 forum a guy named Mike made to test his S-video mod. Despite that not all combinations are supported in the 2 graphic modes you can see the ones that do in this chart.
http://sleepingelephant.com/ipw-web/bulletin/bb/viewtopic.php?t=5164

I wrote this program, so I thought I'd should comment on this a bit:

Regardless whether the VIC chip fetches pixel data from the built-in character ROM, or from user defined graphics in RAM, there's - in principle - only one background colour. The display is tiled in 8x8 or 8x16 'attribute cells' which can have one of 8 different foreground colours, and can be switched between high-res and multi-colour mode. The latter mode combines two bits horizontally to twice-wide pixels in either background (%00), exterior border (%01), foreground (%10) or auxiliary colour (%11) to form 4x8 or 4x16 pixel tiles. The exterior border colour can be chosen from the first 8 colours (like the foreground colour), while for the auxiliary colour all 16 colours are available (like for the background colour).

For the test program above, the different background colours in each line were achieved by changing the background register with the raster beam. This can be done by polling the raster line counter register and/or synchronizing a timer to the VIC chip. Thus, this is a software-assisted 'mode', even if it only displays pixel data from the character ROM.

Another restriction of the VIC chip is, that it only can access the character ROM, and the built-in RAM (5K)! 1K of the RAM is used for the system. In search for a bitmapped graphics mode, which does not use that 1K system area (but rather contents itself with the remaining other 4K RAM), and which also does not use interrupts, I came up with a 160x192 resolution. That one is built from 20x12 attribute cell tiles, each with 8x16 (high-res) or 4x16 (multi-colour) pixels, each one again with a different foreground colour. Background, exterior border and auxiliary colour are global.

I wrote a pixel-oriented editor for this resolution, MINIPAINT, which I published in 2009 on Denial VIC-20. It is hosted on the VIC-20 itself (runs fine under VICE) and produces picture files, that are actually executable programs. Furthermore, it is backed up by a BASIC extension, so the pictures can easily be loaded and used (and even changed!) in own programs. Saehn pixeled the title screen of 'Realms of Quest 3' with MINIPAINT.

With interrupts, cycle exact coding and the CPU shuffling bitmap data around in RAM the restrictions mentioned above can be lifted A LOT (say, 208x256 pixels resolution and/or 8x1 or 4x1 attribute cells), but these enhancements come at the expense of nearly monopolising the CPU to assist the VIC chip for display, so their use is limited to still images.

Greetings,

Michael

P.S.: This is my first post on wayofthepixel.net, so please bear with me. :)

First thanks so much for dropping by as I am not a technically oriented person so it is always great when someone with real expertise can comment, I try my best but these retro machines are hard to figure out. ;D

I see what you're saying about your program, I should have noticed the use of varying background color per line so I'll make that correction and clarify how this is actually displayed.

Its a shame I'm not knowledgeable enough to describe the performance levels of the VIC-20 as I've only been able to explain the basics while the expansion with RAM carts is a grey area as far as my understanding. Other than more RAM equals more stuff you can do that's all I can say on the matter. :lol:
I've only mentioned the room for expanding graphics in a minor way so far but I'll emphasize the CPU costs more and the context of still imagery as opposed to game graphics too.

MINIPAINT looks cool and I can't wait to try it out. Neat to hear Saehn has used it since it was hard to find much VIC-20 pixel art reference from a post modern perspective, the C64 and Nes have received much in the way of artistic technique improvement over these many years past there "suggested" lifespan but the VIC to a far lesser extent.
I'm enjoying my journey into the VIC graphics standard quite a bit compared to the Atari 2600 which is a really hard system to tackle from an art standpoint but I keep trying.

Thanks again for your input as your my first response on the matter. The VIC-20 is about as old as I am so I'm a late collector of it but it interested me a great deal being the precursor of the C64. I'm not too sure about the average age of Pixelation members as I think most of them grew up on Nes/Snes/C64/ZX Spectrum wares but I know they like a good challenge so I thought the VIC would be a good subject for a pixel art restriction guide.

Do you think the 3:2 pixel unit is a fairly accurate representation of a VIC-20 display, it was as close as I could get for a hardware external concept canvas?

Greetings to you as well. :)

Offline Mike72

  • 0001
  • *
  • Posts: 6
  • Karma: +0/-0
    • View Profile

Re: Commodore VIC-20 Pixel Art Guide.

Reply #4 on: May 15, 2012, 07:54:55 pm
Quote from: BladeJunker
Do you think the 3:2 pixel unit is a fairly accurate representation of a VIC-20 display, it was as close as I could get for a hardware external concept canvas?
It's about right for NTSC. On a PAL VIC-20, the pixels are slightly more elongated, 5:3 was the best approximation I could find as ratio of small integers. The 'standard' setting of VICE, 2:1, is totally off.

One other point about the palette in your mock-up of the Colour Test program: Light Red is too dark, it should have a similar brightness as its upper neighbour, Light Orange. On an NTSC VIC-20, Light Orange, Light Red and Light Purple are quite difficult to tell from each other, on a PAL VIC-20 they are easier differentiated.

These are two exemplary palettes we came up with after a longer discussion in Denial:

-- NTSC (darkatx's VIC-20) ------- PAL (tokra's VC-20) ----


I used digital camera shots from CRTs with the VIC-20 running the Colour Test program. Then I took the averages of all RGB values of the bigger colour patches in the middle of the display, and finally stretched the result for maximum contrast. In both cases, only little to no clipping of RGB values occured in the end result - the saturation setting of the monitor/camera combination was just about right.

Of course, the viewers output device will also lead to a different result again, but that's the way it is. ;)

Offline BladeJunker

  • 0001
  • *
  • Posts: 84
  • Karma: +0/-0
  • Know your limits, then break them.
    • View Profile

Re: Commodore VIC-20 Pixel Art Guide.

Reply #5 on: May 15, 2012, 11:12:55 pm
Quote from: BladeJunker
Do you think the 3:2 pixel unit is a fairly accurate representation of a VIC-20 display, it was as close as I could get for a hardware external concept canvas?
It's about right for NTSC. On a PAL VIC-20, the pixels are slightly more elongated, 5:3 was the best approximation I could find as ratio of small integers. The 'standard' setting of VICE, 2:1, is totally off.
That's what I thought too that 2:1 was just not reflecting what I was seeing on an actual VIC-20. I'll make some adjustments to my PAL canvases to 5:3, I'm not in a PAL region so I couldn't even guess at shape accuracy, although at AtariAge one helpful person did mention a shorter pixel height and another mentioned the Denial forum as the best place to ask.

Quote
One other point about the palette in your mock-up of the Colour Test program: Light Red is too dark, it should have a similar brightness as its upper neighbour, Light Orange. On an NTSC VIC-20, Light Orange, Light Red and Light Purple are quite difficult to tell from each other, on a PAL VIC-20 they are easier differentiated.

These are two exemplary palettes we came up with after a longer discussion in Denial:

-- NTSC (darkatx's VIC-20) ------- PAL (tokra's VC-20) ----


I used digital camera shots from CRTs with the VIC-20 running the Colour Test program. Then I took the averages of all RGB values of the bigger colour patches in the middle of the display, and finally stretched the result for maximum contrast. In both cases, only little to no clipping of RGB values occured in the end result - the saturation setting of the monitor/camera combination was just about right.

Of course, the viewers output device will also lead to a different result again, but that's the way it is. ;)
Yeah I have not been happy with the color palette I found through Wikipedia at all, so thank you for this post of colors that are much, much closer to the real thing. Been meaning to sign up with Denial and ask around but I've been catch up with other things. Perhaps the Wiki source tried to average the 2 palettes out to one inaccurate result?  :-\

Looks like PAL users got the better color palette, nicer saturation and separation of colors. This reminds me of 2600 PAL to NTSC color differences as this will require color conversion for graphics as a simple swap won't cut it for most graphics. Damn I really like the PAL version, I keep gravitating towards it and want to use it despite being in a NTSC region. :lol:

Oh sure the display used will effect the look of the colors and any settings it offers but this palette is much closer and is exactly what I was looking for.

Thanks again for your input as I want to get this guide as accurate as possible.  Well I guess I'll get started making adjustments. :)

Offline Helm

  • Moderator
  • 0110
  • *
  • Posts: 5159
  • Karma: +0/-0
    • View Profile
    • Asides-Bsides

Re: Commodore VIC-20 Pixel Art Guide.

Reply #6 on: May 16, 2012, 08:37:23 am
Thank you for all the technical knowledge!

These two palettes are very very different, though. Hasn't there been a consensus on which one is closer? I am asking because the c64 is also notoriously difficult to get the exact palette values from, but they eventually sorta kinda almost did it if I remember correctly. Is the VIC-20 only perceptually tested on this issue? Can't the guts of the system give exact values somewhere?

Offline Mike72

  • 0001
  • *
  • Posts: 6
  • Karma: +0/-0
    • View Profile

Re: Commodore VIC-20 Pixel Art Guide.

Reply #7 on: May 17, 2012, 07:14:34 pm
Quote from: Helm
These two palettes are very very different, though. Hasn't there been a consensus on which one is closer?
The palette in the Wikipedia article as from May 17, 2012 is definitely wrong. For me, it looks more like a copy of the C64 palette; with the greys replaced by the light versions of yellow, cyan and purple. Furthermore the outputs of a PAL and NTSC VIC-20 are different, this had been confirmed by a Denial member, who imported a NTSC VIC-20 to Germany and tested it against his PAL VIC-20 with a beamer that accepted both TV norms.

Quote
I am asking because the c64 is also notoriously difficult to get the exact palette values from, but they eventually sorta kinda almost did it if I remember correctly. Is the VIC-20 only perceptually tested on this issue? Can't the guts of the system give exact values somewhere?
The VIC chip outputs Chroma and Luma, not a RGB signal per se. Which colours are generated from these two signals is at the discretion of the receiving device in any case. Using a frame grabber instead of a CRT/digital camera combination would eliminate one unknown, but still something has to convert LC to RGB.

I know about Pepto's elaboration, but I'm not entirely convinced. For me, the middle-intensities in the Pepto palette appear too dark, and Brown has a greenish tint I couldn't observe on any combination of C64/C128 and CRT I had used.

...

@BladeJunker: Today, I pixeled your concept canvas of the SMB3 mockup (including all test tiles ;)) into MINIPAINT. Some elements had to be re-arranged horizontally (160 pixels horizontal resolution in MP instead of 176 pixels in the concept canvas). It took me roughly 2 hours:


(download)
« Last Edit: August 11, 2012, 07:18:03 pm by Mike72 »

Offline BladeJunker

  • 0001
  • *
  • Posts: 84
  • Karma: +0/-0
  • Know your limits, then break them.
    • View Profile

Re: Commodore VIC-20 Pixel Art Guide.

Reply #8 on: May 17, 2012, 08:51:34 pm

@BladeJunker: Today, I pixeled your concept canvas of the SMW3 mockup (including all test tiles ;)) into MINIPAINT. Some elements had to be re-arranged horizontally (160 pixels horizontal resolution in MP instead of 176 pixels in the concept canvas). It took me roughly 2 hours:


(download)
Very cool and authentic to the original. :lol: Yeah I get lazy and leave a lot of construction and guide lines all over the place. Using the updated colors has been challenging but I'm finding some good compromises. I'm familiar with sprite color limits but I've never worked under a shared color limit however its interesting in the results I get.

I tried MINIPAINT through Vice since I don't have means to transfer the program onto my VIC yet. Under your download page do you think you could add a Help text file with the controls listed as I'm kind of poking keys to find functions and I want to load the PRG file but I don't know how?

I guess there isn't a mouse for the VIC as far as what I read here? I have done joystick drawing on my C64 so its not completely foreign to me. :)
http://sleepingelephant.com/ipw-web/bulletin/bb/viewtopic.php?t=4626&sid=87ecec713b47d3affcb4e1dc40454d56

Offline Mike72

  • 0001
  • *
  • Posts: 6
  • Karma: +0/-0
    • View Profile

Re: Commodore VIC-20 Pixel Art Guide.

Reply #9 on: May 17, 2012, 09:27:55 pm
Quote from: BladeJunker
I tried MINIPAINT through Vice since I don't have means to transfer the program onto my VIC yet. Under your download page do you think you could add a Help text file with the controls listed as I'm kind of poking keys to find functions and I want to load the PRG file but I don't know how?
There's even a manual as zipped *.pdf available for download. Besides, MINIPAINT features on-board help - just press '?' in the editor (on the VIC-20 itself or VICE with an English keyboard, that would be Shift + '/'). :)

To load the picture with MINIPAINT running in VICE, you have to 'mount' the surrounding directory as VDrive. You'd proceed as follows:

- Under Options, tick off True drive emulation,
- In Settings > Peripheral settings ... > Drive 8, select Directory,
- tick off both Read/Write P00 files (these only serve trouble),
- browse to the directory containing the *.prg file,
- confirm by pressing 'OK'.

In the editor, Left-Ctrl + '4' (that would be C=-4 on the VIC-20) shows the directory. The mounted directory should now display, with 'smw3.prg' having 17 blocks. Press SPACE to continue. Shift + 'L' opens the file name requester. Type in the file name, press Return/Enter and there you go. ;D

Quote
I guess there isn't a mouse for the VIC as far as what I read here? I have done joystick drawing on my C64 so its not completely foreign to me. :)
Sadly the 1351 mouse doesn't work on the VIC-20 due to hardware reasons.
« Last Edit: August 11, 2012, 07:19:14 pm by Mike72 »