Jump to content
IGNORED

So far so good?


jbs30000

Recommended Posts

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

Link to comment
Share on other sites

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 by theloon
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 by theloon
Link to comment
Share on other sites

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 by jbs30000
Link to comment
Share on other sites

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 by theloon
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 by grafixbmp
Link to comment
Share on other sites

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

 

post-13-128096381243_thumb.png

 

 

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 by Random Terrain
Link to comment
Share on other sites

  • 2 weeks later...

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.

Link to comment
Share on other sites

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 by theloon
Link to comment
Share on other sites

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 by theloon
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 by theloon
Link to comment
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...