:bm1::bm2::bm3::bm4::bm5::bm6::bm7::bm8::bm9::bm0:

@bonkmaykr@canithesis.org

20 Male, Missouri, United States
Running Canithesis Interactive & Worlio LLC
Software engineer, newly an Amiga + Saturn nut

Currently working on a danmaku shooter game called "Time Falcon", my own game engine for it, and some other stuff. My posts can range anywhere from deep nerd thoughts to brainless shitposting.

Expert at run-on sentences

Give me liberty or give me death
XMPP/Jabberbonkmaykr@canithesis.org

58 following, 37 followers

2 ★ 0 ↺

[?]:bm1::bm2::bm3::bm4::bm5::bm6::bm7::bm8::bm9::bm0: » 🌐
@bonkmaykr@canithesis.org

Went ahead and deleted the queue system with input lag, and replaced it with a new loop that uses integer iterators instead of vector iterators which were prone to causing the crash I posted about a few days ago.

This should be more efficient, and just as stable so long as the vector is only added to and no objects delete from it directly through random access. I have a new deletion queue to handle this situation appropriately.

Next part is hard. collision detection! I have to be careful about this one because every method has drawbacks. The big challenge is getting a system that will work on every piece of hardware I throw this at so I don't have to write entirely different physics for homebrew ports. Complete feature parity if I decide to reuse the codebase on an Amiga or X16.

I considered using the GPU to simulate collisions inside a rendertexture, but this is only viable as far as the PC and modern consoles and I'd need to throw it away for the backports. Plus it has caveats related to precision, increasing that resolution would be a performance detriment.

The other option is to do things the old fashioned way on the CPU and simply calculate the bounding boxes with algebra.

History