Sonic The Hedgehog on the 2600

[raindog]

I think this one is a lot prettier (I assume it's assembly and not bB, so it's possible to do much more fun stuff in the kernel), but I have no idea if it would still work with Sonic and enemies in play.

 

It's also a lot more likely to be C&Ded if it's completed and offered for sale, name change or not. But I love the look of it. Nice demo of what's possible on the 2600.

[roland p]

@Tokumaru.

 

It has been a while ago, but do you hapen to have mockups of longer levels?

[tokumaru]

Cool demo!

 

It has been a while ago, but do you hapen to have mockups of longer levels?

I didn't go very far with designing levels for this, but I just looked and found a couple of mockups I don't remember having shared before:

 

 

Not incredibly inspiring by any means, but this really is everything I have to share! =)

[Estlib]

tokumaru, you should continue this. i would love to see another sonic attempt on the 2600 in addition to zippy.

[tokumaru]

As much as I'd like to see a smooth scrolling Sonic game on the 2600, I feel that the limitations imposed by drawing levels almost exclusively out of player/missile/ball graphics are too restrictive. It would take forever to design decent levels, and even then I fear that the result wouldn't be as fun to play as a Sonic game should be.

 

Right now I'm trying to work on something more suited to the 2600, that embraces the graphical limitations of the console instead of trying to get around them. I'm trying to make the most out of what the TIA has to offer, without having to resort to excessively complex tricks. Hopefully this will be good practice for when I finally decide to work on something more ambitious.

[Andromeda Stardust]

Cool demo!

 

 

I didn't go very far with designing levels for this, but I just looked and found a couple of mockups I don't remember having shared before:

Not incredibly inspiring by any means, but this really is everything I have to share! =)

Is it just me, or does tails look like Mini Mouse?

[phillip_roberts]

As much as I'd like to see a smooth scrolling Sonic game on the 2600, I feel that the limitations imposed by drawing levels almost exclusively out of player/missile/ball graphics are too restrictive. It would take forever to design decent levels, and even then I fear that the result wouldn't be as fun to play as a Sonic game should be.

 

Right now I'm trying to work on something more suited to the 2600, that embraces the graphical limitations of the console instead of trying to get around them. I'm trying to make the most out of what the TIA has to offer, without having to resort to excessively complex tricks. Hopefully this will be good practice for when I finally decide to work on something more ambitious.

 

After looking at the various screenshots & sprite demos.. there is nothing that proper time, planning, & dedication can do to a project on the VCS. The system itself is not limited, only the developer. PERIOD. The cartridge could hold a 6 bit project & would operate fine. Your television is a large portion of it & considering today's television sets - the power behind them with the VCS system outbeats today's 'interactive film players' that we call, Consoles. Again, NOTHING is entirely impossible.. only if you limit yourself in what you set to showcase, especially on the VCS.

[Andromeda Stardust]

Bump. Did any updates come out of this?

[roland p]

My idea on the subject:

The screens look nice, but they should be created in a way so they could be stitched together, so you can scroll from one screen into the other.

 

Maybe kernels of 2 screens wide, 320 color clocks, where each new kernel scrolls into one new screen:

Kernel 1 for scroll position 0...319

Kernel 2 for scroll position 160...479

Kernel 3 for scroll position 320...639

Kernel 4 for scroll position 480...799

etcetera.

 

pos:      0       160     320     480     640     800
kernel1:  |--------------|
kernel2:          |--------------|
kernel3:                  |--------------|
kernel4:                          |--------------|

So every kernel repeats the previous 'screen' and adds a new 'screen' Edited December 17, 2014 by roland p

[roland p]

Some inspiration:

[ZackAttack]

My idea on the subject:

The screens look nice, but they should be created in a way so they could be stitched together, so you can scroll from one screen into the other.

 

Maybe kernels of 2 screens wide, 320 color clocks, where each new kernel scrolls into one new screen:

Kernel 1 for scroll position 0...319

Kernel 2 for scroll position 160...479

Kernel 3 for scroll position 320...639

Kernel 4 for scroll position 480...799

etcetera.

 

pos:      0       160     320     480     640     800
kernel1:  |--------------|
kernel2:          |--------------|
kernel3:                  |--------------|
kernel4:                          |--------------|

So every kernel repeats the previous 'screen' and adds a new 'screen'

 

Wouldn't this create serious limitations to the level design though? Maybe I don't fully understand your intention here. To me this would be the same as having 160 pixel wide tiles to design the level with. I think it would also require a lot of space for the different combinations. For example if you had 5 screens, they could be combined in 15 different ways or n(n+1) / 2. I'm sure you would only implement the combinations that are used in actual levels, but it could still grow very large.

[roland p]

Well, I've not thought about memory usage yet. Maybe some stuff can be reused by making subroutines of them, so a kernel could exist of multiple sub-kernels which are JSR'ed to, and those subkernels could be reused across the other kernels.

[roryjr]

My idea on the subject:

The screens look nice, but they should be created in a way so they could be stitched together, so you can scroll from one screen into the other.

 

Maybe kernels of 2 screens wide, 320 color clocks, where each new kernel scrolls into one new screen:

Kernel 1 for scroll position 0...319

Kernel 2 for scroll position 160...479

Kernel 3 for scroll position 320...639

Kernel 4 for scroll position 480...799

etcetera.

 

 

I get this. Wouldn't the new 512k size of the Harmony Encore (and I assume the corresponding Melody board) allow a lot more level data to be used? I think folks would be willing to pay a premium for the DPC+ larger memory size to get a beautiful and exciting Sonic game on the 2600.

 

pos:      0       160     320     480     640     800
kernel1:  |--------------|
kernel2:          |--------------|
kernel3:                  |--------------|
kernel4:                          |--------------|

So every kernel repeats the previous 'screen' and adds a new 'screen'

 

[Andromeda Stardust]

512kb is a lot, I'll admit. But Sprybug has already pulled it off with 64kb. See also Zippy the (non-infringing) Porcupine

[ZackAttack]

Well, I've not thought about memory usage yet. Maybe some stuff can be reused by making subroutines of them, so a kernel could exist of multiple sub-kernels which are JSR'ed to, and those subkernels could be reused across the other kernels.

 

What if each kernel could be up to 512 pixels wide and each kernel was designed to overlap with other kernels by 160 pixels on each side? I'll attempt to demonstrate with some ascii art. Each character represents 40 pixels. The groups of 4 O's at the top indicate where 2 kernels overlap by one screen. The top shows 3 different kernels stitched together (the loop is placed twice). The bottom shows each kernel separated.

 

If each kernel is only made as high as at needs to be instead of a screen height, they could be stacked vertically as much as we want. The only restriction would be making sure they overlap horizontally by a screen width. This technique could allow for a level engine that supports 8-way single pixel scrolling and a user friendly level editor.

          OOOO            OOOO      OOOO         
      __                        __               
     /  \          ___         /  \              
    |    |     ___/   \__     |    |             
_____\__/_____/          \_____\__/_____     ____
                                        |   |    
                                        |   |    
                                                 
                                                 
      __                        __               
     /  \                      /  \              
    |    |                    |    |             
_____\__/_____            _____\__/_____         
                                                 
                   ___              ____     ____
               ___/   \__               |   |    
          ____/          \____          |   |    

[Andromeda Stardust]

 

     
      __                        __               
     /  \                      /  \              
    |    |                    |    |             
_____\__/_____            _____\__/_____         
                                                 
                   ___              ____     ____
               ___/   \__               |   |    
          ____/          \____          |   |    

I see a frowny face, LOL... Neat idea, hope you pull it off...

[ZackAttack]

I've been working on putting together a 4k demo with an 8 way scrolling engine that will support a level editor and single pixel scrolling in all directions. I'd like to include sonic and tails in this demo, but I'm not very artistic. Would someone more artistic mind putting together a sprite for me? Ideally it will be of tails flying with sonic going along for the ride. It will need to meet the following constraints.

1. Single color bitmap must be 8 pixels wide and less than 65 pixels high.

2. Maximum of 2 bitmaps for animation purposes.

3. One color per horizontal line.

4. Each bitmap can have more than one color scheme. So if changing some of the colors of each line can improve animation, it could improve the animation without adding additional bitmaps.

[ZackAttack]

@Tokumaru

 

Would you mind if I use your artwork in my program?

[tokumaru]

@Tokumaru

 

Would you mind if I use your artwork in my program?

 

Not at all, go ahead. I thought about drawing something according to your request, but couldn't possibly think of a way to draw a flying Tails in just 8 pixels. Sonic hanging might be possible, But I really can't see Tails working.

[ZackAttack]

Awesome thanks. I'll start posting some videos once I make a little more progress. I just about have the player rendering done. Then I can finish up the scrolling implementation.

[ZackAttack]

Got the ring, ball, and running/standing sonic player sprites into the engine. There is still room left for the jumping sprite and the taking damage sprite. I'll add those as soon as I get time. Uncollected rings will be rendered as background since they are stationary. The foreground ring will be for when sonic takes damage. I'll flicker between sonic and one or more rings.

 

I know it's not all that impressive to look at, but the important thing here is that rendering the player uses exactly 22 cycles per scanline during the entire 192 line frame. It had to be small and constant in order to allow the background kernels to work around it.

 

http://youtu.be/AXZcyeuKt6o

[ZackAttack]

Implemented smooth vertical scrolling and became very familiar with the stella debugger. The engine supports a vertical offset of 0-255 and up to 8 background tiles stacked vertically. Each tile can very in height from 1-255. Right now there are 3 different tiles, sky, grass, and dirt. The tiles can be much more complex though, like maybe a nice loop or some enemies.

 

http://youtu.be/FyU75QS3foY

[BrianC]

That video reminds me a lot of the hidden debug code in Sonic 2 for Genesis.

[walaber]

looks like you're making good progress!

[ZackAttack]

looks like you're making good progress!

I was until I forgot to mask of some bits in the horizontal scrolling routine. Of course, debugging would probably be easier if I wasn't using the stack pointer as a spare register.