It's a me...Mario...

[Sprybug]

A while ago I was working on an adventure game to really learn how to use batari basic and it worked out pretty well until the game got too big and buggy so I scrapped it. I put Batari away for a while and recently decided to try something out. I wanted to see if I could do a Super Mario type game on the Atari with a scrolling both left and right playfield. And walla, I did it. Right now it's really basic. One level to run around in. Action button jumps and up does your speed run while you're moving left or right. No enemies or items yet, but that is next on the list. The levels will all be pretty short because I'm using non-sequential data to be able to scroll both left and right, which limits the amount of data I can have. Every level will take up about 256 bytes of ROM, so every "world" will take up about 1K. Because of this the levels will have more of a "puzzle" feel to it, as you need to figure out how to get from start to finish. Instead of a flagpole, you'll need to find the pipe you have to go down to advance to the next level. I had to write my own collision detection, because of the scrolling playfield. It needs a little tweaking still, but it works for the most part. Because of the limitations of the hardware, there are things I'll have to take out that you'd normally see in a mario game and also a few tweaks. A few are that what you get out of the bonus yellow blocks will be random. Could be a coin or a power up, but more than not a coin. The reason for this is because if I wanted to also store level specific event data, it'd take up more space for data and programming which would mean less levels, and I'd rather have more levels, plus the random aspect of the items will make the game different every time. Everything will also regenerate too if you run back again, even destroyed blocks. This is because it rereads the original level data when it scrolls and generates it. There isn't enough RAM in the Atari to remember what has been destroyed and what hasn't. This also led me to the random yellow bonus block feature, so that when you did go back, you just couldn't get the same power ups all the time. But that has yet to be implemented, so for now, enjoy what I got so far!

smb.bas.bin

smb.bas

Edited July 12, 2012 by Sprybug

[+Gemintronic]

Very cool! I didn't see any drastic tweaks that need doing to the collision. I did miss variable jumping though.

 

How do you store and load level data? I hope you get to a point where you're comfortable showing source. I got stuck on loading and displaying level data myself.

 

I've done some work on a smooth horizontal scrolling demo but it'd be hard to transform into a true Mario style game:

http://www.atariage.com/forums/topic/195843-smooth-horizontal-scrolling-demo/

Edited July 4, 2012 by theloon

[Sprybug]

Very cool! I didn't see any drastic tweaks that need doing to the collision. I did miss variable jumping though.

 

How do you store and load level data? I hope you get to a point where you're comfortable showing source. I got stuck on loading and displaying level data myself.

 

I've done some work on a smooth horizontal scrolling demo but it'd be hard to transform into a true Mario style game:

http://www.atariage....scrolling-demo/

 

The source is a touch messy right now, but once I do more and debug a little, I do plan on posting the source because I'd like to see other people out there make games like this for the Atari and it really isn't all that hard to do. For the level, I do make all of the entire level (4 screens worth) in the playfield editor in Visual BB, so I know what it looks like. Once done with that, I drag them into a blank file and then copy and paste the text of the playfield into Notepad and vertical line by vertical line I manually convert it into binary code. Each vertical line is 2 bytes, which explains why each level can be only 4 screens big with each screen being 64 bytes (32 lines x 2 bytes). Grand total = 256 bytes. As you know a non-sequential data statement can only be 256 bytes in size. This is why there is a limitation if I want to scroll both left and right and can change the read pointer on the fly depending on which direction your going. If I scrolled in only one direction and used sdata instead then I could make it as big as ROM could store. Anyhow, I do make the playfield the first screen, because that's where you start and then use the scroll commands when scrolling needs to happen. To input the data on screen I read the data according to the scroll pointer data variable and plot the new graphics with ands & ors, because the scroll wraps automatically and I just need to turn bits on or off depending on what's coming back. First 8 rows of the new line is one value (0-255), and the last 3 rows is one value (0-7). 8-255 will be used for enemy and object plotting data, so yes the enemies will also regenerate, which will be good because sometimes as I have it planned you will need them to get to where you need to go and if you mess up, you can just scroll them off and then back on again. I do plan on variable jumping (longer jump the longer you hold the action button), I just haven't implemented it yet. As I see it, it won't be that hard to do.

[+Random Terrain]

Check out this link:

 

www.atariage.com/forums/topic/181081-keeping-track-of-the-scanline-count-with-stella/

[Sprybug]

Check out this link:

 

www.atariage.com/forums/topic/181081-keeping-track-of-the-scanline-count-with-stella/

 

Wild! I checked this exact link out about 2 hours before you posted it! I did both the scaline count with Stella and the debug cycles in the code and oh boy do I have some clock cycle issues I need to resolve. I seem to exceed the cycles on certain instances of collision detections. I'm going to have to retool my collision detection method somehow. It's going to be hard to do, because it took some time to figure out something that actually worked okay but unfortunately it does a lot of checks and takes up cycles to accurately check things out when jumping, falling, running, making sure Mario is on a platform, etc.

[CrazyChris]

Awesome! It's like, "real" Mario brothers.

 

- Chris

Edited July 4, 2012 by CrazyChris

[Nateo]

The control of Mario is perfect. I'm really excited to see what happens with this!

[Nateo]

Honestly, I just played through some of the older Super Mario based demos, and this one is the best by far. Have you had the opportunity to take another look at it?

[Sprybug]

Honestly, I just played through some of the older Super Mario based demos, and this one is the best by far. Have you had the opportunity to take another look at it?

When you say take another look at it, do you mean my code to try to keep my clock cycles in check for every drawscreen? The way it is right now it won't work on a real 2600 until I fix that issue, and to do so I need to rewrite the collision detection routines. At worst I may have to call a drawscreen more than once before a game cycle is completed which will cause a little bit of flicker with the sprites because I won't plot them until they are in the right place on the screen. I haven't seen any other SMB style homebrews yet, so I'd be interested in seeing them. Actually I would LOVE to see the code for the Mega Man demo, because he seems to have gotten the gameplay and collision detection down to a T while keeping his cycles in check. I know his doesn't scroll while in action, but I might be able to implement some of it to make it work for me.

[+Random Terrain]

This isn't a Mario game, but I wonder if any of the code would be useful:

 

www.atariage.com/forums/topic/179473-fake-gravity-platformer-test/

[Sprybug]

This isn't a Mario game, but I wonder if any of the code would be useful:

 

www.atariage.com/forums/topic/179473-fake-gravity-platformer-test/

 

Thanks! Saw it and actually learned a few things from it right when I got to the collision detection routines in my program from before. I looked at it again, and it goes through quite a bit, just like mine does, for proper detections. One thing with mine though is probably a good quarter of total clock cycles inbetween screendraws get used on the scroll alone. Most of it with the pfscroll command (uses about 500 clock cycles per call). In fact I'm probably going to have to alternate between mario and the object/enemy characters taking turns with drawscreen. It might cause flicker, but we'll see. There's just not enough time to do it all in one game cycle. It's very doable though because I use an overall counter to loop drawscreen before executing the main mario game code, to slow it down (or else he'd book at lightning speed!), so instead of just going back to drawscreen, I'll use that opportunity to move the enemies and objects. In the meantime, I've already gone over some of my control and collision detection coding and have started optimizing it a little. We'll see if I can get it all in before I run out of clock cycles!

[Sprybug]

Update...

 

Well, I retooled my collision detection and a little of where in the code I moved Mario and not only does it work a little bit better, it also cut down on cycles and I never went over! Woot. I had a few unnecessary checks and trimmed down what it checks and once it found something it moved on instead of continuing with stuff that wouldn't have been true anyway. Now I can finally continue on with the rest and see how much more I can squeeze out before the next redraw. Once I add items to get, I'll go ahead and upload a new update. It will include power ups and the chance to become big and firey mario.

[+Gemintronic]

Just thinking about an update makes my mushroom big! Thanks for the explanation on level data and scrolling by the way.

 

Super Mario games need only scroll one way. Did you know blocks in SMB are actually stored as a sequence of blocks? Maybe storing level data as lengths of blocks instead of individual playfield pixels would extend the level size..

[Sprybug]

Just thinking about an update makes my mushroom big! Thanks for the explanation on level data and scrolling by the way.

 

Super Mario games need only scroll one way. Did you know blocks in SMB are actually stored as a sequence of blocks? Maybe storing level data as lengths of blocks instead of individual playfield pixels would extend the level size..

 

True however there's always that Atari ROM size limitation and the longer a level, the more ROM it's going to take up. I like the idea of being able to scroll left and right ala SMB 2,3, and every SMB since. Besides, it gives me more options on how I can design a level to get from point A to point B if you have to double back just to get to point B. Right now I designed the question blocks to go away once you hit them. If you end up passing them completely and have them scroll off they won't return, so you have to get them when you can. It only takes one extra variable to pull that off instead of a whole sequence of data and/or variables. To save on possible flickers, the powerups will just be a 4x4 ball that once you get it'll take you up to the next powerup level. Every sprite that isn't mario is going to take up variables because there will be times when there will be more than just one so I have to info swap with variables, and I'd rather have one extra enemy on the screen rather than the powerup that looks like a mushroom or flower. I'm also going to have to redesign some of the first level once I learned how far Mario could jump and with the new collision detection routines, he can just walk over that first gap (barely). As the AVGN once said during his TMNT review: "You can just...walk over it..."

[Nateo]

Honestly, I just played through some of the older Super Mario based demos, and this one is the best by far. Have you had the opportunity to take another look at it?

When you say take another look at it, do you mean my code to try to keep my clock cycles in check for every drawscreen? The way it is right now it won't work on a real 2600 until I fix that issue, and to do so I need to rewrite the collision detection routines. At worst I may have to call a drawscreen more than once before a game cycle is completed which will cause a little bit of flicker with the sprites because I won't plot them until they are in the right place on the screen. I haven't seen any other SMB style homebrews yet, so I'd be interested in seeing them. Actually I would LOVE to see the code for the Mega Man demo, because he seems to have gotten the gameplay and collision detection down to a T while keeping his cycles in check. I know his doesn't scroll while in action, but I might be able to implement some of it to make it work for me.

 

I can't speak too much to the programming aspect; I'm not much of a programmer, I can only accomplish the basics in a very sloppy manner. But I can speak as a player, and I really do think that the control of Mario is pin-perfect.

[+Random Terrain]

I can't speak too much to the programming aspect; I'm not much of a programmer, I can only accomplish the basics in a very sloppy manner. But I can speak as a player, and I really do think that the control of Mario is pin-perfect.

 

As a player, you must be seeing something that I'm not as a player:

 

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

 

With more work, Sprybug should be able to get his Mario to move like the one in the video above, but right now, the control isn't perfect. His Mario moves too slow and the general feel is off. But it is a good start. Something to build on until it becomes perfect.

[Nateo]

For a four-way control and only one button? I think it's as good as you can get on the 2600. I haven't seen any better, definitely not in any of the other Mario style demos.

[+Random Terrain]

For a four-way control and only one button? I think it's as good as you can get on the 2600. I haven't seen any better, definitely not in any of the other Mario style demos.

 

I'm talking about the walking speed and jumping speed. It's too slow. It's not as good as you can get on the Atari 2600. He can do better after he works on it some more.

[Nateo]

For a four-way control and only one button? I think it's as good as you can get on the 2600. I haven't seen any better, definitely not in any of the other Mario style demos.

 

I'm talking about the walking speed and jumping speed. It's too slow. It's not as good as you can get on the Atari 2600. He can do better after he works on it some more.

 

Hm... I dunno though... personally, I'd rather have it be a little too slow than a little too fast. If he goes too fast, he'll feel like he's out of control, especially without the aid of a run button to allow you switch between running and walking.

[Sprybug]

Well, it's close but it's not pin-point perfect to the SMB control. There are a few concessions I had to make because of some limitations. I can only scroll blocks at a time and not individual pixels, so when it starts scrolling the screen it moves approximately 4 pixels at a time, so no matter if you're running or walking it's going to scroll the same amount of pixels (8 pixels on a run would have been too much too fast). However, I am going to do some speed-up on the run on the draw timing delay in certain parts to make it appear like he's really speed running on the scroll. His jump and momentum does go further though on a speed run regardless. I had to be really tight on my collision detection routines so the detections aren't going to be perfect, but it's close. Just not enough cycles to play with between screen draws unfortunately, and the scroll by itself with one pfscroll command takes nearly a quarter of my available cycles away. In fact the way I have it broken down right now is this: setup level, drawscreen, prep correct sprites, color info, read the joystick, drawscreen, change position of character, scroll screen (and on screen enemies/objects) collisions detect, do what you need to do on bonuses, death, make sure position of character is correct after all of this, drawscreen, enemy routine (a slimmed down version of Mario's previous routine), drawscreen. music and sound stuff, drawscreen, Rinse and repeat. There are other occasional drawscreen calls that I do in between all these, for example, when mario powers up, it stops and does the power up animation for a moment. That's an example of that. I need as many cycles as I can get between drawscreens, so that's why I have this whole thing planned out this way. Because you get 60 FPS, once you get beyond 2 drawscreens in one entire cycle (essentially 30 fps), you'll start to notice a slow-down in game play, so once I get all this sorted out hopefully it doesn't go below 15 FPS or I should say 15 gcps (game cycles per second). I'll keep making adjustments as I go along.

[Sprybug]

Heads up. I just edited my first post to include the new update with power ups, modified collision detection to fit in the limited cycle space I have. It's still not perfect and as I go along I will make modification, but with limited time and space who knows what I'll be able to do next. So now you can turn big, become fire mario, shoot fireballs, get coins, etc. Controls are the same and up fires fireballs when fire mario. Down now ducks when big. The gameplay has slowed down a bit and that's because I call drawscreen 3 times in one game cycle. I had to. I do as much as I can before the characters move and then I call drawscreen so I have a fresh amount of cycles to play with to scroll the screen, do all my collision detections, and move mario around. Once all that is done I barely have any left and need to call another drawscreen. After that comes objects and enemies (including released fireball), then when all that is done another drawscreen is called. It's the best I can do at this moment. I also included the source this time around so you can see how I did it so far. Oh, and you probably noticed that when you hit a power block, it disappears and you automatically get what is in it. I did that to save time and that's probably how it's going to be. At least it beats having to chase down that stupid mushroom. I also made power up probablity about half right now (half the time it'll be a coin, half a power-up) so you can play around and become fire mario. When more of the game is done, I'll cut that down to probably 20% or so. The power blocks do NOT regenerate, so once you scroll one off the screen it won't come back. This is so people won't keep going back and powering up all the time. I have a timer now next to the score, but it doesn't do anything but run down. You aren't punished yet for running out of time. There is also a coin counter on the opposite side, and it goes up one block every 8 coins. You can't get that many coins in the first level so you will never see it go up. But once it goes past max (64 coins), you'll get your 1-up.

Edited July 12, 2012 by Sprybug

[+Random Terrain]

I ran around and jumped and shot and so far it hasn't gone over 262.

[Sprybug]

I ran around and jumped and shot and so far it hasn't gone over 262.

 

I got the same results. I'm going to have to keep a close eye out on it next when I do the enemies because I do need to setup the enemy initialization process on the scroll as with the repositioning on the scroll. Don't have very many cycles left to take care of that there, but that is where it needs to happen. Also when I add more levels I'm going to have to add a small subroutine to scroll the proper level. We'll see what comes of it.

[Nateo]

I'll have to try the latest ROM when I get home from work...