If your .png is authored and is loaded correctly, then it should already be a 32 bit image. I wonder if it's only 24-bit and FreeImage_ConvertTo32Bits is adding an empty alpha channel for you.
Also, could you post your fragment shader, please? The line "I should note as well that if I change the Fragment shader color value to vec4 (it's currently set to a vec3) and include an alpha color (set to anything between 0.1 and 1)" sounds a bit wrong, you probably should be dealing with vec4s when you're manipulating rgba colours.
I suppose that to narrow down whether it's a image loading or a rendering problem, you could experiment by modifying the "textura[j*4+3]= pixels[j*4+3];" line to "textura[j*4+3]= 128;" and see if that gives you a semi-transparent image. If so, then you know it's your image loading, otherwise it's your rendeiring. (Actually maybe it's textura[j*4+0] which represents alpha, I can never remember which order these things are supposed to be)
Yes, you will need to rebuild it every frame (or at least every time that the camera changes, which is going to be most frames probably).
Given that the bounding sphere is going to be used for quick trivial rejection, I'd recommend taking the once-per-frame cost of transforming the sphere from view space to world space, as that'll be more convenient (i.e. faster) to use when you do your many hundreds of trivial rejection tests.
PNG is stupid in that it's authors made the assumption that the RGB values of transparent pixels aren't required.
If an artist tries to have pixels that have a particular colour value, but a zero alpha value, PNG jumps in and turns their colours into garbage.
AFAIK, the RGB values of invisible pixels in a PNG file are *undefined*, they're just garbage.
If you need this feature, which games very often do, then PNG isn't a suitable file format...
I personally deal with this problem by using a pair of two non-transparent files: one contains the RGB values, and the other contains the alpha values in the R channel... :-(
 if you don't need artist-authored values, and are ok with just some constant colour, then you can do this yourself after loading the PNG and before passing the pixel data to GL. Just loop over each pixel, check if alpha is zero, and if so, set RGB to your constant.
For some time, I also blamed the .png file format for this problem, but apparently it's not a deficiency of .png, but a deficiency of Photoshop's png exporter.
The problem with tic tac toe is that it's so simple that most intelligent adults who would devote any reasonable amount of time to playing it will solve it, then lose interest, As such, I don't think your idea has too much traction unless it's targeted at children.
I can see it working as an free to play iPhone/Android game though, make it look pretty enough, monetise it with adverts which are removable through an IAP, and as an 'evergreen' game you might find it makes a small but regular stream of income for you. (I bet someone's pimped tic-tac-toe already though, so check out the competition).
Agree with Ashaman73 that you don't need to sweat too much if the measures aren't accurate, but I wonder if the problem might be your field of view. Maybe your field of view is quite wide (which makes things look little) and you've positioned your aeroplane close to the camera to compensate.
If that's the case, then you've effectively done a dolly zoom (google it, watch youtube vids/gifs, they're cool!) on your aeroplane, distorting the background while keeping the aeroplane looking normal. The fix would be to narrow the field of view and move the camera further back from the focus point.
Edit: PS. Wide field of views give more of a sense of speed, so you might want to consider how important that is to you before narrowing the FOV too much.
A screenshot might help. In particular, I wonder if the front cube is really transparent, or whether the front cube and back cube are actually opaque, but the problem is that the back cube is drawn on top of the front cube.
If so, then perhaps the z-write/z-test is not working, which could be because the depth buffer isn't setup correctly, z-testing or z-writing is disabled, or because the perspective matrix is setup incorrectly.
You are aware of the fact that you should have virtual destructors in order to avoid memory leaks, but I think you are misunderstanding the reason why.
The presence of a virtual destructor helps make sure that the destructor of your derived class is called. This is very important if your derived class has allocated some memory or other resources. If the virtual destructor is missing, the derived class's destructor isn't called and resources that the derived class has allocated are not released.
It sounds like you think that the virtual destructor is involved in the process of telling delete the size of the class it's going to delete. It's not involved in that process at all. Instead, typically, when you ask for a block of memory with new, a memory manager will also allocate a small header (say 16 bytes) which is located directly before the pointer that it returns to you. The size of the object that was allocated will be encoded within that header. When you call delete on your pointer, the memory manager can subtract 16 bytes and read the size from the header block.
So, this question "Is there, e.g., a minimum ("new") allocation block which gets deleted whether the entire allocation is used or not?" is kind of irrelevant to explaining the behaviour you're seeing, but probably yes, there is often a minimum allocation size or alignment. So allocating 100 bytes with 100 calls to new, will likely use a couple of KB at least due to the header overhead and alignment/minimum sizes.
A long time ago, before iOS's 'multitasking', games would often save the entire game state on a suspend event, so that when the app is reopened you can restore the player to the exact position, be it mid-level, deep in the front end menus, or whatever.
These days, for most titles, it's not worth the effort. Just save any user progress as soon as it occurs, if the user suspends your app and tries to return to it, usually the OS will restore your app to the foreground as if nothing has happened. In the event that the OS decided to kill your app to reclaim the RAM, or the user manually killed your app, it doesn't matter much because you will have saved the progress fairly recently.
The only thing I would normally bother doing is to pause the game. One exception is that if your game is pushing the device's memory usage to the limit, then you should make an effort to free a decent chunk of memory on suspend (textures are quite easy to remove/reload), otherwise, the OS is very likely to close your app (particularly bad if your app has links to safari or the app store or something, the user follows the link from within your game, returns to the game only to find it has crashed!).