RAM Combat

[Wickeycolumbus]

I wanted to take a stab at making a RAM based game, so I decided to try to do Combat. Right now, it is two player, and the tanks fire automatically. When you hit your opponent's tank, your tank gets larger, and your opponent's gets smaller. There are several bytes free, so let me know if you have suggestions! The tanks can only move vertically, I am not sure If I can make them move horizontally in only 128 bytes.

Archive_6.zip

[Kojote]

Wickeycolumbus nice to see you joining the RAM game fun

 

Just on a sidenote, such games would also qualify for my compo, if they match the theme =)

[Wickeycolumbus]

I saved a few bytes here and there, 16 bytes free total. I am going to try using the fire button to fire rather than automatic firing.

 

I have found it useful since I make no use of the stack, to use the stack pointer as an extra 'register'. In initialization, set the SP to any byte you will use frequently in your game loop, and when you want to access that number, do a tsx, and x contains the value I hope this helps other people doing RAM based games.

 

Wickeycolumbus nice to see you joining the RAM game fun icon_smile.gif

 

Just on a sidenote, such games would also qualify for my compo, if they match the theme =)

 

Thanks Kojote! I want to enter the contest, but I have not yet come up with a good idea for a puzzle game.

RAMCombat2.zip

[Thomas Jentzsch]

Welcome to the club Wickey!

 

BTW: For checking collision registers, you should use BIT, which will save some bytes. For the joysticks, you can load SWCHA into A and then use repeated LSRs.

 

Also think about looping instead of repeating similiar code for both players.

[Wickeycolumbus]

I added some sound when the tanks get hit

 

Welcome to the club Wickey!

 

 

 

For the joysticks, you can load SWCHA into A and then use repeated LSRs

 

I am not quite sure I understand what you are saying. How would I LSR what I am ANDing?

RAMCombat3.zip

Edited May 10, 2009 by Wickeycolumbus

[Thomas Jentzsch]

I am not quite sure I understand what you are saying. How would I LSR what I am ANDing?

  lda SWCHA
 lsr
 bcc .skipRightUp
 ...
.skipRightUp
 lsr
 bcc .skipRightDown
 ...
.skipRightDown
 ...

I think you got the idea.

 

Works also with ASL e.g. if you are only interested into the left player joystick.

[Wickeycolumbus]

I am not quite sure I understand what you are saying. How would I LSR what I am ANDing?

  lda SWCHA
 lsr
 bcc .skipRightUp
 ...
.skipRightUp
 lsr
 bcc .skipRightDown
 ...
.skipRightDown
 ...

I think you got the idea.

 

Works also with ASL e.g. if you are only interested into the left player joystick.

 

Cool, thanks. Saved 4 bytes

 

Horizontal movement is next! (hopefully)

RAMCombat4.zip

[Thomas Jentzsch]

Horizontal movement is next! (hopefully)

Use relative movements (HMxy) only. RESPx is using way too much bytes.

[Thomas Jentzsch]

Any more progress on this one?

[Wickeycolumbus]

Any more progress on this one?

 

Not much I haven't had much time, but now one of the players can move horizontaly (sort of)

Archive_8.zip

[Wickeycolumbus]

I had some time to work on this today. I decided to drop horizontal movement and use the button to fire instead. I only need to free 4 more bytes so I can include the M1/PF collision detection, let me know if you see anywhere I can free some bytes!

 

EDIT: Now I only need 2 more bytes

Archive_12.zip

Edited June 16, 2009 by Wickeycolumbus

[Omegamatrix]

Hi Wickey,

 

Maybe something like this?

 

   ldx   #1
.loopCollisions:
  lda  CXMOP,X
  bpl  .skipIncrement
  inc  P0_End,X
  dec  P1_End,X
  lsr  AUDV0; will this work?
.skipIncrement
  dex
  bpl  .loopCollisions
; X=$FF, so no need for TSX below

 

I'm using your LSR AUDV0 in there. My question is does that work? It's great if it does.

 

I did not check if you got your ram lined up like this already. I couldn't get your code to compile, so it's untested. There was a branch out of range (easy fix), but a deeper problem with some label mismatch in the "sprite positioning" routine. I was using the non-mac assembly file here.

Edited June 16, 2009 by Omegamatrix

[Wickeycolumbus]

Hi Wickey,

 

Maybe something like this?

 

   ldx   #1
.loopCollisions:
  lda  CXMOP,X
  bpl  .skipIncrement
  inc  P0_End,X
  dec  P1_End,X
  lsr  AUDV0; will this work?
.skipIncrement
  dex
  bpl  .loopCollisions
; X=$FF, so no need for TSX below

 

I'm using your LSR AUDV0 in there. My question is does that work? It's great if it does.

 

I did not check if you got your ram lined up like this already. I couldn't get your code to compile, so it's untested. There was a branch out of range (easy fix), but a deeper problem with some label mismatch in the "sprite positioning" routine. I was using the non-mac assembly file here.

 

That will not work because of these two lines:

 

   inc  P0_End,X
  dec  P1_End,X

 

P0_End, P1_End, P0_Y, and P1_Y are a few bytes apart (this saves 4 bytes) I think I may have come up with a solution though. The lsr AUDV0 works BTW, but you have to clear AUDV0 every frame.

[Omegamatrix]

That will not work because of these two lines:

 

   inc  P0_End,X
  dec  P1_End,X

 

P0_End, P1_End, P0_Y, and P1_Y are a few bytes apart (this saves 4 bytes)

 

Oh well, I tried.

 

The lsr AUDV0 works BTW, but you have to clear AUDV0 every frame.

 

I wonder though if it it is reading INPT1, and then writing it back into AUDV0? If the value from the register is being loaded from memory, shifted, and then put it back into the memory? INPT1 is what is read when you try to read AUDV0, according to the memory map.

Edited June 16, 2009 by Omegamatrix

[Wickeycolumbus]

Ok, just one more byte now!

Archive_13.zip

[Wickeycolumbus]

Got it! I forgot I did not use tsx to get #$FF into X any more, so I set the stack pointer to 1 so I could save a byte by doing a tsx instead of the ldx #1. I think this will be the final version.

Archive_14.zip

Edited June 17, 2009 by Wickeycolumbus