Graphic/Picture File Formats on VIC-20

[a1bert]

I've had all sorts of fun manipulating the starting image before conversion to ensure that I get the aspect ratio correct at the size the VIC can handle.

In VIC one multicolor pixel is about the same width as three scanlines. victoppm uses this aspect ratio, one multicolor pixel becomes 3 pixels wide in the output picture. In hires its alternating 2 and 1 pixels (horizontal) for each VIC pixel, because we don't have half pixels. (Well, it could double-scan the lines to get 1.5x2 = 3..)

This is the same as above but with the contrast increased using ppmtovic by 25%. I think this result is better.

Yes, this is generally true for multicolor also. You have to tune the luminance to the point that the interesting details become visible, and also stretch the contrast to get both black and white (if you can). A so-called dynamic range operation could in most cases do this automatically.

Pasi, I'll setup a web page to put all the pictures on so you can link to it

I would appreciate it.

It may be my imagination, but grayscale seems to work better with hires than my tests.

I have also experimented with an improved hires mode a bit and could get satisfactory three colors, although you need to fine-tune the conversion a lot, and the result can still have some blocky bits. The color selection algorithm should be totally rewritten. The one that works well for multicolor can not be simply modified to work optimally for hires.

-Pasi

[ral-clan]

I'm really impressed with the quality of these images. If any VIC games had implemented that back in the 80s, people would have flipped!

[saundby]

I'm really impressed with the quality of these images. If any VIC games had implemented that back in the 80s, people would have flipped!

I was thinking pretty much the same thing. Even if they'd just been used with fades in a sort of cutscene, I think it would really have knocked people's socks off.

-Mark G.

[PaulQ]

I think if the Vic had shipped with twice as much memory as it did, we would've seen a lot more stuff like this in games and whatnot, and the Vic would've been just as big a success as the C-64.

[hawk]

It may be my imagination, but grayscale seems to work better with hires than my tests.

I tend to agree. The detail seems to come out more.

I would still like to try converting a grey scale image to multicolour, using only shades of the same hue. I've seen this technique commonly used on 8-bit Ataris which only have 4 colour character mode, but they do have many more shades to choose from.

I was thinking pretty much the same thing. Even if they'd just been used with fades in a sort of cutscene, I think it would really have knocked people's socks off.

-Mark G.

That was the sort of thing I was thinking of using them for, some sort of story based game. Most users have access to more RAM these days, and if not, there's always emulation.

-Mike

[carlsson]

While VIMMII runs a picture slideshow on unexpanded VIC, memory expansion really is preferred if you want to fit some gameplay and other code as well as just displaying flashy images. Me and Pasi know how tight memory use was in VIMMII. Did we in the end even have 100 bytes left of all 5K RAM?

[a1bert]

Did we in the end even have 100 bytes left of all 5K RAM?

Slightly less bytes

I calculated about 16 bytes and 288 nybbles free. And remember that this is a simplified version of the vicpic with 16-line color memory resolution.

; 0000-0172 space for music ; ZP = $00 used for display code!
; 0180-01e1 main loop
; 01e2-01ff stack space (30 bytes)
; 0200-02f9 Video matrix
; 02fa-0313 file names
; 0314-0319 IRQ vectors -- Reserved
; 031a-03e3 [loader, do not overwrite]
; 03e8-03fe code
; 0400-0fff --open area--
; 1000-1fa0 graphics
; 1fa0-2000 display code

; 9401-94a0 Background colors (nybbles)
; 9501-95a0 Border colors (nybbles)
; 9600-96ff Color memory (nybbles)
; 9701-97a0 Auxiliary colors (nybbles)


The credits part of VIMMII is almost as tight. but because it is the last part, it can overwrite the loader code..

-Pasi

[ral-clan]

That was the sort of thing I was thinking of using them for, some sort of story based game. Most users have access to more RAM these days, and if not, there's always emulation.

-Mike

A text adventure in the vein of SHOGUN by Infocom or the later Amiga ones by Magnetic Scrolls could be done like this. Only, it doesn't really leave a lot of room for the VIC's large characters on the bottom half of the screen.

[hawk]

I don't know how you guys can fit so much into so little memory. I struggle to fit my ideas into the maximum amount of memory the VIC-20 can handle, and find myself trying to workout how to do bank switching to fit more in.

A text adventure in the vein of SHOGUN by Infocom or the later Amiga ones by Magnetic Scrolls could be done like this. Only, it doesn't really leave a lot of room for the VIC's large characters on the bottom half of the screen.

I've been thinking about the text problem. I was wondering about having a dynamic image size, where the size/proportions of the screen can be changed. This could allow the vertical space available for text to be increased. The screen size would still have to be changed in whole characters, within the limits of how many characters the video memory can handle.
I was also thinking about bitmapping characters on the fly over the top of the image. I'm not sure how fast this could be done. If bitmapped fonts were used then a non-standard size could be used like 5x7 which would fit more text on the screen, or even a proportional font, although I've never worked out how to do this efficiently.

-Mike

[ral-clan]

was also thinking about bitmapping characters on the fly over the top of the image. I'm not sure how fast this could be done. If bitmapped fonts were used then a non-standard size could be used like 5x7 which would fit more text on the screen, or even a proportional font, although I've never worked out how to do this efficiently.

The 80 column software emulators for the VIC-20 do something similar.

[a1bert]

I was wondering about having a dynamic image size, where the size/proportions of the screen can be changed.

Btw, VIMM and VIMMII sources have a couple ppm->font converter (ppmtofont and ppmtomcol) programs that can be used to convert 2- or 4-color ppm to packed character data (hires or multicolor). Both font memory and mapping (video matrix contents) are created. The result is packed, i.e. identical characters are eliminated, thus saving memory.

On top of that, no display code is required because the background+border/aux and color memory contents is fixed.

-Pasi

[a1bert]

I would still like to try converting a grey scale image to multicolour, using only shades of the same hue.

The new version is released. Victoppm now supports more than two colors in hires mode (although more than three is not expected to work very well). Like before.. http://www.iki.fi/a1bert/Dev/vicgfx/ .


-Pasi

[ral-clan]

Wow. I love the new multicolour Hi-Res mode. This program is improving in leaps and bounds!

[Mike]

The following C program converts a 80x192 *.pgm file to a multi-colour MINIGRAFIK bitmap, that uses ordered dither. I use IrfanView beforehand to first crop the image (Aspect width:height ~= 1.4), then to scale down the image (with resample/bell filter). The comment inside the PGM needs to be removed (any binary clean text-editor can do that).

The program assigns black to colour 1 (exterior border), and white to colour 2 (foreground). That means, for the two intermediate colours all 16 colours are available.

Greetings,

Michael

Code: Select all

/*
 *  Ordered Dither Multicolour VIC-20 Bitmap
 *
 *  Written 2007 by Michael Kircher
 */

#include <stdio.h>
#include <stdlib.h>

unsigned char pattern[4][13][2]=
{
  0,0, 0,0, 1,0, 1,1, 1,1, 1,1, 1,2, 2,2, 2,2, 2,2, 3,2, 3,3, 3,3,
  0,0, 0,1, 0,1, 0,1, 1,1, 2,1, 2,1, 2,1, 2,2, 2,3, 2,3, 2,3, 3,3,
  0,0, 0,0, 0,1, 1,1, 1,1, 1,1, 2,1, 2,2, 2,2, 2,2, 2,3, 3,3, 3,3,
  0,0, 1,0, 1,0, 1,0, 1,1, 1,2, 1,2, 1,2, 2,2, 3,2, 3,2, 3,2, 3,3
};

int main(void)
{
  int a,b,x,y,z;
  FILE *stream;
  char *header="P5\n80 192\n255\n";
  unsigned char bitmap[192][20];
  
  if(NULL == (stream=fopen("source.pgm","rb"))) exit(EXIT_FAILURE);
  while(0 != *header) if(*header++ != getc(stream)) exit(EXIT_FAILURE);

  for(y=0; y<192; y++)
    for(x=0; x<20; x++)
    {
      bitmap[y][x]=0;
      for(z=0; z<4; z++)
      {
        a=getc(stream);
        switch(pattern[y%4][(12*a+128)/255][z%2])
        {
          case 0: b=1; break; /* exterior border colour */
          case 1: b=3; break; /* auxiliary colour */
          case 2: b=0; break; /* background colour */
          case 3: b=2; break; /* foreground colour */
          default:     break;
        }
        bitmap[y][x] |= b << (6-2*z);
      }
    }
  fclose(stream);

  if(NULL == (stream=fopen("target.prg","wb"))) exit(EXIT_FAILURE);
  fprintf(stream,"%c%c",0,17);
  for(x=0; x<20; x++)
    for(y=0; y<192; y++)
      fputc(bitmap[y][x],stream);
  fclose(stream);

  exit(EXIT_SUCCESS);
}

This is the BASIC program, that loads the bitmap:

Code: Select all

1 POKE36879,16*9+8+0
2 POKE36878,16*8
3 POKE646,9:@ON:@CLR
4 POKE147,0:SYS57809"TARGET",8,1:POKE780,0:SYS65493
5 GETA$:IFA$=""THEN5
6 @RETURN

[viznut]

In case someone is interested, here's Brickshop: http://www.pelulamu.net/pwp/brickshop/

I was once thinking about the possibility of first doing a very chunky PC->Brickshop conversion for images and then finishing the pic on the real thing, but I then decided that it's be better to draw the picture completely on the VIC.