Friday, March 25, 2016
Hammer devlog 04
note: this has been migrated from elsewhere, and formatting may be a bit wonky
Not the next prototyping milestone, but an interim update:
Aiming is in, and while I haven't gotten the player firing controls up and running, I did a quick-and-dirty test just barfing bullets onto the screen regardless of player state. Works great- cursor is responsive & precise; bullets trace a path along the vector that leads from player position through reticle position at time of firing; sprite movement is kept nice and chunky and pixel-locked no matter what path the bullet needs to trace.
Initial stress test with a 1600-entry object pool for player projectiles is actually fine. I'll probably wanna trim that down nonetheless once I have enemies on screen, of course. That being said, though: great thing about the GB Zelda-style screen scrolling system is that it lets me cheat a lot with costlier logic. I know exactly what's onscreen at any one time, and can set only those objects to active. Like, those bullets - they get put back in the pool the very instant they leave the viewport, because there is never a time when I give the slightest shit about what's happening outside the viewport.
EDIT: the framerate in-game is buttery smooth, fwiw - it's just the gif being kinda janky