Welcome, Guest
You have to register before you can post on our site.

Username
  

Password
  





Search Forums

(Advanced Search)

Forum Statistics
» Members: 28
» Latest member: SteveSTEM
» Forum threads: 93
» Forum posts: 208

Full Statistics

Online Users
There are currently 10 online users.
» 0 Member(s) | 10 Guest(s)

Latest Threads
Nano Pi T4
Forum: Other SBC's
Last Post: Brian Beuken
07-19-2018, 04:36 PM
» Replies: 1
» Views: 19
Code for issue 71
Forum: General Chat
Last Post: Brian Beuken
07-09-2018, 04:13 PM
» Replies: 3
» Views: 135
A little something from m...
Forum: General Chat
Last Post: Brian Beuken
07-08-2018, 11:34 PM
» Replies: 0
» Views: 42
Using Eclipse (IDE) with ...
Forum: Using non Windows systems
Last Post: DieSkaarj
07-02-2018, 11:04 AM
» Replies: 0
» Views: 65
XU4
Forum: Other SBC's
Last Post: Brian Beuken
06-23-2018, 01:17 PM
» Replies: 1
» Views: 188
Odroid C2
Forum: Other SBC's
Last Post: Brian Beuken
06-23-2018, 01:10 PM
» Replies: 1
» Views: 96
C.H.I.P.
Forum: Other SBC's
Last Post: Brian Beuken
06-20-2018, 08:57 PM
» Replies: 0
» Views: 75
Any clever Linux people h...
Forum: Assets, Tools, Libraries and other useful things
Last Post: Brian Beuken
06-20-2018, 08:28 PM
» Replies: 0
» Views: 169
Open AL?
Forum: Assets, Tools, Libraries and other useful things
Last Post: Brian Beuken
06-19-2018, 01:00 PM
» Replies: 0
» Views: 68
I'd like to introduce mys...
Forum: General Chat
Last Post: Brian Beuken
06-12-2018, 05:05 PM
» Replies: 4
» Views: 451

 
  Missing content?
Posted by: Brian Beuken - 04-25-2018, 02:51 PM - Forum: Scratchpad Games - No Replies

There were a couple of Chapters I had to chop out the book to keep the page count to the publishers requirements. At some point I may tidy these up and include them here or if there's ever a 2nd edition.

The one I enjoyed working on most was the creation of a proper 2D framework, fully using the GPU and moving away from the clunky but simple surface system. That would be much more appropriate for some kinds of bullet hell games. but it was quite large, and aside from the better GPU usage didn't offer anything more than the Skramble chapter did. If you get to the point of understanding how the 3D games work, then setting up a 2D viewpoint is not a huge leap so I dropped it.

There was also a chapter on optimization, which provided ways to almost double frame rate with a range of simple and not so simple tips. It was mostly technical issues, to point out the failures of the code that went before it, but I thought about it and I feel I gave readers plenty of notice that there were several ways to optimize code and that they would get more of a thrill from that if they discovered them alone. So I left it out. But I'll drop hints in this forum.


A few chapters were not quite finished but would have added some useful technical content;

I wanted to do a lot more on shaders and light and using bump mapping and other tricks, but I noted that the performance drop was so severe on the Pi, that it would have been even worse on lesser machines, I decided to not commit to it and will leave it to discussion here.  I spent quite some time doing cool things on the Odroid XU4 only to discover that the Raspberry's frame rate would drop to single figures doing the same things even at lower res, making it clear that specific optimizations would be needed and that would cause too many individual case situations to be explained. Its better if I add content to the site and then people can choose if they want to use particular effects as they need them.


A more detailed chapter on multi core usage and use of a job manager to vastly increase performance, but I did find that most of the multi core systems I used, especially Raspberries became overheated very quickly, so I needed to do more research on that, which I will return to. I think the conclusion I reached then, was to consider a sparse use of multi core work which is not really a good design method for game architecture. I am not convinced its an SBC issue, I'm pretty sure it was my methodology and I didn't have enough time to fully explore it.

There was also a chapter on creating a (very) simple Physics engine, but I actually scrapped that when I realized that it was just easier to use Bullet and avoid long and rather dull math heavy content, which I don't enjoy.

I also put down an outline chapter on a more accurate bullet physics vehicle controller for the race game to get something like this but noticed I wasn't really explaining anything differently from the examples I found on line, and I didn't want to just parrot the code that was available,  so if you want to do more accurate vehicle physics its probably best to check out the bullet forums and review what they say. But I will be using this more accurate car control in the finished version of the Race game (coming soon)

Finally I did a nice outline chapter on procedural terrain generation, and fake instancing of detail, but again it was overreaching the base level target of a raspberry Pi system, though it was so much fun to do, maybe I'll come back to it if I can include the performance improvements that would be needed to make it viable.

Print this item

  Setting full screen
Posted by: Brian Beuken - 04-25-2018, 12:00 PM - Forum: Fundamentals Errata/Questions - No Replies

In the listed graphic setup code for the early projects, the init_ogl function is a basic system which works fine for windowed EGL display, but it should also be possible to set full screen mode by sending either 1920x1080 or the returns value from

Code:
    uint width, height;
    graphics_get_display_size(0, &width, &height);
    init_ogl(p_state, width, height);

However due to a missing set up in the init_ogl function, on page 47, the early projects can't go full screen, but you can correct this by adding two lines as noted here

PHP Code:
    state->width width;
    
state->height height;
    
    
dest_rect.0;
    
dest_rect.0;
    
dest_rect.width state->width// it needs to know our window size
    
dest_rect.height state->height;
    
    
src_rect.0;
    
src_rect.0;
//ADD these two lines if you are using a full screen mode    
    
src_rect.width width << 16;
    
src_rect.height height << 16

The downloaded files should all have this fix but I will check to make sure.

Print this item

  Display Size and loading Lenna
Posted by: mayoricecream - 04-24-2018, 07:58 PM - Forum: Help my code won't work?? - Replies (10)

Hello,

When I try and get the pi to display the window in full-screen my monitor will turn black and stay black until the project breaks. When I hard code the resolution it works fine. For now I am just running the code with the resolution hard coded but any tips regarding this subject would be cool. 

I am also having another issue that could very well be a typo. When I try and get the picture of Lenna to come up I can see a opengl window opening up but the program output gives me a error until I break the program. I believe it has something to do when I draw the rectangle but I am not certain.

Print this item

  Depth Buffers
Posted by: Brian Beuken - 04-23-2018, 01:58 PM - Forum: Fundamentals Errata/Questions - No Replies

In page 318, The Fixed Pipeline Isn't Quite Dead

Though the text is all correct, there is no specific notice that the EGL attribute_list will also need to have defined a depth buffer defined as below, if you have expanded from the cubefast demo, you will need to update your attribute list to look like this, the hellocubestex demo already has this set up.

static const EGLint attribute_list[] =
{
EGL_RED_SIZE,
8,
EGL_GREEN_SIZE,
8,
EGL_BLUE_SIZE,
8,
EGL_ALPHA_SIZE,
8,
EGL_SAMPLE_BUFFERS,1, // if you want anti alias at a slight fps cost
EGL_SAMPLES,4,  //keep these 2lines, espeically useful for lower resolution
 
EGL_DEPTH_SIZE,5, //<<<<this allows depth buffers to work
EGL_SURFACE_TYPE,
EGL_WINDOW_BIT,
EGL_NONE
};

Print this item

  I'm not getting the 100x speed
Posted by: Brian Beuken - 04-21-2018, 02:47 AM - Forum: Fundamentals Errata/Questions - No Replies

Page 311 says you will get 100 times the speed using VBO's

yeah, well hmmm, a slight exaggeration on my part, it does depend on what target you are using, and also what format the data is, how much there is of it etc.  So while it is actually possible to get 100x the speed, really with the cube demo, it will only get that good on one of the bigger 8-16core high clock GPU systems I have here, the standard Raspberry 3 and lesser models, can't really match that. Though with  proper optimizations you can get pretty close to that.

But even if you can't manage 15000 cubes in 30+fps, you will notice a big boost in speed simply by avoiding doing too many repetitive calls to the GPU and focusing only on doing the minimum number of draw calls.

The cube demo could be a great demo to show you fake instancing, which allows you to draw around 32 cubes with one draw call.. Now..that does give you a massive speed boost as does using indexing, which I don't use anywhere in the book...try checking it out. 

I think I should make it clear in the next edition, that 100x is really for the higher end GPU's and the majority Raspberry users won't get that much

Print this item

  Hello All
Posted by: mayoricecream - 04-20-2018, 08:50 PM - Forum: General Chat - Replies (1)

Hello my name is Juston Metarref. I am currently a student programmer and am looking forward to making games. I'm mainly here to ask questions about the book. Looking forward to the adventure.

Print this item

  Open VG
Posted by: Brian Beuken - 04-20-2018, 03:36 PM - Forum: Raspberry Pi questions - No Replies

Got asked if I was going to include OpenVG in any tutorials.

I really don't know, I tinkered with it when it 1st came out but only as far as the usual make a shape kinda demo's, I never saw any point in using it in games.

I'm not too sure if it would add anything to a game framework other than making menu's a bit simpler. I don't even know if it can co-exist with OpenGL render buffers doing their thing

Perhaps others can give some input here.  Looking at the Raspberry forums, its a viable concept for 2D and menu systems, but I can't really see what it offers those of us doing 3D?
If it could handle overlays then it might be an interesting way to quickly create text boxes, so its worth an investigation at least.

I do have Jan Newmarch's book Raspberry Pi GPU Audio Video Programming which has a small section on using OpenVG for text rendering, so I might work through that and see what I can do with it.

Print this item

  Immediate error Frame not in Module
Posted by: Brian Beuken - 04-19-2018, 10:36 PM - Forum: Help my code won't work?? - No Replies

This one might happen by accident when you are setting up your project or changing some values in the makefile settings

Check the type of project you are making in Makefile settings Project Type, it should say Executable, if its one of the other 2 options it will not run.

It may be you accidentally set this value by moving a mouse over it an not noticing, or you edit the makefile in error.

But bottom line is the fix is to make sure you are building an executable, just click on the box and select executable, then apply.

Print this item

  OAB's VB's VBO's ermmm
Posted by: Brian Beuken - 04-19-2018, 02:56 PM - Forum: Fundamentals Errata/Questions - No Replies

In Chapter 6, Buffers Buffers everywhere, 

I got a bit mixed up with trying to explain OAB's Object Attribute Buffers, which are actually a generic concept not an OpenGLES2.0 concept, Other graphic API's use different types of buffers and I think I just tripped over my laces after doing some work on another system and my brain farted that out. 

OpenGLES has a more limited type of buffer and its quite wrong to refer to them as OAB's

And in fact despite my tendency to refer to them as VB's they should strictly speaking be called by their proper name of VBO's Vertex Buffer Objects.

So ignore my use of Object Attribute Buffers and call them VBO's

Which is... a buffer containing various attributes which the GPU can use when properly informed of how the data is laid out!


I'll make a note to tidy that section up

Print this item

  Disable OpenGL, for failed to add service error
Posted by: Brian Beuken - 04-15-2018, 11:26 AM - Forum: Help my code won't work?? - Replies (1)

A new thing I wasn't aware of, since my Raspberry Pi's don't have the experimental version of OpenGL activated.

If your pi is currently running with "full" OpenGL enabled, then the OpenGLES2.0 demos in the book and on the site will most likely fail to run, giving a failed to add service error.

The fix is simple, you need to have a totally fresh install of Raspbian before you start working on the book. (this is by far the best option)

or

You have to disable the OpenGL drivers. You can do this by opening a terminal and entering

sudo raspi-config

use your keyboard to select Advanced options, 
select GL Driver
and then use Legacy Original non-GL drivers

(if you have OpenGL drivers installed it will say disable GL drivers instead)

Once done you are back in OpenGLES2.0 mode, and all OpenGLES2.0 projects should now work fine.

There are work rounds to get OpenGL to work, but really I would avoid that, the projects are all designed on OpenGLES2.0 so best to use it.


Reading the Pi forums, there may be other causes for this error, but for Stretch, this seems the most likely.

Print this item