Jump to content
Have You Played Atari Today?
2600|5200|7800|Lynx|Jaguar|Forums|Store  

ZackAttack

Members
 View Profile  See their activity

  • Content Count

    785

  • Joined

  • Last visited

Posts posted by ZackAttack

  6. Posted

    If you can pull this off, it'd be a great feat. If you have Tails in there, it'd make a kick ass "sequel" to Zippy.

    You know I hadn't even considered that. Hopefully I'll have some time to continue work on it this weekend. The biggest issue I see right now is ROM space. I think a full game would need 1MB mapped into 16 different sets of 256 pages. Good thing eeprom is cheap.

  9. Posted

    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.

  10. Posted

    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.

  14. Posted

    I have a slightly strange sprite to hide here is an example of it being displayed

     

    attachicon.gifDemo_000dd0dd.png

     

    As you can see I am looking to hide the parts that are being shown on either side and display only the portion that is overlapping the playfield.

     

    I use a masking kernel and my first thought was moving the mask up and down to draw to hide portions that are not needed.

     

    Then when I saw this i though it could also prove useful in this case.

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

  15. Posted

    Thanks ill have a read of that.

     

    I would like to blank the screen on the far left and right of the screen. I have a mirrored playfield and don't draw anything in the PF0 region. But I am having trouble with sprites straying over this region when they are half on and half off the playfield on either end.

     

    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:

     

    To make the players and missiles move behind the playfield, a "1" must be written to D2 of the CTRLPF register.

     

     

     

  17. Posted

    VBLANK is not that critical. If you enable blanking after the display has been drawn and disable at the beginning of vertical sync, that should be more than long enough. You can keep it enabled during vertical sync or even until the next display starts.

     

    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?

     

    So you are saying when you want to start drawing a picture? As far as I know, it can technically be done at any point in the scan line, but if it is during the visible part you will get a partial line at the top. Same goes for the bottom. There are probably some examples of this in the released games... Lots of times you hit WSYNC first just so you know where you're at. If you know for sure it will be cycle 74 - 76 every time, you should have no trouble.

     

    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.

  19. Posted

    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.

  20. Posted

    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

  23. Posted

    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.

    • Like 1

  24. Posted

    Came up with it on your own? Not bad. This is what we tend to use:

     

    PosObject:              ; A holds X value
        sec             ; 2  
        sta WSYNC       ; X holds object, 0=P0, 1=P1, 2=M0, 3=M1, 4=Ball
DivideLoop:
        sbc #15         ; 2  
        bcs DivideLoop  ; 2  4
        eor #7          ; 2  6
        asl             ; 2  8
        asl             ; 2 10
        asl             ; 2 12
        asl             ; 2 14
        sta.wx HMP0,X   ; 5 19
        sta RESP0,X     ; 4 23 <- set object position
SLEEP12: rts             ; 6 29

    Benefits are it works for all objects, and it eliminates the table. Disadvantage is it sometimes goes to a second scanline.

     

    That SLEEP12 label at the end is used for wasting 12 cycles by doing a jsr SLEEP12.

     

    If you check my blog you'll find source code for all my projects (with the exception of Stay Frosty 2, whose source will be eventually posted as part of my The Story of Stay Frosty 2 blog series).

    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.

  25. Posted

    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

AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2021 AtariAge

×
×
  • Create New...