note that I need to re-call this whenever I have a new max hp
also note that vertmeter does not handle 1024 correctly. find out what max hp functions and hardcap it
Shots that miss are most likely to not be there yet, so check Y-top first.
If I assume shots will never be larger than 16 pixels per side, there is
no reason to check the ship's genuine width and height.
in the "nothing but turrets" worst-case scenario, fast bullet logic costs 133% of slow bullet logic even when almost all shots on screen are slow. when I back out of this, that scenario is _still_ over 300% CPU but at least it's not 400%. note that this is with a screen mostly full of enemies, so processing all of them and their potential collisions also has cost, so the actual bullet-specific change is closer to 150%, maybe 200%. this is genuinely not as bad as I had thought but it doesn't feel like it will be workable; while my worst-case scenario is implausibly bad it's not actually 3x-likely-peak bad. so I'm going to need to find more optimizations, and probably give up on fast bullets. But I can keep the fast bullet branch around in case I find the headroom to reintroduce it later.
avoids hitting enemies before they spawn in.
may need to revisit this for the X coordinate if I want to implement a "Wild Ball" kind of weapon, but I think I won't have the tokens for that anyway
The only use of a collider is intertwined with the ship list, so I can combine the "prepare to yoink" and "populate collider" and "iterate list" steps, and I can combine the "hide" and "yoink" steps. This doesn't save tokens now but it's about to, when I use the eship collider to test pship collision.
I will refactor this next: collider.new will take the linked list to ingest, perform the `insert` and "prevify" loops itself, then replace `hide` with `yoink`, which yoinks the item out of the original list. This pairs the `yoink` operation with the context that makes it possible to do (that is, the context when prevification was implemented); eships therefore cannot be edited in complex ways while the collider is still valid, but we can append to it as long as we don't expect those items to be procesesd correctly this frame. a new_eships+vore plan might be better if we turn out to need it, but presently we don't; flotilla spawning and raider spawning happen at a different point.
causes x offset to reverse for negative aim; may need to be careful
with how I make aiming guns actually work, but this should work for
deriving player guns from enemy guns (by using negative aim)!
I am horrified to admit that C++'s constructor static initialization
list syntax abruptly makes sense to me and I understand the problem
it is trying to solve
