Pyra Learning OpenGL ES 2.0 for Pyra


Okay, I installed git-lfs then ran lfs fetch which reported downloading some 1.4MB. My ship.glb file remains at 132 bytes and when I look at it is like you say a reference with a sha256sum and a size in it. Meanwhile my built code still crashes. Maybe I'll try the download from github later.
 
levi said:
Okay, I installed git-lfs then ran lfs fetch which reported downloading some 1.4MB. My ship.glb file remains at 132 bytes and when I look at it is like you say a reference with a sha256sum and a size in it. Meanwhile my built code still crashes. Maybe I'll try the download from github later.
Click to expand...
In the assets directory, can you try :
Code: 
git lfs install
rm ship.glb
git checkout .

EDIT: I've just tried this on a Mint VM instance I've got, and it worked there.
 
Last edited:
Ah, okay. I also removed numbox.glb and woodBox.glb and got them updated by the checkout. Unfortunately, the code still fails for me, on the same line according to gdb.
 
I've introduced batch rendering to improve the performance of rendering the floor :

https://kaprikawn.wordpress.com/2020/02/23/learning-to-learn-opengl-es-2-0-part-27-batch-rendering/

@levi I think I know why yours isn't working now, it's probably because the updated gltf files haven't been copied into the build directory. I thought CMake did that, but I now think it doesn't. I've updated the 'run' script to cope with that now, so it should just work after you pull down the latest master version (or tag v3.8). Or if not just run

Code: 
./run --fullscreen --clean
 
Thanks, yes that's running well on my system now. Even on a repo where I hadn't installed git-lfs first and then ran ./run a second time after rechecking out the bigger files it spotted those changes and ran as per your gif on your blog.
 
I've added an exhaust/particle system now :

https://kaprikawn.wordpress.com/2020/03/15/learning-to-learn-opengl-es-2-0-part-28-particles/

ezgif.com-video-to-gif20200315.gif
 
If you're interested in working better with gdb, print (or 'p' if you're lazy I think) is the command to print out the value of supplied expressions, and break (or 'b') is for setting a break point in a specified file and function (using the file:function notation), and you can also set conditions using if [condition] at the end. But if you're happy in vscode then I don't blame you to be honest!
 
Okay, currently having trouble with enemypod.glb; I've updated as documented and redid all of the lfs stuff because I wasn't sure I'd done it on this machine yet. It seems to stop saying that enemypod.glb isn't a glb file. But looking at the file, it begins:
Code: 
glTF^B^@^@^@^Le^A^@h    ^@^@JSON{"asset":{"generator":"Khronos glTF Blender I/O v1.1.46","version":"2.0"},"scene":0,"scenes":[{"name":"Scene","nodes":[0,1,2,3]}],"nodes":[{"mesh":0,"name":"EnemyPod"},{"name":"Light","rotation":[0.16907575726509094,0.7558803558349609,-0.27217137813568115,0.570947527885437],"translation":[4.076245307922363,5.903861999511719,-1.0054539442062378]},{"name":"Camera","rotation":[0.483536034822464,0.33687159419059753,-0.20870360732078552,0.7804827094078064],"translation":[7.358891487121582,4.958309173583984,6.925790786743164]},{"mesh":1,"name":"Collider","scale":[0.7885456085205078,0.6418082118034363,0.8866353034973145]}],"materials":[{"doubleSided":true,"emissiveFactor":[0,0,0],"name":"Material",...

That looks like valid data to me, and not the references I had before I did all of the git-lfs stuff, so I'm not sure what that error means.

Code: 
Failed to compile vertex shader : 
0:1(1): error: syntax error, unexpected $end
..snip..
[OpenGL error] (1281)
glEnableVertexAttribArray( bombsPositionID_ )
/home/williain/devt/projects/gles2.0/pyragles/src/hud.cpp
33
[OpenGL error] (1281)
glEnableVertexAttribArray( bombsTexCoordID_ )
/home/williain/devt/projects/gles2.0/pyragles/src/hud.cpp
34
failed to load png
[OpenGL error] (1281)
glTexImage2D( GL_TEXTURE_2D, 0, GL_RGBA, width, height, 0, GL_RGBA, GL_UNSIGNED_BYTE, localBuffer )
/home/williain/devt/projects/gles2.0/pyragles/src/texture.cpp
57
Failed to compile vertex shader : 
0:1(1): error: syntax error, unexpected $end

..snip..
[OpenGL error] (1281)
glEnableVertexAttribArray( healthPositionID_ )
/home/williain/devt/projects/gles2.0/pyragles/src/hud.cpp
48
[OpenGL error] (1281)
glEnableVertexAttribArray( healthColourID_ )
/home/williain/devt/projects/gles2.0/pyragles/src/hud.cpp
49

These errors lead directly to the error about enemypod.glb, and maybe they're more important than the final error it ends up with. I've snipped out repeated errors about vertex shader errors.
 
Hmm, I'll take a look, but it looks almost certainly like a problem with the shader. At a guess, I'd say the file is missing. There should be a bunch of shader*.glsl files in the assets directory, three or four of them I think. Looking at it, I'd say you were missing shaderBasic.glsl.

Try running projectBuild.sh in the root directory, that should set up the assets directory within the build directory (i.e. copying them from the src/assets directory to build/assets)..

I'll see about adding a check to see whether the shader file exists before it tries to compile it, and give the appropriate error if not.
 
Okay, running projectBuild.sh seems to have helped. It still doesn't work for me here, but I remember giving up on this machine before now, although I think at the time it was just that the game was running so slow on this old machine. I thought I'd give it another go after your refactoring, but I get another seg fault:
Code: 
Changing game state to PLAY
./run: line 89:  4041 Segmentation fault      (core dumped) GALLIUM_HUD=".dfps;cpu0+cpu1+cpu2+cpu3+cpu4+cpu5+cpu6+cpu7;GPU-load;VRAM-usage" ./pyragles --invertY

Unless you've got a bright idea, I'll check on my newer machine later. I wouldn't worry too much about getting it running here.
 
After a rather long hiatus, I've done a new blog post. I've deleted most of my code and am now taking a different approach with my code structure. OOP is out, and the coding style of Handmade Hero is in. So I've taken it back to basics with a new release that strips out almost all the other code I had written. The latest release now builds on the Pyra (along with desktop Linux and Windows). Details :

https://kaprikawn.wordpress.com/2021/02/07/learning-to-learn-opengl-es-2-0-part-31-scorched-earth/

The Pyra build tries to run fullscreen, but doesn't. To the best of my knowledge this is a known issue with SDL2 on the Pyra currently. I've confirmed that the previous release doesn't run on the Pyra. With a few small modifications it builds, but segfaults immediately after running. I can't be bothered to figure out why right now. I may do it once I hook my Pyra up to a monitor, keyboard and mouse, but probably not. I'd just rather plow ahead with my current approach.

Edit : I imagine the segfault is the same as the one @levi was seeing above.
 
kaprikawn said:
To the best of my knowledge this is a known issue with SDL2 on the Pyra currently.
Click to expand...
Is it? My own code has zero issues going fullscreen with SDL2. I don't have time to compile and debug your code on my Pyra right now, but I've taken a quick glance over it at least.
There were a few things that stood out to me. Can't say for sure if they're inviting trouble and I admit I've only casually followed this thread over time, but here it goes:

Using SDL_CreateWindow() with 0 width and height is probably not the best idea. Documentation says invalid values can still fail here even if they're not used. Doesn't really matter though since you should just be using SDL_GetDesktopDisplayMode() without creating a window beforehand to get the resolution for fullscreen instead.
SDL_GL_SetAttribute() is supposed to be called before initializing the OpenGL context.
You're passing SDL_RENDERER_ACCELERATED and SDL_RENDERER_PRESENTVSYNC to SDL_CreateWindow(). Those are not flags for this function. Their value just so happen to be the same as the SDL_WINDOW_OPENGL and SDL_WINDOW_SHOWN flags you're passing so they don't do anything bad, but just so you know.

On a second thought this stuff probably doesn't mess anything up so bad that only fullscreen doesn't work. Mhm. Is this running with OpenGLES on the Pyra to begin with? Haven't had much success with anything using GLES directly on the Pyra except GL4es of course (my game currently uses the big OpenGL code path through GL4es for what it's worth).
 
elvissteinjr said:
Is it? My own code has zero issues going fullscreen with SDL2. I don't have time to compile and debug your code on my Pyra right now, but I've taken a quick glance over it at least.
There were a few things that stood out to me. Can't say for sure if they're inviting trouble and I admit I've only casually followed this thread over time, but here it goes:

Using SDL_CreateWindow() with 0 width and height is probably not the best idea. Documentation says invalid values can still fail here even if they're not used. Doesn't really matter though since you should just be using SDL_GetDesktopDisplayMode() without creating a window beforehand to get the resolution for fullscreen instead.
SDL_GL_SetAttribute() is supposed to be called before initializing the OpenGL context.
You're passing SDL_RENDERER_ACCELERATED and SDL_RENDERER_PRESENTVSYNC to SDL_CreateWindow(). Those are not flags for this function. Their value just so happen to be the same as the SDL_WINDOW_OPENGL and SDL_WINDOW_SHOWN flags you're passing so they don't do anything bad, but just so you know.

On a second thought this stuff probably doesn't mess anything up so bad that only fullscreen doesn't work. Mhm. Is this running with OpenGLES on the Pyra to begin with? Haven't had much success with anything using GLES directly on the Pyra except GL4es of course (my game currently uses the big OpenGL code path through GL4es for what it's worth).
Click to expand...
I seem to recall seeing a post from ED saying there was an SDL2 fullscreen issue, but I can't remember where that is, so I could be wrong.

The method I use to get the screen dimensions works on other platforms, but I'll look at SDL_GetDesktopDisplayMode, thanks for the pointer.

I don't think the SDL_GL_SetAttribute calls are necessary, I might take it out. I used it before in the hope that it would make sure I was only using ES 2.0, but that didn't work because I was calling a function not available in ES 2.0 which I only found out when I tried to compile my code on the Pyra. Before I got it I was including GLES2/gl.h, but I don't think that was necessarily the best way to get an OpenGL context, I've now switched it over to using SDL2/SDL_opengles2.h which I think is sufficient.

It's a while since I've looked at the SDL flags, I just copied and pasted from the old code, thanks for the heads up, I'll check they're ok. I probably copied them across from when I was doing 2D stuff.

Yes, this is supposed to be pure OpenGL ES 2.0, no wrappers, specifically written for the Pyra.
 
Correct. SDL2 uses OpenGL / GLES which works fine.
SDL1.2 uses simple 2D drawing. And we don't have hardware accelerated scaling yet as we did for the Pandora (so scaling is horribly slow due to the CPU having to do that) and somehow SDL1.2 doesn't read out the screen mode properly yet due to TILER (it thinks it draws on a 720x1280 screen) - so whenever you switch to fullscreen, it draws a box which is partly outside the screen.
 
Ok this might also be the reason why Muppen 64 runs Fullscreen (and i had some issues on my Pyra to let it run because i missd some packages, ), its also OpenGL ^^ , but the Playstation Emulator only in Maximised Window Mode (Which is also at least most of the Screen)..
 
You must log in or register to reply here.

Similar threads

maiden
The Jungle Of Opengl, Where To Start?
2
Replies
30
Views
6K
bzar
bzar
Blue Ion
Opengl To Opengl Es Porting
Replies
4
Views
4K
Blue Ion
Blue Ion
Pickle
Caanoo / WIZ Howto For Opengl-es 1.1 Lite On The Wiz
2 3 4
Replies
62
Views
24K
trentg
T
ptitSeb
  • Sticky
Beta ptitSeb's Beta Lair
29 30 31
Replies
608
Views
171K
gunrock
gunrock
Pickle
D3D And Opengl Conversions
Replies
4
Views
4K
Pickle
Pickle
Back
Top