multicolor and hires graphics

[Thomas Hechelhammer]

Hi.

On the big brother of the vic20, the c64 we have many graphics-collections available and most in the common dimensions of 320x200 (hires) and 160x200 (multicolor).

Unfortunately, gfx on the vic20 can only be displayed with manipulated charsets; bit 3 in the color-RAM tells if multicolor (1) or hires (0); the colors are definded with bit 0-2 (8 colors).

Digging through vic20-demo-stuff I found an idea of a sort of FLI for the vic (Pu-239).
The resolution is 100x160 pixel.

The super-expander uses 176x184 (hires) and 88x184 (multicolor).

Mandelbrotmenge uses 160x192 (hires) and 80x192 (multicolor). (This is a program a friend of mine coded many years ago to calculate, save, load and display fractal graphics).

Confusing!

Why these comparisons and thoughts?

I have to write a small program in C or C++ which converts PCX-Graphics (16 colors) down to the VIC20.

And I'm still not sure which resolution I should use on the VIC.

I would prefer the original aspect-ratio of 320x200 pixel, but the pixels of the vic are somehow 'flat' and not exactly squared which gives us at 176x176 or 160x160 the impression of the correct aspect-ratio.

For an easy conversion I could use 160x100 / 80x100, but this is only a poor window.
(and makes fat pictures more fatter ).

Using 176x176 gives a nice picture on both PAL and NTSC machines but makes it difficult to reduce from 320x200.

Now, any suggestions for a 'common' graphics-format?

I'm sure there are lots of graphics around (super-expander) which we would like to have in a gfx-collection.
So I prefer this format, but first I would hear your ideas.

Any ideas, suggestions are welcome!

-- Thomas

[tlr]

Digging through vic20-demo-stuff I found an idea of a sort of FLI for the vic (Pu-239).
The resolution is 100x160 pixel.

I have to write a small program in C or C++ which converts PCX-Graphics (16 colors) down to the VIC20.

Why not use Pasi Ojalas converter?

I would prefer the original aspect-ratio of 320x200 pixel, but the pixels of the vic are somehow 'flat' and not exactly squared which gives us at 176x176 or 160x160 the impression of the correct aspect-ratio.

I think you'll have to handle resampling of the picture dimensions if you want the aspect ratio to be correct.

[carlsson]

Albert's (Pasi) converter generates the 100x160 picture. It means 25 columns * 10 rows = 250 characters. 25*4 = 100, 10*16 = 160.

It would be possible to use 20 columns * 12 rows to achieve 80x192 resolution. For the FLI effect to change colours on raster lines, I don't know if the number of rows is important, such as more screen height would take more raster time to maintain the screen.

I agree that 25 columns may be on the outer edge on a NTSC machine. Maybe 24 columns is max, which would give an effective resolution of 96x160.

[Thomas Hechelhammer]

Why not use Pasi Ojalas converter?

I'll have to code my own thing, it's a work for my office because I want to move from the inner service to the development and have to prove that I can write code (structured C++ prefered) by my own.
And I'll have to explain it.

In this program I extract the bitplanes to characters in a 512-character-field and have to arrange them in a string. The same I have to do with the colors, background, foreground and auxilary-color (only one because I don't use any FLI-Modes).


But I have another topic in mind: It seems there exists no standard for displaying graphics on the VIC.

So it's more important for me what other people think which dimensions pictures on the vic20 should have.

-- Thomas

[carlsson]

The resolution most resembling text mode would be 176x176, as you already suggested.

I suggest 160x192 (80x192 multicolour, 20x24 characters), as it will give an image resolution of 1.40:1, the closest you get to 4:3. It is based on that each pixel is about 0.60:1, or 1.67 y-pixel per x-pixel. 160/(192/1.67) = 4/3 = 1.39.

POKE 36866,128+20:POKE 36867,48 to test how it feels.
POKE 36866,128+22:POKE 36867,46 to compare with normal.

[CurtisP]

I'm going to suggest one other thing.

Since the Vic uses redefined characters to display hi-res graphics and in order to get a full screen worth of graphics you need to use double size characters, I think it best to format the screen as as bytes running top to bottom then right to left...

Code: Select all

 0  20
 1  21
 .   .
 .   .
 .   .
19  39 etc.

[Mike]

@CurtisP:

Of course we don't want to re-create the, uhm rather interesting, addressing scheme of the C=64.

@Thomas:

I'd vote for 160x192, too. It makes optimal use of the memory between 4096 and 8191, and it doesn't clobber the bottom 1K. I employ this mode for my program VIC Life.

Michael

[martin_f]

I think it best to format the screen as as bytes running top to bottom then right to left...

Hey curtis, forgive my ignorance but is there any advantage to going top to bottom, then left to right, over left to right, then top to bottom.

I am using user defined gfx, for a bitmapped display on my current project at home. To be honest I didn't even think about which way to set the characters. For some reason I just automatically went with left to right, then top to bottom.

I would be keen to know any pluses of the other way.

Does the C64 have a true bitmapped display, or does it also have to use user defined gfx like the VIC ? Just curious on that one.

Martin

[Mike]

I didn't see that CurtisP suggested top to bottom, then right to left, but ... at first the array DIM B(7) shall contain B(0)=128, B(1)=64, ... , B(7)=1 ... then, if you put the characters left to right, and then top to bottom you'll get this address-scheme (assuming double-height chars 20x12):

Code: Select all

   0|  16|  24|
   1|  17|  25|
....|....|....|  ....
  15|  31|  47|
-----------------------
 320| 336|
 321| 337|
....|....|   ....
 335| 351|

To address a single point in (X,Y) you'll need:

Code: Select all

AD=base+INT(Y/16)*320+INT(X/8)*16+(YAND15):POKEAD,PEEK(AD)ORB(XAND7)

... contrary, if you put the characters first top to bottom, then left to right, you'll get:

Code: Select all

   0| 192
   1| 193
....|....
  15| 217
------------------
  16|
  17|
....|
  31|
---------
  32|
  :
  :
  :
 191|
---------

with the corresponding access as:

Code: Select all

AD=base+INT(X/8)*192+Y:POKEAD,PEEK(AD)ORB(XAND7)

... which speaks for itself.

Michael

[martin_f]

Indeed it does michael. Thanks for pointing that out.

Think I have left my brain in bed the last week or so. A third kid seemed like such a good idea 10 months ago. The sleepless nights, how quickly we forget.

Martin

[vic user]

A third kid seemed like such a good idea 10 months ago. The sleepless nights, how quickly we forget.

sorry, but that's too funny!

chris