Alien Revenge ( W.I.P?) but help needed

[easmith]

I know everyone is busy with their own projects, but any advice along the way would be appreciated.

 

The idea is for a game which allows for paddles or joystick . This would be a sequel to my other game Alien Attack.

 

The basic setup is that your cannon rotates around a central base or power supply , which must be defended against enemy bombardment. There are 6 rows of enemies, whose number (<= 3) , spacing, direction , and speed are variable each wave. Thinking a mini kernel each for score, each enemy row, player section, and wave/timer.

 

The enemies fire at your power supply. You can knock out the enemies AND the enemy missiles . If paddle , you will have automatic fire and depressing the button will cease firing . If joystick, button fires.

 

 

 

Assembly using Stella is what I will use as that is all l know. Would also like to keep it 4K.

The logic and programming I think I can handle, but the kernel is a bit daunting. Here are the main challenges and questions I face :

 

1. I have to learn how to display 6 digit score.

2. I need to be able to check, in each section, for at least 6 different enemy missile y locations, player missile y location ( possibly two players) , load PF graphics ( for power supply section) , and then load graphics to draw either player or enemy.

My other games Alien Attack and Pickle use single line kernels, and I struggled to detect and draw three objects on a line in both.

 

So I need some serious schooling on 2 line kernel I guess, which I have been avoiding! I suppose Collect Tutorial is the best source. Is what I want to do even possible? I could probably only draw the missiles for the top 3 rows of enemies in the top three rows and power supply kernels and same for bottom....

 

3. Also would like multi-colored sprites which I have not done.

 

4. I would like to have it to where the enemy missiles can be destroyed without removing the enemy and vice versa.

 

This is a lot of questions, really just thinking out loud I guess. But any thoughts would be appreciated as always. Not sure if I have the chops to tackle this.

 

 

 

 

[ZackAttack]

I like the concept. Would be really cool if the 2 player mode is co-op and gives a slight advantage.

 

My suggestions are:

1. Ditch the horizontal positions of the cannons and instead map Left, LU, Up, UR, and Right to 5 positions facing above. Then mirror that cannon with a second cannon facing down.
2. Single player controls both cannons by moving the top cannon.
3. Double player moves cannons independently making the game a little easier if you team up.
4. P0 for the enemy ships and the Cannons.
5. P1 for enemy missile/bombs.
6. Sync the fire timing of all three enemy rows to keep consistent spacing between the missile/bombs.
7. Shooting the last enemy in row will sometimes drop a powerup which is picked up by shooting it before it expires.
8. BL for cannon fire. Can be different colors depending on current activated powerup.
9. Rapid fire cannon always. Should make kernel design much easier if bullets always have constant vertical spacing and vertical velocity.
10. Button reserved for special powerups such as slow motion, nuke, wide bullets, etc
11. Core is drawn via mirrored PF so only a single PF register needs to be updated.
12. Try to make 1LK work before resorting to 2LK. HMOVE and ENABL can be set at the end of the previous line. GRP0 and COLUP0 should be simple LDA (ind),y STA ZP pairs only taking 16 cycles total. With the lack of PF where all the action is there might just be enough room to pull it off.

[easmith]

 

I like the concept. Would be really cool if the 2 player mode is co-op and gives a slight advantage.

 

My suggestions are:

1. Ditch the horizontal positions of the cannons and instead map Left, LU, Up, UR, and Right to 5 positions facing above. Then mirror that cannon with a second cannon facing down.
2. Single player controls both cannons by moving the top cannon.
3. Double player moves cannons independently making the game a little easier if you team up.
4. P0 for the enemy ships and the Cannons.
5. P1 for enemy missile/bombs.
6. Sync the fire timing of all three enemy rows to keep consistent spacing between the missile/bombs.
7. Shooting the last enemy in row will sometimes drop a powerup which is picked up by shooting it before it expires.
8. BL for cannon fire. Can be different colors depending on current activated powerup.
9. Rapid fire cannon always. Should make kernel design much easier if bullets always have constant vertical spacing and vertical velocity.
10. Button reserved for special powerups such as slow motion, nuke, wide bullets, etc
11. Core is drawn via mirrored PF so only a single PF register needs to be updated.
12. Try to make 1LK work before resorting to 2LK. HMOVE and ENABL can be set at the end of the previous line. GRP0 and COLUP0 should be simple LDA (ind),y STA ZP pairs only taking 16 cycles total. With the lack of PF where all the action is there might just be enough room to pull it off.

 

After much struggling to get a stable 1L kernel, I have somewhat of a proof of concept (kernel only --no motion or gameplay). I am able to get enemies, player laser, and up to 3 enemy missiles on a single scanline. This is done at the expense of some (hopefully) acceptable flicker for the missiles and player laser ( each is drawn once every 4 frames--screenshot only captures 1 frame).

A main concession was eliminating the core/cannon idea and just having a core ( or two cannons) .

For one player, 8 directions of shooting ( this will be needed to hit incoming missiles),

For two player, one will control top cannon ( 5 directions of shooting L,UL,U,UR,R) and the other will control bottom (also with 5 directions L,DL,D,DR,R). Firing will be joystick. Button will be for shield or power-up use.

 

Must destroy incoming fire and enemies before your core/cannon is hit X number of times. Will progressively get faster. Again, want to stay 4K so somewhat limited. Already at 2250 bytes with no gameplay logic. Lot of work to do. Also need to figure out 6-digit score using Assembly.

 

Edited July 9, 2018 by easmith

[easmith]

At a very rough early stage, but a few mysteries I am having trouble solving. I apologize for the low level of these questions...

 

1. My scanline count is a stable 268 ( i understand this is fine ) UNLESS the player laser is fired right ( 270) or fired right up or right down (269). I don't understand what would cause this since firing the laser should not affect the number of scanlines.

 

2. Also, even when the scanlines remain stable ( no firing) , on any frame where no enemy missiles are drawn, the screen gets slightly shorter vertically

( this is causing the jumping). Stepping frame by frame through Stella debugger shows this.

 

 

 

 

 

I am assuming that I must be exceeding the allotted number of cycles somewhere ?? I am pretty sure I am under 76 cycles on every scanline ...

 

The kernel consists of 10 different parts: top numbers, enemy row 1, enemy row 2, enemy row 3, player row 1, player row 2, enemy row 5,

enemy row 6, enemy row 7, bottom numbers.

 

Help please!

 

 

 

 

Revenge.bin

Edited July 12, 2018 by easmith

[ZackAttack]

Are you using the PositionObject subroutine on the ball after the score is drawn? That routine will take 1 or 2 scanlines depending on the position of the object, which isn't a problem during vblank if you're using the timer, but will cause problems if you're using it to position something in between display kernels.

[easmith]

using this routine:

 

Posloop ; this is positioning routine

sec

sta WSYNC

DivideLoop

sbc #15

bcs DivideLoop

eor #7

asl

asl

asl

asl

sta HMP0,x

sta RESP0,x

rts

kernel sequence :

 

1. draw score

************************

position P0=each enemy,P1=enemy1 missile, M0 = enemy 2 missile , M1= enemy 3 missile, BL = player laser

********************

2. draw enemy row 1

***********************

re -position P0

*******************************

3. draw enemy row 2

**********************

re-position P0

************************

4. draw enemy row 3

**********************

re-position P0

**********************

5. draw base level top ( top enemy missiles will not go below here)

********************

re-position P0=each enemy,P1=enemy6 missile, M0 = enemy 5 missile , M1= enemy 4 missile, BL = player laser

**********************************

6. draw base level bottom ( bottom enemy missiles will not go above here)

**********************************

re position P0

*****************************

7. draw enemy row 4

*********************

reposition P0

*********************

8. draw enemy row 5

***********************

reposition P0

*********************

9. draw enemy row 6

*****************************

10. draw bottom numbers

Edited July 12, 2018 by easmith

[ZackAttack]

Yeah, that routine takes a varying number of lines depending on object position. Either modify the routine to always consume 2 lines or use the timer again to make the number of lines for positioning all those objects constant.

 

You could also position some of the objects in vblank if they're not used by the score.

[easmith]

Yeah, that routine takes a varying number of lines depending on object position. Either modify the routine to always consume 2 lines or use the timer again to make the number of lines for positioning all those objects constant.

 

You could also position some of the objects in vblank if they're not used by the score.

 

Sorry for being so dense, but I don't think I quite understand. I see how each pass through the loop would take a variable number of cycles depending on position, but doesn't the WSYNC even out the timing of each positioning?

 

I moved the initial positioning of the objects to vblank, but still must position P0 between each row kernel.

 

Still have to re position all objects after top (red) half of base. Now 259 scanlines and 260 when firing R and DR. Also, the top laser does not reset in center exactly after firing up left or up right ( can see better in the attached ROM). . Also still don't understand the general jumpiness of objects which are not supposed to flicker ( enemies and base)

Revenge.bin

[Just Jeff]

 

Sorry for being so dense, but I don't think I quite understand. I see how each pass through the loop would take a variable number of cycles depending on position, but doesn't the WSYNC even out the timing of each positioning?

 

I moved the initial positioning of the objects to vblank, but still must position P0 between each row kernel.

 

Still have to re position all objects after top (red) half of base. Now 259 scanlines and 260 when firing R and DR. Also, the top laser does not reset in center exactly after firing up left or up right ( can see better in the attached ROM). . Also still don't understand the general jumpiness of objects which are not supposed to flicker ( enemies and base)

 

For horizontal positioning, if your object is too far to the right (very late timing), the WSYNC will happen after the beam has hit the next line already, causing it to add a line.

 

But you can see that your background colors stay stable, so I don't think that is it. Your vertical size of your sprites is changing.

 

Check your immediate loads. At some points, you have SBC $03 which is the RSYNC register. Likely you meant SBC #03. You may have others.

 

Also, not that it will cause an error, your are loading the accumulator with the same value that is already in it a lot.