Pyra Learning OpenGL ES 2.0 for Pyra

[kaprikawn]

It's sorted now I think. Initialising the rotation variable to 0 instead of declaring it with no value seems to have fixed it so I think it's what I suspected.

 

[levi]

Ah, that makes sense. I still wonder why your code supports rotation about that axis at all, but I guess it came from the code you cribbed and inserted.

Edit: Git pulled and run - yes, the ship is stable from the start now, and I can now observe without being distracted that the ship does indeed bank as you move left and right, so that's why the rotation and normalising code is needed. And I think it build most it not all of the source files, and the warnings seem to be gone, so thanks for that all round!

 

[kaprikawn]

Slight bit of code cleanup so that I make fewer redundant calls and OpenGL context switches :

https://kaprikawn.wordpress.com/201...n-opengl-es-2-0-part-17-buffers-code-cleanup/

 

[levi]

Nice, that version does seem to move around a lot faster on my old hardware now. Although now it's running so fast that it seems to be dropping some frames here - could I add vsync to this to slow it down?

 

[kaprikawn]

That's odd, it is more efficient code, but at this stage pretty much any hardware should have been able to handle the inefficiencies from before. I'm running on a powerful computer, I'll maybe have to test on something a bit less capable like a Raspberry Pi.

VSync is already enabled, or at least it should be. There's a chance it isn't because I cribbed that code from an old 2D project. In that you declare a SDL Renderer object and that's where you enable vsync. This object is used extensively when using 2D graphics, but here I'm instantiating it, but not using it after that. Maybe that means vsync isn't being applied?

Regardless, there's frame limiting code in main.cpp which should stop the game running too fast so I don't know what's going on there. Maybe when I try it on the Raspberry Pi I'll be able to see what's going on.

 

[kaprikawn]

I've rejigged the controls and added the ability to fire now :

https://kaprikawn.wordpress.com/2018/04/08/learning-to-learn-opengl-es-2-0-part-18-pew-pew/

 

[levi]

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. This may be a deliberate gameplay element, stopping you from overloading one spot and forcing you to continually adjust to succeed. The other is more concerning; if you're firing and you move, you stop firing until you hit the fire button again. It seems it's using text input style autorepeating to give the turbo fire effect and the continuous movement while you hold down an arrow yet; this doesn't seem ideal for a game, which I'd really expect more to be looking at the keyboard martix, and polling the fire button state for example. Maybe this works differently with a joystick - I've not pulled any of those out yet though.

 

[kaprikawn]

Added another blog post :

https://kaprikawn.wordpress.com/2018/04/16/learning-to-learn-opengl-es-2-0-part-19-were-moving/

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 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.

The drifting isn't intentional, I just need to figure out some better code to make the ship come to a standstill. Other options I've tried before have made the ship come to too abrupt a stop.

 

[levi]

Runs 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

 

[kaprikawn]

Runs 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

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 do

./exe --fullscreen

(I prefer using the run file because I've written in the GALLIUM_HUD parameters).

I've also sorted out the vsync properly, so any stutter should be gone, I found it quite noticeable before and I'm not particularly bothered by stutter normally.

Taking out the out-of-bounds limits was probably just me rewriting the velocity code and not reimplimenting it, I'll add it back in at come point. Probably when I do some work on the camera so that it moves. The only out-of-bounds code in there at the minute stops the target reticule going below the floor.

New blog post is here:
https://kaprikawn.wordpress.com/201...rn-opengl-es-2-0-part-20-collision-detection/

Collsion detection has been added so the ship knows when it hits the arch.

 

[levi]

Hmm v0.3.0 runs like treacle for me. Luckily v0.3.1 runs a lot smoother somehow on this old netbook. Yes, --fullscreen works nicely on v0.3.1 also, and also I can no longer fly through the floor, which I could on all previous versions since you introduced the floor including v0.3.0. I'm not sure v0.3.1 is as fast as the old v0.2.x versions but it's doing a lot more so that's probably okay. Guess I shouldn't expect any final game to run well here though.

FWIW, you seem to have switched to WASD controls rather than arrow keys. That's probably preferable for me, as I did initially wonder what was up with the controls until I finally tried the arrow keys, but it did produce an episode of the opposite confusion on this occasion!

 

[kaprikawn]

I've implemented some code to move the camera now, new blog post :

https://kaprikawn.wordpress.com/2018/05/05/learning-to-learn-opengl-es-2-0-part-21-moving-camera/

 

[levi]

Awesome, my RSS reader picked up your post and I've given it a few plays already. Initially I found the effect as you bottom out looking a lot like you'd bounced off the floor, but actually it's just the camera repositioning directly behind you once you stop moving (because you've hit an extent). It's not so much of a problem at the top of space I found. Then I found something weird when you kept going left and right, in that after a while your reticule would suddenly ping and reach further out, and your ship would level out. But that's just another insance of hitting a boundary, this time the left and right one.

I'll hold out on making any suggestions about the way these could look more natural until you've got some more things happening on the screen. Maybe it'll all make more sense once you can see your movement relative to them, but it's hard to say at the moment.

 

[kaprikawn]

I've put in some hard boundaries now so the ship can't go beyond certain points. The movement of the ship, or more rather the target I think, still isn't right. But yeah, I think that'll be easier to sort out when there's more stuff on screen like you said. I'm going to add enemies next, then after that add the ability to load objects via config files so it'll be a lot easier to populate the levels with objects

 

[kaprikawn]

I've taken some time off my project, but I came back to it and it doesn't work

At first I was getting linker errors that didn't make any sense, then the exact same code compiled and ran, but showed nothing on my screen. I suspected my SSD was corrupt and brought a new one, installed a fresh disto, and it's still not displaying anything.

Would someone mind compiling my code and see what's happening on their system please, I'm starting to suspect I've got a hardware fault maybe with my graphics card. The commands would be :

git clone https://github.com/kaprikawn/pyragles.git
cd pyragles/src
./run

You'll need SDL2 dev, cmake and glm dev installed.

I can get my code running that displays a static cube, but all the releases after that don't seem to be working. I get the same thing on a different distro so I don't think Arch has broken something.

 

[pimaster]

Tested on a raspberry pi. Was worried that it may not have the right hardware so I went through some tags to test.

v0.1.3 spinning thing
v0.1.4 doesn't spin?
v0.1.5 red in lower right
v0.1.6 start getting warnings
v0.1.10 blue/white
v0.1.17 does not work (teal)
v0.2.0 does not work (red)

Hope that helps identify your problem.

 

[levi]

Hmm, that's weird. I tried building v0.2.3 and v3.3.0 and just got blue and light blue backgrounds respectively, but I'd backed up my workspace beforehand and the old exe still ran well. I got no linker errors at any stage though.

 

[kaprikawn]

Thanks, that helps, at least I know it's not my system (though I've just wasted £100 on an SSD, though it is an nvme so at least it's an upgrade). Crap, I suspect it's going to be a pain debugging this one

 

[Pocak]

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.

 

[kaprikawn]

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.

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.

That explains why the code that presented a static cube worked, and everything afterwards with moving geometry didn't.

Ha ha, yes, I imagine this "improvement" is certainly infuriating to a lot of people. My problem now is that my blogs which tell people to pull down older versions of the code that doesn't work, so now I have to do some reading on git/github to figure out how to modify previous releases so anyone following them in future gets working code.

Anyway, thanks again, I'll look into it this weekend. Guess I'll have to do some reading up on glm.