130 replies to this topic

[atari2600land]

Here ya go:

[Brian O]

Wow. This is really good. The only suggestion I would make is to try and differentiate the look of the coins and power boxes (that turn you into big/fire Mario). Not sure if it is possible, though.

Love the music, too. Can't wait to see more.

-B

[Sprybug]

Brian O, on Wed Aug 15, 2012 7:06 PM, said:

Wow. This is really good. The only suggestion I would make is to try and differentiate the look of the coins and power boxes (that turn you into big/fire Mario). Not sure if it is possible, though.

Love the music, too. Can't wait to see more.

-B

Well, the one thing about the yellow power blocks is they can contain a coin or power-up and I want it to be a secret until you hit it.  One difference is that what is in the power blocks is totally random.  Mostly coins than anything else.  Since I couldn't store and keep what is in the individual blocks (lack of RAM), I decided to have it at random and the reason why I didn't have the power ups pop out was because it'd take up sprite #1's spot and I'd rather have that go to the enemies or else it'd be too easy.  Besides each row of the playfield is a set color and if I changed a row of color for one thing, it'd apply it to the rest of the playfield blocks on that row.  Too bad that when I applied flicker for the level intro screen to pull off 4 sprites (the same goes for the game over screen), it only shows half of it on the video capture (guessing you have the capture set up at 30FPS, so it only catches half of the renders).  Thanks for the putting the video up and I will be putting up one of my own when I get the latest update up, which may be this weekend.

[Sprybug]

atari2600land, on Wed Aug 15, 2012 7:06 PM, said:

Here ya go:

Thanks for that!  Too bad the capture only caught half of the screens that use flicker (Atari renders at 60fps, while a standard video shoot is 30fps which explains it).  I'll be posting my own video probably this weekend with an updated version of the game.

[Godzilla]

yea if this ever gets finished and cartridgeized, DO WANT looks great!

[Shawn Sr.]

_{This is all out fucking amazing! If you make it into a full game your not gonna be able to keep up with the number of cartridges
people are gonna want.}

[DemonoidTentacle]

Awesome! I'll be buying a cart if one is released!

[TwiliteZoner]

Very nice. That really is amazing. Especially the sound.

[Jan Hermanns]

Very well done!

But you could slightly improve the games physics.

I did some research when I programmed "Blinky goes up" (feel free to check the links below).

e.g. add acceleration and friction to make the control of Mario smoother.
Another trick is to vary the gravity. Use a higher gravity value when Mario is falling.

If you want, I can provide some assembler routines.

Greetings, Jan

Here are the links

http://www.lov3machi...inky/index.html

http://www.atariage....s-demo-release/

[Amazin]

Despite having a Harmony cart, count me in for buying a cartridge when this game gets released!!!

[the.golden.ax]

This is as good as that Mega Man demo a few years back. You have come closer than anyone on the very real desire to port this title to 2600. Shawn is right, you are going to have to beat people off with a stick due to the demand for this. The scrolling is FANTASTIC. All to often I hear people say how it can't be done on 2600.

[tremoloman2006]

HOLY ***KING $H!T!!!  LOVING THIS!!!

Awesome job!

[DT Kofoed]

Very impressive work.

However: I find the urge to recreate the original limiting. I think if you set yourself to creating original levels - using your own game 'engine' - rather than recreating the familiar ones from the original program, you can raise this from a technical demonstration into a truly great playing experience.

Just a thought.. I'm still down with this!

[Sprybug]

DT Kofoed, on Thu Aug 16, 2012 9:06 PM, said:

Very impressive work.

However: I find the urge to recreate the original limiting. I think if you set yourself to creating original levels - using your own game 'engine' - rather than recreating the familiar ones from the original program, you can raise this from a technical demonstration into a truly great playing experience.

Just a thought.. I'm still down with this!

The way I see it is that it's another Super Mario Bros. Game.  There's a lot of them out there and each one has their own quirks but play similarly.  I just updated the program to include hidden items such as 1up mushrooms, starman, and an 8X silver coin.  They come when you smash bricks, but only rarely.  I also added the ability to jump bounce off of enemies by holding down the jump button when you jump on them.

[Sprybug]

Okay folks, I just updated the 2 files at the beginning of this thread.  The new version now has secret items in blocks (8X Silver Coin, Starman, and 1UP Mushroom). You get them by busting red bricks, but they only come rarely.  You also now have the ability to jump bounce enemies, so when you hold down the jump button while jumping on an enemy, you'll bounce off of them like a regular jump.

[Sprybug]

Jan Hermanns, on Thu Aug 16, 2012 6:29 AM, said:

Very well done!

But you could slightly improve the games physics.

I did some research when I programmed "Blinky goes up" (feel free to check the links below).

e.g. add acceleration and friction to make the control of Mario smoother.
Another trick is to vary the gravity. Use a higher gravity value when Mario is falling.

If you want, I can provide some assembler routines.

Greetings, Jan

Here are the links

http://www.lov3machi...inky/index.html

http://www.atariage....s-demo-release/

I have thought about adding him "sliding" when you're running and you decide to go another direction instantly, just like the real game, but just haven't gotten to that point, plus I want to add another sprite to show him sliding.  Nobody had mentioned it yet so I thought I would hold off until people started asking about it.  Something I will probably do next.  As for falling, originally I had him falling faster as he built up falling momentum, but I found after six pixels at a time, he would occasionally start falling through platforms and that's very bad.  I could build up a beefier collision detection, but I'm so squeezed on cycle time where that needs to happen that I can't add more detections than I already have and they are already limited.  Doing a PFRead takes quite a bit of cycle time.  Now unless you have some assembly way around this, I am all ears.

[Sprybug]

the.golden.ax, on Thu Aug 16, 2012 9:44 AM, said:

This is as good as that Mega Man demo a few years back. You have come closer than anyone on the very real desire to port this title to 2600. Shawn is right, you are going to have to beat people off with a stick due to the demand for this. The scrolling is FANTASTIC. All to often I hear people say how it can't be done on 2600.

If I actually knew assembly, I could probably make it even better, and this is all done with Batari.  It just shows you how powerful it really can be.  I don't even consider myself all that great of a programmer either.  I've just been doing it as a hobby since I was 9 years old so I could make my own computer games.  Now if I can pull something like this off in Batari then a lot of other people should be able to do it and probably better than me.

[Jan Hermanns]

Sprybug, on Fri Aug 17, 2012 2:50 AM, said:

Jan Hermanns, on Thu Aug 16, 2012 6:29 AM, said:

Very well done!

But you could slightly improve the games physics.

I did some research when I programmed "Blinky goes up" (feel free to check the links below).

e.g. add acceleration and friction to make the control of Mario smoother.
Another trick is to vary the gravity. Use a higher gravity value when Mario is falling.

If you want, I can provide some assembler routines.

Greetings, Jan

Here are the links

http://www.lov3machi...inky/index.html

http://www.atariage....s-demo-release/

I have thought about adding him "sliding" when you're running and you decide to go another direction instantly, just like the real game, but just haven't gotten to that point, plus I want to add another sprite to show him sliding.  Nobody had mentioned it yet so I thought I would hold off until people started asking about it.  Something I will probably do next.  As for falling, originally I had him falling faster as he built up falling momentum, but I found after six pixels at a time, he would occasionally start falling through platforms and that's very bad.  I could build up a beefier collision detection, but I'm so squeezed on cycle time where that needs to happen that I can't add more detections than I already have and they are already limited.  Doing a PFRead takes quite a bit of cycle time.  Now unless you have some assembly way around this, I am all ears.

I ran in exactly the same problem. Regarding the issue when Mario is falling through platforms, the solution is to limit the falling speed to a certain maximum value. Just choose an appropriate value and you dont need to pimp up your collision detection.

[Sprybug]

Jan Hermanns, on Fri Aug 17, 2012 3:07 AM, said:

Sprybug, on Fri Aug 17, 2012 2:50 AM, said:

Jan Hermanns, on Thu Aug 16, 2012 6:29 AM, said:

Very well done!

But you could slightly improve the games physics.

I did some research when I programmed "Blinky goes up" (feel free to check the links below).

e.g. add acceleration and friction to make the control of Mario smoother.
Another trick is to vary the gravity. Use a higher gravity value when Mario is falling.

If you want, I can provide some assembler routines.

Greetings, Jan

Here are the links

http://www.lov3machi...inky/index.html

http://www.atariage....s-demo-release/

I have thought about adding him "sliding" when you're running and you decide to go another direction instantly, just like the real game, but just haven't gotten to that point, plus I want to add another sprite to show him sliding.  Nobody had mentioned it yet so I thought I would hold off until people started asking about it.  Something I will probably do next.  As for falling, originally I had him falling faster as he built up falling momentum, but I found after six pixels at a time, he would occasionally start falling through platforms and that's very bad.  I could build up a beefier collision detection, but I'm so squeezed on cycle time where that needs to happen that I can't add more detections than I already have and they are already limited.  Doing a PFRead takes quite a bit of cycle time.  Now unless you have some assembly way around this, I am all ears.

I ran in exactly the same problem. Regarding the issue when Mario is falling through platforms, the solution is to limit the falling speed to a certain maximum value. Just choose an appropriate value and you dont need to pimp up your collision detection.

And that's why I set the maximum falling rate to 6.  You had mentioned him falling faster and I just said why I don't have him falling any faster than he is now.  As soon as there's nothing below him, his north/south momentum goes up one pixel every game cycle until it reaches 6.  I would have liked it to be a little more than that.

[PFL]

More genius at the Atariage forum.  This is super impressive.  +1 on a cart too!

[MausGames]

This looks and plays similar, but better than my DPC+ smb attempt. You should seriously consider the jump, DPC+ is perfect for this and Melody boards are well worth their price.

[theloon]

I kinda didn't realise DPC+ didn't have pfread working yet.  Even though I suggested it to Batari many moons back.  He would have to change the pfread statements into something that reads the level data instead.

[Sprybug]

theloon, on Fri Aug 17, 2012 4:00 PM, said:

I kinda didn't realise DPC+ didn't have pfread working yet.  Even though I suggested it to Batari many moons back.  He would have to change the pfread statements into something that reads the level data instead.

Yeah, from what I understand it's still kinda buggy which is why I haven't used it, and not just that there are a few things I wouldn't be able to do that I can do now as well.

[theloon]

Sprybug, on Sat Aug 18, 2012 3:24 AM, said:

theloon, on Fri Aug 17, 2012 4:00 PM, said:

I kinda didn't realise DPC+ didn't have pfread working yet.  Even though I suggested it to Batari many moons back.  He would have to change the pfread statements into something that reads the level data instead.

Yeah, from what I understand it's still kinda buggy which is why I haven't used it, and not just that there are a few things I wouldn't be able to do that I can do now as well.

Sorry for more technical questions than review.. but, how difficult would it be to replace those pfread commands with reading level data anyway?  What approach would you take?

[Sprybug]

theloon, on Sat Aug 18, 2012 6:14 AM, said:

Sprybug, on Sat Aug 18, 2012 3:24 AM, said:

theloon, on Fri Aug 17, 2012 4:00 PM, said:

I kinda didn't realise DPC+ didn't have pfread working yet.  Even though I suggested it to Batari many moons back.  He would have to change the pfread statements into something that reads the level data instead.

Yeah, from what I understand it's still kinda buggy which is why I haven't used it, and not just that there are a few things I wouldn't be able to do that I can do now as well.

Sorry for more technical questions than review.. but, how difficult would it be to replace those pfread commands with reading level data anyway?  What approach would you take?

Is it still possible to use the screen variables to be able to do reads?