Denial

So here's a photo of the original Super Mario Bros. on the NES:


Here's two photos of what it would look like on the VIC-20.



I just decided to play around with a paint program and figure out what could be done on the VIC-20. I drew it both as a multi-color mode and as a monochrome. While the multi-color at first glance looks more similar to the original, the monochrome would have more detail and potentially be easier to code since we'd be dealing with software sprites.

Incidentally.. does the VIC-20 have smooth scrolling like the C64?

Both look great, and it is just the sort of non released game for the VIC 20 that I would love to see. I'm sure that others would too.

Would be nice to have colour though.

I actually like the monochrome one. It's reminiscent of the Game Boy games.

It would be great to see something like this on the Vic. After seeing the demo that's on the VCS I'm pretty sure the Vic could do at least as well.

It actually surprises me that the original Mario Bros game wasn't released on the Vic. I reckon that would've been a perfect fit. Atarisoft would've done a great job of it I'm sure.

adric22 wrote:does the VIC-20 have smooth scrolling like the C64?

No. You can only move the screen in 4 pixel steps horizontally.

Scrolling can be done a number of ways.

A) Scroll in one character increments by copying across one character at a time.
B) A smoother option with ragged edges (unless you reformat the screen so that the edges are outside the tv borders) is to scroll a half character by shifting the X position 4 pixels (by writing a byte to a VIC register) and a full character with option A.
C) If you have a limited number of tiles (and tile pairs), you can scroll by shifting tile pairs in pixel increments (or more or less) and every 8 pixels recalculating the new tile pairs.
D) Shifting every pixel on the screen is probably too slow. It can be done vertically pretty quickly but I doubt horizontally.

Kweepa wrote: D) Shifting every pixel on the screen is probably too slow. It can be done vertically pretty quickly but I doubt horizontally.

Yikes! I was afraid of that. Which brings up the question about if this game were to be done, how smoothly could it work? I wonder if we just moved a full 8-pixels at a time, how jittery it would appear? I suppose it would all have to do with how fast it was moving.

But the second question is... I was thinking about software sprites (especially when I drew the monochrome version) but if I wound up moving the screen a whole 8 pixels at a time, there wouldn't be a lot of reason to use software sprites. In which case mario and his enemies would all just move 8 pixels at a time. Again, I wonder what the gameplay would be like with this method?

I know it's not the best solution but have you thought about using smaller graphics a la Blue Star and use flip screens?

I remember a while back someone released a 'condensed' version of SMB which pretty much did that and it looked pretty good.

You could get pretty much a whole level on one screen.

Also, I know it automatically scrolls but Aleksi Eeben's Dragonwing scrolls like melted butter on toast. Maybe you could pick up something from the source code?

http://www.youtube.com/watch?v=bgTYLuCvzMA

This was done bei streetuff of TRSI for the VIC-20 a while back. I had a chance to chat with him at the Nordlicht-demoparty this year asking him what kind of scrolling this uses. As I suspected he confirmed it uses 4 pixel scrolling.

For a real game I don't know how smooth this would look, but having no sprites will get a you whole can of worms of other problems like color-clashing.

tokra wrote:http://www.youtube.com/watch?v=bgTYLuCvzMA

This was done bei streetuff of TRSI for the VIC-20 a while back. I had a chance to chat with him at the Nordlicht-demoparty this year asking him what kind of scrolling this uses. As I suspected he confirmed it uses 4 pixel scrolling.

Wow! I've never seen this before! Its amazing how closely it resembles the C64 version. I would have thought the color limitation on the VIC-20 would have made it look different.

Flip-screens like Legend of Zelda would be hilarious!

Skyhawk had smooth horizontal scrolling from memory, not many games on the Vic did. Could also be 4 pixel I guess.

Actually, now I'm kind of wondering if it might actually be possible to simply redraw the entire screen each frame. There are a few things going for this idea. For one thing, I'm used to programming on the C64. But the VIC-20 has only about half as much data on the screen, plus the VIC-20 has a faster CPU.

Plus... the more I think about it, since I'd be using software sprites, there'd be a lot of wasted CPU time redrawing the characters each time the screen scrolled. In which case, why not just redraw the whole screen each time.

I'm actually thinking maybe from a perspective of doing the whole game in bit-mapped mode. Yes, I know the VIC-20 doesn't have an official bit-mapped mode, but anyone around here would know what I'm talking about. In which case I'd simply need to design some routines to blit the sprites onto the screen as quickly as possible. Only in this case, everything would be treated as a sprite, including the clouds, backgrounds, and little question mark boxes, etc.

For example, one way that might be used to speed up the draw routines would be to store each sprite in memory 64 times. Each one accounting for the 64 different possible positions it might be slapped onto the screen based on the character cells. Granted that would be about 2Kb for each sprite. Hmm.. I'll have to think about that. Maybe store each sprite 8 times instead, just to account for the variations in horizontal conditions so that it would not be necessary to do any bit shifting when copying the sprite to the screen.

Rats.. that is one of the conundrums of the VIC-20. Even with a 32KB ram expansion, there still isn't much room for speed-code.

The game needs multicolor; the VIC was not intended to be a Game Boy clone. People have a fear of multi-color mode, and a fear of programming overlapping objects. This fear is unwarranted.

Cheat on the scrolling; when Mario is about to move off the screen, quickly scroll half a screen-width to put Mario in the center of the screen. Do it quickly enough and you won't be able to see that the screen is scrolling in four or eight pixel jumps.

You might need to change the colors of some things in your design to get it within the limitations of VIC-20 multicolor. Every 4x8 region of the screen must have one color of its own, and three colors (including background) shared with the rest of the screen. Raster splits can partially get around this limitation, but there must still be three shared colors on each scan line.

Here, look at this:

http://www.youtube.com/watch?v=9yl_XPkcTl4

Now, instead of looking at the entire game screen, concentrate on a small spot of scrolling ground in the lower left corner.

Do you see pixel patterns smoothly scrolling? I think that the background is jumping about half a tile at a time, and you don't notice because of the speed.

A conversion of the above with beamrider's screen designer:

http://hugbox.org/pixel/external/denial/mario-vicsd.txt
It's been raining cats and dogs, you know?... So here come a couple of considerations along 1 full charset of 256 chars and 2 screens.

Challenge 1: Colours
However you turn and wiggle it: there would be no background gfx like the green bush unless you want it to become (mostly) red where a sprite is. Full gfx detail could be done in monochrome mode but that's very expensive for the sprites.

Challenge 2: Sprites
Super Mario on the NES pumps out up to 64 8x8px sprites at once. They're lined up to make the 8x16/16x8/16x16/32x16px objects. Having 16 8x8px sprites around is already kind of over the edge on the VIC. A 16x16px sprite can also eat up 9 chars.

Challenge 2: Scrolling
Hardware scrolling would mess up sprite positioning and rob 44 chars to conceal it at the sides. If no more than 32 different character pairs (left/right) appear at the same time perhaps that could be managed with the right kind of bookkeeping. You've got to be able to update all scrolling chars before a retrace. Even worse: scrolling varies in speed.

Suggestion:
Grab whichever memory expander provides at least 512K RAM and go with pre-calculated chars for the scrolling and compiled sprites (generated machine code which plots immediate values).