ZackAttack

I went ahead and put the HMOVE in every scan line of tile anyway. I figure it's better to do it now before I create a bunch of tiles that would need to be changed later. Besides, almost all the tiles will need to position objects. Only the simplest tiles don't require player1 and ball objects, and those can certainly afford the extra 3 cycles. Now I'm thinking about making P0 single width so moving sonic off the screen can be done without having to mask the graphics that wrapped around to the other side of the screen. Which means lost rings can bounce completely off the screen in either direction anywhere in the level. I'll upload another video once I finish the platform tile. Right now you can't tell that it's scrolling horizontally cause all the tiles are horizontal lines. Basically the Engine handles coarse (32pixel) horizontal scrolling and each SubKernel handles smooth scrolling inside of a 32pixel range. With the exception of the sky,grass, and dirt tiles, each tile will be built up of 6 or more SubKernels. The level data stores the SubKernel ID and the Height for that instance of the SubKernel. Each 32pixel column of the level gets 8 slots to place SubKernels. So it works out to 2 horizontal pixels per byte of level data plus an extra 159 pixels when you scroll all the way to the right of the level. Currently I have reserved 128 bytes for level data which produces a level that is 415x447 pixels total. Hopefully I'll have enough room for one more page of level data, bringing the level size up to 671x447.

I really want to keep it a single line kernel. There will have to be some "dead space" at the top of each tile where only the background color can be controlled. I finished up the horizontal scrolling. It works in all 8 directions now. The biggest hurdle now is creating the tiles to place in the level. The other issue I ran into is the HMOVE bar on the left side of the screen. This is my first Atari project and I didn't realize that issue existed. The cycle 74 trick is out because the loop and downhill sections require right movement. So it's either use a black PF0 with high priority or HMOVE every scan line. The PF0 option requires the ball to be black too so that probably won't work. So I think HMOVE on every scan line will have to be what is done.

Well done. This game is a lot of fun. I suck at it though. Am I the only one who thinks the ninja looks like he is pooping when he is sliding down the wall? Maybe it's just the lack of sleep...

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.

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

Have you tried out setting PF0 to $FF on reset and leaving it at that to see what it looks like?

That would require some amazingly timed code in every kernel. Did you try changing the object priorities? Here's an excerpt from the stella guide:

That's a good idea. If you can, it would be perfect for building a 2 player split screen game.

I thought blanking was required for 37 scanlines after vertical sync to prevent the electron beam from producing artifacts on the screen while it retraced from the bottom of the screen to the top. Isn't turning it on during overscan just a convenient way of drawing black during overscan? I'll go with this for now until I get my Encore to test with. Maybe in addition to the Harmony Encore, I should buy a CRT TV to test on too. It would suck to spend all this effort on making an 8way scrolling game engine if it doesn't work properly on the original hardware.

How much of a window is there for clearing the VBLANK flag? If the STA VBLANK occurred on cycles 74-76 of the 37th scanline would that be good? Or should it be cleared during the HBLANK of the scanline following the 37 VBLANK scanlines?

I really like the new colors and enemies. This version is a huge improvement over the last. The jump could use some work though, it should allow you to move horizontally and the vertical speed should slow at the top of the jump and then speed up again on the way down. In other words, better physics would be cool. I'd still like to see the dragon breathing fire.

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

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.

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

I'd suggest coloring the enemies based on class instead of using random colors. Each class of enemy should have a different attack pattern, power, damage, and color. It would be cool if the dragon was green and breathing fire. Since there are no playfield objects in the horizontal region where the dragon resides, you could set the playfield color to orange/red/yellow and use the ball to draw the flame. This technique could be used for other enemies too on some screens. It might be interesting to have to bring the princess back to the castle. She could follow you to the edge of the screen and then wait there while you clear the enemy on the next screen. As soon as the enemy is dead, she would come running up to you and follow you to the edge of the screen again. If the falling rocks hit her it could decrease your health or end the game.

This is really nice. I will definitely use this routine when I need to position multiple objects and the extra scanline/cycles can be tolerated. The 8way scrolling engine I'm constructing only needs to position P0 in this manner. I guess once I run out of CPU cycles or ROM bytes I'll know which approach is right for that project.

I was able to increase the range to 0-160. 160 is equivalent to 0, but it could be useful for smoothly moving the player off the right side of the screen. The ides behind this algorithm is that it uses the division by 15 to create the delay required to position the RESP0 strobe. The remainder is used for fine movement of course. Since the division itself produces the delay, there is no need to track the quotient. Bit 7 in PlayerX is used to decide if the player is on the left or right side of the screen. This gives enough time to calculate and set HMP0 on the same scan line. I wrote this cause I couldn't find any existing code to do this. If there is a better way to do it, I'd like to know. I couldn't figure out how to edit my original post so I'll attach the files here. positionMacro.asm positionMacro.bin

I've created a macro to position player0 and was hoping I could get someone to test it on real hardware for me. It only uses 72 CPU cycles and supports a horizontal position from 0 through 157. Left/Right on joystick moves sprite back and forth. Hold fire to step the movement 1 pixel per joystick movement. I'm including the bin and the asm file. Any feedback is appreciated. Thanks. positionMacro.bin positionMacro.asm

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.

If there's going to be a gap in the middle of the scanline, couldn't the COLUPF just be set to match the COLUBK halfway through the scanline to avoid the merging of PF and player graphics? Then you'd only have to update the COLUPF register twice per scanline instead of all the PF registers. (Assuming SpiceWare's assumption is right)

It looks like variable v holds which room you are currently in and can be 0-8. It also looks like you always begin in room 0. So I would recommend generating a number between 1-8. This will prevent the random number from ever being the starting room. if joy0fire then g = (rand&7) + 1 : goto start Now g will contain a room 1-8 to hide the item in. Instead of having an if for each room you can simply compare g with v. If they are equal, you must be in the room with the item. Then we can use data arrays to lookup the x and y positions for each room. Notice that v is used to index into the _item_x_location data array. For example if v is 3, _item_x_location[v] will evaluate to 120 since 120 is the 3rd item in the _item_x_location[v] array. if g = v then missile0x=_item_x_location[v] : missile0y=_item_y_location[v] else missile0x=0 : missile0y = 0 data _item_x_location 30, 30, 120, 80, 50, 50, 50, 50, 50 end data _item_y_location 50, 50, 20, 50, 50, 50, 50, 50, 50 end Hope that helps.

This code looks very redundant. There should be a much easier way to do it than having so many similar if/else statements. I'm not sure how v is being used in the rest of your program. If you post the .bas source file I could assist you further.

You could use this to generate a random number between 0 and 8. (Add 1 if you need 1-9 instead) a = (rand&1) + (rand&7) There are other ways you could do it too. Though I'm guessing the speed for this isn't critical since it's at the start of the game.

Congrats on your first game! I'd like to suggest you change the cowpie behavior so it doesn't follow the cow's horizontal movements. Occasionally the cow moves while a cowpie is flying and it looks weird when the cowpie follows the cow.

If you're looking to understand the internal workings of the CPU I'd start with this video https://www.youtube.com/watch?v=fWqBmmPQP40 and then play with the 6502 simulator at http://visual6502.org/JSSim/expert.html You can also download the source for the visual 6502 simulator if you want to go all the way down to the gate level of the chip.