www.retrosoftware.co.uk
http://www.retrosoftware.co.uk/forum/

I'm thinking of programming a Bi-plane Dogfight game
http://www.retrosoftware.co.uk/forum/viewtopic.php?f=19&t=905		 Page 1 of 1
Author:  jbnbeeb [ Tue May 20, 2014 10:07 am ]
Post subject:  I'm thinking of programming a Bi-plane Dogfight game
...In fact I've been thinking about it for a while and working on it since Dec 2013! Progress has been slow so I've not really said much about it other than cries for help when I've been stuck writing some routines.

The game will be a clone /based on the plane dogfight game "BiPlane" on the Commodore Amiga. I think it was a public domain game given away on magazine cover disks BITD.
http://www.youtube.com/watch?v=VOfG04NFt0E

I think the original 2 player biplane dogfight type game was the Atari 2600 release "Atari Combat" . This was 2 player only, and had multiple game options - you could choose between tanks or biplanes.
http://www.youtube.com/watch?v=yfwj1fe3QEY

There were a couple of attempts on the Beeb BITD ("Bandits - Dogfight" by Micropower and "Dogfight" by Opus) but they're a bit slow and unsatisfying to play. Also I don't think there was a 1 player option on the Beeb efforts either.

Last night, I finally found a bug in my sprite movement routine (which was causing uneven movement) that I've been trying to fix for months. I'm really chuffed as I can now move the plane around the screen..so I have something to show now! I was holding back from a dev diary until this was the case otherwise it would've made for a bit of a dull read.

My goal is to have a better dogfight game than the original Beeb releases and for it to have a 1 player option - i.e game AI which will be a real challenge for me.

Cheers,
jbnbeeb
[edited for links and names of the original Beeb dogfight games]
Author:  tricky [ Tue May 20, 2014 7:08 pm ]
Post subject:  Re: I'm thinking of programming a Bi-plane Dogfight game
What was the bug and how did you find it?
Author:  jbnbeeb [ Tue May 20, 2014 8:25 pm ]
Post subject:  Re: I'm thinking of programming a Bi-plane Dogfight game
tricky wrote:
What was the bug and how did you find it?


Good question. I was using the wrong branch instruction in the y axis part of the sprite movement routine. I used BCS instead of BCC when determining whether I needed to move down the screen to the next char row (snippet below).

I tracked it by using debugger in B-Em + pencil and paper. Previously, I had been trying to use just the debugger on mylaptop whilst on my commute to work..kept running out of time and forgetting what I was doing each time I tried to carry on!

At home, by scribbling notes and referring to the Mode 5 screen layout in Adv user guide, plus the debug output I could see what was happening.

I put a Break at the start of the MoveSprite routine and Watched for writes of updates to the screen address the routine was outputting to the Sprite structure. By checking the addr of the PC register from the Watch output, I was able to see where the writes were occurring and work it out from there.

..I should say also that I redirected the verbose B-Em assembled output to a text file which gives the memory address of each instruction.

Speaking of verbose .. above is a bit waffly but maybe it will be of use to others. Might even be a useful little tutorial in it perhaps!.


Code:
ldy #SS_CurrScrAddr
               lda (SprStructPtr), Y
               clc
               adc tmp
               sta tmp2 ; addr + y move amount
               and #&7   ;
               cmp #&8
               bcc posyWithinChar  ; changed from incorrect bcs to bcc on 19th may.. we need to be checking that 3 lsbs are <=7 (<8)  as each char row is 8 pixels deep. so if we are the 8th pixel down in a char row, and we want to go one pixel lower, we need to cross in to the next char row - thus increment hi byte of scr addr, and then decrement by 8 pixels
Author:  tricky [ Wed May 21, 2014 8:40 am ]
Post subject:  Re: I'm thinking of programming a Bi-plane Dogfight game
I've made similar mistakes with the carry being a borrow.
CMP is the only instruction that I have anything other than cycle counts for when programming!
I know it is the same as SBC, but never trust my memory for which way round it is ;)
Author:  RichTW [ Fri May 23, 2014 9:05 am ]
Post subject:  Re: I'm thinking of programming a Bi-plane Dogfight game
jbnbeeb wrote:
Code:
ldy #SS_CurrScrAddr
               lda (SprStructPtr), Y
               clc
               adc tmp
               sta tmp2 ; addr + y move amount
               and #&7   ;
               cmp #&8
               bcc posyWithinChar  ; changed from incorrect bcs to bcc on 19th may.. we need to be checking that 3 lsbs are <=7 (<8)  as each char row is 8 pixels deep. so if we are the 8th pixel down in a char row, and we want to go one pixel lower, we need to cross in to the next char row - thus increment hi byte of scr addr, and then decrement by 8 pixels

Just looking at that code snippet, the bcc will always be taken as ANDing with 7 ensures that the result will always be less than 8. Another bug?
Author:  jbnbeeb [ Fri May 30, 2014 6:35 pm ]
Post subject:  Re: I'm thinking of programming a Bi-plane Dogfight game
:oops:
Good spot Rich, thanks for that!
I've now amended to:
Code:
;sta tmp ; ymov amount
               ldy #SS_CurrScrAddr
               lda (SprStructPtr), Y
               and #7
               clc
               adc tmp
               ;sta tmp2 ; addr + y move amount
               ;and #&7   ;
               cmp #&8
               bcc posyWithinChar  ; changed from incorrect bcs to bcc on 19th may.. we need to be checking that 3 lsbs are <=7 (<8)  as each char row is 8 pixels deep. so if we are the 8th pixel down in a char row, and we want to go one pixel lower, we need to cross in to the next char row - thus increment hi byte of scr addr, and then decrement by 8 pixels 





RichTW wrote:
jbnbeeb wrote:
Code:
ldy #SS_CurrScrAddr
               lda (SprStructPtr), Y
               clc
               adc tmp
               sta tmp2 ; addr + y move amount
               and #&7   ;
               cmp #&8
               bcc posyWithinChar  ; changed from incorrect bcs to bcc on 19th may.. we need to be checking that 3 lsbs are <=7 (<8)  as each char row is 8 pixels deep. so if we are the 8th pixel down in a char row, and we want to go one pixel lower, we need to cross in to the next char row - thus increment hi byte of scr addr, and then decrement by 8 pixels

Just looking at that code snippet, the bcc will always be taken as ANDing with 7 ensures that the result will always be less than 8. Another bug?
Page 1 of 1 All times are UTC [ DST ]
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
http://www.phpbb.com/