20 replies to this topic

[jbs30000]

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   32K   77 downloads

[Random Terrain]

He'd look better if he looked more like this:

http://www.atariage..../86620-matario/

[theloon]

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, Fri Jul 30, 2010 6:40 AM.

[TrekMD]

Looks nice! The flicker does kill you, though.

[jbs30000]

Random Terrain, on Fri Jul 30, 2010 6:18 AM, said:

He'd look better if he looked more like this:

http://www.atariage..../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.

[jbs30000]

theloon, on Fri Jul 30, 2010 6:37 AM, said:

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.

[theloon]

jbs30000, on Fri Jul 30, 2010 11:21 AM, said:

theloon, on Fri Jul 30, 2010 6:37 AM, said:

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, Fri Jul 30, 2010 12:33 PM.

[jbs30000]

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   32K   59 downloads

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, Mon Aug 2, 2010 12:51 AM.

[theloon]

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....d-acceleration/

Edited by theloon, Mon Aug 2, 2010 10:46 AM.

[jbs30000]

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.

[grafixbmp]

jbs30000, on Mon Aug 2, 2010 12:40 PM, said:

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.

[jbs30000]

I'll go over what you wrote and see if I can incorporate it. Right now I have this:
 default.bas.bin   32K   60 downloads
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.

[grafixbmp]

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....-mega-man-2600/

Edited by grafixbmp, Tue Aug 3, 2010 5:39 PM.

[Random Terrain]

I've been playing with batari's platformer source for the past couple of days:

http://www.atariage....41#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   8K   75 downloads




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, Wed Aug 4, 2010 5:17 PM.

[jbs30000]

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   32K   69 downloads
(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.

[theloon]

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....__defaultbasbin

It's smooth scrolling vertically but maybe the code can be modified for side-scrolling..!

Edited by theloon, Wed Aug 18, 2010 12:08 AM.

[theloon]

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.

Attached Files

•  sidescroll.bin   8K   96 downloads

Edited by theloon, Wed Aug 18, 2010 3:01 PM.

[jbs30000]

Wow, that is awesome. It is so much better than mine. Would you mind posting the source?

[RevEng]

theloon, on Wed Aug 18, 2010 2:37 PM, said:

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.

[theloon]

jbs30000, on Wed Aug 18, 2010 3:30 PM, said:

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!

Attached Files

•  sidescroll.bas   2.21K   47 downloads

Edited by theloon, Thu Aug 19, 2010 2:51 AM.

[jbs30000]

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.