Welcome, Guest |
You have to register before you can post on our site.
|
Forum Statistics |
» Members: 103
» Latest member: yelruh
» Forum threads: 233
» Forum posts: 989
Full Statistics
|
Online Users |
There are currently 2 online users. » 0 Member(s) | 1 Guest(s) Bing
|
Latest Threads |
Is Vulkan the future?
Forum: General Chat
Last Post: web2gamedevconvert
07-07-2024, 12:29 PM
» Replies: 8
» Views: 18,220
|
hello
Forum: Scratchpad Games
Last Post: web2gamedevconvert
05-20-2024, 04:20 PM
» Replies: 10
» Views: 30,759
|
So, you're bypassing Unit...
Forum: General Chat
Last Post: web2gamedevconvert
05-18-2024, 10:34 AM
» Replies: 3
» Views: 14,995
|
Arise dead book?
Forum: Scratchpad Games
Last Post: Brian Beuken
02-29-2024, 08:07 AM
» Replies: 0
» Views: 1,058
|
Im working on a Game..
Forum: Scratchpad Games
Last Post: Brian Beuken
08-04-2023, 10:58 AM
» Replies: 8
» Views: 18,351
|
OpenGL Error handling
Forum: Assets, Tools, Libraries and other useful things
Last Post: Brian Beuken
12-07-2022, 11:48 AM
» Replies: 0
» Views: 5,616
|
Rock Pi5B
Forum: Other SBC's
Last Post: Brian Beuken
11-12-2022, 10:14 PM
» Replies: 5
» Views: 11,584
|
Setting Up Bullet
Forum: Assets, Tools, Libraries and other useful things
Last Post: Brian Beuken
10-12-2022, 11:36 AM
» Replies: 3
» Views: 14,385
|
Building with a toolchain
Forum: General Chat
Last Post: junglie85
09-11-2022, 07:45 AM
» Replies: 3
» Views: 11,452
|
Window doesn't open on Pi
Forum: Help my code won't work??
Last Post: junglie85
09-05-2022, 01:28 PM
» Replies: 5
» Views: 9,929
|
|
|
Arise dead book? |
Posted by: Brian Beuken - 02-29-2024, 08:07 AM - Forum: Scratchpad Games
- No Replies
|
|
Well this is rather surprising.
Out of the blue this week my publisher contacted me on Linkedin, as the email address they had on line for me was no longer valid.. This is true, I used freeserve.co.uk for many years but they closed down a few years ago, and though I thought I had updated everyone, it seems they still had the freeserve address.
It turns out the book has done quite well, (yeahh), and its recently been released on Humble bundle... which means some new people are going to buy it in pdf format (I wasn't even aware there was a pdf version).
Which is a weee bit worrying as its now quite out of date with 2 generations of hardware and 3 generations of OS updates having come along to make that content a bit of a challenge to run.
The book was written for the Pi3 and thats now very redundant.. I did some updates for the Pi4 but even those have become a bit redundant.
But I will try over the next few weeks to update everything and also clean up the website a bit, so if you just bought a copy of the book, thank you, sorry its a bit old, but the ideas are still all valid, and I'll try to update the code for you. Any questions, feel free to ask.
|
|
|
OpenGL Error handling |
Posted by: Brian Beuken - 12-07-2022, 11:48 AM - Forum: Assets, Tools, Libraries and other useful things
- No Replies
|
|
Pretty sure I have this elsewhere on this forum but adding it again for students to see.
OpenGLES2.0 has limited error handling
GLint err = glGetError();
Only gives you an indication that an error happend once, sometime ago... you need to step back and find it
Its far easier to check an error when it happens, and OpenGLES3.0 allows that. You need to install some libs, your system may not need all of them but best to try and install them.
sudo apt-get install libglx-mesa0-dbgsym libglapi-mesa-dbgsym libgl1-mesa-dri-dbgsym
Also as this is also an extension it will also need libdl added so add dl to your binary libs it shouldn't need to be installed it should be onboard
Next you need a small callback function somewhere in your code but you need to set that up I use this, which is the actual callback and the init function, this lives in my main.cpp file and is called after openGL is initialised.
My sincere thanks tomy collegue Phil de Groot for working this out, its proved very helpful.
Code: #include <csignal> //Raise and SIGTRAP constants.
#include <GLES2/gl2ext.h>
void OpenGLErrorCallbackHandler(GLenum source, GLenum type, GLuint id, GLenum severity, GLsizei length, const GLchar* message, const void* userParam)
{
// try to stop the jetson complaining
if (id != 0x00020092) // this seems to stop the strange recompile error but not an issue for Pi, confused!!
{
switch (severity)
{ // we can choose to ignore most of the minor error reports, here we just focus on high and med
case GL_DEBUG_SEVERITY_HIGH_KHR:
case GL_DEBUG_SEVERITY_MEDIUM_KHR:
std::cout << "OpenGL High/Med Error: " << message << std::endl;
//Set a hard-coded breakpoint for only the error that we encounter.
static bool onlyBreakOnFirst = true;
if (onlyBreakOnFirst)
{
raise(SIGTRAP);
onlyBreakOnFirst = false;
}
break;
case GL_DEBUG_SEVERITY_LOW_KHR:
case GL_DEBUG_SEVERITY_NOTIFICATION_KHR:
// std::cout << "OpenGL Low/Notice Warning: " << message << std::endl;
//
break;
default:
break; //Ignore.
}
}
};
void InstallOpenGLErrorCallback()
{
PFNGLDEBUGMESSAGECALLBACKKHRPROC peglDebugMessageControlKHR = (PFNGLDEBUGMESSAGECALLBACKKHRPROC)eglGetProcAddress("glDebugMessageCallback");
if (!(peglDebugMessageControlKHR != 0)) {
printf("failed to eglGetProcAddress eglDebugMessageControlKHR\n");
raise(SIGTRAP); //Be sure that we know about this.
}
else {
glEnable(GL_DEBUG_OUTPUT_KHR);
glEnable(GL_DEBUG_OUTPUT_SYNCHRONOUS_KHR);
peglDebugMessageControlKHR(OpenGLErrorCallbackHandler, nullptr);
}
}
|
|
|
Rock Pi5B |
Posted by: Brian Beuken - 10-09-2022, 10:56 AM - Forum: Other SBC's
- Replies (5)
|
|
What is it with me and RockPi?
I really want to like these boards but always seem to find them lacking, often due to OS issues... but... anway, I took advantage of the preorder discount at the start of the year and today was finally allowed to make the order, technically with the discount the board came in at $79 so inside my $100 limit, but I did add ac ase and power supply then postage, so yeah it went over $100...
That said the Rocks are functional, just not the Raspberry beaters they ought to be, I pulled out my rockpi4 for a bit of testing the other week after a painful update and resetting of things, tbh it was no better so I put it back in the drawer... But maybe the 5B is the answer. (or the 6 or 9?)
So one of these should be hitting my desk around November....
On paper... as always, a beast... I hope it actually lives up to the promise a 2.4/1.8ghz octacore and a stunning Mali G610MC4 GPU should make this a total monster.....also has NTU, but thats not something I know a lot about
Fingers crossed
https://www.cnx-software.com/2022/01/09/...-computer/
|
|
|
Window doesn't open on Pi |
Posted by: junglie85 - 09-04-2022, 06:50 AM - Forum: Help my code won't work??
- Replies (5)
|
|
It's not so much that my code won't work as it is that it doen't work how I think i should.
Having built and run the first triangle example, VisualGDB asked me to install XMing so that it could display the X11 session on my Windows box. I'm building on the Pi currently, not cross-compiling.
I was expecting the graphics to show up on the actual Pi's X11 session; that's what it looks like happens from the screenshot in the book.
VisualGDB only has a "Local Windows Debugger" option available in the dropdown (VS2022, Win11). However, I've only recently moved back to Windows from macOS and I usually use VSCode and/or the Jetbrains IDE's, so it's possibly just not knowinbg where to click!
How do I launch the program (in debug mode and normal running mode) on the Pi from my development host?
|
|
|
Getting started on Raspberry Pi 4 with Debian Bullseye |
Posted by: junglie85 - 09-02-2022, 04:29 PM - Forum: Help my code won't work??
- Replies (8)
|
|
I've recently purchased the book and am trying to get the initial triangle code running. I've some experience with normal OpenGL but I'm by no means a graphics programmer. I have no experience with SBC and thought this would be really fun. But I'm struggling to figure out what needs to change to work on the current hardware, despite the helpful posts dotted around the forum.
Specifically, I currently get squiggly red errors that EGL and GLES cannot be found when included. Here's my list of libraries and includes from VisualGDB:
Include directories: - /usr/include
- /usr/include/interface/vcos/pthreads
- /usr/include/interface
- /usr/include/interface/vmcs_host/linux
Library directories:
Library names:- GLESv2
- EGL
- X11
- bcm_host (although I don't think I need this)
- pthread
I've installed the following packages:- libgles2-mesa-dev
- libxrandr-dev
- mesa-utils
I've got a Raspberry Pi 4 on Debian 11 / Bullseye (latest Raspberry OS).
Here's some helpful glxinfo output:
Code: glxinfo | grep version
server glx version string: 1.4
client glx version string: 1.4
GLX version: 1.4
Max core profile version: 0.0
Max compat profile version: 2.1
Max GLES1 profile version: 1.1
Max GLES[23] profile version: 3.1
OpenGL version string: 2.1 Mesa 20.3.5
OpenGL shading language version string: 1.20
OpenGL ES profile version string: OpenGL ES 3.1 Mesa 20.3.5
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.10
GL_EXT_separate_shader_objects, GL_EXT_shader_implicit_conversions,
I saw the comment about disabling OpenGL in raspi-config but there is no option to do so under advance or, as far as I could see, any other menu.
I don't know where to go from here to get things working. If anyone can let me know what packages need to be installed, what libraries and includes, etc, I can figure the rest. I'm probably even happy to try GLES3 if need be.
Cheers.
If I change the libraries to:- GLESv2_static
- EGL_static
- vchiq_arm
- vcos khrn_static
- bcm_host
- pthread
I get the following error:
Code: Run "gcc -Wl,--start-group "/tmp/VisualGDB_ToolchainTestProgram.o" -o "/tmp/VisualGDB_ToolchainTestProgram" -Wl,-gc-sections -L/usr/lib -lGLESv2_static -lEGL_static -lvchiq_arm -lvcos -lkhrn_static -lbcm_host -lpthread -Wl,--end-group " in directory "/tmp/VisualGDB/d/SBC_Game_Dev/PiGame1/PiGame1/PiGame1" on local computer
--------------------------
/usr/bin/ld: cannot find -lGLESv2_static
/usr/bin/ld: cannot find -lEGL_static
/usr/bin/ld: cannot find -lkhrn_static
collect2: error: ld returned 1 exit status
--------------------------
Command exited with code 1
|
|
|
Bullseye on Rpi2/3 |
Posted by: Brian Beuken - 04-09-2022, 08:11 PM - Forum: Help my code won't work??
- Replies (8)
|
|
Hi all
Well we've reached a point sadly where the rpi3 code is not going to work any more using Bullseye. all the old Broadcom vc4 drivers have been depricated and are no longer part of the bullseye install, so the code will no longer build or run as it stands.
Generally this isn't a massive issue, as once we have the graphic systems set up we can ignore the OS, but in the case of the Rp1-3 the broadcom DispmanX system was used to make the graphics framebuffers. Without them the code isn't going work
But in theory installing the mesa libs which now have VC4 support you can get things up and running, the set up is similar to how we do the Pi4 code, and we now use X11 to send our graphics to the screen.
But there's a small problem at the moment with the EGL drivers not initialising, I am looking into it, when I work it out, I'll post a new hello triangle project set up for you here to allow you to progress if you are using a Pi1-3
Im working on the issue and will try to get the fix to you soon, I've also asked the Pi forums if theres a way to install the depricated system.. I suspect not but who knows.
|
|
|
OpenGLES3.x extensions |
Posted by: Brian Beuken - 11-10-2021, 08:34 AM - Forum: OpenGLES3.1 Shaders
- No Replies
|
|
Something I was not aware of, but am passing on here relating to extensions in OpenGLES3.x
Though it seems odd, the gl3ext.h file is redundant, it has no content, in fact all extensions for OpenGLES3.x are actually listed in gl2ext.h
I know right? This was news to me, but happy to have been informed about it.
Anyway, I post this because I was just trying out the new Geometry Shader extensions on the latest mesa drivers for Raspberry (Bullseye OS, mesa 20.3.5) and was having some issues getting it to recognise GL_GEOMETRY_SHADER as a valid shader type to compile and link.
Geometry Shaders are a 3.2 feature of course, so I included the gl32.h header and it worked fine and is an exciting addition, expecially to make particles more interesting and for a quick normal display debug option. But it niggled me that was probably going to cause an issue using that header, and posted a question on the Raspberry forums which I'm happy to say was responded to promptly.
Use the gl2ext.h header and for the type of shader use, GL_GEOMETRY_SHADER_OES and now we're in business. The only other thing to do is make sure in the gshader itself you inform the shader to use a couple of important extension values to allow it to compile, it needs to be version 310 es and you have to inform it about 2 extensions that are required to make it work
#version 310 es
#extension GL_EXT_geometry_shader : require
#extension GL_EXT_shader_io_blocks : require
thats it.. when you make a PO, just add the geometry shader you compile to the vertex and fragment shader before you link. It will sit in the middle of them, they seem to work very well, though I've not pushed them to any extreme, I can indeed generate new vertex outputs. I will tinker with them a little more and report any problems.
There's a great tutorial on geometry shaders here
|
|
|
Im working on a Game.. |
Posted by: Brian Beuken - 01-07-2021, 09:11 AM - Forum: Scratchpad Games
- Replies (8)
|
|
As I've been doing a lot of research to create new OpenGLES3.x systems and at the same time prepping my students to do a Pi4 project this year, I have decided to roll the research and student project into making a full scale freeware game..
I'd like to update my webpage to show this but as I've just completed a transition to a new PC i dont' currently have the tools in place to do that, but will sort it soon..
Details of the project are on my Patreon page at www.patreon.com/BrianBeuken
If you would like to support this, please sign up, even a few dollars can make a difference.
I won't post too much on here until its done but when it is complete I'll use make the key componants available and useable for readers to build their own content.
|
|
|
bad habits come back to bite you |
Posted by: Brian Beuken - 12-06-2020, 02:52 PM - Forum: Help my code won't work??
- Replies (2)
|
|
I have a very bad habit... when defining classes in C++ I often just put the label and type... This is usually ok, since I seldom write release builds.
The reason there's a difference is that in debug builds the compiler usually nulls all variables and clears memory to 0..release builds don't, memory is as it is when it fires up.
Usually.
I discovered the compiler on the Arm64 Jetson doesn't.......
And it took me 6 hours to work out why, in a demo I was workig on that worked perfectly on 8 other machines, only the Jetson redused to display the 1st of 4 test models........
I had not 0'd a rotation Vec3, and in the update of the model I was rotating assuming 0.....
Bad habits only get broken when you make bad mistakes.... 6 hours though...ooooff.. I should know better.
I have now put default values in all class varibles in the class define.
|
|
|
|