Amiga Super Mario Bros. ?

[lesta_smsc]

I'm surprised this has not yet been ported. We have plenty of good programmers that could code for such a thing. My theory was Amiga had no limitations - well certainly not for the consoles around its era!

[fishyfish]

The lack of tile based hardware on the Amiga isnt an issue for something as simple as SMB. There's not even a need to render an entire strip per frame. Ive always rendered 1 16x16 tile either side of the screen per pixel scrolled. This only requires 12 pixels (2/3rds the width of a "tile"), with 4 pixels/events/whatever_you_want_to_call_them to do other stuff. On top of this the sprites in SMB (apart from bowser) are only 16 pixels wide and 3 colors. The Amiga can easily mach this, even ocs. There's few enough sprites onscreen to even get away with 16 color sprites for 80% of the moving objects, apart from coins. As for the coins the way Ive always tackled it was to use the 4 spare pixels/events to simply copy a new image to the bitmap.There's no need to update them all at once, simply splitting them up over the remaining "pixels" is fine. These dont need to be bobs either, simply overwriting the bitmap will suffice (even if using animated coins).

This is of course over simplifying things, a little logic is needed so the game isnt dependant on the screen moving to do anything, but it's the basic jist. Too many other things to do 1st, but maybe one day I'll have a crack at it if no-one beats me to it.

[seuden]

Originally Posted by Boo Boo

Thanks Teddys is quite fun

Nice to see someone else is enjoying it.

[Amiga1992]

The MD version is an almost identical port, it is true to the original in every aspect. Level design, gameplay aspects, speed, everything has been ported untouched and this is the main thing about it, that it remains extremely true to the original with minor changes (the music does not work very well on the FM chip but the sound effects are exactly the same using the MD's PSG chip).

Being that the Amiga couldn't handle the tile-based rendering, a 1:1 port would prove more challenging. But with 68k sources it could be possible for a dedicated person to make it happen. Also the sound would have to be rewritten or something, as the Amiga has no hardware synthesis capabilities. Maybe a realtime 4 pulsewave soft synth can be run concurrently with the game, maybe not.

[fishyfish]

Of course the Amiga can handle tile based rendering. It's just the tiles are rendered with the blitter/copper rather than dedicated tiling hardware. Even so the amiga can blit more "tiles" at higher color depths and speed than the 8bit NES.

Really not a problem with such a simple game.

[Retro1234]

There some info on the Mario port here
http://devster.proboards.com/index.c...lay&thread=613

Its hard to believe someone doing this as both machines are not open like the Amiga

I think I read one the Megadrive engineers also doing this

Of course Amiga can do this all platformers are tile based but some NES games make you wonder if NES could handle more sprites

Originally Posted by seuden

Nice to see someone else is enjoying it.

Unless someone else does it I'll try and compile the games for everyone at some point

[Thorham]

The original Super Mario is a very simple game and would be very easy to recreate 100% on an Amiga. Don't see what the fuss is about

[LocalH]

Originally Posted by Boo Boo

I think I read one the Megadrive engineers also doing this

You might be thinking of the unreleased (and likely lost to time) Famicom emulator that Yuji Naka developed in his spare time, as he got SMB running on it.

I should qualify my earlier statement - the difficulty would be in doing a 1:1 port from the original 6502 codebase (or even the MD port) due to the tile-based logic. It could be written from scratch and the Amiga could easily handle it, given the other platformers (including high-speed scrolling ones such as Wiz n' Liz which scrolls at least as fast as SMB if not faster). Heavy testing would have to be done to ensure that everything is accurate to the original (if the physics are even slightly off, people like me will notice and complain, hell Nintendo changed one value in porting SMB to the SNES and it was bad enough that in later years, someone developed a patch to revert that value).

[s2325]

Someone wanted Super Mario Bros on Atari 8-bit, I hope Amiga version will be better: [ Show youtube player ]

[phx]

Originally Posted by Codetapper

I'm sure the Superfrog engine would handle Mario no problem at all, and it even handles vertical scrolling without a copper controlled blitter. Giana Sisters showed it could be done. It would just need a custom Amiga solution for the graphics rather than emulating an NES on the fly.

Giana Sisters doesn't really fit into this category of tile-based platform scrollers. Two years ago I reassembled and documented the whole Giana source, so I know for sure that it uses plain hardware scrolling on a giant bitmap.

[Asman]

Originally Posted by phx

Giana Sisters doesn't really fit into this category of tile-based platform scrollers. Two years ago I reassembled and documented the whole Giana source, so I know for sure that it uses plain hardware scrolling on a giant bitmap.

Perhaps a bit of topic.
So If I understand correctly, there is no double buffering ( not enough memory ). What about putting objects (enemies, diamonds), how they handled ? Could you tell a bit more about screen and objects - just for educational purposes. Thank you.

Added: Of course that is possible to make nice version of Super Mario Bros on Amiga.

[redblade]

NES fans have already disassembled SMB with comments and there are at least 2 different disassembled versions out on the net

[Codetapper]

Originally Posted by phx

Giana Sisters doesn't really fit into this category of tile-based platform scrollers. Two years ago I reassembled and documented the whole Giana source, so I know for sure that it uses plain hardware scrolling on a giant bitmap.

I just had a quick look at the game, the game is 16 colour, uses continuous bitmaps with dimensions 2048 x 160 (bitplane pointers at $54000, $5e000, $68000 and $72000). With this layout, the maps are a maximum of 2048 x 160 pixels in size.

In my opinion, that's a very silly way to store the screen but I guess if they pre-planned the game to use the same maps data across all platforms I guess it's OK as it fits into the Amiga. I certainly wouldn't do it that way, as it's so wasteful and limiting. You're using 40,960 bytes per plane to store the graphics. The amount you'd have to plot per frame is very small to keep up with continuous scrolling.

By using the "normal" method (plotting tiles in the sides and using interleaved bitplanes) you would need less than 7k per plane and you could still have double the size of the map! If you used the entire 40k you could have maps more than 800 screens wide using the same block of memory! (Of course the map data would be a lot bigger too!)

The top score panel is rather strange, as the screen layout is different and when objects go up there, it must be having to do a few tricks to draw the object correctly. The clouds near the top are sprites.

Originally Posted by Asman

Perhaps a bit of topic.
So If I understand correctly, there is no double buffering ( not enough memory ). What about putting objects (enemies, diamonds), how they handled ? Could you tell a bit more about screen and objects - just for educational purposes. Thank you.

Added: Of course that is possible to make nice version of Super Mario Bros on Amiga.

With that screen layout, double buffering would be impossible on a 512k chip machine. I imagine that all objects are sorted into the logical order (top to bottom), and drawn as fast as possible directly onto the buffer, and restored at a safe time (after the raster beam is past the object).

The game doesn't even have a level 3 interrupt, so it must be waiting for a specific position then doing all the routines (sound, updating objects, drawing objects).

For animated tiles, the new animation frame would just be redrawn over the top of the existing tile. No doubt it just treats these tiles as objects rather than having to scan the map looking for animated tiles. That's how I'd do it anyway as it's quicker to update a list of objects than scan the screen area 336 x 160 (21 x 10 in blocks = 210) every update to see if that tile needs updating.

The Amiga could easily create a much nicer version of Mario!

[dlfrsilver]

the main enhanced would be the graphics, when i see BCkid, the game is really great, and those games like SMB uses very small tiles portion (see the extracts from the cartrige code)

[ComputingData]

CodeTapper is right, a Mario clone would be pretty easy on an Amiga. ;p

I have no idea why they programmed Gianna that way - pure madness if you ask me.

I'll try get a video or a disk image* of something I did back in 1990/91, it was just messing around though - so there is no real game, just a bunch of ideas and hardware tricks.

The demo runs on a standard 8Mhz 512K A500 (I don't know about ECS/AGA as it was done before AGA, can't remember about ECS).

* The disk image may be on an A4000 that was recently in a house fire, dowsed down by firemen with a high pressure hose pipe, left outside for a few days then brought inside to dry out. I don't think the A4000 will work anymore (!!!), but CodeTapper says that the HDD in the A4000 should be an IDE, so I've ordered an IDE drive caddy from EBay, it should arrive in the next few days. Once it arrives I'll see if I can sort it out.

[phx]

Originally Posted by Codetapper

In my opinion, that's a very silly way to store the screen but I guess if they pre-planned the game to use the same maps data across all platforms I guess it's OK as it fits into the Amiga.

Exactly. Objects had to be placed at 8-pixel boundaries (because the C64 maps were like that), which would have made a tile-based approach quite difficult.

BTW, you got everything right about Giana.

Originally Posted by Codetapper

By using the "normal" method (plotting tiles in the sides and using interleaved bitplanes) you would need less than 7k per plane and you could still have double the size of the map!

This probably gets off-topic and belongs into the coding section, but it is very interesting.

I could imagine that doing animations and foreground/background tiles are not so easy with the "normal" method, when just plotting in the sides.

And I always asked myself how this is done in detail. When plotting in the sides you either have to update the whole bitmap at one point, or use a double-size bitmap, which jumps back to the left border when you reached the right border. But then you would always have to keep a copy in the invisible half (i.e. blitting the side tiles twice when scrolling).

Or is there a better method which I'm missing?

(I'm currently working on a small jump&run game port for OCS Amigas.)

[ComputingData]

There is a better method - you just spiral up/down memory. You don't have to have 2 screens and then flip to the beginning again (didn't they do that with Blood Money? - I can't remember).... As long as the map has a limit then it's better to use the spiral method.

If you combine this with an interrupt that resets the vertical position and you track everything then you can do the same draw on either the top of bottom (a non visible block) to add a barrel scroll. Again this is only one screen - not two high.

This combo will give you an 8-way scroll using only one screen (+ the horizontal max pixels/16 *2 (width of a block in bytes) *4 (bitplanes) - you only need to update either/both of two edges. All in one screen (+ a little bit) of memory.

If you combine this with maximum speeds of say 7 pixels then you only need to draw half of each, each frame. This saves a few (raster) lines, if you need Sonic speeds then you need to do the whole line each frame.

In practice, if you can get it right, then it all works really well. Combine this with double buffering, then redraw destroyed section sprite drawing and you can get loads of objects flying around on a 60hz 8-way 0-7 pixel scroll.

[dlfrsilver]

thanks you for sharing such good technical advices !

[Asman]

@ComputingData - Is there any Amiga game which use such technique ( or source code ) ?


@Codetapper - Thank you for explanation.

[ComputingData]

Originally Posted by Asman

@ComputingData - Is there any Amiga game which use such technique ( or source code ) ?

Yes. ;p

I have source code on my hdd - don't know if the hdd works though. Will find out soon.