Raycster: improve sprite rendering and more #704
Conversation
Gadgetoid
commented
Aug 13, 2021
Gadgetoid
commented
- Rip out scanline rendering of sprites and use stretch_blit_sprite and screen.clip instead, this isn't really faster but it's a little less painful to look at.
- Remove tile visibility map, it did nothing much but introduce pop-up bugs
- Add some very minor optimisations
- Delete some dead code
- Add and load "wasp" sprite
TODO
|
- Rip out scanline rendering of sprites and use stretch_blit_sprite and screen.clip instead, this isn't really faster but it's a little less painful to look at. - Remove tile visibility map, it did nothing much but introduce pop-up bugs - Add some very minor optimisations - Delete some dead code - Add and load "wasp" sprite
* Make sprite textures an enum * Swap between wasp/environment spritesheets * Generate random wasps * Add explicit size to "sprite" struct for scaling spray * Add spritesheet offset and transform calculation for 8 directons of wasp facing
* Merge bug spray entities with "map_sprites" entities * Handle spraypaint as a sprite, so it's clipped behind walls * Handle collission between sprites/walls/wasps * Wasps follow player, collide with walls, take damage * Spray damages wasps * Wasps damage player * "Game Over" condition * Add player velocity to spray
* Tweak spray to scale against MAX_SPRAY_HEALTH correctly and look like it's coming from the nozzle
Gadgetoid
force-pushed
the
patch-raycaster-sprites
branch
from
8db42d5
to
718044c
Compare
|
Fixed the build 😄 |
|
I would have totally got 'round to that, if I could just stop being ruthlessly obsessed with my blog CSS and HTML for ten minutes 😆 Thank you! |
|
Hah, I'm definitely not using 32blit "maintenance" as an excuse to avoid fixing my own stuff. BTW, I |
|
I think we are rather overdue a release! I'll reserve some time one evening to try and draft up some notes. |
|
Release notes are the main reason I didn't do it myself 😆 Also assuming you want to merge this before someone looks at #744 |
|
Ooof I thought about that last week - not sure if we: Add unit tests for actual proper coverage and spit the SDK wholly from the distribution of 32blit games. OR Add a list or manifest or submodules (or whatever other technique is in vogue at the moment) of projects to be cloned by the workflow and built against the SDK automatically as a means of CI. The latter feels like it would be reproducing your build box, could be non-required test and used to detect the impact of (some) breaking changes more directly. Kinda feels like we should do both 💀 |
|
I was mostly thinking that the examples should demonstrate some SDK functionality in a simple enough way. TBH they're a large amount of the "documentation" right now. raycaster (and voxel) don't seem to be a good fit for this. (Also voxel has a giant data file that slows down the build a bit) Anyway, should probably discuss this over there. |
|
Can progress this in some future project, it's been in PR hell for too long! Thanks for the assist. |
