So, I've been doing tests with Brux, trying to see what the source of the immense lag I get is. I've done stress tests, one involving a for loop that grows longer with each passing frame and draws a number of sprites equal to the number of frames passed at random positions. This particular test stresses not only SDL's rendering, but Squirrel's speed at iterating through loops. What was the result? I got up to 3000 sprites and each time it stayed between 70 and 90 FPS when it hit that number.

So what's the problem? It's me.

My collision detection is too bloated. I either need to let a premade physics engine like Chipmunk handle collisions for me, or learn to write a better one using examples from other open source games. I'm actually going to do both, because there's going to be some games where you need really complex physics, but I also want to keep the option of just checking whether or not you're touching the ground.

I've already found an interesting example in a game called Hexoshi where they used an orthogonal rectangle to indicate a slope. I was like "how does that work for detecting a slope?!" Then it clicked. If you're colliding with the rectangle, simply use the X position of the player as a factor in a slope formula with the width of the rectangle as the other factor to determine at what height the player's feet would be touching the ground. It's hard to put into words, I actually haven't worked out the math precisely, but I can visualize it pretty well. This would cut out the series of line-line and point-in-poly tests used to check polygons on polygons. I think this will drastically cut down on the time it takes to check collisions.

TL;DR: I'm not bad at putting a game engine together, just bad at using it. XD