16 replies to this topic

[atari2600land]

I am wanting to expand my knowledge of assembly, so I'm beginning work on a second game. It took at least a few hours to start a new game from scratch. I want to draw a different playfield though, just stars since this game is set in outer space (yes, another one.) I am wanting to draw the constellation Ursa Major and call the game that as well since we need more 2600 games that start with the letter U. So my question is, how does one go about figuring out what the values in PF0, 1, and 2 do? I mean, for example, I used the playfield in Dodgeball just to see if I could. Its PF values are in lines 344-399 in my code. The problem is, I don't know why those specific values produce exactly what's on the screen.

 

Attached Files

•  ursa1.zip   34.23KB   71 downloads

[SpiceWare]

Session 14: Playfield Wierdness

 

Session 18: Asymmetrical Playfields

 

Step 3 - Score & Timer display

[atari2600land]

OK, I have an idea for this game. It's called "Alien Jail." (Not to be confused with "Alien Greed.") You play the role of Zybort, a space cop patrolling Area 4751 of the Lllarbignil Galaxy. It's like a gated community, only in space, and with no gates. But apparently some aliens refuse to listen or don't know any better, and make their way into the area. Your job is to take them to the Alien Jail (the box-like structure in the center of the screen). While avoiding the nasty moving stars. (I'll make them easy to distinguish from the stars on the screen now. They will be colored differently, bigger, and perhaps blinking.)

Missile 0, missile 1 = stars

Player 0 = Zybort's ship

Player 1 = alien to haul off to jail.

Your patrol ship doubles as a tow truck. To tow the alien, touch it with your ship and it will follow you. Then, drag it into the Alien Jail.

All I have got so far are the stars, the alien jail, and a 0000 score.

Sound fun?

Attached Files

•  alienjail1.zip   4.68KB   64 downloads

[atari2600land]

I got Zybort's ship in the game, but it doesn't bump into the playfield even though it's supposed to. Why not?

Attached Files

•  alienjail2.zip   6.72KB   55 downloads

[tschak909]

Run it through the debugger and set a breakpoint where the collision register is checked.

 

-Thom

 

p.s. I find it scary that you're using bits of my code.

[atari2600land]

I fixed it. I'm guessing the problem was I was checking the collisions before the playfield was drawn.

Attached Files

•  alienjail2a.zip   6.56KB   55 downloads

[tschak909]

Yes, This is commonly why collisions are checked during the overscan period. As the screen gets clocked out, the collision registers will latch as things overlap, and stay latched until you clear the registers.

 

-Thom

[atari2600land]

Trying to work on the other alien's movement. I want him to go randomly around the stars and if he hits the playfield, change direction. What it does now is if he hits the playfield, the screen goes black. Sometimes it starts with a frozen black screen. Help would be appreciated.

Attached Files

•  alienjailthree.zip   6.86KB   61 downloads

[atari2600land]

I did it! Game now works the way I want it to for now, and at a stable 262 scanlines. I'm not done yet, though, so I'll probably break the game a lot more.

 

Attached Files

•  alienjail3a.zip   7.37KB   46 downloads

[atari2600land]

Question time. I put missile0 in the game and it's supposed to move diagonally and bounce around the edges of the screen (and not the playfield), but instead it moves in conjunction with player1 (the purple ship.) Why? I also spent an hour and a half trying to disable diagonal movement since it was making the scanline 264 instead of 262, until I realized that by switching the SWCHA test value from 127 to 63, it didn't bump up the scanline count to 264. Most of that hour and a half was spent trying to get everything an even 262. I think I did it here.

Attached Files

•  alienjail4.zip   7.8KB   51 downloads

[Omegamatrix]

You got errors.

 

 

Look at your ram:

PlayerX0:	ds 1
PlayerX1:	ds 1
PlayerX1S: 	ds 1
PlayerY1S: 	ds 1
PlayerX0S: 	ds 1
PlayerY0S: 	ds 1

Look at your loop for positioning:

	;;
	;; Apply X motion vectors.
	;; 
	ldx #$00
	
ApplyMotion:	
	lda PlayerX0,x
	jsr PosObject
	inx
	cpx #$06
	bne ApplyMotion

Look at what X does in the "PosObject" Subroutine:

        sta.wx HMP0,X  ; 5 19 - store fine tuning of X
        sta RESP0,X    ; 4 23 - set coarse X position of object

In other words, the value of X will be used to index which registers get written to:

X=0  HMP0, RESP0
X=1  HMP1, RESP1
X=2  HMM0, RESM0
X=3  HMM1, RESM1
X=4  HMBL, RESBL

Putting it all together with your current ram layout:

PlayerX0   ----> X position for P0
PlayerX1   ----> X position for P1
PlayerX1S  ----> X position for M0
PlayerY1S  ----> X position for M1
PlayerX0S  ----> X position for BL
PlayerY0S  ----> THIS is also being called by your loop, and ultimately writes to VDELP0 and AUDC0!!

That should help you a bit.

[atari2600land]

OK, I'm trying to understand. I tried to fix the errors I had, but now all missile0 is doing is moving up and down and not left and right like I want.

 

Attached Files

•  alienjail5.zip   8.24KB   43 downloads

[Omegamatrix]

I would suggest at this point you look at renaming your variables and searching where they are being used in your file, because:

 

1) BallX0 is actually not the ball (confusing!), but M0 X-position.

2) Several places in the code have comments indicating BallX0 is a Y variable, not and X variable.

 

You could do better by naming BallX0 something like m0_Xpos, or whatever floats your boat. 

 

It looks like you got the positioning loop straightened out. As you can see it positions P0,P1,M0,M1, and the BL each time it runs. Make sure all the variables are set up correctly in ram so that they can be indexed as lda PlayerX0,X

 

 

BTW, your loop is more efficient if it counts down. This is because you can DEX and skip the compare. Just change the branch to BPL. When X goes from 0 to $FF the branch will not be taken.

    ;;
    ;; OLD
    ;;
    ldx #$00

ApplyMotion:
    lda PlayerX0,x
    jsr PosObject
    inx
    cpx #$04
    bne ApplyMotion



    ;;
    ;; NEW
    ;;
    ldx #4

ApplyMotion:
    lda PlayerX0,x
    jsr PosObject
    dex
    bpl ApplyMotion

[atari2600land]

I would like missile0 to move diagonally. It does, but it ignores the part of the code about m0_X's borders I put (lines 866-910 in my code). Any idea why? I renamed the Ball variables and changed them to reflect what they are: Missile0.

Attached Files

•  alienjail6.zip   8.28KB   52 downloads

[tschak909]

 

I would suggest at this point you look at renaming your variables and searching where they are being used in your file, because:

 

1) BallX0 is actually not the ball (confusing!), but M0 X-position.

2) Several places in the code have comments indicating BallX0 is a Y variable, not and X variable.

 

You could do better by naming BallX0 something like m0_Xpos, or whatever floats your boat. 

 

It looks like you got the positioning loop straightened out. As you can see it positions P0,P1,M0,M1, and the BL each time it runs. Make sure all the variables are set up correctly in ram so that they can be indexed as lda PlayerX0,X

 

 

BTW, your loop is more efficient if it counts down. This is because you can DEX and skip the compare. Just change the branch to BPL. When X goes from 0 to $FF the branch will not be taken.

    ;;
    ;; OLD
    ;;
    ldx #$00

ApplyMotion:
    lda PlayerX0,x
    jsr PosObject
    inx
    cpx #$04
    bne ApplyMotion



    ;;
    ;; NEW
    ;;
    ldx #4

ApplyMotion:
    lda PlayerX0,x
    jsr PosObject
    dex
    bpl ApplyMotion

 

OmegaMatrix: This is because he's using parts of one of my iterations of the Dodgeball kernel and vblank code.

 

-Thom

[gauauu]

So my question is, how does one go about figuring out what the values in PF0, 1, and 2 do? I mean, for example, I used the playfield in Dodgeball just to see if I could. Its PF values are in lines 344-399 in my code. The problem is, I don't know why those specific values produce exactly what's on the screen.

 

 

Now that you understand how they work, here's a tool I threw together to make it easier to design playfields.  May or may not be helpful, but thought I'd mention it just in case.

[MacrosCode]

 

Now that you understand how they work, here's a tool I threw together to make it easier to design playfields.  May or may not be helpful, but thought I'd mention it just in case.

 

Nice tool!

 

I played around a bit with it!

This is very useful to understand the messy bits of the playfield registers (different left-to-right order).

 

Wouldn't it be a nice idea to collect this and even more tools in a different blog/thread or whatever here at atariage.com?