Sonic The Hedgehog on the 2600

[Brian O]

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

 

I second this. Good stuff, make it happen! Need any help, let me know.

[Atari_Falcon]

This looks like a very promising project for me! I would love to have sonic on 2600!

[Bountybob]

I think if you kept it simple and fun A Game and Watch style Sonic.

[+grafixbmp]

I have an idea for ya since your design is similar to my castlevania work. The technique i'm using for creating the many different screens could be adapted to horizontal scrolling and save you more space than mine does. What i've been doing is loading a list of index values into ram and the area of the kernel that handled the playfield would load from the list of index values by using Y as a scanline counter to go through the list and the index value would be in X for the playfield data. Then the playfield portion of the kernel just loaded from each page for each section of the playfield.

 

page A is the color of the scanline

page B is PF1 left side

page C is PF2 left side

page D is PF2 right side

page E is PF1 right side

 

With all these loading from the same index, everything lines up fine for a total of 256 individual scanline data. The index list loaded into RAM handles the overall screen image. Once this is done, load 0 into the accumulator and turn the playfield color to black and blank out PF1 and PF2. Changing the playfield color to black at the right time causes PF0 which is already 1111 to be black while blanking the next scanline of any data and it will keep PF0 black while the next scanline handles nothing but sprites. I also have several cycles left during the PF section for other things nd the Y value in mine decrements every 2 scanlines instead of every scanline.

 

This is what I did:

Scanline start

;11 cycles free

ldx 80,y	;4	
lda fa00,x	;4*
sta PF1		;3
lda fb00,x	;4*
sta COLPF	;3
lda fc00,x	;4*
sta PF2		;3

;7 cycles free

lda fd00,x	;4*
sta PF2		;3  begin on cycle 48
lda fe00,x	;4*
sta PF1		;3
dey		;2

;5 cycles free

; blank out playfield
lda #0		;2
sta PF1		;3
sta COLPF	;3
sta PF2		;3

;1 cycle free
;scanline end

 

As you can see I haven't killed the free cycle areas with any code yet. But it fills all 76 cycles of a scanline and sets up the next scanline for sprites.

 

One way you could get your scrolling is simplify for detail and pre-render all the horizontal movements you want to design and have them fill up a few pages. I said ya could do it and take up less data than mine. Here's how. All you would need is atleast 2 pages of data to get quite a few variations of PF data. The key to your type though, is having 2 index values stored in RAM (as compared to my 1 per instance) which reference diffrent parts (left and right sides). The entire height of the ground type object you want to draw can reference those 2 index values for all of it since it doesn't have to change from the top of it to the bottom unless you want it to, you won't need near the huge list mine does in RAM. One difference you would need would be for your PF color loading. I had mine builtinto the same system for simplicity, but you may want to do that differently for more detail each scanline (same visual data, different color). The horizontal movement would just be changing out your index tables in RAM for every frame it needs to change for movement. (for both vertical and horizontal movement)

 

So this way all of your movement is simply processed by changing the set of index values you store in RAM. In mine, I will be using superchip RAM and for such a game as yours it would be advised as well.

[GameGirl420]

i'd like to buy a copy ofthis when it gets finished. looks really good so far...

 

playing Sonic on Atari would be groovy.

[JohnnyAtari]

You should port this to the http://the-nd.com/ here is the site for the SDK http://the-nd.com/develop/

[tokumaru]

You should port this to the http://the-nd.com/ here is the site for the SDK http://the-nd.com/develop/

I'm sure it would look much more like an Genesis/MD game than an Atari 2600 game! I had never heard of this nD thing... pretty interesting! I wish them luck.

 

Now, since some of you are talking about the game being "ported", "sold", stuff like that, I'd just like to say that the game doesn't really exist. Unfortunately, I'm not working on it at all. I did begin some kernel coding, but real life stuff got in the way, I got a new job, and now this is just an idea I may or may not make real in the future. Sorry guys.

[JohnnyAtari]

You should port this to the http://the-nd.com/ here is the site for the SDK http://the-nd.com/develop/

I'm sure it would look much more like an Genesis/MD game than an Atari 2600 game! I had never heard of this nD thing... pretty interesting! I wish them luck.

 

Now, since some of you are talking about the game being "ported", "sold", stuff like that, I'd just like to say that the game doesn't really exist. Unfortunately, I'm not working on it at all. I did begin some kernel coding, but real life stuff got in the way, I got a new job, and now this is just an idea I may or may not make real in the future. Sorry guys.

What about the source

[+Propane13]

Since you're new here, I'd like to mention that I saw your other post:

http://www.atariage.com/forums/topic/132116-porting-the-original-classic-castlevania-to-the-2600/page__view__findpost__p__2309990

 

Source code can tend to be very personal stuff around here.

 

I wouldn't make an assumption that authors (like me) who work for hours / weeks / months / years on a project are going to just give their source code away for free.

These are very personal projects. We all get busy, and some of us come back to these projects over time. Development can take years.

 

I don't think it's too cool to ask someone else to work on another author's code.

I just wanted to say that up front. If this was my project thread, I'd be pretty unhappy with such a post.

And, I'm one of the nicer guys on here.

 

I am hoping the author goes back and looks at this again at some point (which has happened).

But, as I said in my reply to your other post-- patience.

 

Support the author. Tell him your interest. Help out if you can.

Don't suggest that others take over-- that's not really the way this works.

 

And, have patience. If you can't program for the 2600 yourself, then you have to cut the authors some slack, and be supportive.

 

-John

[raindog]

I wouldn't make an assumption that authors (like me) who work for hours / weeks / months / years on a project are going to just give their source code away for free.

 

While Mr. Atari has some other netiquette lessons to learn, and the attitude on AtariAge may be a little more mercenary than it was on [stella], it's never, ever inappropriate to inquire about source code in a homebrew discussion forum unless someone has already said they weren't releasing it in a place the poster could reasonably have been expected to see (e.g., on the same thread).

 

Especially when the project involves something that might someday incur a C&D letter.

[Keatah]

I.......I thought this was impossible.

 

It is, till it happens.

[maiki]

Instead of painting irrelevant artworks you should start coding some real 2600 kernel and then come up with some real 2600 graphics... Because all your sprites look at least suspiciously unreal to be a 2600 graphics... Plus your demonstation screen - you are using nothing but player 1? How would you display the platforms when Sonic would be on the same scanline... This is all just bragging around with no real output to come... But still some will keep saying whow... like on a pyramide multilevel marketing meeting.

[PAC-MAN-RED]

Instead of painting irrelevant artworks you should start coding some real 2600 kernel and then come up with some real 2600 graphics... Because all your sprites look at least suspiciously unreal to be a 2600 graphics... Plus your demonstation screen - you are using nothing but player 1? How would you display the platforms when Sonic would be on the same scanline... This is all just bragging around with no real output to come... But still some will keep saying whow... like on a pyramide multilevel marketing meeting.

 

Perhaps, as a suggestion, you may want to re-read the first post again, as everything is explained within it.

 

Illya

[roland p]

I just found this:

http://www.youtube.com/watch?v=5RweZQNUvzw&feature=related

[Keatah]

I just found this:

http://www.youtube.com/watch?v=5RweZQNUvzw&feature=related

 

Looks fake

[roland p]

Yep, there are some non-TIA graphics.

And I guess every atari programmer visits atari-age so it would be announched here first

[DemonoidTentacle]

I think if you kept it simple and fun A Game and Watch style Sonic.

 

I agree, simple G&W / arcade styling could be great.

[+JAC!]

I just found this:

...

 

Looks fake

 

It's done with BOB 2.0

[player 0ne]

ooohhh.. i could get my girlfriend to play atari with me. i whanna play!

[CorTat-G]

Cool!

Any Improvements? Because this would be cool to play on the 2600.

[roland p]

Just playing around

rom.bin

sonic_src.zip

[CorTat-G]

Awesome!

[tokumaru]

Nice!

[roland p]

I've now added sonic and a new kernel that uses the playfield to produce a more interesting level. This kernel could include a spring also.

 

It uses 32 line high kernels. At the end of every kernel it does an RTS to jump to the next kernel. So parameters + pointers to kernels are pushed to the stack before the screen is drawn (in setupscreen.h, at the end)

 

Smooth scrolling should be possible too, at least with the current system by adding/removing lines at the top (smooth) and adjust the kernel setup (coarse).

 

Now I need a way to describe the levels like: 200px space kernel, 160px platform kernel, 200px rings kernel. And that for each line. A sort of Run Length Encoding I guess.

 

I now I should be working on ballblazer, but this is fun to do...

rom.bin

sonic_src.zip

[+Gemintronic]

Smooth scrolling should be possible too, at least with the current system by adding/removing lines at the top (smooth) and adjust the kernel setup (coarse).

 

Could you exand on this further? I don't know enough assemmbly to interpret your source. The few demos I've seen with smooth horizontal scrolling also seem to take on a staggered line appearance. Is this because playfield pixels cannot be used for horizontal smooth scrolling? Somehow this is using the other graphic objects?