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=3312The 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.
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-20I 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.
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.
Show Posts
Phew that's a relief. 
