VIC-20 screen shots/ Pixel Art canvas?

[BladeJunker]

I've noticed VIC-20 screen shots look kind of lousy which I assume is from its odd graphics properties preventing sharp per pixel shots. Also I've been trying to find a basis for pixel art canvas dimensions and resolution for hardware external conceptualizing.

 

Basics:

-176X84 pixels.

-22 columns and 23 rows of 8-by-8 pixel characters.

-Each VIC pixel is much wider than it is high.

-Fixed color border to the edges of the screen.

 

Mostly it's that the native resolution won't work as a canvas since it doesn't reflect the final 4:3 aspect ratio that it will be a run time. While taking a mockup and resampling it to 800X600 to simulate the stretch works the distance between composition and actual image distortion is a slow trial & error process.

 

I just stuck an arbitrary border around the screen resolution since despite special coding to employ the border it sounds too temperamental for average use.

 

I tried to 2 main re-scales of double wide and another that is 3X wide and 2X tall which makes the "drawing" pixel 2-by-1 and 3-by-2 respectively. I guess the question is which do you think looks closest to the real thing?

 

I've just started playing VIC-20 stuff so I'm looking for more seasoned impressions.

[PFL]

The second one looks the closest to my eye. You should maybe ask over at the Denial forum too. Those guys are Vic graphics experts (even inventing new hi res formats!).

 

I understand your problem though. I've always wanted to make some pixel art for the Vic but the pixel shape is really idiosyncratic - I suppose that's inevitable for the world's first 'widescreen' computer!

[BillyHW]

Wiki says 176 x 184...is that a typo?

 

And why didn't people believe in square pixels back then?

[TMR]

Wiki says 176 x 184...is that a typo?

 

No, it's right for a change; 22 characters across by 23 down, so 176 by 184. In multicolour mode with two pixels pairing up to generate one coloured pixel, it drops to 86x184 and, if there's memory present for more screen RAM, there are options to overscan too. i think BladeJunker's just missed a 1 out because the rest of what he wrote seems to make sense for the actual resolution.

 

And why didn't people believe in square pixels back then?

 

Various reasons depending on the machine; some hardware with 320x200 1:1 ratio pixels had issues with artefacting on televisions, many machines offered an option to pair up pixels for chunkier 2:1 ratio ones that could be one of four colours... the VIC is just chunky though, that's part of it's charm. =-)

 

All i've ever done with the VIC is treat it as 2:1 or 4:1 ratio pixels and not worried about things after that, it's about as accurate as you need to get considering variations between televisions/monitors, PAL/NTSC (if you're allowing for it in the first place) and so on. Here's one i made earlier:

 

[+SpiceWare]

You can change the display size quite a bit. There are registers to control how many columns, how many rows, X offset, Y offset, and even select between 8x8 or 8x16 sized characters.

 

The VIC doesn't have a bitmap mode but you can create your own using a RAM based character set and filling up the screen with a different character in each position. 22x23 = 506 but there's only 256 characters so you turn on 8x16 mode and set it to something like 22x11 which would use 242 characters. The internal 5K must be used to hold the character set, displayed characters and colors so the bitmap was probably smaller than 22x11 characters. Back in the day I wrote a 40 column terminal program that used a 20 column bitmap display. The letters were 3 pixel wide letters with 1 pixel spacing.

 

From this, the max screen size is:

NTSC 26x29

PAL 29x35

[BladeJunker]

The second one looks the closest to my eye. You should maybe ask over at the Denial forum too. Those guys are Vic graphics experts (even inventing new hi res formats!).

 

I understand your problem though. I've always wanted to make some pixel art for the Vic but the pixel shape is really idiosyncratic - I suppose that's inevitable for the world's first 'widescreen' computer!

Yeah I was thinking that too about the second one but I thought I should ask. Denial forum hmm, thanks I'll be sure to check them out. Heh widescreen, yeah I guess you could call it that.

[BladeJunker]

Wiki says 176 x 184...is that a typo?

 

And why didn't people believe in square pixels back then?

Whoops my bad, that is indeed a typo. Well the square pixel was hard to come by back then, the hardware costs to render a single pixel were much higher in the old days. You should try looking at the Apple II that Wozniak designed, great balance of chips and costs but very odd pixel color output requirements.

http://www.filfre.net/2011/10/mystery-house-part-1/

[BladeJunker]

Wiki says 176 x 184...is that a typo?

 

No, it's right for a change; 22 characters across by 23 down, so 176 by 184. In multicolour mode with two pixels pairing up to generate one coloured pixel, it drops to 86x184 and, if there's memory present for more screen RAM, there are options to overscan too. i think BladeJunker's just missed a 1 out because the rest of what he wrote seems to make sense for the actual resolution.

 

And why didn't people believe in square pixels back then?

 

Various reasons depending on the machine; some hardware with 320x200 1:1 ratio pixels had issues with artefacting on televisions, many machines offered an option to pair up pixels for chunkier 2:1 ratio ones that could be one of four colours... the VIC is just chunky though, that's part of it's charm. =-)

 

All i've ever done with the VIC is treat it as 2:1 or 4:1 ratio pixels and not worried about things after that, it's about as accurate as you need to get considering variations between televisions/monitors, PAL/NTSC (if you're allowing for it in the first place) and so on. Here's one i made earlier:

 

 

Yeah I do check over before hitting the Post button but somehow I missed 1 from the 184 lol. I wouldn't go as far as saying Wiki is 100% accurate but yes the older the subject matter the more errors I find in my experience, still a good tool though.

 

Artefacting I hadn't considered that, I thought it was just CPU to thoroughput balancing and keeping the units cost effective to make was the reason for the odd resolutions IE. RAM costs.

 

Yeah I find the chunky look of the VIC software sprites quite charming and has influenced my 2600 pursuits as well in terms of resolution quality and art technique.

 

I'll give 2:1 and 4:1 a try, nice looking game btw.

[BladeJunker]

You can change the display size quite a bit. There are registers to control how many columns, how many rows, X offset, Y offset, and even select between 8x8 or 8x16 sized characters. The VIC doesn't have a bitmap mode but you can create your own using a RAM based character set and filling up the screen with a different character in each position. 22x23 = 506 but there's only 256 characters so you turn on 8x16 mode and set it to something like 22x11 which would use 242 characters. The internal 5K must be used to hold the character set, displayed characters and colors so the bitmap was probably smaller than 22x11 characters. Back in the day I wrote a 40 column terminal program that used a 20 column bitmap display. The letters were 3 pixel wide letters with 1 pixel spacing. From this, the max screen size is: NTSC 26x29 PAL 29x35

 

That's what I hear, that it has many options in how you use hardware resources and the screen setup. Does the 8X16 mode or 1X2 block size include the 4X8 pixel characters(3 color) or 4X16 as well for software sprites? Also is 26X29 NTSC or 29X35 PAL maximum grid allotment or is that the default 22X23 residing in the middle of the border space, I read something about running out the sides of the monitor eventually which I guess you didn't run into?

 

More characters or resolution is always nice but average setups used by most games suits me fine and I'd like to avoid a NTSC PAL difference by selecting a safe range.

Does the screen shape change between modes or does everything get stretched to 4:3? I need some sort of basis to produce a canvas resolution default even if that means including multiple sizes but it has to be limited to most common options with the least amount of distortion(sharp pixels/close to final shape) if external conceptualizing can be done. I mean the C64 has some pretty funky screen modes people have employed over the years that would be hard to impossible to screenshot well but most VIC-20 games must have a commonality?

[TMR]

Does the 8X16 mode or 1X2 block size include the 4X8 pixel characters(3 color) or 4X16 as well for software sprites?

 

That mode doubles characters up to save screen RAM, so one byte in the screen appears as two characters, one above the other. Poke a value of $00 and it appears as $00 with $01 directly below it, poking $01 gets an $02 and $03 under it and so on. The colour RAM use changes as well, so colour is dished out to 8x16 pixel areas instead of 8x8.

 

Multicolour mode is always an option and groups characters in the same way, producing 4x16 pixel objects.

 

Does the screen shape change between modes or does everything get stretched to 4:3?

 

The modes aren't really modes in the sense that anything changes like they do elsewhere; high res and multicolour characters can co-exist and the latter are probably best considered as being made up from pairs of pixels from the former. Even if the size of the screen itself is changed, that just adds new columns or rows into what are at power-up the borders so the actual ratio of the display doesn't change.

 

The VIC can really mess with it's screen layout, have a look at the screenshot for my game ViColumn because the blue border around the play area (apart from the bit between the game and status bar) is literally that, the border colour - it reduces the screen width to eight characters wide and expands the height a little into the upper and lower borders.

[+SpiceWare]

Does the screen shape change between modes or does everything get stretched to 4:3?

As TMR showed with ViColumn, the pixels remain the exact same size while the border moves to accommodate any changes in rows and/or columns. Here's a photo of my Vic's boot screen:

 

And here's a photo of the game Skramble, which adds columns to the screen

 

I probably need to adjust the horizontal image size so Skramble fits within the screen, but that's the only game I've noticed an issue with and I don't play it. The 1084S is normally used to play Atari VCS games and it's adjusted for that.

[BladeJunker]

That mode doubles characters up to save screen RAM, so one byte in the screen appears as two characters, one above the other. Poke a value of $00 and it appears as $00 with $01 directly below it, poking $01 gets an $02 and $03 under it and so on. The colour RAM use changes as well, so colour is dished out to 8x16 pixel areas instead of 8x8. Multicolour mode is always an option and groups characters in the same way, producing 4x16 pixel objects.

Okay that makes sense where 8X8 would actually be like widescreen than what could be displayed with 8X16 which is closer to 4:3 at least in regards to RAM characters.

 

The modes aren't really modes in the sense that anything changes like they do elsewhere; high res and multicolour characters can co-exist and the latter are probably best considered as being made up from pairs of pixels from the former. Even if the size of the screen itself is changed, that just adds new columns or rows into what are at power-up the borders so the actual ratio of the display doesn't change. The VIC can really mess with it's screen layout, have a look at the screenshot for my game ViColumn because the blue border around the play area (apart from the bit between the game and status bar) is literally that, the border colour - it reduces the screen width to eight characters wide and expands the height a little into the upper and lower borders.

So high res and multicolour characters can coexist like C64 and Apple II do. I've never found that useful or effective on C64 but on the VIC-20 it seems to look more contiguous instead of clashing in resolution.

 

I'm somewhat familiar with bit or pixel constructed sprites from my research into the 2600 but I still don't understand what the process is to make a software sprite. I understand its pixel/colour resolution and its uses plus visual advantages but not how its made.

 

I see what you did there in ViColumn, you emphasized height without exceeding the character limit. That is an interesting system of character grid limits, I'm glad I asked about this issue since I was not ready to start a pixel art guide for this system.

[BladeJunker]

As TMR showed with ViColumn, the pixels remain the exact same size while the border moves to accommodate any changes in rows and/or columns. Here's a photo of my Vic's boot screen:

 

And here's a photo of the game Skramble, which adds columns to the screen

 

I probably need to adjust the horizontal image size so Skramble fits within the screen, but that's the only game I've noticed an issue with and I don't play it. The 1084S is normally used to play Atari VCS games and it's adjusted for that.

 

Okay so the screen shape or space is fixed while the number of columns and rows can vary based on the setup used. That's good news since one canvas is easier than many, I'll just have to emphasize the border more as potential screen space. I guess I'll just describe the NTSC PAL difference and how to deal with it like they do for mobile games on multiple brands of cellphones, adding or deducting characters on the game space but keep the HUD/Menus the same.

 

Thanks for the pictures, I'm still fiddling with my monitors and TVs so I didn't know what the VIC-20 picture is supposed to look like. I've heard of Skramble, most people either seem to like it or hate it but not much in between.

[TMR]

So high res and multicolour characters can coexist like C64 and Apple II do.

 

Yup, if you've a little experience of the C64 it's pretty much the same but each pixel twice as wide really.

 

I've never found that useful or effective on C64 but on the VIC-20 it seems to look more contiguous instead of clashing in resolution.

 

On the C64 it's used a lot for things like status displays (having a nice, multicolour surround with clean high res text) or in scrolling games for background parallax so they can be shifted back against the scrolling.

 

I'm somewhat familiar with bit or pixel constructed sprites from my research into the 2600 but I still don't understand what the process is to make a software sprite. I understand its pixel/colour resolution and its uses plus visual advantages but not how its made.

 

Basically software sprites are just characters. To start with, they can be as simple as having a shape drawn into a character that is then moved around a cell at a time and you'll see that on quite a few unexpanded VIC games since this is the most memory efficient solution.

 

More complicated software sprites for something like Jetpac will probably have a workspace of, as an example, two by two characters; the four characters on screen where the soft sprite is about to sit are stashed for later reference and replaced by the workspace, which then has it's definitions replaced by copies of what was there previously. Then one of the pre-shifted sprite definitions (because having the four or whatever states pre-shifted as an object moves from character cell to character cell is the fastest way, although some engines do the shift "live") are merged into the workspace at whatever pixel height needed. Then the entire lot is undone by recovering the stashed background characters and the process starts again for the next refresh.

 

And there's variatious on both themes, some games store pre-shifted objects in their main font and cycle through those animations to make something move from character cell to character cell - far quicker than the full on complicated sprites but better looking than just jumping a character at a time.

 

I see what you did there in ViColumn, you emphasized height without exceeding the character limit.

 

i also reduced the play area to a single 256 byte page in memory as well, so i've got a bit of extra memory in the remaining screen RAM that isn't visible to use as label space and moving the game itself is easier because i don't have to use indirect indexed addressing or self mod to access everything. =-)

[carlsson]

I'd like to add that pixel proportions differ between NTSC and PAL systems. The NTSC VIC-20 can display fewer columns and fewer rows, so each pixel will normally appear a little more square than the PAL VIC-20 does. You might have some help from this technical document that measures the number of lines per frame, cycles per frame and theoretical maximum screen size in pixels:

http://zimmers.net/anonftp/pub/cbm/documents/chipdata/VIC-I.txt

[BladeJunker]

Okay I adjusted the canvas sizes to include the border character space that I thought was just border lol. I stuck to the default grid size(22X23) for 8X8 characters in ANSI mode with "options" to expand outwards into the border space. For PAL I added a column to every PAL specific canvas to even out the horizontal character alignment which works fine for RAM characters using 8X16 characters as 23x11=253 which just fits.

 

Can't do much about the pixel shape whether NTSC or PAL since neither is perfectly square, mostly it looks like one has to shave small units of width and height off sprites when possible to get them to approximately correct proportions.

 

I ended up going with 3X by 2X as that is as close to 4:3 I can get with crisp pixel units, its not perfect but I think it will have to do for composition needs. I think the canvas will work now unless anyone can think of something I missed.

 

Thank you to everyone helping with this.

[BladeJunker]

Just thought I'd post some stuff using the canvas since I never really demonstrated it beyond the character grid layout. Just put some time into wrapping my head around the color limits, challenging but not too frustrating.

[BladeJunker]

Thought I'd add an update on the progress, well a guy named Mike from the Denial forum got wind of my pursuit of the VIC-20 as an art medium and helped iron out the basics of colors, resolution, and elaborated more on screen mode options than I could ever do.

 

So I invite you to take a look the pixel art guide that has formed based on this initial posting. Thanks again for all those that posted here.

http://www.wayofthep...p?topic=13904.0

[+SpiceWare]

That bestiary is impressive.

[BladeJunker]

That bestiary is impressive.

Oh thanks, I've actually gotten better since then and got some more accurate RGB colors too. Still experimenting on how to tackled different genres best on the VIC.