Jump to content

Photo

Sonic The Hedgehog on the 2600


204 replies to this topic

#26 tokumaru OFFLINE  

tokumaru

    Moonsweeper

  • Topic Starter
  • 263 posts
  • Location:Rio de Janeiro - Brazil

Posted Sun Oct 10, 2010 10:39 AM

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

#27 Animan OFFLINE  

Animan

    River Patroller

  • 2,391 posts
  • Just some guy who plays Atari and watches Anime.
  • Location:Texas

Posted Sun Oct 10, 2010 10:49 AM

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

#28 tokumaru OFFLINE  

tokumaru

    Moonsweeper

  • Topic Starter
  • 263 posts
  • Location:Rio de Janeiro - Brazil

Posted Sun Oct 10, 2010 10:56 AM

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.

#29 Animan OFFLINE  

Animan

    River Patroller

  • 2,391 posts
  • Just some guy who plays Atari and watches Anime.
  • Location:Texas

Posted Sun Oct 10, 2010 11:01 AM

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.

Attached Thumbnails

  • enemiys.png


#30 Koopa64 OFFLINE  

Koopa64

    Stargunner

  • 1,183 posts
  • Love havin' an Apple //e again!
  • Location:Canada

Posted Sun Oct 10, 2010 11:32 AM

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

#31 grafixbmp OFFLINE  

grafixbmp

    Dragonstomper

  • 685 posts
  • Location:South Central US

Posted Sun Oct 10, 2010 12:52 PM

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.

#32 roland p OFFLINE  

roland p

    River Patroller

  • 2,455 posts
  • $23
  • Location:The Netherlands

Posted Sun Oct 10, 2010 1:15 PM

Any chance of using dpc+ for this game?

#33 Innovative Leisure OFFLINE  

Innovative Leisure

    Star Raider

  • 72 posts
  • Location:Des Moines, IA

Posted Sun Oct 10, 2010 2:51 PM

I'd buy this port of Sonic.

Edited by Innovative Leisure, Sun Oct 10, 2010 2:52 PM.


#34 tokumaru OFFLINE  

tokumaru

    Moonsweeper

  • Topic Starter
  • 263 posts
  • Location:Rio de Janeiro - Brazil

Posted Sun Oct 10, 2010 3:46 PM

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! =)

#35 roland p OFFLINE  

roland p

    River Patroller

  • 2,455 posts
  • $23
  • Location:The Netherlands

Posted Mon Oct 11, 2010 2:42 AM

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.

#36 OldAtarian OFFLINE  

OldAtarian

    Stargunner

  • 1,599 posts

Posted Fri Oct 15, 2010 11:25 AM

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

#37 Octavio OFFLINE  

Octavio

    Space Invader

  • 32 posts

Posted Fri Oct 15, 2010 1:22 PM

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.

#38 Animan OFFLINE  

Animan

    River Patroller

  • 2,391 posts
  • Just some guy who plays Atari and watches Anime.
  • Location:Texas

Posted Sat Oct 16, 2010 9:26 PM

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.

#39 Rex Dart OFFLINE  

Rex Dart

    Quadrunner

  • 6,658 posts
  • NO CASH VALUE
  • Location:Austin, TX

Posted Wed Oct 20, 2010 11:47 AM

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.

#40 tokumaru OFFLINE  

tokumaru

    Moonsweeper

  • Topic Starter
  • 263 posts
  • Location:Rio de Janeiro - Brazil

Posted Thu Oct 21, 2010 11:11 PM

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!):

Posted Image

Posted Image

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.

#41 GroovyBee OFFLINE  

GroovyBee

    Games Developer

  • 9,821 posts
  • Busy bee!
  • Location:England

Posted Fri Oct 22, 2010 2:33 AM

If anyone has interesting ideas


7800 version :P

#42 jaybird3rd ONLINE  

jaybird3rd

    Quadrunner

  • 9,289 posts
  • "Excuse me, sir? I have a question ..."
  • Location:806.4616.0110

Posted Fri Oct 22, 2010 2:42 AM

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!

#43 jaybird3rd ONLINE  

jaybird3rd

    Quadrunner

  • 9,289 posts
  • "Excuse me, sir? I have a question ..."
  • Location:806.4616.0110

Posted Fri Oct 22, 2010 2:45 AM

7800 version :P

:thumbsup:

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.

#44 psquare75 OFFLINE  

psquare75

    Dragonstomper

  • 708 posts
  • Location:Assonet, MA

Posted Fri Oct 22, 2010 7:49 AM

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

#45 tokumaru OFFLINE  

tokumaru

    Moonsweeper

  • Topic Starter
  • 263 posts
  • Location:Rio de Janeiro - Brazil

Posted Fri Oct 22, 2010 8:46 AM

7800 version :P

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:

Posted Image

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.

#46 Propane13 OFFLINE  

Propane13

    Stargunner

  • 1,649 posts
  • Location:Charleston, SC

Posted Tue Oct 26, 2010 2:05 PM

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


Something like this:
Posted Image


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

#47 tokumaru OFFLINE  

tokumaru

    Moonsweeper

  • Topic Starter
  • 263 posts
  • Location:Rio de Janeiro - Brazil

Posted Tue Oct 26, 2010 11:09 PM

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! =)

#48 Dino OFFLINE  

Dino

    River Patroller

  • 3,362 posts

Posted Wed Oct 27, 2010 4:36 PM

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 ;)

#49 Gemintronic ONLINE  

Gemintronic

    Jason S. - Lead Developer & CEO

  • 9,358 posts

Posted Fri Nov 5, 2010 10:28 AM

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 by theloon, Fri Nov 5, 2010 10:29 AM.


#50 Godzilla OFFLINE  

Godzilla

    Quadrunner

  • 6,794 posts
  • Location:Jacksonville, Fl

Posted Fri Nov 5, 2010 1:00 PM

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




0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users