Re: Super Mario on the C64

David Murray <adric22@xxxxxxxxx> wrote in news:

I wanted to get a discussion going about the technical challenges
involved in this, as compared with the original Nintendo version.
Now, I am making a wild guess here, but I am going to assume Mario 2
and Mario 3 are out of the question because I don't think the C64 has
enough RAM for that. I could be wrong, but it seems unlikely.
Looking at the ROM files for the Nintendo, the original Super Mario
game is 44K, whereas Mario 2 is 260K and Mario 3 is 388K.

Yes, but SMB2 and SMB3 (and most NES games) are bank-switched. The NES can
only access 32k of code and 8k of graphics data at a time.

Now let's discuss scrolling (very important).

The C64 and NES both use character graphics, but scrolling is more involved
on the former. The NES merely requires you to adjust the PPU's scrolling
registers to move the screen. Scrolling on the C64 is done by reducing the
width of the screen by one character, thus creating an off-screen buffer.
You can only scroll one character before refilling the buffer with the next
row of characters.

This is more complicated and CPU-intensive than on the NES. In addition,
double-buffering is usually a necessity because otherwise the CPU will move
the graphics data faster than the VIC-II can update the screen, resulting
in mid-screen tearing.

You would need a multiload even for SMB. Giana Sisters was single-load, but
it was also a much simpler game. C64 games tend to be larger than NES games
because of the more complicated scrolling, and because it takes more code
to load files from disk than it does to bank-switch a cartridge. Observe
that Castlevania on the NES was 128k in size, while the C64 version took
three 170k disks.

SMB should be possible on the C64, since NES games like Castlevania were
ported pretty faithfully. I would think that any NES game that used the
MMC1 or no mappers could be done. Some music would have to be omitted
because the C64 can't bank-switch from cartridges instantaneously. Forget
about SMB2 or SMB3. They used the MMC3 mapper, which allowed advanced
tricks like diagonal scrolling, animated tiles, and instant bank-switching
of sprites.

So then there is the question of which graphics mode to use to best
make things work. I do not currently think the bit-mapped graphics
mode would be best. So that leaves us with redefined characters and
either multi-color or 2-color. Obviously, either one would work but
I'd have to decide between detail or extra color. I'm not sure the
original Mario graphics could be duplicated exactly in either mode.
I'm not sure of the Nintendo's exact graphics capability, but I get
the impression it may be a bit better than the VIC-II.

The NES's resolution is 256x224. It has 64 colors, of which 25 may be on
screen at once (13 for tiles and 12 for sprites). Each tile is 8x8 pixels,
but every block of four tiles must use the same colors (except with MMC5
games, where it's every two tiles). It also has no true bitmap mode.

You can't scroll bitmaps on the C64, so you would have to use character
graphics (unless you want to leave out scrolling and merely switch
screens). Character graphics can be a mix of multicolor and hires, but the
former requires that two of the three colors be shared. Thus character
graphics are much less colorful than bitmaps.

Then there is the issue of sprites. I realize you can make more than
8 sprites with raster tricks.. but that may be a bit beyond me. yet,
I feel that in order to simulate the breaking of bricks, I would have
to create a routine that would remove the custom characters from the
screen and replace with 4 sprites. That would be a problem if there
were a lot of bad guys on the screen. I think the way Giana sisters
handles the bricks (where the implode) is a bit of a cop-out.

The NES has 64 sprites (8 per scanline), but they are smaller than the
C64's sprites (8x8 or 8x16 vs. 12x21 or 24x21). They do not have to share
two colors like on the C64. Most moving objects in NES games are actually
made of several sprites.
.

Relevant Pages

  • Re: Animating monster moves?
    ... I prefer character displays and target ssh, ... My advice is most ... than with graphics per se. ... Windows, included for back compatibility. ...
    (rec.games.roguelike.development)
  • Re: Permadeath and savescumming
    ... enerate character ... Tile graphics. ... Swords did good damage (long swords ... did more damage than any other melee weapon full stop), ...
    (rec.games.roguelike.development)
  • TOC: The Graphics Book for the Commodore 64
    ... Sprite definition pointers ... Multi-color sprites ... Character representation ... Moving the graphics storage ...
    (comp.sys.cbm)
  • Re: VPLUS and dynamically displaying graphics characters
    ... It is not really graphics, just alternate character. ... the screen image in the forms file. ... * To join/leave the list, search archives, change list settings, * ...
    (comp.sys.hp.mpe)
  • Re: Dialog Management Scrolling WAS Left & Right Scrolling in ISPF
    ... Making the panel width larger than 80 characters will cause an error if someone attempts to display the panel on a regular 80 width screen size. ... Dialog Management Scrolling WAS Left & Right Scrolling in ISPF ... My thought was that I would have to build a Panel table larger than the traditional 80 Character width. ... For IBM-MAIN subscribe / signoff / archive access instructions, ...
    (bit.listserv.ibm-main)