raindog Posted June 3, 2014 Share Posted June 3, 2014 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. Quote Link to comment Share on other sites More sharing options...
roland p Posted June 9, 2014 Share Posted June 9, 2014 @Tokumaru. It has been a while ago, but do you hapen to have mockups of longer levels? Quote Link to comment Share on other sites More sharing options...
tokumaru Posted June 15, 2014 Author Share Posted June 15, 2014 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! =) 3 Quote Link to comment Share on other sites More sharing options...
Estlib Posted June 28, 2014 Share Posted June 28, 2014 tokumaru, you should continue this. i would love to see another sonic attempt on the 2600 in addition to zippy. Quote Link to comment Share on other sites More sharing options...
tokumaru Posted June 28, 2014 Author Share Posted June 28, 2014 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. 1 Quote Link to comment Share on other sites More sharing options...
Andromeda Stardust Posted June 28, 2014 Share Posted June 28, 2014 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? Quote Link to comment Share on other sites More sharing options...
phillip_roberts Posted December 17, 2014 Share Posted December 17, 2014 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. Quote Link to comment Share on other sites More sharing options...
Andromeda Stardust Posted December 17, 2014 Share Posted December 17, 2014 Bump. Did any updates come out of this? Quote Link to comment Share on other sites More sharing options...
roland p Posted December 17, 2014 Share Posted December 17, 2014 (edited) 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 Quote Link to comment Share on other sites More sharing options...
roland p Posted December 17, 2014 Share Posted December 17, 2014 Some inspiration: Quote Link to comment Share on other sites More sharing options...
ZackAttack Posted December 17, 2014 Share Posted December 17, 2014 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. Quote Link to comment Share on other sites More sharing options...
roland p Posted December 17, 2014 Share Posted December 17, 2014 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. Quote Link to comment Share on other sites More sharing options...
roryjr Posted December 18, 2014 Share Posted December 18, 2014 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' Quote Link to comment Share on other sites More sharing options...
Andromeda Stardust Posted December 18, 2014 Share Posted December 18, 2014 512kb is a lot, I'll admit. But Sprybug has already pulled it off with 64kb. See also Zippy the (non-infringing) Porcupine Quote Link to comment Share on other sites More sharing options...
ZackAttack Posted December 18, 2014 Share Posted December 18, 2014 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 __ __ / \ ___ / \ | | ___/ \__ | | _____\__/_____/ \_____\__/_____ ____ | | | | __ __ / \ / \ | | | | _____\__/_____ _____\__/_____ ___ ____ ____ ___/ \__ | | ____/ \____ | | Quote Link to comment Share on other sites More sharing options...
Andromeda Stardust Posted December 19, 2014 Share Posted December 19, 2014 __ __ / \ / \ | | | | _____\__/_____ _____\__/_____ ___ ____ ____ ___/ \__ | | ____/ \____ | | I see a frowny face, LOL... Neat idea, hope you pull it off... Quote Link to comment Share on other sites More sharing options...
ZackAttack Posted January 10, 2015 Share Posted January 10, 2015 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. 2 Quote Link to comment Share on other sites More sharing options...
ZackAttack Posted January 13, 2015 Share Posted January 13, 2015 @Tokumaru Would you mind if I use your artwork in my program? Quote Link to comment Share on other sites More sharing options...
tokumaru Posted January 13, 2015 Author Share Posted January 13, 2015 @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. Quote Link to comment Share on other sites More sharing options...
ZackAttack Posted January 13, 2015 Share Posted January 13, 2015 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. Quote Link to comment Share on other sites More sharing options...
ZackAttack Posted January 14, 2015 Share Posted January 14, 2015 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 Quote Link to comment Share on other sites More sharing options...
ZackAttack Posted January 15, 2015 Share Posted January 15, 2015 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 Quote Link to comment Share on other sites More sharing options...
BrianC Posted January 16, 2015 Share Posted January 16, 2015 That video reminds me a lot of the hidden debug code in Sonic 2 for Genesis. Quote Link to comment Share on other sites More sharing options...
walaber Posted January 16, 2015 Share Posted January 16, 2015 looks like you're making good progress! Quote Link to comment Share on other sites More sharing options...
ZackAttack Posted January 16, 2015 Share Posted January 16, 2015 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. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.