11/02/2011
11:30
Late start today. Fixed a few little issues and now started working on the bullet code.
--Blah blah, various other things, cooking cleaning blah--
15:00
Bullet code is done. It’s amazing how complex something can become when you start writing it if you don’t think about it properly to begin with.. That’s why some places I’ve worked they don’t like my method of planning everything out before starting to code. It may take longer to get going but it’s way faster in the long run. I’ve not done it with Invaders though and now I’m wishing I had..
When the routine is called it takes the current X/Y pos of the bullet and clears it by ANDing the background with an inverse (EOR #$FF) of the bullet graphic. It then moves it up 1 in Y (4 pixels) and draws the new bullet. While it’s drawing it also does a quick AND with the bullet graphic and the background. The reason for this is to see if a bullet pixel and another pixel (anything else on screen) intersect. If so, collision!! So there’s pixel accurate collision detection.
Next up is to take that collision info and the X/Y and extrapolate from that just what’s been hit. Above a certain height it can ONLY be the mothership. Below that it’s going to generally be the enemy ships until really low down which will be the shield/base things but I can’t rely on that because the enemy ships might have dropped down to base level. The X/Y and row/column min and max will all come into play here.
--Why does my chicken from asda smell like feet?--
17:00
Just noticed after a play of the arcade version (on MAME) that the attack wave stops redrawing while an explosion sprite is being displayed. I can see I’ll end up doing another vid output from MAME with thoooousands of frames just so i can check how many frames that happens for..
20:00
Ok, now the enemy sprites don’t leave a copy of themselves when they move down a row... I’d totally forgotten about needing to deal with that and hadn’t put the “move down” code in till earlier because it’s easier to test everything else without the enemies advancing on me. Anyway, a quick think and a quick few lines of code to set a flag on row advance which the sprite routine then checks and clears the previous sprites position if the flag was set (ie when it’s moved down a line).
It’s starting to look like a game :)
22:00
Ste has done some “decal” graphics for the free space at the sides of the screen. I mentioned it to him yesterday but that I was worried unless I also put it in the borders it might look a bit odd with a + shaped screen (320 wide but bottom border sprites inside the 224 wide center area). It actually looks ok and really does look like a decal and I “should” be able to use free sprites to continue it into the border anyway :)
11:30
Late start today. Fixed a few little issues and now started working on the bullet code.
--Blah blah, various other things, cooking cleaning blah--
15:00
Bullet code is done. It’s amazing how complex something can become when you start writing it if you don’t think about it properly to begin with.. That’s why some places I’ve worked they don’t like my method of planning everything out before starting to code. It may take longer to get going but it’s way faster in the long run. I’ve not done it with Invaders though and now I’m wishing I had..
When the routine is called it takes the current X/Y pos of the bullet and clears it by ANDing the background with an inverse (EOR #$FF) of the bullet graphic. It then moves it up 1 in Y (4 pixels) and draws the new bullet. While it’s drawing it also does a quick AND with the bullet graphic and the background. The reason for this is to see if a bullet pixel and another pixel (anything else on screen) intersect. If so, collision!! So there’s pixel accurate collision detection.
Next up is to take that collision info and the X/Y and extrapolate from that just what’s been hit. Above a certain height it can ONLY be the mothership. Below that it’s going to generally be the enemy ships until really low down which will be the shield/base things but I can’t rely on that because the enemy ships might have dropped down to base level. The X/Y and row/column min and max will all come into play here.
--Why does my chicken from asda smell like feet?--
17:00
Just noticed after a play of the arcade version (on MAME) that the attack wave stops redrawing while an explosion sprite is being displayed. I can see I’ll end up doing another vid output from MAME with thoooousands of frames just so i can check how many frames that happens for..
20:00
Ok, now the enemy sprites don’t leave a copy of themselves when they move down a row... I’d totally forgotten about needing to deal with that and hadn’t put the “move down” code in till earlier because it’s easier to test everything else without the enemies advancing on me. Anyway, a quick think and a quick few lines of code to set a flag on row advance which the sprite routine then checks and clears the previous sprites position if the flag was set (ie when it’s moved down a line).
It’s starting to look like a game :)
22:00
Ste has done some “decal” graphics for the free space at the sides of the screen. I mentioned it to him yesterday but that I was worried unless I also put it in the borders it might look a bit odd with a + shaped screen (320 wide but bottom border sprites inside the 224 wide center area). It actually looks ok and really does look like a decal and I “should” be able to use free sprites to continue it into the border anyway :)
He's also persuaded me to add a 2 player co-op option a-la the Atari 2600 version. He's right, it was LOTS of fun, especially as you're both the same colour which causes endless hilarity as you try to shoot an alien with your friends ship! :) There will also be a normal 2 player mode.
No comments:
Post a Comment