Sonic The Hedgehog on the 2600

[tokumaru]

...it never hurts to do what the GG games did (showed a single ring fly away, and you couldn't get it back).

The GG/SMS games reduced the number of flying rings (1 ring for every 10 you had or something like this), but they were collectable. I'm not really having trouble with these rings though, it's just that since P0's colors are updated during the visible part of the scanline (a part where Sonic never goes to, but the rings can), they must use only one color to avoid visible color changes in the same scanline. I'll probably limit the number of flying rings to 2 or 3 though, I can't waste much CPU or RAM with them. To me this is a major aspect of a Sonic game, the guarantee that if you have even a single ring (that you can lose and get back) you'll be OK.

 

If I get around to it, I might draw up some enemy sprites that you can use if you want.

I'd love to see what you have in mind! I'm having trouble thinking of interesting enemies...

[Animan]

...it never hurts to do what the GG games did (showed a single ring fly away, and you couldn't get it back).

The GG/SMS games reduced the number of flying rings (1 ring for every 10 you had or something like this), but they were collectable. I'm not really having trouble with these rings though, it's just that since P0's colors are updated during the visible part of the scanline (a part where Sonic never goes to, but the rings can), they must use only one color to avoid visible color changes in the same scanline. I'll probably limit the number of flying rings to 2 or 3 though, I can't waste much CPU or RAM with them. To me this is a major aspect of a Sonic game, the guarantee that if you have even a single ring (that you can lose and get back) you'll be OK.

 

If I get around to it, I might draw up some enemy sprites that you can use if you want.

I'd love to see what you have in mind! I'm having trouble thinking of interesting enemies...

 

As I am quickly discovering, recreating the original enemies is very hard. As much as I want them to be the original one, it might end up being new characters "inspired" by the original one.

[tokumaru]

As I am quickly discovering, recreating the original enemies is very hard.

I reached that same conclusion. I tried to draw a simple crab and couldn't come up with anything convincing.

[Animan]

As I am quickly discovering, recreating the original enemies is very hard.

I reached that same conclusion. I tried to draw a simple crab and couldn't come up with anything convincing.

 

Here is 3 I threw together. The 3rd one was supposed to have spike tops, but it doesn't really look like so.

[Koopa64]

Holy crap! The sprites and examples screens look AMAZING! Now THIS is a homebrew I could really get behind (Castlevania still looks pretty good too).

[+grafixbmp]

Even Somari on NES (or any other variation of sonic on NES) would only drop 3 rings from sonic when he was hit. you could have 3 copies bounce away I guess.

[roland p]

Any chance of using dpc+ for this game?

[Innovative Leisure]

I'd buy this port of Sonic.

Edited October 10, 2010 by Innovative Leisure

[tokumaru]

Even Somari on NES (or any other variation of sonic on NES) would only drop 3 rings from sonic when he was hit.

Not necessarily... considering that Sonic flickers after getting hurt, I find it acceptable that the rings flicker a lot too. I think you could go up to 8 or so rings without slowing the system down or making it look like crap.

 

 

you could have 3 copies bounce away I guess.

It would look kinda weird, you know? Three rings bouncing in perfect sync, not moving away from each other horizontally... I think I'd take the flicker approach, taking advantage of the fact that Sonic is flickering too. Each frame where Sonic isn't displayed would show one of the rings. This and the fact that there isn't much RAM to keep track of their positions are the reasons I want to limit bouncing rings to at most 3.

 

 

Any chance of using dpc+ for this game?

I don't know, I'm kind of a purist... I don't like to use hardware that makes mass-production of carts harder, even if I don't plan on selling carts (something I'm not sure I could do if using Sonic as a character).

 

 

I'd buy this port of Sonic.

So would I! Unless I actually succeed in making it! =)

[roland p]

I don't know, I'm kind of a purist... I don't like to use hardware that makes mass-production of carts harder, even if I don't plan on selling carts (something I'm not sure I could do if using Sonic as a character).

 

That's ok Although I don't know the price difference between a bankswitching cart and a ARM equipped one.

I'm trying a little demo which includes a ramp, but it will ommit some of the other stuff.

[OldAtarian]

But....the 2600 doesn't have Blast Processing.

[Octavio]

This kind of reminds me when I played that crappy Sonic port on the Game.com.

 

But I'm sure that you'll do better than that.

[Animan]

This kind of reminds me when I played that crappy Sonic port on the Game.com.

 

But I'm sure that you'll do better than that.

 

Anybody can do better than that wretched thing.

 

I really, really wish I could slap those programmers in the face, and kick them in the balls continuously for 20 minutes. And that is if I am in a good mood.

[Rex Dart]

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

 

Nope... it'd be Sonic 4!

 

This is looking GREAT, though. The art & ideas are already up there with the master system game.

[tokumaru]

Nope... it'd be Sonic 4!

Man, I played half of that game and I don't think I will be playing it ever again!

 

Anyway, I worked on a couple of new sprites for the end-of-level sign (Sonic doesn't look so great, I know, but it's the best I could do with 5 pixels across... Robotnik looks pretty good though!):

 

 

 

The sad thing is that programming is not going so well. I noticed that while attempting to make the 8-way scrolling possible I had to give up on many features I planned on implementing, a fact that will cause the backgrounds to look a lot less interesting than I originally expected, and I really don't want that, since I'm very happy with the sprites. I have absolutely no desire of making this into a screen-by-screen game though, as that wouldn't fit Sonic at all, so I'm really not sure where to go from here.

 

If anyone has interesting ideas on how to implement 8-way scrolling efficiently I'd love to hear them. My main problem is that P0 is dedicated to drawing Sonic only, while P1, M1 and the Ball are used to draw the level, and repositioning them horizontally (specially P1, since objects drawn with it must be able to stand on platforms drawn with it) quickly enough from section to section has proven to be very difficult. Also, I don't want to waste too many bytes with the kernels, since they'll have to be repeated across banks with different graphics and that could mean a lot of wasted space.

[GroovyBee]

If anyone has interesting ideas

 

7800 version

[jaybird3rd]

I really, really wish I could slap those programmers in the face, and kick them in the balls continuously for 20 minutes.

Be careful ... if they're masochistic enough to have worked on the game.com, they might like it!

[jaybird3rd]

7800 version

 

If you're going to port Sonic to an Atari system, I'd say the 7800 would be the best choice, especially with the upcoming Expansion Module. And, you'll be able to keep at least some of the sprite design work you've done, at least if you plan to implement it using one of the 7800's 160 modes.

 

Either that, or design a simpler game around the Sonic characters, something that would work within the limitations of the 2600 and doesn't need to replicate the more advanced features on the newer consoles.

[psquare75]

What does the 'actual background thus far' look like, as opposed to the sample screens posted on page 1?

[tokumaru]

7800 version

No chance... The 2600 is the only Atari console I have any interest in. I played it a lot as a kid, so making software for it has a special meaning to me. Also, since the 2600 is a much more successful system, it's much easier/cheaper to find/buy hardware (seeing as I don't like to develop for systems I don't personally own). I don't think the 7800 was even released officially here in Brazil, as I've never seen one for sale. Most people here think "Atari" is the name of the 2600, because nobody even knows that the company released anything else (I had never heard of the 7800 until emulation kicked in). Plus I'm already working on a similar game for the NES, which is a system I really like to code for.

 

So this is not about "making a game with Sonic characters on an Atari console", it's about "making a game that plays similar enough to a real Sonic game on a system that's not supposed to handle that". =)

 

What does the 'actual background thus far' look like, as opposed to the sample screens posted on page 1?

Something like this:

 

 

What's bothering me the most is that whenever a section ends and another one starts there needs to be a "break" between them so that P1 can be repositioned, and that looks terrible on slopes, it really affects their continuity. Maybe if I treated slopes differently I could avoid repositioning them and just modify HMxx values to change the angle of the slopes instead of fully repositioning the objects...

 

The problem is that all these special cases will add up to many kernels for the different sections, and that will eat a lot of the space that could be used for graphics, which would still result in dull-looking levels. I mean, it's not like 4096 bytes is a lot when I have to hold graphics for Sonic, the common objects (rings, springs, monitors, etc), level graphics (platforms, ground, decorative objects) and level enemies. That end sign alone is 32 lines tall, and since there are 5 frames it needs a total of 320 bytes... That's a lot to waste on a non essential object.

[+Propane13]

 

What does the 'actual background thus far' look like, as opposed to the sample screens posted on page 1?

 

Something like this:

 

Looks good!

 

What's bothering me the most is that whenever a section ends and another one starts there needs to be a "break" between them so that P1 can be repositioned, and that looks terrible on slopes, it really affects their continuity. Maybe if I treated slopes differently I could avoid repositioning them and just modify HMxx values to change the angle of the slopes instead of fully repositioning the objects...

 

How big were you planning the "break" to be? The reposition algorithms typically take 1-2 scanlines.

But, yes, you are learning that there are major tradeoffs when it comes to a kernel.

Remember tho, Thrust did 8-way scrolling (or at least 4-way). I think the gap between PF objects was 3 spaces for reposition type things.

Thinking outside the box is what we strive for.

 

The problem is that all these special cases will add up to many kernels for the different sections, and that will eat a lot of the space that could be used for graphics, which would still result in dull-looking levels. I mean, it's not like 4096 bytes is a lot when I have to hold graphics for Sonic, the common objects (rings, springs, monitors, etc), level graphics (platforms, ground, decorative objects) and level enemies. That end sign alone is 32 lines tall, and since there are 5 frames it needs a total of 320 bytes... That's a lot to waste on a non essential object.

 

I would agree that you'll need at least some special kernels:

One for end-screen (that's typically a "final" state with no scrolling and special gfx).

One for main scrolling

Some other cases (ones with strange objects on screen)?

 

For now, work the main one, and I'd say.. see it's limitations.

 

I am very much looking forward to this. It looks awesome.

Even a side-scroll only demo of Sonic speeding up and running fast would be neat.

Heck, if you did that only for a first run, you could still end up with a heck of a game.

That's probably how I'd start. Then, after that, I'd look at the verticals.

 

Good luck! And, feel free to share your questions/frustrations. Maybe some of us can help a bit.

 

-John

[tokumaru]

How big were you planning the "break" to be? The reposition algorithms typically take 1-2 scanlines.

I'm striving to have the gap be only 2 scanlines tall. This is not so easy because in addition to the repositioning, I have to keep drawing Sonic and load additional parameters for the next section (pointers, indexes, etc.).

 

But, yes, you are learning that there are major tradeoffs when it comes to a kernel.

Normally, I find the process of deciding the tradeoffs very entertaining (and the reason I got interested in programming the 2600 in the first place)... it's just frustrating when I don't have a lot of free time!

 

And, feel free to share your questions/frustrations.

Thanks. I'm much more optimistic now. I decided on some limitations for the ball and missile 1 that should simplify things with minor sacrifices to graphical detail. Actually, I now think the game can even have loops!

 

Maybe some of us can help a bit.

Thanks for the support! =)

[Dino]

Hi Tokumaru

 

Excellent stuff!! Please do not give up on this project. I suggest you put minimal effort into the platforms (just blocks will be fine) and focus on the playability, and the sonic and enemy sprites

[+Gemintronic]

I know nothing about assembly on the 2600, so, forgive my ignorance. What about making a vertical and then a horizontal scrolling kernel? Sort of like levels in Metroid. Would that simplify things so you can have time for other features?

Edited November 5, 2010 by theloon

[Godzilla]

neat ideas... interesting to see where it goes...