Page 1 of 1

Mario Bros

Posted: Sat Mar 30, 2019 5:20 pm
by nicksen782
Game page on nicksen782.net:
https://nicksen782.net/r_mariobros.php

This is a port of the Atari 2600 version of Mario Bros from 1983. I've been faithful with most of the graphics. Actually, that isn't 100% true since I needed to hand-draw them all in Gimp. The Atari 2600 was not tile based and sprite sizes can vary so I did the best I could to fit the sprites into 8x8 tiles. All are one tile wide.

I really liked this game as a kid so I decided that I would port it to Uzebox for the Competition. I have quite a bit of it done.

Main menu, graphics, Enemy behaviors, scoring, collision detection, etc.

This is not done yet but it is playable. I need to finish some enemy behaviors, add sound, Uzenet for player 2. You can play as player two if you have two gamepads. That works.

This is a demo at the moment since I still need to finish it. If you go to the game link page (top of this post) you can play the current version, milestones, find a link to the game on Github, and also download a .zip of the game directory (which has a little more than Github since I don't upload the management folders.)

Please comment! I am very interested in feedback.

Re: Mario Bros

Posted: Sat Mar 30, 2019 8:37 pm
by L4rry
Ah dude!! Well done :D The animations and physics are so smooth and the game play is nice and challenging. I've only ever played the arcade version of Mario so this is intriguing to me. I love how fluid everything is.

I will spend some time tomorrow to play through this and give some proper critical feedback. For now thow, I can say, I don't think I've seen a game on uzebox with as smooth animation as this one. Top job.

Re: Mario Bros

Posted: Sun Mar 31, 2019 12:31 pm
by Jubatian
Huh, this is a surprisingly fun game! The mechanics feel all right, it is easy to control, while the game itself progresses in difficulty nicely. That is, I don't feel like battling with the controls when playing it which is a good thing. I tried with the real HW with the actual SNES pad, and it works pretty well!

If I count it right, it appears to be 26 tiles wide.

The actual Atari 2600 has 160 pixels horizontal, the background (playfield) is 40 "quite wide" pixels, while sprites are 8 pixels wide. On the Uzebox a proper mode for an exact replica would be one with 8 clocks / pixel. With Mode 3 the difficulty is that it is just not the right resolution for the Atari 2600, so to get things looking reasonably similar, you need to recreate graphics (like you did). To have similar sprite dimensions to the Atari, on Mode 3, you would have to create ~11 pixels wide sprites. The 26 tiles width you choose is actually quite close to how wide the Atari's display would be (slightly wider, 27 Mode 3 tiles would be actually closer to the truth).

Maybe hack Mode 3 to make it 8 cycles / pixels? It is an easy hack, actually the mechanism is already in the current kernel as you can choose between 5.5 and 6 cycles per pixel for this mode.

Re: Mario Bros

Posted: Tue Apr 09, 2019 2:39 pm
by nicksen782
Thank you for the nice comments!

I do the animations on a type of counter/timer. Each time the sprites are redrawn a timer is checked. If under a value then frame1, if under another value then frame2. Else, frame 1 again. Each enemy can have different values. For instance, the sidestepper (crab) has more than the rest. If you bump it and do not kick it in time you'll see that just before it gets back up but that will shift it's claws in a little dance. I added that.

Also, whenever an actor makes it to the bottom pipe it disappears. It remains in the queue for the level but the enemy disappears. If there are now less than 3 enemies then the next remaining enemy in the queue would be spawned from the top pipes. Actor slots are dynamic and it doesn't matter what slot an enemy or the player use. Same with sprites. Upon redrawing all sprites I handle the next sprite number automatically. This means that an enemy/player might not always have the same sprites, which is fine. The whole goal was to not be locked down to specific sprite or ram tile indexes.

(That was a problem that I ran into when doing Zelda. For example, if an enemy has been cleared then you SHOULD have 4 more ramtiles/sprites available which means that the enemy should be able to shoot more arrows. I was hard-coding the sprite numbers so I couldn't. With ramtile sprite sourcing, in some cases I may even be able to change colors on the fly too.)

I really need to add sound, fix the hitpoints bug with the sidestepper being the last enemy and handle levels beyond 11. These are the bigger bugs I know of. Did anyone find any other bugs? The source code is available at the first link I posted in this topic.

Re: Mario Bros

Posted: Wed Apr 10, 2019 11:08 am
by L4rry
Just finished the 11 levels on Normal difficulty. 88000!

I honestly couldn't find any obvious bugs. Though a small win would be to add a pause function when pressing the start key. I'm assuming you've relied on the emulators F9 button up until this point

Things as a gamer that I would like to see are:

- A high scores table persisted to eeprom
- A demo mode

But that's just my wishlist.

Is this the first Uzebox game with multiple difficulty modes? It's the first one I can remember. I haven't played them all though.

Anyway, again, solid effort. Looking forward to future iterations :)

Re: Mario Bros

Posted: Fri Apr 26, 2019 4:23 am
by uze6666
Add the sound I say and it's a wrap! Never knew there was an Atari version in fact, will have to check this out. Let me know when it's gold, I'll post the news! With Janka's, it's two new games in a very short time, very cool. 8-)

Re: Mario Bros

Posted: Fri Apr 26, 2019 7:37 am
by nicksen782
Thank you! ... Actually, I'm finishing up a second game too! (Totally different.) So, make that three! ;)

It would be awesome to get on the Uzebox home page!

... Unfortunately, I'm not so great with creating sounds or music.