(Action RPG) Version 0.009
Nov. 30th, 2006 08:31 am![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
owsf2000Final "release" of version 0.009. It does everything I set out to do for this version.
*> Displays 2 sprites on the screen.
*> Playfield is striped instead of solid.
*> Ball functions as an extension of the playfield in the form of a positional vertical bar.
*> Player is a little more "refined" - more out of timing necessity than on purpose, but still. ;)
With respect to the display routine, there's a few things I still need to examine to make sure they're working properly. Mainly to make sure that given the valid range of Y coordinates that it positions the sprite on the proper line. I'm quite sure that's not working properly right now, but where I'm positioning them in the middle of the screen for now, that's not important. I'll save that for version 0.011. ;)
Additionally, I don't actually have the sprites positioning themselves horizontally. That'll be added for version 0.011 as well. Just have to make better use of the lines between the Status Bar and playfield so that I can add the routines in. This will generate Ugly Black Bars, but no helping that for now. For now the sprites use the left-over horizontal position of P0 and P1 from the Status bar. This is why one is a double/quad sized sprite while the other is normal and why one is moving. ;)
It doesn't show in the screenshot, but the Ball is blinking while it moves from left to right. This is because I decided to use bit 0 of the Ball_X variable to indicate if the ball is to be shown or hidden. The demo function is just incrementing that value, resetting it to 0 if it hits 150. Fun thing is, due to the way I'm currently doing collision detection, the ball won't hinder X movement while it's blinking like that. It does hinder Y movement. I'm changing how I do collision detection with version 0.010 so I don't know if this kind of behavior is of any use to me.
Finally, for Sprite display, I had 3 choices to choose from as far as I could think of.
1. lsr the offset generated in Skipdraw prior to moving it Y to be used.
2. Count Scanline Pairs instead of Scanlines.
3. Interleave the sprites.
I went with option #3. There isn't enough time to squeeze a lsr in the busiest lines of the kernel. And counting scanline pairs needed additional calculation to determine what scanline it should be on for the scanline pair. (The lsr seemed cheap by comparison.)
Interleaving the sprites required no special code or additional cpu cycles during the kernel. The trade off is that it's going to be a nightmare keeping track of the sprites manually once there's a lot of sprites. If I get that far and find it impossible to keep track of them by hand even with the comments and labels I can probably resort to writing some small program to import/export sprites. Importing would generate the .byte data tables, premixed with the necessary labels and comments. Exporting would take a sample of interleaved .byte data and convert them to an easy to read txt file for editting. I'm rusty at C/C++ but with a bit of help from friends who code in C far more often than myself I'm sure I could do that.
So. Version 0.009 finally done. After several betas and some wtf's and one refresh of the source code. Before I go ballistic on the display code, I'm switching back to looking at the display code. Partly to see if it's actually causing the screen to roll on real hardware or not and definitely to redo the collision detection. I'd have to redo it eventually anyway because it's not 100% foolproof. Randomly I'd find it'd still let walls grab players and hold on to them until you shut off the rom. In the real game that wouldn't be much fun. "Yay, beat the boss final-DAMMIT!!!" The way I'm thinking of right now feels like it would be far more efficient in time and rom-space. I suspect most of those glitches are caused by the AlterPlayerSpeed demo which wouldn't exist in the main game anyway but since changing speed is something that can happen in the real game it could still happen in the game itself.
I include a rom and screenshot in the Atari Age Blog.
*> Displays 2 sprites on the screen.
*> Playfield is striped instead of solid.
*> Ball functions as an extension of the playfield in the form of a positional vertical bar.
*> Player is a little more "refined" - more out of timing necessity than on purpose, but still. ;)
With respect to the display routine, there's a few things I still need to examine to make sure they're working properly. Mainly to make sure that given the valid range of Y coordinates that it positions the sprite on the proper line. I'm quite sure that's not working properly right now, but where I'm positioning them in the middle of the screen for now, that's not important. I'll save that for version 0.011. ;)
Additionally, I don't actually have the sprites positioning themselves horizontally. That'll be added for version 0.011 as well. Just have to make better use of the lines between the Status Bar and playfield so that I can add the routines in. This will generate Ugly Black Bars, but no helping that for now. For now the sprites use the left-over horizontal position of P0 and P1 from the Status bar. This is why one is a double/quad sized sprite while the other is normal and why one is moving. ;)
It doesn't show in the screenshot, but the Ball is blinking while it moves from left to right. This is because I decided to use bit 0 of the Ball_X variable to indicate if the ball is to be shown or hidden. The demo function is just incrementing that value, resetting it to 0 if it hits 150. Fun thing is, due to the way I'm currently doing collision detection, the ball won't hinder X movement while it's blinking like that. It does hinder Y movement. I'm changing how I do collision detection with version 0.010 so I don't know if this kind of behavior is of any use to me.
Finally, for Sprite display, I had 3 choices to choose from as far as I could think of.
1. lsr the offset generated in Skipdraw prior to moving it Y to be used.
2. Count Scanline Pairs instead of Scanlines.
3. Interleave the sprites.
I went with option #3. There isn't enough time to squeeze a lsr in the busiest lines of the kernel. And counting scanline pairs needed additional calculation to determine what scanline it should be on for the scanline pair. (The lsr seemed cheap by comparison.)
Interleaving the sprites required no special code or additional cpu cycles during the kernel. The trade off is that it's going to be a nightmare keeping track of the sprites manually once there's a lot of sprites. If I get that far and find it impossible to keep track of them by hand even with the comments and labels I can probably resort to writing some small program to import/export sprites. Importing would generate the .byte data tables, premixed with the necessary labels and comments. Exporting would take a sample of interleaved .byte data and convert them to an easy to read txt file for editting. I'm rusty at C/C++ but with a bit of help from friends who code in C far more often than myself I'm sure I could do that.
So. Version 0.009 finally done. After several betas and some wtf's and one refresh of the source code. Before I go ballistic on the display code, I'm switching back to looking at the display code. Partly to see if it's actually causing the screen to roll on real hardware or not and definitely to redo the collision detection. I'd have to redo it eventually anyway because it's not 100% foolproof. Randomly I'd find it'd still let walls grab players and hold on to them until you shut off the rom. In the real game that wouldn't be much fun. "Yay, beat the boss final-DAMMIT!!!" The way I'm thinking of right now feels like it would be far more efficient in time and rom-space. I suspect most of those glitches are caused by the AlterPlayerSpeed demo which wouldn't exist in the main game anyway but since changing speed is something that can happen in the real game it could still happen in the game itself.
I include a rom and screenshot in the Atari Age Blog.
