Jump to content
IGNORED

Sonic The Hedgehog on the 2600


tokumaru

Recommended Posts

Hey everyone!

 

I guess most of you don't know this but I'm a huge Sonic The Hedgehog fan (I'm talking about the classic games here, I don't care for anything since Adventure). And every time I learn to code for a new platform I start considering the possibility of coding a Sonic game for it (I have a NES engine in the works, but not really playable yet). With the 2600 I quickly gave up on that idea though, given how difficult it would be to scroll the screen and the fact that a screen-by-screen sonic game probably wouldn't be much fun.

 

But the other day I started thinking about the possibility of making a platformer with 8-way scrolling, and suddenly the idea didn't seem so technically impossible. I know that there are a couple of 8-way scrolling games for the 2600, but they don't seem to use the technique I thought of. Since I wanted smooth scrolling (not the 4-pixels-at-a-time that are possible with the playfield) I decided that it should be possible to have the level map constructed mainly by sprites. So, while player 0 would be used for the main character, player 1 (and its copies) would be used for both enemies and level blocks, and those two wouldn't be allowed to share the same scanlines.

 

Since a level made only of a few sparse floating blocks would be too dull, I decided that it should be possible to use the playfield to represent longer sections of ground, as well as longer platforms. I would only use solid colors for the playfield, and would use player 1 and/or the ball to smooth out the transitions from ground to empty space and empty space to ground to keep the scrolling smooth. There will of course be several limitations regarding the way in which objects and the terrain can be arranged in the level map, but I think it's still possible to come up with interesting results without making the limitations obvious to the average player.

 

So, just for the heck of it, I went ahead and made a few sprites:

 

sonicsprites.png

 

And here are a few animations based on the sprites above:

 

sonicwalk.gifsonicup.gifsonicdown.gifsonicroll.gifthreerings.gifmonitorring.gifrobotniklaugh.gif

 

Forgive me if I made any mistakes regarding resolution or color count, it's just that I use MS Paint to draw my sprites instead of a 2600-specific tool. Also, these sprites obviously need a black (or at least considerably dark) background to look good.

 

Anyway, you may have noticed that Sonic has half of the vertical resolution, this is so that he can "play nice" with all the mini-kernels, since he can be anywhere in the level. Player 1 is full resolution though. Sonic uses its missile to have 9 pixels across instead of 8. Both players can be stretched in case they need to represent wider pictures, but they can't mix different widths (except for the bosses, which would probably have their own kernel to accommodate that).

 

I did some math and it looks perfectly possible to come up with a combination of mini-kernels to accomplish what I want. The main bottleneck in a project like this would be storage, RAM and ROM.

 

Well, this is it I guess. I'm not sure I'll go through with this project, but I'm playing with the idea, and thought some of you would find it interesting. Any thoughts?

Edited by tokumaru
  • Like 8
Link to comment
Share on other sites

Those are some nice looking sprites.

 

8-way scrolling on the 2600 is a tall order. I'd suggest revisiting the idea of a single screen Sonic, or restricting to vertical scrolling only.

 

If you look at Halo 2600, you will see that it captures the essence of the game, without trying to replicate all of the details. A similar approach may work nicely for Sonic.

 

Chris

Link to comment
Share on other sites

Here's a very simple screen showing the multiple functions of player 1:

 

mockup01.png

 

As you can see, only the central portion of the screen is used, meaning that only 2 playfield registers are used. Also, the blanked area at the sides will conveniently hide portions of the sprites so that they can smoothly scroll in and out of view. This scene has no slopes (something a Sonic game can't lack!), but player 1 can also be used to make those. I'll post a screen with slopes later.

 

EDIT: Of course the game would have decent physics, with acceleration, inertia, and so on... otherwise it wouldn't be Sonic!

Edited by tokumaru
  • Like 5
Link to comment
Share on other sites

8-way scrolling on the 2600 is a tall order. I'd suggest revisiting the idea of a single screen Sonic, or restricting to vertical scrolling only.

 

I've got a little demo with 8-way scrolling working using just the technique he mentions (p0 is the player and it remains relatively stationary in the center of the screen - only moves up and down), P1 and the missiles are used for everything else. Probably won't use the playfield at all for the same reasons he mentions: I want smooth scrolling left and right. It's still early but it certainly seems to be possible.

 

-EdF

  • Like 3
Link to comment
Share on other sites

Here's a very simple screen showing the multiple functions of player 1:

 

mockup01.png

 

As you can see, only the central portion of the screen is used, meaning that only 2 playfield registers are used. Also, the blanked area at the sides will conveniently hide portions of the sprites so that they can smoothly scroll in and out of view. This scene has no slopes (something a Sonic game can't lack!), but player 1 can also be used to make those. I'll post a screen with slopes later.

This looks so nice... If this screens can be done AND you can create some nice gameplay this will be a winner.

  • Like 3
Link to comment
Share on other sites

p0 is the player and it remains relatively stationary in the center of the screen - only moves up and down

That's actually a pretty good idea! By keeping player 0 always centered (or nearly centered) you can be more flexible with the times you set its graphics and colors. I wonder how I'd prevent the player from moving to the sides when it reaches the horizontal edges of the level though... Invisible wall? =)

 

Probably won't use the playfield at all for the same reasons he mentions: I want smooth scrolling left and right.

I plan on using player 1 + its missile and/or the ball to smooth out playfield scrolling. So even though the playfield can only scroll 4 color clocks at a time, the sprites layered on top of it will make it seem like it con move 1 pixel at a time. I won't be able to add any detail to the playfield though, because I'll only be able to smooth out the edges, not the middle.

 

It's still early but it certainly seems to be possible.

I agree. It's a technique that hasn't been explored much, probably because it is "unconventional", but it definitely seems possible.

  • Like 1
Link to comment
Share on other sites

I plan on using player 1 + its missile and/or the ball to smooth out playfield scrolling. So even though the playfield can only scroll 4 color clocks at a time, the sprites layered on top of it will make it seem like it con move 1 pixel at a time. I won't be able to add any detail to the playfield though, because I'll only be able to smooth out the edges, not the middle.

You could also use player 1 to make the hole in the floor. So you only need to change the background color each line.

 

Edit: I don't know if this still works the right way with sprite priorities...

Link to comment
Share on other sites

p0 is the player and it remains relatively stationary in the center of the screen - only moves up and down

That's actually a pretty good idea! By keeping player 0 always centered (or nearly centered) you can be more flexible with the times you set its graphics and colors. I wonder how I'd prevent the player from moving to the sides when it reaches the horizontal edges of the level though... Invisible wall? =)

 

I guess I am suggesting that you keep Sonic in the middle of the screen (horizontally, he can jump up and down vertically) and just scroll the terrain past him. You have some awesome sprites. My advice is to get something simple working now and then build from it.

 

-EdF

Link to comment
Share on other sites

Thanks, LS_Dracon! Coming from a person who makes such great Atari 2600 sprites that means a lot! =)

 

Check out this project, may hep you with the concept of player based backgrounds.

 

http://www.atariage.com/forums/topic/148898-mega-italian-twins-2600-wip/

Yeah, I remember that. In fact that might be where I got the idea from! I want to do something similar, but without the flickering (I'm very annoyed by it on the 2600) and with vertical scrolling as well.

 

You could also use player 1 to make the hole in the floor. So you only need to change the background color each line.

That's a good idea, but I don't want the floor to go all the way to the end of the level, I want to be able to make larger gaps, wider than player 1 and its missiles would allow me to (larger than a screen).

 

Edit: I don't know if this still works the right way with sprite priorities...

Yeah, I guess that if the background has high priority it will be in front of the sprite that is trying to cover it, so it wouldn't work. For now I don't plan to mess with the background priority though.

 

What I would like to do is dynamically switch player 0 and player 1 in order to control whether the player is in front or behind of other objects, but that would complicate the kernels too much... I'm having enough trouble fitting it all as it is! =)

 

My advice is to get something simple working now and then build from it.

Yeah, I'm awfully tempted to try this. I'm sketching some kernels on paper, let's see how this goes...

 

One problem I can foresee is that all these graphics will take a lot of space, and I'll probably have to use different banks for different levels, replicating the sprites that are used through the whole game (Sonic, rings, monitors, etc). The level maps will probably take a lot of space too, so I'm afraid even 32KB won't be enough for a complete game (which means I won't be able to test it on my Harmony cart). Oh well, I guess it's too soon to worry about that, so I'll try not to! =)

Edited by tokumaru
Link to comment
Share on other sites

So this isn't a port, this will have original levels?

Well, apart from the mandatory green level, anything is game I suppose. =)

 

I thing making a port would be kinda pointless, considering that most of the existing maps and gimmicks wouldn't be possible, so I feel like it's better to design new content with the limitations in mind.

 

If you don't want items to share the same scanline you'll have to be really clever with your level design. Like anything within one screen apart cannot be on the same level.

Yup, that's right. I don't think this is a problem though, since it's still possible to have lots of things vertically/diagonally.

Link to comment
Share on other sites

Hey everyone! Unfortunately I don't have anything significant programmed yet, but I have a few updates on the sprites I'd like to show you:

 

sonicsprites2.png

sonicrun.gifanimmonitorring.gifanimrings.gif

 

The lower resolution/color rings are the ones Sonic loses when he gets hit (they'll flicker so much I don't think it makes a difference).

 

About programming, I'm having some trouble efficiently repositioning P1. I'm sure it can be done though. And I might have to go with roland p's idea of using P1 to make holes on the ground, and not use the playfield at all (BTW roland, I mistakenly read "playfield" when you said "background", so I don't think there would be any priority issues with your idea), because of the time it would take to draw the asymmetrical playfield and the RAM necessary to maintain its state. I don't think this decision compromises the level layout much though.

  • Like 1
Link to comment
Share on other sites

Hey everyone! Unfortunately I don't have anything significant programmed yet, but I have a few updates on the sprites I'd like to show you:

 

sonicsprites2.png

sonicrun.gifanimmonitorring.gifanimrings.gif

 

The lower resolution/color rings are the ones Sonic loses when he gets hit (they'll flicker so much I don't think it makes a difference).

 

About programming, I'm having some trouble efficiently repositioning P1. I'm sure it can be done though. And I might have to go with roland p's idea of using P1 to make holes on the ground, and not use the playfield at all (BTW roland, I mistakenly read "playfield" when you said "background", so I don't think there would be any priority issues with your idea), because of the time it would take to draw the asymmetrical playfield and the RAM necessary to maintain its state. I don't think this decision compromises the level layout much though.

 

One idea, if you are having trouble with the rings that Sonic loses (the way they are animated), it never hurts to do what the GG games did (showed a single ring fly away, and you couldn't get it back). I know it was kind of dumb, but it will be easier to program.

 

This is a very promising project. If I get around to it, I might draw up some enemy sprites that you can use if you want.

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