I've changed a call to OpenGL from once per frame to once at the start which may increase performance. But on the other hand I've just added a dirty hack to render a whole bunch of triangles without figuring out how many I actually needed for the floor. So performance could go either way with the latest commit. I'm planning to do a rewrite from scratch once I've got one or two complete levels working, I'm not too concered about performance right now.Just tried it again, and it seems less choppy now. Maybe because I'm running it earlier in my session, my web browser hasn't decided to eat so much of the CPU yet, dunno. Now that I'm able to shoot, I note two things; one it tends to drift in the last direction moved...
I've just had the week off, so I've rewrote all my code. I've added a fullscreen option which will run at your native resolution. To run it fullscreen, change fullscreen=0 to fullscreen=1 in the run file, or if you're running the exe file manually doRuns fine for me again on the latest tag version. I wonder if this could detect the screen size, because on the machine I'm currently running this on, the game window is significantly bigger than the available screen space I have. You haven't implemented all of the window furniture buttons, so I couldn't see what would happen if I tried to maximise it.
I note also that you've no removed the hard barriers at the edge of the screen. It's quite easy to lose the ship now, so if you're planning to leave that in, I'd suggest you add arrows at the edges of the screen to indicate where your lost ship is, and how to get it back. I note that it's currently possible to disappear below the floor, so I guess it wasn't entirely intentional, but at least bullet occlusions with the floor all seem to be working
git clone https://github.com/kaprikawn/pyragles.git cd pyragles/src ./run
Thank you so much, that's massively helpful. It would have taken me ages to figure that out. I was so demotivated by this issue because I really had absolutely no clue what the problem was, usually when you get an error, even if the error message is a bit obtuse you usually have an avenue to explore. But I had some code that worked, I came back a few weeks later and it simply didn't work.Did somebody say "debugging"? It was quite circuitous, but I did find the problem.
tl;dr: As an optimization, glm v0.9.9.0 no longer default initializes vectors and matrices, i.e. glm::vec3() now has undefined value instead of zero. As expected, this "improvement" broke plenty of projects, you're not alone here.
In your project you do a good job at initializing everything, but I've only seen some glm::mat4() calls that need to be changed to glm::mat4(1.f) to get an identity matrix. There's also PhysicsObject::rotationMatrix_, which is not set by some derived classes e.g. Scenery (Scenary?) so now you'll have to give it a default value. Hope that puts you back on track, I like reading your blog posts and witnessing the progress.
As for the linker error, it's because you updated your system and still had object (.o) files that were compiled against older libraries.