Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

I would like to abstract all the images in memory, to do so i would like to have just 1 format of reference without talking about the usual file formats for the filesystem like JPG, TGA, and so on.

I hear about BLOB in RGBA format but i don't get what is this format, RGBA for me is just a way to abstract color reproduction not a way to serialize image in memory. This also can be the case where one word "RGBA" is used for defining a more general concept and approach.

The possible explanation for me is that a BLOB in RGBA is just a matrix of pixels, but how is formed and what is the order that i'm supposed to use for reading them ? Technology like OpenGL can directly manage this BLOB ?

share|improve this question
add comment

2 Answers

up vote 2 down vote accepted

Normally you use a library e.g. SOIL to load and upload your textures. It takes care of decoding incoming image formats for you, and is used by real games (as was its predecessor, sb_image).

SOIL supports DDS compressed textures as well as classic JPG and PNG formats etc.

share|improve this answer
add comment

I can't help you with OpenGL, as I have never used it, but blobs of image data are usually just byte arrays, that are created row-wise from top to bottom. If you lock textures or images, the returned array might be bigger as expected because rows are usually stored aligned which is called the image stride. Those are effectively wasted bytes at the end of each row due to memory alignment.

What format will be returned depends on how you create/load the texture/file. If you create a texture with GL_RGBA? each pixel will be represented by 4 bytes RGBARGBARGBA.... The byte array in that case is at least width * height * 4. It might be bigger due to image stride.

I have found this question on SO that describes how to load such an array directly in to an OpenGL texture.

A general rule for row-wise reading/writing pixels looks like this

for(int y = 0; y < imageHeight; ++y)
for(int x = 0; x < imageWidth; ++x){
  //channels is usually 4 for RGBA, 3 for RGB, 1 for grayscale or palette, though other formats exist.
  int arrayPos = (y * imageStride + x) * imageChannels;

  byte red = imageData[arrayPos + 0];
  byte green = imageData[arrayPos + 1];
  byte blue = imageData[arrayPos + 2];
  byte alpha = imageData[arrayPos + 3];

  //if you get back an integer(int32 = 4 bytes) array instead of a byte array
  int arrayPos = y * imageStride + x;

  byte red = (imageData[arrayPos] >> 24) & 0xFF;
  byte green = (imageData[arrayPos] >> 16) & 0xFF;
  byte blue = (imageData[arrayPos] >> 8) & 0xFF;
  byte alpha = (imageData[arrayPos] >> 0) & 0xFF;    
}

There are quite a bit of image formats for use, that might make sense depending on the data you want to store, or if you need to save memory. R5G6B5 for example is RGB with only 16 bits. R5G5B5A1 with a transparency bit for RGB textures that need only binary transparency.

That said, it might make sense to store all images in an OpenGL format that includes mipmaps so they don't have to be generated at runtime.

share|improve this answer
1  
+1 for last paragraph. Games should be loading processed formats (DDS, etc) and loading them directly to the GPU, rather than unpacking them in memory and doing unnecessary processing. –  Sean Middleditch Aug 13 '12 at 22:47
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.