NES -> Atari 2600 port

[8th lutz]

 

I made that pic myself, without being sure if the 2600 can handle it. 

991750[/snapback]

That is an impressive picture. I think the 5200 is more likely to do that picture then the 2600. I have played 2600 games including rador lock, and solaris. I may have to play Road Runner to check. The bricks in the picture could look similar on the 2600. The Characters shouldn't be able to look like that on 2600. That part looks more like Atari 5200/ atari 8 bit computer, or the Colecovision for Mario. Silver_surfer is doing a great Job with his version.

Edited December 31, 2005 by 8th lutz

[simbalion]

I showed a friend that is a Metroid fanatic this thread and he was quite impressed with the mockups that have been shown for possible Metroid 2600 sprites. He says that Samus looks better in the mock-ups in some ways than she does on the NES! He showed me a screen from the NES and he is right. The graphics actually look bland on it.

[Pixelboy]

That is an impressive picture.

Thanks for the compliment!

 

I think the 5200 is more likely to do that picture then the 2600.  I have played 2600 games including rador lock, and solaris.  I may have to play Road Runner to check.  The bricks in the picture could look similar on the 2600.

I certainly hope so, since there are 2600 games (like Crystal Castles) with much more detailed backgrounds... The way I picture my rendition of SMB, the screen would scroll in blocks of 16 pixels, not unlike how it's done in Gateway to Apshai on the ColecoVision. It would be choppy scrolling, but it would make collision detection far easier to implement for when Mario hits a brick from under.

 

Also note that each column of bricks could be stored using just 4 bits of data: 3 for the suspended bricks, and the last bit would be used for the ground bricks. The rest would be just rendering logic (which is beyond my current understanding of the 2600, mind you...)

 

 

The Characters shouldn't be able to look like that on 2600.  That part looks more like Atari 5200/ atari 8 bit computer, or the Colecovion for Mario.

I don't see what problem my character objects would pose for the 2600, aside perhaps for Mario's hands. I don't know much about the hardware, but I'm only using two colors for each object (black parts are actually transparent, which is why the background should remain black in all levels of the game), and Mario is only 8 pixels wide, just like Silver_Surfer's version, and it's also roughly the same height. Seing how Activision was able to render similar ghaphics with great detail in their games (especially Keystone Kapers), I can see no reason why the 2600 couldn't handle my rendition of SMB...

[8th lutz]

I certainly hope so, since there are 2600 games (like Crystal Castles) with much more detailed backgrounds... The way I picture my rendition of SMB, the screen would scroll in blocks of 16 pixels, not unlike how it's done in Gateway to Apshai on the ColecoVision. It would be choppy scrolling, but it would make collision detection far easier to implement for when Mario hits a brick from under.

 

Also note that each column of bricks could be stored using just 4 bits of data: 3 for the suspended bricks, and the last bit would be used for the ground bricks. The rest would be just rendering logic (which is beyond my current understanding of the 2600, mind you...)

 

I don't see what problem my character objects would pose for the 2600, aside perhaps for Mario's hands. I don't know much about the hardware, but I'm only using two colors for each object (black parts are actually transparent, which is why the background should remain black in all levels of the game), and Mario is only 8 pixels wide, just like Silver_Surfer's version, and it's also roughly the same height. Seing how Activision was able to render similar ghaphics with great detail in their games (especially Keystone Kapers), I can see no reason why the 2600 couldn't handle my rendition of SMB...

991849[/snapback]

I decided to check again with your picture, I see what your talking about with Mario. I am only guessing, since I have no Experience with progamming games and had very little regular programming outside of games and it was 10 years ago. I went by pictures of games for the 5200 and colecovision. The game it is capable of being on a 2600 since Pitfall 2 is on the 2600. I questioned Mario before because of the amount memory that a 2600 game cartridge has is 32k I am aware, along with what I played saw. Also ColecoVision has a different processor then the 2600. There has to be something sacrifice in graphics or cut down on levels to make the game fit. I am sure the graphics would improve due to size and the tools available. What you show on screen be different in actual gameplay. I know what your talking about activision games showing 2600 game capabilities, I own some of their games including pitfall 1&2. I do think that company is a good reference for seeing what a 2600 game can do.

Edited December 31, 2005 by 8th lutz

[supercat]

I certainly hope so, since there are 2600 games (like Crystal Castles) with much more detailed backgrounds... The way I picture my rendition of SMB, the screen would scroll in blocks of 16 pixels, not unlike how it's done in Gateway to Apshai on the ColecoVision. It would be choppy scrolling, but it would make collision detection far easier to implement for when Mario hits a brick from under.

991849[/snapback]

 

One useful way to think of the 2600 is that there are a number of display registers that have certain effects; they may be changed as often or as seldom as desired, but updating any of them takes time, which is a very limited commodity on the 6507. The CPU will execute 76 cycles per scan line, and instructions take 2-8 cycles each; a typical register update will take 6-8 cycles (unless two or more registers are being loaded with the same thing, in which case the additional registers take 3).

 

If a sprite keeps the same shape or color from one scan line to the next, it does not need to be reloaded. If the playfield stays the same from one line to the next AND the right half matches the left half either reflected or non-reflected, it does not have to be reloaded.

 

There is barely time to show a 32-block-wide assymmetric playfield and two full-color sprites at full resolution in a scan line, but that doesn't leave much time for some of the other necessary computations. If the players were only half-resolution things would be much more practical. Even then, however, RAM might still be a problem since the Atari only has 128 bytes. An expanded-RAM cart would help things a lot, however, and might make things almost possible.

[Pixelboy]

If a sprite keeps the same shape or color from one scan line to the next, it does not need to be reloaded.  If the playfield stays the same from one line to the next AND the right half matches the left half either reflected or non-reflected, it does not have to be reloaded.

 

There is barely time to show a 32-block-wide assymmetric playfield and two full-color sprites at full resolution in a scan line, but that doesn't leave much time for some of the other necessary computations.  If the players were only half-resolution things would be much more practical.  Even then, however, RAM might still be a problem since the Atari only has 128 bytes.  An expanded-RAM cart would help things a lot, however, and might make things almost possible.

I see, so what you're saying is that a game like my rendition of SMB would be very graphically intensive for the poor ol' 2600 (I would understand better if I knew what "block" and "half-resolution" mean in your explanation), and sprite flicker would probably be necessary when there are more than 2 objects on the screen... It really makes one realize how good those Activision programmers were back in the day.

 

Well, I guess that settles it: I'll stick to the ColecoVision from now on.

[bowser724]

Lord knows that the ole 2600 needs more action-type puzzle games so I chose Dr. Mario. Okie Dokie is good too, but it makes me bored very quickly with its limited gameplay (don't jump on my head about this it's just my opinion).

[supercat]

Lord knows that the ole 2600 needs more action-type puzzle games so I chose Dr. Mario. Okie Dokie is good too, but it makes me bored very quickly with its limited gameplay (don't jump on my head about this it's just my opinion).

991972[/snapback]

 

If I recall correctly, Okie Dokie allows any square to be toggled, regardless of its state. This means that all one has to do to 'solve' it is determine which squares need an even or odd number of flips. The ones that need an odd number, flip once. Those that need an even number, simply leave alone.

 

The game could be made much more interesting by requiring that only squares that are already in the 'final' state (is all on or all off the goal?) can be toggled. This means that computing the basis vector is no longer sufficient for finding a solution. To be sure, it will indicate which squares must be hit an even or odd number of times, but some squares will have to be hit two or three times instead of all squares being hit zero or one time.

[vdub_bobby]

A few quick hits here:

 

A Metroid port for the 2600 is very doable. It would require compromises, but I think it would be recognizable, in look, sound, and gameplay, as Metroid.

 

On the other hand...I don't think a 2600 SMB port is really possible. Well, anythings possible with massive flicker, I suppose, but I think the visual demands are too much. Look at almost any screenshot: it will have 3 different background objects that can interact with Mario, each of which needs to look distinct. (Think: unbreakable bricks, breakable bricks, and coin boxes). These not only have to look distinct, they have to scroll horizontally. And don't really think about using sprites for any of those objects, because you not only have Mario onscreen, you can also have 3+ enemies onscreen at the same time. And almost nothing, Mario, enemies, or any of the 3+ background objects, are restricted as to where on the screen they can be.

 

You could maybe do it with playfield color striping; say blue for the unbreakable bricks, yellow for the breakable bricks, and white for the coin boxes (or whatever), but that's a pretty significant compromise in the look of the game. Too significant, to my mind.

[Impaler_26]

Hi there!

 

I voted for donkey kong 3 coz the 2600 versions of donkey kong and donkey kong jr. suck.

 

a good donkey kong game for the 2600 would be nice.

 

Careful what you wish for. DK3 is a mediocre shoot'em up, sorta like Centipede crossed with Space Invaders.

 

Greetings,

Manuel

991442[/snapback]

 

 

I know, i played it on the NES and i liked it...

[TheHoboInYourRoom]

Man, oh man is this thread making me crave Metroid on the VCS, and I'm absolutely loving the music and the mock-ups.

[Atariboy2600]

I really hope some programer will make this Super MArio Bros game for the 2600 cuase I REALLY wanted one, baldly!

[Atariboy2600]

If I had to pick my second game to be made from the list it had to be Metroid.

[~llama]

A Metroid port for the 2600 is very doable.  It would require compromises, but I think it would be recognizable, in look, sound, and gameplay, as Metroid.

992058[/snapback]

 

How would you jump? Push up? If that's the case, then how would you shoot up? Perhaps a two-controller Robotron scheme

Edited January 4, 2006 by ~llama

[Shawn]

Neither Mario nor Metroid or any other pipe dream fantasies are gonna be one the VCS. Only way it would happeen is if you do it yourself. That was my reason for making Mario Rescue cause that is as close as your gonna get cause lets face it there is alot more "I wants" around here than there is "I made".

[Shawn]

Looks pretty good, but I was thinking more along the lines of this:

 

 

I made that pic myself, without being sure if the 2600 can handle it. 

991750[/snapback]

 

 

I played a VCS game with graphics like that once... In ZzzZZZzz land while dreaming I was a millionare.. That picture looks very nice but its is FAR past the 2600 limits.

Edited January 4, 2006 by silver_surfer

[vdub_bobby]

Neither Mario nor Metroid or any other pipe dream fantasies are gonna be one the VCS. Only way it would happeen is if you do it yourself.

Well, obviously. That's why I might do Metroid myself.

 

As to the controls...that's a sticky problem. I was thinking:

Autofire when you hold the fire button down.

 

D = go into ball

U = jump

LR = run

FIRE = shoot

FIRE then U = fire up w/o jumping

 

Problem with this: you have to stop shooting, at least momentarily, to jump. Plus a little clumsy. Other ideas?

[Atariboy2600]

A Metroid port for the 2600 is very doable.  It would require compromises, but I think it would be recognizable, in look, sound, and gameplay, as Metroid.

992058[/snapback]

 

How would you jump? Push up? If that's the case, then how would you shoot up? Perhaps a two-controller Robotron scheme

993479[/snapback]

 

Yes I think there's a way to do this on both Metroid and Super Mario Bros on the Jump button.

 

You can use theTelegames Super Deluxe Joystick (aka 7800's Pro-Line Joystick) or the Atari 7800 Joypad. Or better yet the Sega Mater System Control Pad and the Genesis pad. just need to fine a way to make the game to see the second button to Jump or Fire.

[Shawn]

Neither Mario nor Metroid or any other pipe dream fantasies are gonna be one the VCS. Only way it would happeen is if you do it yourself.

Well, obviously. That's why I might do Metroid myself.

 

As to the controls...that's a sticky problem. I was thinking:

Autofire when you hold the fire button down.

 

D = go into ball

U = jump

LR = run

FIRE = shoot

FIRE then U = fire up w/o jumping

 

Problem with this: you have to stop shooting, at least momentarily, to jump. Plus a little clumsy. Other ideas?

993499[/snapback]

 

 

 

If you use UP UP as jump you could still be able to aim while holding a sinlge press of UP. I would love to see Metroid when you get some work started. Put me down as "will buy a cart" for your list.

[Atariboy2600]

If you set up the button like the NES pad B: For Fire and A: For Jump then you can play both Super Mario and Metroid on the 2600, Also the same on Sega Master System or Genesis pad as well.

Edited January 4, 2006 by Atariboy2600

[8th lutz]

If you set up the button like the NES pad B: For Fire and A: For Jump then you can play both Super Mario and Metroid on the 2600, Also the same on Sega Master System or Genesis pad as well.

993567[/snapback]

Your thumbnail was 2 different 7800 controllers not 2600 controllers. It is the right set up for for those two games, though.

[Cybergoth]

Hi there!

 

If you set up the button like the NES pad B: For Fire and A: For Jump then you can play both Super Mario and Metroid on the 2600, Also the same on Sega Master System or Genesis pad as well.

993567[/snapback]

 

Just for the record, the 2600 can't distinguish the fire buttons of 7800 controlers. Coleco or Sega controlers might work though.

 

Greetings,

Manuel

[Pixelboy]

Just for the record, the 2600 can't distinguish the fire buttons of 7800 controlers. Coleco or Sega controlers might work though.

993715[/snapback]

I used to play my Atari 2600 with a ColecoVision controller (it's the only compatible controller I had at the time), and I know the other trigger button didn't work with the 2600. The keypad didn't work either, obviously.

[Cybergoth]

Hi there!

 

Just for the record, the 2600 can't distinguish the fire buttons of 7800 controlers. Coleco or Sega controlers might work though.

I used to play my Atari 2600 with a ColecoVision controller (it's the only compatible controller I had at the time), and I know the other trigger button didn't work with the 2600.

 

Certainly. Since the 2600 can distinguish those buttons, in standard games only one of them works. You should try Omega Race, Spy Hunter or Stargate with the other button, there it might make a difference.

 

Greetings,

Manuel

[ZylonBane]

The 7800 buttons map to the paddle lines, so theoretically the 2600 could read them.

 

Theoretically...