I'm never really going to get my head around the idea that people will actively refuse to use the best systems, because they hate Windows, or hate MS or hate VS or hate PC's or whatever, thats just being stubborn and self damaging for not valid reason. But I do accept that some people simply may not have access to a PC running windows.

But for me there is no doubt that having 1 machine as your dev system and one machine as your target is far and away the simplest way to code any kind of project.

So here's a question....how could I set up a Raspberry Pi, to run an IDE, (preferably code::blocks or similar) and have it build then send code to another Rpi to run and debug?

Since SSH connections between Pi's are perfectly possible, and GDB is also available, how can we recreate the functionality of VisualStudio/VisualGDB with a pair of PI's?

Or indeed any other SBC..

I'm very curious to know what people here think.

One of my students is struggling a bit with the book, mainly because she's a very inexperienced C++ coder and some things are a bit of a struggle..even so she's making steady progress.

But.

She's finding it a little hard to get started on the invaders project, mainly because she's typing in code which is being described as examples, rather than code you should actually enter.

I have to take some of the blame for not making it clear, especially in the early parts. The discussion is about arrays and vectors, and I describe ways to use arrays in code terms, but then go on to use a MyObjects vector.

So I should have been much clearer, not to type the code in until after we get past the explanation.

The key thing is to read the sections, absorb and digest what it says and then act on the conclusions, don't slavishly enter the code each time it is listed. 

I will make that clearer in a 2nd edition.

Not quite an error, but it could cause errors, so I've updated the source code to contain the overloaded constructor,  you also need to have an overridden update.
Page 88- The code listed does not specifically give an example of the overloaded Objects(char*, MyFiles*); constructor, or the overridden update method in Objects, the constructor hase been added to the InvaderStart source code though, so if you download (as suggested) you will not have a problem. You should provide your own version of the overloaded objects update

Something I mentioned in the book and said I would come back to, but it seems the come back, got cut in the edit....which is not surprising because this "fix" is only partially effective.

Basically we need to stop the normal linux key responses from happening when we  are pressing keys for our game... we don't want to see a lot of WWWSSSSSEEEEEE   EEE  in our terminal when we quit the game, or worse a mouse actually opening a desktop app or folder under our game image. Linux is always working in the background so we have to stop it acting on key and mouse inputs.

So the traditional way is to redirect our key systems to a null file....like this, it overrides the key and stops them being echo'd so no input will happen...nice.
You'll need these headers
#include <termios.h>
#include <unistd.h>
#include <sys/ioctl.h>
#include <stdio.h>
// this lets us redirect our OS keyboard systems
    
// we need to save the original terminal io settings
struct termio original_termio;
struct termio new_termio;

    int fd = fileno(stdin);
    ioctl(fd, TCGETA, &original_termio);

    new_termio = original_termio;
    new_termio.c_cc[VMIN] = 0;http://gleenders.blogspot.nl/2014/08/banana-pi-resizing-sd-card-root.html
    new_termio.c_cc[VTIME] = 0;
    new_termio.c_lflag = 0; // stop echo (and other things)
    
    ioctl(fd, TCSETA, &new_termio);

// and this puts them back when done
    fd = fileno(stdin);
    ioctl(fd, TCSETA, &original_termio);  // put the old one back

Now that's perfectly ok unless you are using VisualGDB...because visual GDB applies another redirect to get data back from the target....so it overrides our override.
That is a bit of a pain, but while it will impact on us when running our debug systems, we can be confident that running the projects directly from console/gui will be fine (since VisualGDB isn't in place to override the override)

Conversely if you are using Visual Studio for Linux... it will stop GDB sending data to your debugger.....we suffer in different ways. 
Keep your terminals closed, don't have too much clickable stuff on your desktop and just live with it, the ability to debug is worth a little bit of key echo, but any distributed final builds need to have this

thought it might be useful for some to get an idea of what you find tricky to get your head around, here's a small poll, if a subject gets enough interest I'll see if I can make a video or something to help out.

Those lovely people at Pine, have sent me a new toy

Another RK3399 board but also a bit of a big beast with lots of ports and extra bits on it, they've been kind enough to supply the heatsink and power supply too.

Sadly though need to wait till the weekend (or next) to play with it, but I'll download whatever OS they have and see what it can do when I've got some spare time

Interesting question from a reader, is deferred rendering possible on my Rpi?

Well...long answer is yes, short answer is no. Let me explain;

Currently the only kind of rendering we do, is known as forward rendering. Its a simple concept, all your shader outputs are effectivly sent or forwarded to your display framebuffer which is usually what you see on screen. It works pretty well.

But there are sometimes issues when you want to do complex light calculations that might depend on information you've not got direct access to, like previous pixels or multiple light directions, type, colour etc.  Also light of different types and value don't always show up when the pixels light value is just accumulated.

We do sometimes use a kind of rendering where  we have shadow maps in some demo's, in other words we made a depth buffer, stored it in a texture and then used it for a 2nd pass to work with. This is partially deferred rendering, we are collecting some info to use later, but we are using it during another forward rendered pass.

Deferred rendering takes this idea further, it is a way of generating an intermediate set of buffers held in textures known as the G buffer (Geometry buffer, but in fact its multiple different buffers or elements representing the scene to draw), which can then be used to do a much more accurate rendering as you can then keep track of and access, usually 4 main types of information, texture positions, normals. position info (usually world) and a standard light buffer, usually diffuse, LearnOpenGL.com has a great tut on this, and uses slightly different buffer types which helps to show the levels of complexity you can get into.
https://learnopengl.com/Advanced-Lightin...ed-Shading


Its a "2" pass process, the "1st" Geometry pass does the extraction of data to create the GBuffer and the "2nd" light pass does the per pixel fragment shading to realise all the different light effects you want to have. But our "1st" pass is going to pull  potentially more than 1 data element. On OpenGL this is fine a pass can fill multple buffers, becuase full OpenGL can define multple render targets (MRT)

Once you have framebuffers or textures in place many more calculations can be done on your 2nd pass, giving you access to much more data for more complex info to use in the FS.

So, we know we can send data down to different FB's which we can then render to textures for use in a 2nd pass, but the problem is the G buffer has more than 1 type, it usually has 4, and its not impossible to have many more, after all if you treat it as a Texture2D, its just a large sequence of RGBA values of variable size....there's lots of options. We treat a part of our RGBA values as depth, because ES2.0 doesn't naturally have depth buffer generation capabilties. (theres actually an extension on RPi we could play with, and most other ES2.0 systems have it too)

But...OpenGLES2.0 does not have MRT's, can can only write to 1 buffer at a time meaning you have to do seperate passes to create each element of the Gbuffer you want.
We can get away with 2 passes most of the time, our shadow maps do that and its usually ok as its a simple enough shader, but 4 passes,  as well as a per pixel fragment shader? Chugsville dead ahead, that will be very slow.
If you can live with that, then great, but it really is a limitation,  you need to have a fairly sparce scene, and make sure your shaders do as little as possible, to even have a chance of a decent frame rate. Oh and there is one other issue to consider, 4 more screen sized frambuffers in memory, is a big ol' chunk of GPU RAM, not something we're blessed with at the best of times.
Oh and as the LearnOpenGL site points out there's a couple of issues with filtering, the fix for which is not so easy on OpenGLES, as we don't have the ability to blit. So its basically something you have to let go. There's also the fact once you create your Gbuffer, you can only apply 1 type of Fragment Shader on the final pass...though depending on the data you generate in the geometry pass, you might be able to apply different lighting effects on different pixels, but you can start to sense the level of complexity (and resulting speed loss) building here.

As usual with our low power GPU's being able to do something, does not mean you should. It will very much depend on you project and how much you stress the GPU, if you can manage it, deferred rendering can produce stunning results, making for very real and effective lookiing graphics, but the price is speed.

Now, OpenGLES3.0+  does have Multiple Render Targets so you can generate complete Gbuffers made up as you like in 1 pass....and even though activating them does have a speed hit, its far far faster than doing individual accumulations of the buffers... This makes it more viable on the bigger GPU's 

This is a topic I'll go into in more detail in the future when we have more OpenGLES3.0 stuff up and running. I probably won't do anything on OpenGLES2.0 but feel free to if you want.

Hi, I am working on a billboard model that simply consists of a few hard coded vertices. I want to use this model a lot throughout the project I'm working on so I figured it would be a good idea to make these as optimized as possible and thus use element indices to define which vertices must be drawn and which ones ignored.

My primary source for this has been the LearnOpenGL website. 
The snippet for drawing my quad is as follows:

Well this is fun, in a kinda, why can't they do that with the bigger boards, way.

As a games system on its own this is pretty useless, unless you can hook up the USB on the GPIO pins. It comes with only HDMI out and a single OTG micro usb for power..so no where to hook up networking or keyboards.

But..there is a small inexpensive expansion board available for the zero range which gives you access to a few more pins and that lets you plug in two more usb units, in this case, my powered hub for keyboard, mouse and usb->RJ45 network connector. Suddenly this becomes a viable machine...barely

It does also have wifi though and onboard emmc with a Chinese version of Android in place, which actually makes it a really nice self contained unit if you can get Linux on the eMMC which has to be possible somehow? right? Oh easy, sudo install_to_emmc

Well no matter, I only got this out of the drawer because I saw that they had a recent version of Ubuntu available, most recent Ubuntu's seem to be quite stable on older chips.

This is the H3 version, so a Mali 400Mp2, very old hardware. But hardware that is now supported, Allwinner gave out driver spec for most of their older chips last year and we're seeing more and more of these older boards becoming usable.

And I'm happy to say that indeed the Ubuntu build I installed on the SD, booted up straight away, and gave no issues. GLMark2-es2 is onboard and running on screen gave a respectable score of 79 (for a Mali 400MP2, thats about normal). Running offscreen it returns 150, again, for such an old GPU, not bad

It is running in 720p though so not sure if the lower res helped it.

The H3 is not a fast chip though, and this baby only has 512Mb of ram on board so this is a board for test and small projects only.

None the less..it works... its cheap, its compact and when fitted into a nice case is portable and fun, which is frustrating because some of the higher end OrangePi boards are really nice spec but their software is so painfully bad that they become paperweights as soon as you open the box. 

As always I can't comment on other features being good or bad, I only care about graphical ability. This puppy has drivers, and runs fine, a properly optimised multi core game with effective rendering is quite possible.

The Ubuntu build is also in Chinese...ermm ok, but thats not a massive issue as I don't generally need to use the terminal much once I'm set up, but it would be nice to see a standard English or at least roman language system as navigating around Chinese is not on my list of skills. I'll post on their forums to see if that can be sorted.

I'm quite impressed with this, so much so I might splash out on the H5 version to compare the performance but something tells me the H5 will suffer like other H5 boards from a lack of drivers. 

Running the maze demo, it managed it quite well, 40-45fps on a Mali400Mp2, isn't too bad, but at 720p, with some good coding it can do better. It does overheat very quick so it needs a heatsink and probably a fan, or it freezes up and can be a bitch to get back to working state

Unfortunately, we can rely on OrangePi software to screw things up. After an update/upgrade cycle, SSH no longer connected, making it impossible to compile from PC....meh I noticed on the forums people have been complaining about this for 2 years.....so no chance of a fix soon then?

But leave the original chinese ubuntu in place, do a simple update, no upgrade, and it works fine
The Mali GPU also has some nice extensions to play with.

GL_OES_texture_npot GL_OES_compressed_ETC1_RGB8_texture GL_OES_standard_derivatives GL_OES_EGL_image GL_OES_depth24 GL_ARM_rgba8 GL_ARM_mali_shader_binary GL_OES_depth_texture GL_OES_packed_depth_stencil GL_EXT_texture_format_BGRA8888 GL_OES_vertex_half_float GL_EXT_blend_minmax GL_OES_EGL_image_external GL_OES_EGL_sync GL_OES_rgb8_rgba8 GL_EXT_multisampled_render_to_texture GL_EXT_discard_framebuffer GL_OES_get_program_binary GL_ARM_mali_program_binary GL_EXT_shader_texture_lod GL_EXT_robustness GL_OES_depth_texture_cube_map GL_KHR_debug

A super low budget Kickstarter board I had for a while but until recently there was no OS. 
They now have Debian and Ubuntu.
Despite having an h5 on board though it does seem to be shackled by something, it runs quite slow and there's something odd going on with the gpu.
So for now, its not really worth the effort, though once everything was installed it did run the demo, but threw out loads of errors and less that 10fps (more like 5) and the screen was very broken and fragmented as though the GPU was only able to do a few things.

I built and installed glmark2-es2 which does seem to recognise the Mali-450 but the frame rate of every on screen test is single figures, but it may not be the GPU itself, it could be the EGL or X11 systems at fault, running off screen the scores were much more as you would expect for a penta core system giving me a mark of 260.
 
I also burned Armbian, and though generally it seemed a bit smoother, it is emulating the GPU and is very slow but does not suffer from the refresh errors, or throwing errors, but I would expect the emulation not to do this as its extremely effective. But slow.

Not really sure how to overcome this, at the moment. I think if they fix this it will be a nice board, but the company don't sell many of these boards so support and the desire to fix this issue is likely to be limited

I'll post a note on their support sites and then I'll fire it up again in a month or so to see if any updates have fixed it.