Pyra Learning OpenGL ES 2.0 for Pyra

kaprikawn · Jan 14, 2018

I've decided to learn OpenGL ES 2.0 for use on the Pyra. And as I started poking around I realised that there's not a lot of learning materials for the kind of stuff I want to do, and some of these things I'm learning might be useful to others.

So I'm writing a blog documenting my journey. There's very little in it at the minute, and I imagine it's going to be a long time before it's complete. But on the off chance that it's useful to anyone, feel free to follow along :

Intro :
https://kaprikawn.wordpress.com/2018/01/07/learning-to-learn-opengl-es-2-0-part-01/
Getting a dev environment running :
https://kaprikawn.wordpress.com/2018/01/07/learning-to-learn-opengl-es-2-0-part-02/
Creating a window using SDL2 :
https://kaprikawn.wordpress.com/2018/01/07/learning-to-learn-opengl-es-2-0-part-03/
Rendering a triangle (using the code from the Pandora Wiki) :
https://kaprikawn.wordpress.com/2018/01/14/learning-to-learn-opengl-es-2-0-part-04/

EDIT : to clone the repo :

Code:

git clone https://github.com/kaprikawn/pyragles.git

levi · Jan 14, 2018

Nice stuff, I've meant to understand writing SDL2 stuff for a while now, whereas this has got me a window in under five minutes.

I didn't follow your instructions in step 4 to completely wipe the repo and redownload it. I first discovered I couldn't checkout the new version because of the build file not being in your .gitignore (I think), and then I discovered your make clean target didn't clean it out, so I manually deleted src/Makefile, and then I could checkout the v0.1.2, cmake . it then make and run a.out and it worked. It would be cleaner if you could just make clean then git checkout the new version, or even (if it works with cmake) just have the makefile in your .gitignore so it won't block the checkout.

But it's a great start, and I'll now have to go back over the code and work out how it's doing what it's doing. This machine only actually supports GLES2.0 at max, but that's enough for Pyra so that's cool.

kaprikawn · Jan 14, 2018

Thanks for the feedback. I've never really used make clean, I only really have a passing understanding of what it is actually. I'll do some reading on CMake and make adjustments accordingly.

I've got to set up a Debian environment so I don't accidentally include code that works on my machine and not other peoples. But in the meantime it's great to know what's working and what's not.

levi · Jan 14, 2018

I'm using arch here by the way. I so far have only had to install cmake on top of stuff I already had in that environment; I suspect otherwise only git has transferred from my previous work, so I suspect on top of arch base you only need to install cmake and git, as long as you're using intel graphics at least.

kaprikawn · Jan 14, 2018

I'm on Arch too, it doesn't split the the packages and the development headers, so if you install sdl2 you don't need to install libsdl2-dev like you do on Ubuntu which makes life easier. It also means that you have GLES2/gl.h if you've got mesa installed (which I think is in the base package anyway).

Life would be much easier if everyone just ran Arch

But we just have to accept the fact that Debian and its derivatives are the majority

levi · Jan 14, 2018

Yeah, I tend to think that arch users deserve to work it out for themselves to this extent.

levi · Jan 16, 2018

Hmm, I don't know what I was thinking expecting 'make clean' to clean src/Makefile - that's generated by cmake, so it's cmakes responsibility to clean, not make's. The cmake man page suggests 'cmake --target clean' but that doesn't work either.

I tried adding the makefile to .gitignore, but it seems that doesn't stop git moaning if its been modified in your local copy. I've been using git to maintain my projects for the past couple of years, but it's foibles can still surprise me.

In your v0.1.2 tagged source, you provide a 'clean' file and if you run it with './clean' then it'll empty the Makefile and that seems sufficient to checkout different tags. However, that file's not provided in the lower numbered tags, so it's of no use coming up from v0.1.1 to v0.1.2.

kaprikawn · Jan 16, 2018

Yeah, sorry about that. Up until now I've used github as a personal online repo to access code from multiple devices. Everything has just been commit -> git push origin master. This is the first time I've had to do it in a way that other people may actually use my code. So the clean file is just a dirty workaround rather than something related to a proper make clean function. I'm trying to get familiar with branches, patches and releases so it may be a bit bumpy along the way.

I'm slightly worried that if I remove the Makefile from my master it'll delete it from my earlier releases which need the Makefile. I don't imagine that would be the case, I'm sure it will handle it fine. But I just need to be sure.

I'll try to sort it out for my next release, which I'm hoping will be sooner than expected. I found some good videos last night which made me understand the code I copied from the wiki a bit, so I'm hoping to re-organise that code in a way that makes more sense to me.

Pocak · Jan 16, 2018

I’m also going to introduce the CMake build system. I haven’t mastered it, I’ve not been able to figure out how to build outside of the src directory.

What was the problem? Does the following not work for you?

Code:

git clone https://github.com/kaprikawn/pyragles.git
cd pyragles
git checkout v0.1.1
mkdir build
cd build
cmake ../src
make -j4
./a.out #yes, it's in the current (build) directory

This has the advantage of keeping your source directory clean — everything created by cmake and make will be in the build directory. You can also put /build/ in your .gitignore file to hide it in git status and git gui etc.

It's the possible to delete the build directory and start over, but there's usually no need for that. So you can continue the above with

Code:

git checkout v0.1.2
make -j4
./a.out

I just discovered that you don't even need to rerun cmake, despite CMakeLists.txt having been updated, because the generated Makefile checks for that.

kaprikawn said:
I'm slightly worried that if I remove the Makefile from my master it'll delete it from my earlier releases which need the Makefile. I don't imagine that would be the case, I'm sure it will handle it fine. But I just need to be sure.

If hearing it from me helps, rest assured: git won't go back and modify your previous commits.

kaprikawn · Jan 16, 2018

I'll try that, thanks. But when I was researching CMake, it seemed to be best practice to have a CMakeLists.txt file in the root directory, and one per sub directory (in my case just the src dir). And you'd have all the global stuff in the root instance (min version, findpkgs etc.), and things like the source files in the the src instance to build the cpp files in that directory. And you'd invoke CMake on the root version, and that in turn would call the instance(s) in the sub directory/directories.

Anyway, I lost interest in trying to make it work, mines only a small project after all. Maybe I'm fussing too much about it, it seemed to be more useful if you have your cpp files in multiple sub-directories. I like to use best practice if I can, but in this case it seemed to be a lot of work for not a lot of payoff.

Pocak · Jan 16, 2018

My impression is that it's good practice to make each CMakeLists.txt self contained, and that means the one in src has to have the findpkg stuff. So your outer CMakeLists.txt would just read "add_subdirectory(src)". Yeah, don't worry about it for now

levi · Jan 16, 2018

Don't forget if you want to play with git safely, you can always temp copy your repo somewhere as a play area (or a backup copy depending on how you want to work). Then, if you balls that up you've always got the other copy - just remember to delete the messed up area before you forget about it and accidentally push it up to github (you can probably remove the github remote by editing the config files but for just a quick experiment I rarely bother). I guess you could also locally clone the folder, but I consider a filesystem copy to be cleaner somehow.

kaprikawn · Jan 20, 2018

New post :

https://kaprikawn.wordpress.com/2018/01/20/learning-to-learn-opengl-es-2-0-part-05/

I've refactored/cleaned up some of the code, the output is still the same as before.

levi · Jan 20, 2018

Do you not need to run ./clean before doing a git pull still?

kaprikawn · Jan 20, 2018

I don't think so, it should work without it. I've removed the Makefile from the latest release, so that should get deleted with the git pull. No other files are both in the repo and affected by the clean script.

Also in case you're interested, there's another release that you can get from 'git checkout v0.1.4', or at the time of writing will be the master branch. It's a simpler implementation of a 'hello triangle', there's less going on than in the Pandora Wiki example, I'm going to be using the 'OpenGL ES 2.0 Programming Guide' textbook I think. The opening couple of chapters have code that's geared towards Windows using some old version of VS, I've spent a couple of hours getting that to run in my framework. It's basically the code here :

http://www.informit.com/articles/article.aspx?p=1232365&seqNum=3

It was one of the code examples I initially tried to compile at the beginning, but gave up on and moved on because I was just trying to get something that worked at the time. I've gotten it working now I've gotten rid of the Windows cruft and converted the appropriate code to SDL calls. There was also some bits of C which I had to work around.

levi · Jan 20, 2018

Ah yes, you're right. That may be been my confusion; I hadn't realised you'd been committing your makefile to the repo even after your makefile became generated by cmake instead. All good then.

This still builds and runs fine for me. It now generates a static triangle rather than one that bounces around and changes colour, but I guess that was what you were aiming for at this stage.

Looking at the C code as a mainly python coder these days, I can't see where these objects TheGame and TheInputHandler are defined. Or is this some C-ism that I'm not familiar with?

Edit: My bad once again; I'd accidently checked out master to allow me to pull again, and forgot to checkout the right tag for the lesson. I was building master by mistake - if I build v0.1.3 as specified I still get the bouncing multicolour triangle. If I build master or v0.1.4 I get your newer red triangle. So both are working for me as expected.

Yori · Jan 21, 2018

Cant add any useful input but I am enjoying the blog posts

Keep them going!

kaprikawn · Jan 21, 2018

levi said:
Looking at the C code as a mainly python coder these days, I can't see where these objects TheGame and TheInputHandler are defined. Or is this some C-ism that I'm not familiar with?

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.
[doublepost=1516529944,1516529897][/doublepost]

Gremblo said:
Cant add any useful input but I am enjoying the blog posts

Keep them going!

Thanks, I fully intend to

ClockworkCoder · Jan 21, 2018

kaprikawn said:
My (very basic) understanging...

Just a slight typo. Nice work

kaprikawn · Jan 21, 2018

ClockworkCoder said:
Just a slight typo. Nice work

Fixed, thanks. I'll fire my editor shortly

Pyra Learning OpenGL ES 2.0 for Pyra

Very Active Member

Still fresh, damnit!

Very Active Member

Still fresh, damnit!

Very Active Member

Still fresh, damnit!

Still fresh, damnit!

Very Active Member

Member

Very Active Member

Member

Still fresh, damnit!

Very Active Member

Still fresh, damnit!

Very Active Member

Still fresh, damnit!

Hi, how was your day?

Very Active Member

Chaotic Neutral

Very Active Member

Similar threads