The shields are now rendered in the correct location on the screen. As planned, the code now buffers the complete 512-byte area of the screen containing the shields. So whilst the rendering into the buffer is now more complicated, the save/restore is a simple block copy. This is in contrast with the original code.
However, now I'm not 100% sure that this won't cause graphical glitches if there's another object (eg player laser) in the shield area when the player is hit. In theory the laser will be saved and restored and become another 'shield'. Which means I would need to store a copy of the virgin shields as a mask... arghh...
This is getting more complicated than I ever thought it would be.
I've also introduced a few more graphical glitches, most notably in the explosions, which I simply cannot explain from merely updating the shield rendering at all.
But with the shields done now, I think all that remains is to review dead code, revisit all the alignment issues (absolute locations on the screen) and then fix the graphical glitches one-by-one. Once all that's complete, all that remains is to reposition the score (and credit text if required) and maybe then think about adding some rudimentary sound.
Until next time...
Thursday, 9 July 2020
Wednesday, 1 July 2020
Shielding you from the ugly truth
I've rotated the shields and have them rendered on the screen...
... but, and it's a pretty big but at this point, not accurately. The locations are only approximate atm, off by progressively a few (more) pixels for each shield left-to-right. But it's a good start.
The shields have quite 'inconvenient' dimensions and spacing; 22 pixels across and spaced 23 pixels apart. Not an issue on a vertical monitor but after rotating, the rendering obviously needs to progressively shift each shield by 5 bits (22+23/8 = 5r5).
The shields are actually rendered into a RAM buffer at the start of each wave and then block-copied to/from the screen at the start/end of the player's turn. Thus each player's shields are saved and then subsequently restored during a 2-player game.
Because RAM is limited on the original hardware, shields are 'packed' together in the buffer without any intervening empty space. Each player's buffer is 22*2*4 = 176 bytes.
Already simply rotating the shields requires 3*16*4 = 192 bytes, which is too big for the existing player data structure. So I've had to move that just to get this far.
Given this, and the fact that I have plenty of RAM to play with, the easiest solution would be to buffer the entire 16 rows of the video memory for each player, ie. 16*32 = 512 bytes. And since the save/restore is only done between plays, the slight difference in execution speed will be of absolutely no consequence.
So this is my next task.
 |
| Shield locations are only approximate at this point |
... but, and it's a pretty big but at this point, not accurately. The locations are only approximate atm, off by progressively a few (more) pixels for each shield left-to-right. But it's a good start.
The shields have quite 'inconvenient' dimensions and spacing; 22 pixels across and spaced 23 pixels apart. Not an issue on a vertical monitor but after rotating, the rendering obviously needs to progressively shift each shield by 5 bits (22+23/8 = 5r5).
The shields are actually rendered into a RAM buffer at the start of each wave and then block-copied to/from the screen at the start/end of the player's turn. Thus each player's shields are saved and then subsequently restored during a 2-player game.
Because RAM is limited on the original hardware, shields are 'packed' together in the buffer without any intervening empty space. Each player's buffer is 22*2*4 = 176 bytes.
Already simply rotating the shields requires 3*16*4 = 192 bytes, which is too big for the existing player data structure. So I've had to move that just to get this far.
Given this, and the fact that I have plenty of RAM to play with, the easiest solution would be to buffer the entire 16 rows of the video memory for each player, ie. 16*32 = 512 bytes. And since the save/restore is only done between plays, the slight difference in execution speed will be of absolutely no consequence.
So this is my next task.