Super Mario Bros for VIC-20

Basic and Machine Language

Moderator: Moderators

Post Reply
adric22
Vic 20 Hobbyist
Posts: 143
Joined: Fri Mar 11, 2005 6:54 pm

Super Mario Bros for VIC-20

Post by adric22 »

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

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

ImageImage

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?
16KVIC20
Vic 20 Nerd
Posts: 510
Joined: Tue Apr 06, 2010 5:02 am

Post by 16KVIC20 »

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.
User avatar
Pedro Lambrini
Vic 20 Scientist
Posts: 1132
Joined: Mon Dec 01, 2008 11:36 am

Post by Pedro Lambrini »

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.
"...That of the Eastern tribe being like a multitude of colours as if a rainbow had settled upon its brow..." Daniels 1:3
Boray
Musical Smurf
Posts: 4064
Joined: Mon May 03, 2004 10:47 am

Re: Super Mario Bros for VIC-20

Post by Boray »

adric22 wrote:does the VIC-20 have smooth scrolling like the C64?
No. You can only move the screen in 4 pixel steps horizontally.
PRG Starter - a VICE helper / Vic Software (Boray Gammon, SD2IEC music player, Vic Disk Menu, Tribbles, Mega Omega, How Many 8K etc.)
User avatar
Kweepa
Vic 20 Scientist
Posts: 1314
Joined: Fri Jan 04, 2008 5:11 pm
Location: Austin, Texas
Occupation: Game maker

Post by Kweepa »

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.
adric22
Vic 20 Hobbyist
Posts: 143
Joined: Fri Mar 11, 2005 6:54 pm

Post by adric22 »

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?
User avatar
Pedro Lambrini
Vic 20 Scientist
Posts: 1132
Joined: Mon Dec 01, 2008 11:36 am

Post by Pedro Lambrini »

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?
"...That of the Eastern tribe being like a multitude of colours as if a rainbow had settled upon its brow..." Daniels 1:3
User avatar
tokra
Vic 20 Scientist
Posts: 1120
Joined: Tue Apr 27, 2010 5:32 pm
Location: Scheessel, Germany

Post by tokra »

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.
adric22
Vic 20 Hobbyist
Posts: 143
Joined: Fri Mar 11, 2005 6:54 pm

Post by adric22 »

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.
User avatar
Jeff-20
Denial Founder
Posts: 5759
Joined: Wed Dec 31, 1969 6:00 pm

Post by Jeff-20 »

Flip-screens like Legend of Zelda would be hilarious!
High Scores, Links, and Jeff's Basic Games page.
Vic20-Ian
Vic 20 Scientist
Posts: 1213
Joined: Sun Aug 24, 2008 1:58 pm

Post by Vic20-Ian »

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

The best things in life are Vic-20

Upgrade all new gadgets and mobiles to 3583 Bytes Free today! Ready
adric22
Vic 20 Hobbyist
Posts: 143
Joined: Fri Mar 11, 2005 6:54 pm

Post by adric22 »

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.
RJBowman
Vic 20 Enthusiast
Posts: 198
Joined: Tue Oct 25, 2011 7:50 pm

Post by RJBowman »

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.
RJBowman
Vic 20 Enthusiast
Posts: 198
Joined: Tue Oct 25, 2011 7:50 pm

Post by RJBowman »

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.
User avatar
pixel
Vic 20 Scientist
Posts: 1330
Joined: Fri Feb 28, 2014 3:56 am
Website: http://hugbox.org/
Location: Berlin, Germany
Occupation: Pan–galactic shaman

Re: Super Mario Bros for VIC-20

Post by pixel »

A conversion of the above with beamrider's screen designer:
Image
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).
A man without talent or ambition is most easily pleased. Others set his path and he is content.
https://github.com/SvenMichaelKlose
Post Reply