jbs30000 Posted July 30, 2010 Share Posted July 30, 2010 A while ago I was working on a bB Super Mario Bros game. It wasn't too bad, but I hadn't gotten very far because the more I worked on it the harder it was to make it, and then about a month ago my hard drive died, and like an idiot I didn't back up everything. So I'm starting over. So far all I have is Mario on the title screen. You can walk him back and forth and make him jump. Does the flicker seem like too much of a problem? default.bas.bin Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted July 30, 2010 Share Posted July 30, 2010 He'd look better if he looked more like this: http://www.atariage.com/forums/topic/86620-matario/ Quote Link to comment Share on other sites More sharing options...
+Gemintronic Posted July 30, 2010 Share Posted July 30, 2010 (edited) Looks like a good beginning tech demo. The legs seem to need a little work. Also, variable jump would be very nice. One thing that steers me away from flicker is that, even if your audience uses real Atari 2600, their TVs are all LCD, DLP or plasma - no phosphor burn-in. The kiddies that didn't grow up with the 2600 are all using emulators where the phosphor burn feature is optional (if present at all.) Still, I always wondered what flickering different colors would look like on a playfield. Now I know it's strictly for old TVs. Dat flicker effect would kill an epileptic It looks like you're using both player0 and player1 sprites to create a multi-colored Mario. I'm curious as to how 'yer gonna include enemy sprites with both players used (if that's your technique) Edited July 30, 2010 by theloon Quote Link to comment Share on other sites More sharing options...
TrekMD Posted July 30, 2010 Share Posted July 30, 2010 Looks nice! The flicker does kill you, though. Quote Link to comment Share on other sites More sharing options...
jbs30000 Posted July 30, 2010 Author Share Posted July 30, 2010 He'd look better if he looked more like this: http://www.atariage.com/forums/topic/86620-matario/ That is a pretty cool sprite. I was trying for the original arcade version. The giant Mario looks more like the Mario in that link, so I'll probably make my giant Mario more like that. Quote Link to comment Share on other sites More sharing options...
jbs30000 Posted July 30, 2010 Author Share Posted July 30, 2010 It looks like you're using both player0 and player1 sprites to create a multi-colored Mario. I'm curious as to how 'yer gonna include enemy sprites with both players used (if that's your technique) Yes I am. Enemies will have to be players 0 and 1 drawn in different positions and collisions will have to be determined by coordinates. And of course drawing the players in two different locations will cause them to flicker with the screen. Quote Link to comment Share on other sites More sharing options...
+Gemintronic Posted July 30, 2010 Share Posted July 30, 2010 (edited) It looks like you're using both player0 and player1 sprites to create a multi-colored Mario. I'm curious as to how 'yer gonna include enemy sprites with both players used (if that's your technique) Yes I am. Enemies will have to be players 0 and 1 drawn in different positions and collisions will have to be determined by coordinates. And of course drawing the players in two different locations will cause them to flicker with the screen. You might try using a technique I used for my CandyBar game. I used playfield pixels for the pink color in the Chefs face. Maybe you could use that for Mario and or the enemies.. just move the playfield pixels with the sprites. Tradeoffs: Unless you increase the resolution of the playfield the movement is choppy since you have to move the whole sprite a playfield pixel at a time. Also, you're always "colliding" with the playfield pixels coloring your sprite so hardware collision is out. Edited July 30, 2010 by theloon Quote Link to comment Share on other sites More sharing options...
jbs30000 Posted August 2, 2010 Author Share Posted August 2, 2010 (edited) OK, after trying to remain faithful to the original arcade when it came to making the Mario sprite, I gave up. What I have is closer to the other Mario game linked to earlier. It's not great, but it'll do. I also decided not to flicker the screen. His jump while walking needs work, but I'll fix it. default.bas.bin But I have a question. This time, and the last time I attempted this game, I got the same complaint. You guys want it so that the longer you hold down the joystick the higher Mario goes. And of course the shorter you hold it the less he jumps. I don't know how to do that. As he's jumping I could see if the button is being pressed, but then he'd jump off of the screen. If any of you know how to do this I'll see about working it into the game. Edited August 2, 2010 by jbs30000 Quote Link to comment Share on other sites More sharing options...
+Gemintronic Posted August 2, 2010 Share Posted August 2, 2010 (edited) In a different programming language I think the technique was to have a vspeed variable that determined the upward velocity of Mario. If the player is still pressing JUMP (a.k.a. FIRE) then vspeed = -5 else vspeed = -3 or something. In other words, if the player stops pressing fire his upward leap is less. UPDATE: I think this thread on acceleration could help: http://www.atariage.com/forums/topic/139926-horizontal-friction-and-acceleration/ Edited August 2, 2010 by theloon Quote Link to comment Share on other sites More sharing options...
jbs30000 Posted August 2, 2010 Author Share Posted August 2, 2010 I see what you're getting at, but it's a little more complicated than that. I guess what I can do is have a counter that, while being counted Mario goes up. If the fire button is being pushed it's y-2, if not it's y-1. Quote Link to comment Share on other sites More sharing options...
+grafixbmp Posted August 3, 2010 Share Posted August 3, 2010 I see what you're getting at, but it's a little more complicated than that. I guess what I can do is have a counter that, while being counted Mario goes up. If the fire button is being pushed it's y-2, if not it's y-1. I would say as far as jumping, There would be a maximum height that runs its full course as long as the button is still being pressed. If the button is not being pressed any longer durring the initial part of the jump, the last leg of the jump height is in turn jumped to automaticaly. Like (sudocode) jump height = 18 ;this is the maximum height of any jump crescendo = 3 ; this is a sine like slowndown at the top of the jump before the fall ; on a side note, any horizontal movement from the stick after being airborne is cut in half if button press then y = y-1 jump height = jump height -1 if no button press then go to crescendo if jump height = 0 goto crescendo crescendo ; just a slower process for the last 2 or 3 pixels at the top that also begins the drop down. then just check for your floor. I hope you get a basic idea of what I mean. Quote Link to comment Share on other sites More sharing options...
jbs30000 Posted August 3, 2010 Author Share Posted August 3, 2010 I'll go over what you wrote and see if I can incorporate it. Right now I have this: default.bas.bin It's harder to jump while walking to the left for some reason, I'll have to fix that. But at any rate, a quick press of the fire button has him go lower than long press. It's not that great though, so I'll see about your method. Anyway, while having Mario jump I also have to check to see if he hits any blocks above him, which would stop him from going up, or if he hits an enemy to kill him, so I can't make his jump routine too elaborate. Quote Link to comment Share on other sites More sharing options...
+grafixbmp Posted August 3, 2010 Share Posted August 3, 2010 (edited) A few things that need tweaking is: need some horizontal control while mid air. Not much but some. At any time in the air there needs to be a complete sense of loose control even when falling so you can control to an extent where you will land. And theloon is right about a velocity control. This is key for a crescendo. And as far as checking for blocks. This should instantly knock him back down thereby bypassing any crescendo code. I actually asked about jump coding and I thought that the megaman demo had great jumping. the source code was available at http://www.atariage.com/forums/topic/146936-making-of-mega-man-2600/ Edited August 3, 2010 by grafixbmp Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted August 4, 2010 Share Posted August 4, 2010 (edited) I've been playing with batari's platformer source for the past couple of days: http://www.atariage.com/forums/topic/143772-platformer-source/page__p__1750241#entry1750241 You might be able to adapt it. I don't understand the code yet because there aren't many rem statements explaining what is going on, but here's what I've done so far: batari_platformer_adapted_by_random_terrain_2010y_08m_04d_1634t.bin Ever since batari posted his platformer code, I wanted to use it to make my own game, but I was doing other stuff. I need to change the look of the guy, have randomly placed platforms (using controlled randomness) and figure out what the game is about. Edited August 4, 2010 by Random Terrain Quote Link to comment Share on other sites More sharing options...
jbs30000 Posted August 14, 2010 Author Share Posted August 14, 2010 I've come upon a setback. I decided to skip Mario jumping and focus on "scrolling". I put the word in parentheses because what I came up with, well it is pretty much scrolling I guess. But it took a ton of code and came out too jerky. Plus some of the graphics get messed up. default.bas.bin (hit the fire button to get to the scrollable playfield) For instance, scrolling towards the right you'll see two pipes next to each other. There should be only one. And the lower blocks kind of get messed up while getting scrolled. I made the clouds move only half as often as everything else to give the game a more realistic look, but that didn't turn out well either. So unless anyone knows of a good way to horizontally scroll, I guess I'll have to have the game just switch screens every time Mario makes it to the far right side of the screen. Quote Link to comment Share on other sites More sharing options...
+Gemintronic Posted August 17, 2010 Share Posted August 17, 2010 (edited) I hope you continue to challenge this, er, challenge! Side scrolling platforming would be awesome! I'm trying to scroll and clear the far side that's scrolling then add in the new blocks. Timing is a big deal and so far I've not got it right. UPDATE: Check out the code in this topic: http://www.atariage.com/forums/topic/148427-vertical-scrolling-through-a-playfield-that-wont-fit-the-screen/page__hl__defaultbasbin It's smooth scrolling vertically but maybe the code can be modified for side-scrolling..! Edited August 18, 2010 by theloon Quote Link to comment Share on other sites More sharing options...
+Gemintronic Posted August 18, 2010 Share Posted August 18, 2010 (edited) Sorry to post again but I think it's possible. This is a test without level data loading: While up-down scrolling is pixel perfect I think Batari BASIC can only do side scrolling a playfield pixel at time. Basically, pfscroll and then load each new tile column a vertical line of pixels at a time. sidescroll.bin Edited August 18, 2010 by theloon Quote Link to comment Share on other sites More sharing options...
jbs30000 Posted August 18, 2010 Author Share Posted August 18, 2010 Wow, that is awesome. It is so much better than mine. Would you mind posting the source? Quote Link to comment Share on other sites More sharing options...
RevEng Posted August 19, 2010 Share Posted August 19, 2010 While up-down scrolling is pixel perfect I think Batari BASIC can only do side scrolling a playfield pixel at time. Yup, though it's a 2600 limitation, rather than a batari Basic one. Nice demo! It looks like you're hitting 263 scanlines instead of the usual 262, but that should be easily enough fixed up. Quote Link to comment Share on other sites More sharing options...
+Gemintronic Posted August 19, 2010 Share Posted August 19, 2010 (edited) Wow, that is awesome. It is so much better than mine. Would you mind posting the source? No prob. Actually, it's all eye candy. Your binary seems to have level/tile loading which is beyond me at the moment. I just wanted to show what the potential for side scrolling was. As RevEng noted there may be cycle issues and I couldn't get it to play on a 2600 emulator for PSP. I think how a side-scrolling engine would work is the level data is stored as strips of 8 vertical tiles. Each tile would be a 4x4 block of pixels (Assuming a 32x32 pixel playfield). When the player "moves" right the pfscroll left command would execute. Most of the screen looks to have scrolled but the last vertical line of pixels gets wrapped around and is now effectively garbage. We must draw over that wrapped line of pixels with a strip from our level data. We determine which strip to load and then further determine which line of pixels from the tiles to draw. Using pfpixel the routine should then draw that vertical line. As a side the rem'ed out lines are code I used to determine when I ran out of playfield data. The turtle like object between the pipes is actually just a leftmost pixel and rightmost pixel to demark the edges. The rem if !pfread(15,26) then pfscroll right and rem if !pfread(18, 26) then pfscroll left were commented out collision detection using playfield pixel reads instead of collision commands. Remember: the player is stationary but the playfield pixels move! sidescroll.bas Edited August 19, 2010 by theloon Quote Link to comment Share on other sites More sharing options...
jbs30000 Posted August 20, 2010 Author Share Posted August 20, 2010 Thank you theloon, although my code is fairly basic, but uses LOTS of code. Too much code in fact, and I completely forgot about the bB scroll commands. This weekend I'll work on re-doing the code to make it smoother. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.