NES -> Atari 2600 port

[mäsäxi]

Super Mario is gonna look bad on 2600...and I don't mean bad as in good.

941616[/snapback]

 

 

Super Mario Bros. would be cool, but I don't think the 2600 could do it justice.

943011[/snapback]

 

 

Sounds like you want to get 2600 SMB which has as good graphics as arcade version had.

 

In the past, graphically many 2600 games didn´t do any justice to originals. (And people liked to play them!)

 

So what? If someone makes Super Mario Bros to it I surely will play it! So what, if "bricks" are just solid blocks as long as game is playable! Playability is the most important thing to me!

 

And when you look at 2600 versions of Mario Bros and Donkey Kong, you can clearly see that at least Mario can be easily make to look good. And to me it is enough if mario and koopas look good! Scenery can be blocky, as scenery is blocky in most 2600 games anyway.

[Serguei2]

>The legend of Zelda

>Final Fantasy

 

Hmmm. Could be possible making a 2600 game with battery system?

[Shawn]

If the Super Mario Bros was to be true at least to game play and Mario was able to to obviously look just as good as he did in DK or Mario Bros then HELL YES, I would love have 2600 SMB. But how the heck would the whole game (as in 1-1 to 8-4) be able to get on a 2600 cart? That is the first problem I see is that I don't think it would fit as far as I know of 2600 chips.

 

This is a great topic of discussion but it just pains me to to get my hopes all roared up when there is a good chance it won't amount to much more than a good chat. I want a game damn it!!

[tmont]

It's been awhile since I played [sMB].  How many different types of bricks are there, and how many bricks across the screen?  If the bricks were drawn with a striped playfield, how often would there be more than two, or more than four, other moving objects per scan line?

944757[/snapback]

If I recall correctly, there's three different types: a regular brick that can be broken with Mario's oversized head, a coin box, and a coin box that has already been hit (unbreakable). Of course, there's the 10-coin boxes, the vine boxes, the mushroom/flower boxes, and so on. But physically, there's only three (I think). And since the NES lagged like a whore whenever there was more than 4 moving things per screen, I can't imagine that you'd need more than three moving objects per screen/scan line. But I know little about 2600 programming. Hmmm, but then there's Bowser's hammers that he throws, and of course the Hammer Bros., so there might be as many as five moving objects on the screen at once, but the hammers don't stay very long. And for the 2600, it's probably not necessary to have more than two or three hammers throwing at a time; I think most of that was just for visual effect.

 

 

So what? If someone makes Super Mario Bros to it I surely will play it! So what, if "bricks" are just solid blocks as long as game is playable! Playability is the most important thing to me! 

 

And when you look at 2600 versions of Mario Bros and Donkey Kong, you can clearly see that at least Mario can be easily make to look good. And to me it is enough if mario and koopas look good! Scenery can be blocky, as scenery is blocky in most 2600 games anyway.

I'm more concerned that the control will be more like Mario Bros. (for 2600) than Super Mario Bros. for NES. Mario Bros. was cool, but the control of the character was so unwieldy that it just wasn't very fun. The control for SMB on NES was bad enough compared to games later in the series that I don't really enjoy playing it that much anymore. However, it might be cool to not make a direct port of SMB, and to add little splashes of your own creativity to make it more interesting. Like, new enemies, new levels, time attacks (i.e. races), different bosses, etc. Just speculating...

Edited October 9, 2005 by HeckYesIDid

[jussts]

I think it's too much to ask for these games to be done well on the 2600. They are more suited to the 7800 or Lynx.

943964[/snapback]

On the contrary, I think you could do a fantastic port of many of these.

 

EDIT: Here's a possible, very doable mockup for Metroid. I think Thrust-style scrolling would be best for this.

943970[/snapback]

 

I took a few minutes to figure out how I would adapt Samus' sprites from the original NES Metroid into something that would work on the VCS. If you put them side by side they appear quite different (mine actually more closely resembles Samus from later games in the series) but I think think that the overall change is justified. The NES sprite relies heavily on color to give it its definition... so, after you lose that and then shrink and stretch the sprite to the proper size, you've got a messy blob that only vaguely resembles the original. I basically just started from scratch after failing to recreate the sprite in the fashion described above. I've placed it in vdub_bobby's mockup to give it some context. If anyone is interested in taking on the project, I'm still interested in doing all the sprites.

Edited October 10, 2005 by jussts

[vdub_bobby]

Here are a couple of screenshots of SMB.

 

The main screenshot types that are missing are the cloud bonus "levels," the levels that look like 1-1 through 1-3 but have a black sky, the water levels, and the castle levels (which look similar to the inside-the-pipe screenshots).

 

EDIT: Added some of the missing screenshots.

Edited October 10, 2005 by vdub_bobby

[cd-w]

Here are a couple of screenshots of SMB.

The main screenshot types that are missing are the cloud bonus "levels," the levels that look like 1-1 through 1-3 but have a black sky, the water levels, and the castle levels (which look similar to the inside-the-pipe screenshots).

945589[/snapback]

 

I'm not sure how you could ever pull this off on the 2600? The best that could probably be done would be a blue/yellow striped playfield as in this post for the background. This would allow a range of different block types to be defined. The player sprites could then be used for Mario and the various monsters, and the missile sprites for the coins, but it would almost certainly require a lot of flicker.

 

Chris

[supercat]

The player sprites could then be used for Mario and the various monsters, and the missile sprites for the coins, but it would almost certainly require a lot of flicker.

945682[/snapback]

 

Why the missiles for the coins? Use the playfield for whatever the "grab 'em" object is. I don't see any need to make a perfect port of Mario, especially since the licensing would never happen, so things could probably be simplified so that there wouldn't be too many places with escessive objects per scan line.

[Omegamatrix]

I voted for Excitebike, because after playing Motorodeo I feel that Excitebike could be a good possibility on the 2600. It could really be stripped down, and still be a lot of fun to play. Secretly though I would kill for a Metroid game. I would love to see it pulled off, but I just can't imagine a 2600 version having a big enough world to explore. I hope someone proves me wrong. Please, please prove me wrong.

[vdub_bobby]

I voted for Excitebike, because after playing Motorodeo I feel that Excitebike could be a good possibility on the 2600. It could really be stripped down, and still be a lot of fun to play. Secretly though I would kill for a Metroid game. I would love to see it pulled off, but I just can't imagine a 2600 version having a big enough world to explore. I hope someone proves me wrong. Please, please prove me wrong.

946169[/snapback]

Well...the Metroid mockup I posted would require about 64 bytes for the platforms (playfield data). Maybe less if you simplified a little and compressed some. I'll be conservative and say 64 bytes.

 

According to a map I got somewhere, there are about 48 different screens. So figure 3K for screen data, plus the 32x32 master map; that would take 1K.

So figure 4K for the all the platform data. Figure 4K for sprite data, 4K for music/sounds, maybe 1K for the kernel, maybe 4K for game logic.

 

Looks like a candidate for a 16K cartridge. Maybe more. But easily in 32K.

 

It could be done.

Edited October 11, 2005 by vdub_bobby

[jussts]

I voted for Excitebike, because after playing Motorodeo I feel that Excitebike could be a good possibility on the 2600. It could really be stripped down, and still be a lot of fun to play. Secretly though I would kill for a Metroid game. I would love to see it pulled off, but I just can't imagine a 2600 version having a big enough world to explore. I hope someone proves me wrong. Please, please prove me wrong.

946169[/snapback]

Well...the Metroid mockup I posted would require about 64 bytes for the platforms (playfield data). Maybe less if you simplified a little and compressed some. I'll be conservative and say 64 bytes.

 

According to a map I got somewhere, there are about 48 different screens. So figure 3K for screen data, plus the 32x32 master map; that would take 1K.

 

So figure 4K for the all the platform data. Figure 4K for sprite data, 4K for music/sounds, maybe 1K for the kernel, maybe 4K for game logic.

 

Looks like a candidate for a 16K cartridge. Maybe more. But easily in 32K.

 

It could be done.

946221[/snapback]

 

It could be made into a Supercharger game if cartridge space is a problem...

 

Here's a slightly modified sprite that attempts to look even more like Samus from the sequels... I think it looks rather good, if I do say so myself. I wasn't sure, but it looked like you were using the missile or ball or something to extend her gun arm a bit... I ran with this logic and made it a different color (not sure if that's strictly possible, but while we're dreaming here...) to match it more closely to the original games.

 

Edit: Added second mock up with a revised Samus sprite and a new enemy.

Edited October 13, 2005 by jussts

[vdub_bobby]

Here's a slightly modified sprite that attempts to look even more like Samus from the sequels... I think it looks rather good, if I do say so myself.  I wasn't sure, but it looked like you were using the missile or ball or something to extend her gun arm a bit... I ran with this logic and made it a different color (not sure if that's strictly possible, but while we're dreaming here...) to match it more closely to the original games.

Yep, using missile as extra pixel. It probably can't be a different color, but why not dream?

 

And it might be possible to:

-get color changes on enemy sprites (line by line)

and/or

-get enemy sprites to have 1-line resolution.

[vdub_bobby]

Despite the fact that I could never sell carts, I am leaning more and more towards making a 2600 Metroid port my next project. I've currently got a kernel (on paper; untested) that would allow:

 

striped PF, similar to the screenshots above. Blockier, though. Same overall screen resolution as the NES version: screen composed of 256 tiles (16x15), where the tiles are 8 pixels wide by 12 pixels tall (pretty close to square).

Samus at 1-line graphical resolution + 1-line color resolution, a 9x24 sprite, with the 9th pixel of varying width (i.e., the missile). Has to be the same color as the other 8 pixels on its row(s), though.

Enemies at 1-line graphical resolution + 2-line color resolution.

The ball (flickered like mad) would be all particles. Might possibly use a sprite to show missiles.

 

Intelligent flicker would allow multiple enemies onscreen.

Edited October 26, 2005 by vdub_bobby

[DominiRican05]

Metroid definitely looks good, I think it would be very possible, but I'm even more interested in the possibility of SMB. It was my first video game and I'm really curious to see what it would look like on the 2600, and how many levels could be crammed in since I like variety.

 

It's nice to see the pics from the NES version, anyone want to try some mock-ups of a 2600 SMB?

[jussts]

Despite the fact that I could never sell carts, I am leaning more and more towards making a 2600 Metroid port my next project.  I've currently got a kernel (on paper; untested) that would allow:

 

striped PF, similar to the screenshots above.  Blockier, though.  Same overall screen resolution as the NES version: screen composed of 256 tiles (16x15), where the tiles are 8 pixels wide by 12 pixels tall (pretty close to square).

Samus at 1-line graphical resolution + 1-line color resolution, a 9x24 sprite, with the 9th pixel of varying width (i.e., the missile).  Has to be the same color as the other 8 pixels on its row(s), though.

Enemies at 1-line graphical resolution + 2-line color resolution.

The ball (flickered like mad) would be all particles.  Might possibly use a sprite to show missiles.

 

Intelligent flicker would allow multiple enemies onscreen.

954734[/snapback]

 

Unable to stop revising, I've changed my mock up once more to fit your proposed kernel. I've pretty much finalized the Samus sprite (at least the standing still frame) and I've reworked the first enemy you encounter to fit the two line color resolution limitation (as I understand it, at least... I may have screwed up). I've also included a pic that shows the color palette I'd use for Samus' power suit and varia suit... it also shows the little enemy guy walking. If you're serious about continuing the project, I'd be more than happy to sprite the rest of it as I have too much free time on my hands right now and the only other things I'm working on are the Prince of Persia sprites.

[vdub_bobby]

Unable to stop revising, I've changed my mock up once more to fit your proposed kernel.  I've pretty much finalized the Samus sprite (at least the standing still frame) and I've reworked the first enemy you encounter to fit the two line color resolution limitation (as I understand it, at least... I may have screwed up).  I've also included a pic that shows the color palette I'd use for Samus' power suit and varia suit... it also shows the little enemy guy walking.  If you're serious about continuing the project, I'd be more than happy to sprite the rest of it as I have too much free time on my hands right now and the only other things I'm working on are the Prince of Persia sprites.

956455[/snapback]

Even though my post wasn't real clear, I think you got the idea.

 

For the enemies...basically, the sprite shape can change every line but the color can only change every other line. The sprite you created looks like fine.

 

I am suddenly a bit busy trying to madly wrap up everything for the Minigame Multicart release, but I *may* be in contact soon after that...

 

 

[rockfistus]

Dude that picture makes me want to play Metroid on the 2600 so bad! I've actually re-written the Brinstar song on the Pokey chip but I had some questions:

 

1. It's a 3 channel song, is there any way we could fake having another Pokey chip on the cartridge so that I could get the extra channel? (I know Ballblazer on the 7800 had one on the cart)

 

2. I'm using Raster Tracker which can dump the songs into assembler code but it's for the Atari 8-bit computers, would that cause problems? Or is it possible to use it.

 

3. Here's the mp3 version of the song:

 

Metroid 2600

Edited November 7, 2005 by rockfistus

[vdub_bobby]

Dude that picture makes me want to play Metroid on the 2600 so bad! I've actually re-written the Brinstar song on the Pokey chip but I had some questions:

 

1. It's a 3 channel song, is there any way we could fake having another Pokey chip on the cartridge so that I could get the extra channel? (I know Ballblazer on the 7800  had one on the cart)

 

2. I'm using Raster Tracker which can dump the songs into assembler code but it's for the Atari 8-bit computers, would that cause problems? Or is it possible to use it.

 

3. Here's the mp3 version of the song:

 

Metroid 2600

961698[/snapback]

Nice sounding Brinstar song!

 

Answering...

 

1. Nope. Two channels is all you get.

2. The assembler code would probably have to be edited by hand for the 2600; so it depends on how much code it generates and what kind of code it generates.

[rockfistus]

Okay, thanks. I'll do one of the songs with 2 tracks, dump it, and post it here when I get a chance....that way you guys can look at it and see if it will be usable.

Edited November 7, 2005 by rockfistus

[rockfistus]

Okay here we go, I looked at the ASM dump and it contains the tracks and note-data, but not the instruments or anything.....so I guess I'd have to write down what each instrument should sound like or something?

 

This is the Chozo song, the real short one. The first instrument/track is a pure-tone, any kind of lead sound that fades out would work, and the second instrument/track is a really short cutoff percussive sound.

 

(BTW, if you download Raster Tracker it comes with some Docs about this stuff which you'd probably understand more than me, I just learned how to use the program last night after I saw you guys talking about this project, been tracking songs for a long time though. I hope you have luck with this.)

 

Raster Tracker

Metroid_Chozo.zip

Edited November 7, 2005 by rockfistus

[rockfistus]

After examining it some more I realized that it's pretty bare-bones......All it contains are the tracks, note values and empty spaces.

 

I left some feedback at the authors site about maybe getting an export to A2600 option in the program so I've got my fingers crossed.

 

The other export options that exist right now do export the instruments, tempo, volumes....etc but they are native to the Atari 8-bit computers so that doesn't help us much.

[supercat]

I left some feedback at the authors site about maybe getting an export to A2600 option in the program so I've got my fingers crossed.

961811[/snapback]

 

The only way a 2600 option is going to be any good is if it allows the user to hear the music with different transposition and timbre options. Depending upon the exact notes used, many pieces of music will only 'work' in one or two keys on the Atari (some won't work well in any key). What I would want to see would be a dialog box with a slider (to set transposition), some radio buttons (to set timbre), some option controls for what to do with 'clinkers' (play best pitch in selected timbre, play best pitch in another timbre, play down an octave, play up an octave, or play nothing). I would expect an automated tool could probably get 95% of the way 'there' in converting music for another machine into something reasonable, but it would need some help from a user to decide what really worked and what didn't.

 

For example, in my Strat-O-Gems game, the nine notes I use for chain reactions have the clock ratio 60, 48, 40, 32, 30, 24, 20, 16, 15. All but the last use the 'lead' sound (divide ratio 2) while the last uses the 'saw' sound (divide ratio 15). Normally, the saw sound would be out of place, but in that particular spot it works fine. And it's much better than would be using a value of 16 or 14.

[sukotsu9]

First I was leaning toward SMBs, but reading everyone's enthusiasm about Metroid got me to thinking: this is a project that could happen. People have to care enough to slog through the programming or it'll never happen. Plus, I know Metroid is trademarked, but it seems less Nintendo than SMB.

 

My real opinion is to focus on gameplay, less on graphics. Acheiving both would be great, but even if the enemy sprites are monochrome, if the feel of the game is there, I'm satisfied.

[rockfistus]

My real opinion is to focus on gameplay, less on graphics. Acheiving both would be great, but even if the enemy sprites are monochrome, if the feel of the game is there, I'm satisfied.

961840[/snapback]

 

Yeah I liked the *second* screenshot the best BTW. It looks completely possible, even if you have to cheese out some stuff to make it happen. Pitfall 2 is a lot like Metroid if you think about it.

Edited November 9, 2005 by rockfistus

[rockfistus]

Here's what that Chozo song asm code is supposed to sound like:

Metroid_Chozo.zip