Taking Control


Adding Doc

Now that I have the foundations of my scroller and IRQ management routines, I can begin creating the code needed to actually control Doc. The original game had some issues with imprecise collision so I want to try and spend some time getting it tighter this time. Before that can begin though I have to actually get a player sprite into the VIC banks. 

I've taken the original Doc sprite and given him a gun, not sure if this is the final design but for now it doesn't matter it's just for show. I really wanted to give Doc a weapon in the original game and it's hinted at during the completion message that any sequel would have Doc brandishing a weapon. I'm toying with a few ideas how this will work but will definitely need character bullet routine at some point in the future.


Anyway with the sprite in the game and animating I've linked its movement to the map scroller and created the map boundaries so that Doc cannot walk of the edges of the map. 


Collisions

As I mentioned the original collisions in Doc were not great, although they were solid enough to release I think. I want the collisions to be much better this time, however this is not going to be an easy task. To make sprites and background collide you have to convert the sprite co-ordinates into character space, this is easy enough to do just by dividing X and Y by 8 (or X by 4 if you store the X position as an 8 bits rather than 9 bits for simplicity) after subtracting a value to deal with the border . But with the fine scroll added in this gets complicated especially when map data is updated at different points in each frame to keep it smooth for the full colour scroll.

As if this wasn't enough I also want Docs  jump and fall routines to shift Doc in values of between 1 and 5 pixels per frame which means even when solid ground is detected, the player won't always be exactly on it, sometimes a little through, sometimes a little above it. So we have to also snap the player to the floor when not jumping or falling, and of course this means also means taking into account the current fine scroll values.

  

Before and after snapping


What all this meant was getting the collision routine correct took most of the weekend (sigh), but finally its looking accurate, relatively glitch free and at least as good as it was with flick screens. I'll keep coming back to tweak this routine as the player control is central to the game feeling good. When I implement enemies I'll most likely have to revisit this routine anyway to add support for tile map lookup rather than screen lookup, as unlike the player, enemies can be off screen and I think I want to try and avoid having them do odd things when they do (check out Turrican, I'm pretty sure enemies are removed once they go off screen to avoid having to deal with tile map look ups).


More Scroller Fun!

Despite having created a fully working scroller, I decided it wasn't good enough. The main problem it suffered with was the slow speed. I had split the scrolling over 4 frames to help shift the colour ram without glitching, this gave me a maximum speed of 2 pixels per frame (1/50sec). But Doc can fall at a speed of 4 pixels per frame which wouldn't be great with the kind of maps I have in mind. So I looked to better the scroller:

First job was to find a way to quickly shift the map and colour ram. I achieved this by unrolling a lot of the loops that shifted the data and creating one for each direction this meant being able to have single LDA/STA pairs in absolute mode (8 cycles per pair) rather than my previous LDA/STA pairs using indexed mode and in a loop costing a lot more cycles (up to 16 per pair). This in my  opinion is well worth the 4kb memory hit as  this means that I can now squeeze the shifts into 2 frames and still have similar spare raster time. Additionally not everything needs to run every frame (enemy AI, bullet updates, for example) so these updates can be slower and staggered across frames to save CPU time.

As well as unrolling the loops I spent some time optimising the border redraw code that fetches new char and colour data from the tile map to reduce the cycles used by about 60%

The end result is that I now have a full colour scroll that as long as I use inertia when changing directions will work at up to 7 pixels per frame!!! For now I've limited it to 4 pixels per frame without inertia as the code is simpler, it will adjust between 1,2 and 4 pixels per frame in any one of the eight directions depending on the players position, Doc can only walk at 2 pixels per frame so this is plenty. I have a plan for a potential later level that might make use of the speedy 7 pixels per frame, but we'll see. 

The downside is that the new scroller has made the player animations and collision a little glitchy again, so I'll probably be spending this weekend redoing that code. Anyway here's a little peek at this weeks progress.


Leave a comment

Log in with itch.io to leave a comment.