Pyra Learning OpenGL ES 2.0 for Pyra

[levi]

There's a typedef at the bottom of the game.hpp and inputHandler.hpp files which define those. I'll be honest, I don't understand them, and why they're needed. I usually don't like using code that I don't understand, but occasionally I do it if it's a small thing like this.

They are basically a renaming of the Game and InputHandler objects so that when I call them, instead of Game I'll call TheGame, but it's really just calling the functions in the Game class. I have no idea why that's necessary, but that's what I was taught by my learning materials to do for singletons. But if you want to learn more, google typedef.

Ah, it must be a naming convention or something.

I think the thing that makes these objects singletons is the fact they maintain a static _instance and their Instance method checks for that when you try to instantiate one, so you just get the same old one if there is one. If it's just a naming convention I don't know why you don't name the class itself TheGame and so on though.

IIRC I only learned singletons in a C++ context, and the naming conventions there were a lot more lax back when I learned it (1996-ish).

 

[Yori]

Any new posts coming soon?

 

[kaprikawn]

I've made some progress, but not much. As expected, it's been difficult finding appropriate learning materials, but that was always kinda the point, overcoming that obstacle.

I started reading this OpenGL ES 2.0 book, but it didn't have much in the way of code examples in the early chapters. I was expecting it to be like 'here's a chapter on x, and here's some code you can do that uses x', but, it didn't really have that as I was going through it. So I bailed and explored following some standard OpenGL tutorials, mostly OpenGL 3.x, in the hopes that I'd gain some transferable knowledge. I was thinking learn OpenGL, then try to recreate the code in OpenGL ES 2.0. But that turned out to be a dead end. And now I'm thinking that going back to the OpenGL ES 2.0 book is the way to go.

I've since found out that in later chapters (starting Ch8) there are code examples that you can follow along with. The problem is that the example code is C, and it's heavily coupled to a framework they use which I think is badly written. So they've got things like creating windows, and establishing OpenGL contexts quite tightly coupled with the code that makes the OpenGL calls. I don't want to use their framework, I want to use SDL2 for that stuff. So I'm in the process of unpicking their crappy code (particularly their heavy use of structs which seems to me unnecessary), isolating the stuff I want to use and learn, and re-implementing it in SDL2 and my framework with a C++ base. It's early in that process but I'm currently going through this code, in particular the chapter 8 directory.

I've tended to only really have time to look at this on the weekends, and it doesn't help that I just spent the entirety of this Saturday looking at build systems. I wanted to see if I could get my project built in meson in a way that I could build on Windows without going through the nonsense that developing on Windows entails (specifying the include directories in the VS gui, copying dll files to a million different locations etc.). My thinking was that if I could more easily develop on Windows, I could spend some time on this at work if I could get it up-and-running on my work laptop. But that didn't pan out. I got the meson code working on Linux, but I couldn't get the SDL code to compile on Windows because it couldn't find the directx headers, and it seemed like sunk time to get that working. Getting a dev environment up-and-running on Windows totally blows, but it would help my progress. It doesn't help that the firewall at work blocks all external SSH traffic (which makes sense), so I can't connect to github other than through the web, downloading the zip files. I might try Codeblocks to see if that's any better, but I don't want to throw good time after bad and sink more time into this. But basically, I just wasted a whole bunch of my dev time this weekend, and I spent a lot of my Sunday upgrading my Linux box because I got a new CPU.

But anyway, I'm still going strong and fully intend to finish. I'm hoping to do another post this weekend. But that might prove un-achievable and the next weekend might be more realistic, I'll see how it goes.

 

[sebt3]

While gles is a subset of OpenGL, GL tutorials focus on the part that gles doesnt have So indeed those are useless in your quest.

But starting with gles 2.0 is indeed all a learning curve. Start by learning the 1st version. At least most your knowledge will then be transferable to gles 2

 

[Pickle]

Ive already taken the same journey that your on. Before the pandora was out I had zero opengl knowledge.

The way I took was to port existing full opengl code to be gles compatible. I started with Ken's labyrinth. Ive eventually worked up to making my own full 3d arcade shooter (Polyhedra).

I also started with GLES 1.0 then you dont have to worry about the programmable part (shaders).

personally i use codeblocks with mingw. But you have to be careful with win32 since the way the opengl is setup many gl functions need to be dynamically linked.

for pandora specfics you might find openCatacomb port I did of some use for reference for context setup and simple ortho 2d opengl.

 

[kaprikawn]

Ive already taken the same journey that your on. Before the pandora was out I had zero opengl knowledge.

The way I took was to port existing full opengl code to be gles compatible. I started with Ken's labyrinth. Ive eventually worked up to making my own full 3d arcade shooter (Polyhedra).

I also started with GLES 1.0 then you dont have to worry about the programmable part (shaders).

personally i use codeblocks with mingw. But you have to be careful with win32 since the way the opengl is setup many gl functions need to be dynamically linked.

for pandora specfics you might find openCatacomb port I did of some use for reference for context setup and simple ortho 2d opengl.

Thanks for this, I'll certainly consider looking at the approach you've suggested. But for now I'm somewhat comfortable with pressing ahead with just learning ES2. I've got the hard part coming up so I might look at ES1.x if this proves to be a stumbling block and I need to simplify things to gain some more understanding of GL concepts.
[doublepost=1518347182,1518346850][/doublepost]I've just made a new blog post :
https://kaprikawn.wordpress.com/2018/02/11/learning-to-learn-opengl-es-2-part-06/

I haven't made as much progress as I'd like to have done by this point (I was aiming for rendering a cube but only achieved a rectangle), but my code has some useful steps in progression. I think it's worthwhile seeing the smaller steps at this stage so that if anyone is following along, they can see new function calls introduced in bitesized chunks rather than me posting a massive code dump that's radically different from the preceding one.

 

[kaprikawn]

I've finally gotten over an impasse I was at. An impasse made of my own stupidity. So I've been able to post four new blogs :
https://kaprikawn.wordpress.com/2018/03/03/learning-to-learn-opengl-es-2-0-part-07-indices/
https://kaprikawn.wordpress.com/2018/03/03/learning-to-learn-opengl-es-2-0-part-08-the-mvp-matrix/
https://kaprikawn.wordpress.com/2018/03/03/learning-to-learn-opengl-es-2-0-part-09-adding-colour/
https://kaprikawn.wordpress.com/201...arn-opengl-es-2-0-part-10-game-state-machine/

The next stage is to be able to move stuff in response to user input. For that I need to learn how best to do transformation matrices, everything is hard coded at the minute. I'm not sure how long that'll take me, could be done this evening, could take a few weeks.

 

[levi]

Nice. I tried out version v0.1.6-v0.1.8 yesterday when you published them, and I found I had to install the glm package from extra on my arch machines. Perhaps this is part of a development metapackage on debian say that you've probably already installed, but on arch at least it needs a pacman -S to fullfil that #include.

 

[kaprikawn]

Oh yeah, I forgot about that, thanks for letting me know. I doubt glm is installed by default on Debian, I'll go back and put in an instruction to apt-get install it.

At some point I will need to actually install Debian to test this stuff Hopefully the Pyra will come out before I have to actually do that

 

[kaprikawn]

Few new posts :
https://kaprikawn.wordpress.com/2018/03/10/learning-to-learn-opengl-es-2-0-part-11-a-new-approach/
https://kaprikawn.wordpress.com/2018/03/17/learning-to-learn-opengl-es-2-0-part-12-back-to-the-cube/
https://kaprikawn.wordpress.com/201...-opengl-es-2-0-part-13-added-gamepad-support/

The latest code is about where I wanted to be about a month ago, but hey, I'm still making progress.

Now I've got something a bit more interesting than a triangle on the screen it should be a bit more motivating.

 

[levi]

After playing with this a bit, thanks very much to adding some interactivity to this - I've been waiting for that. However, the movement seems a little odd. Left-right seems to go through an imaginary vertical axis, but up-down always go through an axis which has been rotated by the left-rightness of the cube already. Without looking at the code, I guess this is because you're always multipling by the up-down matrix before the left-right one. I'm not sure the best way to make it work like I would expect it to. I guess the only way to do it without risking multiplying up approximation errors over time, it to keep adding multiplication matrixes as you switch between rotating up/down and rotating left/right. But that would still give you rounding errors as the chain gets longer, and will eventually affect the frame rate as the chain grows. And I guess mathematically that's actually no different to just rotating the previous result, and collapsing all of the rotatiions down to three dimensions as variables every time you transition between left-right and up-down and vice versa.

 

[kaprikawn]

Not sure what you mean to be honest. It was just some stepping stone code anyway, it's pretty much been thrown out now. I've updated the repo and posted a new blog :

https://kaprikawn.wordpress.com/2018/03/24/learning-to-learn-opengl-es-2-0-part-14-moving-the-box/

 

[levi]

Ooof; inverted aeroplane style vertical controls for a 2d game - that's certainly original!

 

[kaprikawn]

A bit more progress today and another blog post :

https://kaprikawn.wordpress.com/2018/03/25/learning-to-learn-opengl-es-2-0-part-15-takeoff/

 

[kaprikawn]

Happy Easter to those who observe such things, in lieu of getting you all chocolate eggs, I've made a blog post instead :

https://kaprikawn.wordpress.com/2018/04/01/learning-to-learn-opengl-es-2-0-part-16-analogue-support/

 

[levi]

Thanks, that looks and feels better for a game now (although I found myself getting slightly more confused about up/down now that I seem to be more controlling a square on the screen, but maybe the background imagery rushing towards and past me will make it feel more like flying a plane, who knows).

I'll mention that I now get two warnings about declared but unused variables when building this. I realise I'm waging something of an unwinnable war on this one, but I tend to believe it's worth fixing anything the compiler thought worth mentioning.

And slightly more seriously, my ship seems to be careering out of control in that it's in something of a tailspin, rapidly rotating at program start. This seems to settle down after 10 seconds or so if I start moving the ship around, but if I start and leave it in the middle, it seems to spin almost indefinitely - it tried my patience waiting for it when I tried it at least. Once it settles down, assuming it does in all cases, it behaves fine though, and throughout it always seems to be pointed in the right direction, just rotating freely about the Z axis. As it comes out of the spins, it does seem to slow down before flipping over a couple of times, and while it's spinning too fast to see, sometimes it comes in sync with the framerate, so it seems its speed is varying then also. It's like it's trying to attain being a specific way up a certain number of times round, rather than it taking a random number in that orientation per frame.

 

[kaprikawn]

I had the spinning on a previous version, it didn't happen every time but I think it's fixed now, I put some code in which I think has sorted it.

I didn't realise I'd left the unused variables in, yeah, things like that bother me too. I'll have to try to remember to do a full rebuild before I commit a new version to the master branch.

 

[levi]

Hmm, just checkout master and fast forwarded to the latest changes and built that. I still get the spinning I'm afraid. I don't really understand why it's spinning at all - in normal use as far as I can tell the ship should never rotate about that axis, so why it isn't just a constant I don't know. I may get round to actually understanding the code one of these days and then maybe I can help.

 

[kaprikawn]

Damn, yeah, I got it happening again too. Not sure what it is, I think it might be that on the first frame the function is testing against a variable that hasn't got a value in it yet or something like that. And I'd imagine it's going 'rotation += 1.56673456E0' or something (I don't understand scientific numbers, but you get the idea).

I'll apply a thermonuclear option of sticking in 'if rotation > max rotation then rotation = max rotation' when I get home I think.

I really should start using an IDE or learn to use gdb for more than debugging segfaults, something like this would be easy to debug with break points.

 

[levi]

Yeah, I've spent a little time recently getting to grips with the gdb syntax for debugging a wayward python program of mine (I think the pdb syntax is very similar to gdb).

Basically, I use 'l <line number>' to orient myself, then 'b <line number>' to set the break point, 'c' to start running, and once I've hit the break point I can 'p' any variables or 's' to step to the next line, or 'i' to enter the first function on the current line. If you're inside a function call, once you're done investigating it, use 'r' to jump forward to the return code line, then you can 's' to get back out.