Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!

1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


Member Since 02 Nov 2012
Offline Last Active Today, 11:42 AM

#5153722 OpenGL png transparency

Posted by C0lumbo on 15 May 2014 - 01:23 AM

I'm a little suspicious about this snippet:


    FIBITMAP* imagen = FreeImage_Load(formato, imageName);

FIBITMAP* temp = imagen;

imagen = FreeImage_ConvertTo32Bits(imagen);


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)

#5153218 Texturing issue

Posted by C0lumbo on 12 May 2014 - 11:05 PM

This problem is a real pain. Here's a couple of articles that address it. Basically you need to be able to mess around with the q coordinate.




#5151851 wrapping sphere around frustum

Posted by C0lumbo on 06 May 2014 - 11:43 AM

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.

#5149866 Alpha blending with a color that has no RGB components

Posted by C0lumbo on 27 April 2014 - 08:28 AM

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... :-(

[edit] 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.

#5149790 Best tic tac toe game ever (is this stupid?)

Posted by C0lumbo on 26 April 2014 - 11:53 PM

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).

#5149429 Screenshot of your biggest success/ tech demo

Posted by C0lumbo on 25 April 2014 - 11:38 AM

Here's what I'm currently working on for my hobby project. Follow the link in my sig if you want to see more. I do higher profile stuff in my day job, but that doesn't need the plug :)



#5149113 Pentagons in geometry shaders

Posted by C0lumbo on 24 April 2014 - 01:27 AM

Just a guess, but it looks like maybe your code is intended to produce a triangle fan, but it's actually outputting a triangle strip (with some of the triangles being back faced culled). .

#5149005 Communicating "scariness" without openly showing the enemy

Posted by C0lumbo on 23 April 2014 - 11:58 AM

Audio, music and shadows were going to be my main suggestion, but you already mention them...

Have a second badass looking monster, that gets to see your monster, and is absolutely terrified of it?

Camera shakes associated with the monsters footsteps? Maybe dust shaken from the roof too.

Have lots of physics objects (barrels, crates) in the corridors you run through, that get smashed into by the unseen monster so that they fly in front of you?

Dolly zoom as the monster gets closer?

#5149003 Your most valuable debugging techniques for Networked games?

Posted by C0lumbo on 23 April 2014 - 11:49 AM

Make sure that your game launching code lets you create multiplayer games with just one player in debug mode, make it so that it uses as much of the regular multiplayer logic as possible.

Put systems in place to allow creation of AI driven clients (ideally running in a console window on the same machine, so you're not wasting time with multiple machines)

#5147408 Scaling in 3D aircraft game, objects look too small!

Posted by C0lumbo on 16 April 2014 - 11:29 AM

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.

#5147057 Problem with perspective view

Posted by C0lumbo on 15 April 2014 - 01:42 AM

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.

#5143726 Deleting pointers to inherited objects

Posted by C0lumbo on 01 April 2014 - 10:24 AM

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.

#5140999 Why does my game restart when I minimize and reopen it?

Posted by C0lumbo on 21 March 2014 - 10:47 AM

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!).


Here's the relevant doc from Apple: https://developer.apple.com/library/ios/documentation/iphone/conceptual/iphoneosprogrammingguide/ManagingYourApplicationsFlow/ManagingYourApplicationsFlow.html

#5139926 Getting a direction constant from normalized vector

Posted by C0lumbo on 18 March 2014 - 02:32 AM

People are probably correct suggesting that you shouldn't end up needing this function, but to implement it I would perhaps do something like:


float fThreshold = cos(PI / 8);


If (x > fThreshold)

    return East;

else if (x < -fThreshold)

    return West; 

else if (y > fThreshold)

    return North;

else if (y < -fThreshold)

    return South;

else if (x > 0 && y > 0)

    return NorthEast

else if (x > 0 && y < 0)

    return SouthEast

else if (x < 0 && y > 0)

    return NorthWest

else if (x < 0 && y < 0)

    return SouthWest


(this is assuming positive x is east and positivie y is north)

#5139643 [TEXTURE] BC7

Posted by C0lumbo on 17 March 2014 - 12:31 AM

BC7 is pretty great and is incredibly versatile, and is probably the best choice in a wide variety of situations (Chris_F points out the exceptions well, but I'd just emphasize that when Chris_F says that "For some textures BC7 will be too large, so for that you will want BC1", he's not just talking about the amount of memory available, there's a very real performance benefit from reducing the amount of texture data that has to be thrown around, so I don't think BC1 will disappear too quick).


However, you touched upon it's main disadvantage in your original question, BC7s versatility is largely down to the fact you can choose from 8 different encoding schemes at a per block level, and many of these encoding schemes have many different partition tables and other options. This means an exhaustive BC7 encoder has to do similar work to a BC1 encoder but do it many hundreds of times. The result is that the time required to generate a decent quality BC7 compressed version of a texture is huge, it's very slow even with a compute shader to do the heavy lifting.


That said, I have no doubt though that those developing exclusively for hardware that supports BC7 (not very many people on PC yet!), will end up with the majority of their textures as BC7, especially if someone can put together a faster encoder with some clever heuristics to reduce the search space.