Learn OpenGL ES

Loading a PNG into Memory and Displaying It as a Texture with OpenGL ES 2, Using (Almost) the Same Code on iOS, Android, and Emscripten

Posted on by Kevin

In the last post in this series, we setup a system to render OpenGL to Android, iOS and the web via WebGL and emscripten. In this post, we’ll expand on that work and add support for PNG loading, shaders, and VBOs.

TL;DR

We can put most of our common code into a core folder, and call into that core from a main loop in our platform-specific code. By taking advantage of open source libraries like libpng and zlib, most of our code can remain platform independent. In this post, we cover the new core code and the new Android platform-specific code.

To check out the completed project for this part of the series, head over to GitHub and download the files for ‘article-2-loading-png-file’.

Prerequisites

Before we begin, you may want to check out the previous posts in this series so that you can get the right tools installed and configured on your local development machine:

You can setup a local git repository with all of the code by cloning ‘article-1-clearing-the-screen’ or by downloading it as a ZIP from GitHub: https://github.com/learnopengles/airhockey/tree/article-1-clearing-the-screen.

For a “friendlier” introduction to OpenGL ES 2 using Java as the development language of choice, you can also check out Android Lesson One: Getting Started or OpenGL ES 2 for Android: A Quick-Start Guide.

Updating the platform-independent code

In this section, we’ll cover all of the new changes to the platform-independent core code that we’ll be making to support the new features. The first thing that we’ll do is move things around, so that they follow this new structure:

/src/common => rename to /src/core

/src/android => rename to /src/platform/android

/src/ios => rename to /src/platform/ios

/src/emscripten => rename to /src/platform/emscripten

We’ll also rename glwrapper.h to platform_gl.h for all platforms. This will help to keep our source code more organized as we add more features and source files.

To start off, let’s cover all of the source files that go into /src/core.

Loading vertex buffer objects

Let’s begin with buffer.h:

1
2
3
4
5

#include "platform_gl.h"

#define BUFFER_OFFSET(i) ((void*)(i))

GLuint create_vbo(const GLsizeiptr size, const GLvoid* data, const GLenum usage);

We’ll use create_vbo to upload data into a vertex buffer object. BUFFER_OFFSET() is a helper macro that we’ll use to pass the right offsets to glVertexAttribPointer().

Let’s follow up with the implementation in buffer.c:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

#include "buffer.h"
#include "platform_gl.h"
#include <assert.h>
#include <stdlib.h>

GLuint create_vbo(const GLsizeiptr size, const GLvoid* data, const GLenum usage) {
    assert(data != NULL);
    GLuint vbo_object;
    glGenBuffers(1, &vbo_object);
    assert(vbo_object != 0);

    glBindBuffer(GL_ARRAY_BUFFER, vbo_object);
    glBufferData(GL_ARRAY_BUFFER, size, data, usage);
    glBindBuffer(GL_ARRAY_BUFFER, 0);

    return vbo_object;
}

First, we generate a new OpenGL vertex buffer object, and then we bind to it and upload the data from data into the VBO. We also assert that the data is not null and that we successfully created a new vertex buffer object. Why do we assert instead of returning an error code? There are a couple of reasons for that:

  1. In the context of a game, there isn’t really a reasonable course of action that we can take in the event that creating a new VBO fails. Something is going to fail to display properly, so our game experience isn’t going to be as intended. We would also never expect this to fail, unless we’re abusing the platform and trying to do too much for the target hardware.
  2. Returning an error means that we now have to expand our code by handling the error and checking for the error at the other end, perhaps cascading that across several function calls. This adds a lot of maintenance burden with little gain.

I have been greatly influenced by this excellent series over at the Bitsquid blog:

assert() is only compiled into the program in debug mode by default, so in release mode, the application will just continue to run and might end up crashing on bad data. To avoid this, when going into production, you may want to create a special assert() that works in release mode and does a little bit more, perhaps showing a dialog box to the user before crashing and writing out a log to a file, so that it can be sent off to the developers.

Loading and compiling shaders:

Let’s add the following shader.h:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

#include "platform_gl.h"

GLuint compile_shader(const GLenum type, const GLchar* source, const GLint length);
GLuint link_program(const GLuint vertex_shader, const GLuint fragment_shader);
GLuint build_program(
    const GLchar * vertex_shader_source, const GLint vertex_shader_source_length,
    const GLchar * fragment_shader_source, const GLint fragment_shader_source_length);

/* Should be called just before using a program to draw, if validation is needed. */
GLint validate_program(const GLuint program);

Here, we have methods to compile a shader and to link two shaders into an OpenGL shader program. We also have a helper method here for validating a program, if we want to do that for debugging reasons.

Let’s begin the implementation for shader.c:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40

#include "shader.h"
#include "platform_gl.h"
#include "platform_log.h"
#include <assert.h>
#include <stdlib.h>
#include <string.h>

#define TAG "shaders"

static void log_v_fixed_length(const GLchar* source, const GLint length) {
    if (LOGGING_ON) {
        char log_buffer[length + 1];
        memcpy(log_buffer, source, length);
        log_buffer[length] = '\0';

        DEBUG_LOG_WRITE_V(TAG, log_buffer);
    }
}

static void log_shader_info_log(GLuint shader_object_id) {
    if (LOGGING_ON) {
        GLint log_length;
        glGetShaderiv(shader_object_id, GL_INFO_LOG_LENGTH, &log_length);
        GLchar log_buffer[log_length];
        glGetShaderInfoLog(shader_object_id, log_length, NULL, log_buffer);

        DEBUG_LOG_WRITE_V(TAG, log_buffer);
    }
}

static void log_program_info_log(GLuint program_object_id) {
    if (LOGGING_ON) {
        GLint log_length;
        glGetProgramiv(program_object_id, GL_INFO_LOG_LENGTH, &log_length);
        GLchar log_buffer[log_length];
        glGetProgramInfoLog(program_object_id, log_length, NULL, log_buffer);

        DEBUG_LOG_WRITE_V(TAG, log_buffer);
    }
}

We’ve added some helper functions to help us log the shader and program info logs when logging is enabled. We’ll define LOGGING_ON and the other logging functions in other include files, soon. Let’s continue:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21

GLuint compile_shader(const GLenum type, const GLchar* source, const GLint length) {
    assert(source != NULL);
    GLuint shader_object_id = glCreateShader(type);
    GLint compile_status;

    assert(shader_object_id != 0);

    glShaderSource(shader_object_id, 1, (const GLchar **)&source, &length);
    glCompileShader(shader_object_id);
    glGetShaderiv(shader_object_id, GL_COMPILE_STATUS, &compile_status);

    if (LOGGING_ON) {
        DEBUG_LOG_WRITE_D(TAG, "Results of compiling shader source:");
        log_v_fixed_length(source, length);
        log_shader_info_log(shader_object_id);
    }

    assert(compile_status != 0);

    return shader_object_id;
}

We create a new shader object, pass in the source, compile it, and if everything was successful, we then return the shader ID. Now we need a method for linking two shaders together into an OpenGL program:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

GLuint link_program(const GLuint vertex_shader, const GLuint fragment_shader) {
    GLuint program_object_id = glCreateProgram();
    GLint link_status;

    assert(program_object_id != 0);

    glAttachShader(program_object_id, vertex_shader);
    glAttachShader(program_object_id, fragment_shader);
    glLinkProgram(program_object_id);
    glGetProgramiv(program_object_id, GL_LINK_STATUS, &link_status);

    if (LOGGING_ON) {
        DEBUG_LOG_WRITE_D(TAG, "Results of linking program:");
        log_program_info_log(program_object_id);
    }

    assert(link_status != 0);

    return program_object_id;
}

To link the program, we pass in two OpenGL shader objects, one for the vertex shader and one for the fragment shader, and then we link them together. If all was successful, then we return the program object ID.

Let’s complete shader.c by adding two helper methods:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

GLuint build_program(
    const GLchar * vertex_shader_source, const GLint vertex_shader_source_length, 
    const GLchar * fragment_shader_source, const GLint fragment_shader_source_length) {
    assert(vertex_shader_source != NULL);
    assert(fragment_shader_source != NULL);

    GLuint vertex_shader = compile_shader(
        GL_VERTEX_SHADER, vertex_shader_source, vertex_shader_source_length);
    GLuint fragment_shader = compile_shader(
        GL_FRAGMENT_SHADER, fragment_shader_source, fragment_shader_source_length);
    return link_program(vertex_shader, fragment_shader);
}

This helper method method takes in the source for a vertex shader and a fragment shader, and returns the linked program object. Let’s add the second helper method:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

GLint validate_program(const GLuint program) {
    if (LOGGING_ON) {
        int validate_status;

        glValidateProgram(program);
        glGetProgramiv(program, GL_VALIDATE_STATUS, &validate_status);
        DEBUG_LOG_PRINT_D(TAG, "Results of validating program: %d", validate_status);
        log_program_info_log(program);
        return validate_status;
    }

    return 0;
}

We can use validate_program() for debugging purposes, if we want some extra info about a program during a specific moment in our rendering code.

Loading in textures

Now we need some code to load in raw data into a texture. Let’s add the following into a new file called texture.h:

1
2
3
4
5

#include "platform_gl.h"

GLuint load_texture(
    const GLsizei width, const GLsizei height,
    const GLenum type, const GLvoid* pixels);

Let’s follow that up with the implementation in texture.c:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22

#include "texture.h"
#include "platform_gl.h"
#include <assert.h>

GLuint load_texture(
    const GLsizei width, const GLsizei height,
    const GLenum type, const GLvoid* pixels) {
    GLuint texture_object_id;
    glGenTextures(1, &texture_object_id);
    assert(texture_object_id != 0);

    glBindTexture(GL_TEXTURE_2D, texture_object_id);

    glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR_MIPMAP_LINEAR);
    glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR);
    glTexImage2D(
        GL_TEXTURE_2D, 0, type, width, height, 0, type, GL_UNSIGNED_BYTE, pixels);
    glGenerateMipmap(GL_TEXTURE_2D);

    glBindTexture(GL_TEXTURE_2D, 0);
    return texture_object_id;
}

This is pretty straightforward and not currently customized for special cases: it just loads in the raw data in pixels into the texture, assuming that each component is 8-bit. It then sets up the texture for trilinear mipmapping.

Loading in PNG files

For this post, we’ll package our texture asset as a PNG file, and use libpng to decode the file into raw data. For that we’ll need to add some wrapper code around libpng so that we can decode a PNG file into raw data suitable for upload into an OpenGL texture.

Let’s create a new file called image.h, with the following contents:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

#include "platform_gl.h"

typedef struct {
    const int width;
    const int height;
    const int size;
    const GLenum gl_color_format;
    const void* data;
} RawImageData;

/* Returns the decoded image data, or aborts if there's an error during decoding. */
RawImageData get_raw_image_data_from_png(const void* png_data, const int png_data_size);
void release_raw_image_data(const RawImageData* data);

We’ll use get_raw_image_data_from_png() to read in the PNG data from png_data and return the raw data in a struct. When we no longer need to keep that raw data around, we can call release_raw_image_data() to release the associated resources.

Let’s start writing the implementation in image.c:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22

#include "image.h"
#include "platform_log.h"
#include <assert.h>
#include <png.h>
#include <string.h>
#include <stdlib.h>

typedef struct {
    const png_byte* data;
    const png_size_t size;
} DataHandle;

typedef struct {
    const DataHandle data;
    png_size_t offset;
} ReadDataHandle;

typedef struct {
    const png_uint_32 width;
    const png_uint_32 height;
    const int color_type;
} PngInfo;

We’ve started off with the includes and a few structs that we’ll be using locally. Let’s continue with a few function prototypes:

1
2
3
4
5
6

static void read_png_data_callback(
    png_structp png_ptr, png_byte* png_data, png_size_t read_length);
static PngInfo read_and_update_info(const png_structp png_ptr, const png_infop info_ptr);
static DataHandle read_entire_png_image(
    const png_structp png_ptr, const png_infop info_ptr, const png_uint_32 height);
static GLenum get_gl_color_format(const int png_color_format);

We’ll be using these as local helper functions. Now we can add the implementation for get_raw_image_data_from_png():

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

RawImageData get_raw_image_data_from_png(const void* png_data, const int png_data_size) {
    assert(png_data != NULL && png_data_size > 8);
    assert(png_check_sig((void*)png_data, 8));

    png_structp png_ptr = png_create_read_struct(
        PNG_LIBPNG_VER_STRING, NULL, NULL, NULL);
    assert(png_ptr != NULL);
    png_infop info_ptr = png_create_info_struct(png_ptr);
    assert(info_ptr != NULL);

    ReadDataHandle png_data_handle = (ReadDataHandle) {{png_data, png_data_size}, 0};
    png_set_read_fn(png_ptr, &png_data_handle, read_png_data_callback);

    if (setjmp(png_jmpbuf(png_ptr))) {
        CRASH("Error reading PNG file!");
    }

    const PngInfo png_info = read_and_update_info(png_ptr, info_ptr);
    const DataHandle raw_image = read_entire_png_image(
        png_ptr, info_ptr, png_info.height);

    png_read_end(png_ptr, info_ptr);
    png_destroy_read_struct(&png_ptr, &info_ptr, NULL);

    return (RawImageData) {
        png_info.width,
        png_info.height,
        raw_image.size,
        get_gl_color_format(png_info.color_type),
        raw_image.data};
}

There’s a lot going on here, so let’s explain each part in turn:

1
2

assert(png_data != NULL && png_data_size > 8);
assert(png_check_sig((void*)png_data, 8));

This checks that the PNG data is present and has a valid header.

1
2
3
4
5

png_structp png_ptr = png_create_read_struct(
    PNG_LIBPNG_VER_STRING, NULL, NULL, NULL);
assert(png_ptr != NULL);
png_infop info_ptr = png_create_info_struct(png_ptr);
assert(info_ptr != NULL);

This initializes the PNG structures that we’ll use to read in the rest of the data.

1
2

ReadDataHandle png_data_handle = (ReadDataHandle) {{png_data, png_data_size}, 0};
png_set_read_fn(png_ptr, &png_data_handle, read_png_data_callback);

As the PNG data is parsed, libpng will call read_png_data_callback() for each part of the PNG file. Since we’re reading in the PNG file from memory, we’ll use ReadDataHandle to wrap this memory buffer so that we can read from it as if it were a file.

1
2
3

if (setjmp(png_jmpbuf(png_ptr))) {
    CRASH("Error reading PNG file!");
}

This is how libpng does its error handling. If something goes wrong, then setjmp will return true and we’ll enter the body of the if statement. We want to handle this like an assert, so we just crash the program. We’ll define the CRASH macro later on.

1

const PngInfo png_info = read_and_update_info(png_ptr, info_ptr);

We’ll use one of our helper functions here to parse the PNG information, such as the color format, and convert the PNG into a format that we want.

1
2

const DataHandle raw_image = read_entire_png_image(
    png_ptr, info_ptr, png_info.height);

We’ll use another helper function here to read in and decode the PNG image data.

1
2
3
4
5
6
7
8
9

png_read_end(png_ptr, info_ptr);
png_destroy_read_struct(&png_ptr, &info_ptr, NULL);

return (RawImageData) {
    png_info.width,
    png_info.height,
    raw_image.size,
    get_gl_color_format(png_info.color_type),
    raw_image.data};

Once reading is complete, we clean up the PNG structures and then we return the data inside of a RawImageData struct.

Let’s define our helper methods now:

1
2
3
4
5
6
7
8

static void read_png_data_callback(
    png_structp png_ptr, png_byte* raw_data, png_size_t read_length) {
    ReadDataHandle* handle = png_get_io_ptr(png_ptr);
    const png_byte* png_src = handle->data.data + handle->offset;

    memcpy(raw_data, png_src, read_length);
    handle->offset += read_length;
}

read_png_data_callback() will be called by libpng to read from the memory buffer. To read from the right place in the memory buffer, we store an offset and we increase that offset every time that read_png_data_callback() is called.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39

static PngInfo read_and_update_info(const png_structp png_ptr, const png_infop info_ptr)
{
    png_uint_32 width, height;
    int bit_depth, color_type;

    png_read_info(png_ptr, info_ptr);
    png_get_IHDR(
        png_ptr, info_ptr, &width, &height, &bit_depth, &color_type, NULL, NULL, NULL);

    // Convert transparency to full alpha
    if (png_get_valid(png_ptr, info_ptr, PNG_INFO_tRNS))
        png_set_tRNS_to_alpha(png_ptr);

    // Convert grayscale, if needed.
    if (color_type == PNG_COLOR_TYPE_GRAY && bit_depth < 8)
        png_set_expand_gray_1_2_4_to_8(png_ptr);

    // Convert paletted images, if needed.
    if (color_type == PNG_COLOR_TYPE_PALETTE)
        png_set_palette_to_rgb(png_ptr);

    // Add alpha channel, if there is none.
    // Rationale: GL_RGBA is faster than GL_RGB on many GPUs)
    if (color_type == PNG_COLOR_TYPE_PALETTE || color_type == PNG_COLOR_TYPE_RGB)
       png_set_add_alpha(png_ptr, 0xFF, PNG_FILLER_AFTER);

    // Ensure 8-bit packing
    if (bit_depth < 8)
       png_set_packing(png_ptr);
    else if (bit_depth == 16)
        png_set_scale_16(png_ptr);

    png_read_update_info(png_ptr, info_ptr);

    // Read the new color type after updates have been made.
    color_type = png_get_color_type(png_ptr, info_ptr);

    return (PngInfo) {width, height, color_type};
}

This helper function reads in the PNG data, and then it asks libpng to perform several transformations based on the PNG type:

  • Transparency information is converted into a full alpha channel.
  • Grayscale images are converted to 8-bit.
  • Paletted images are converted to full RGB.
  • RGB images get an alpha channel added, if none is present.
  • Color channels are converted to 8-bit, if less than 8-bit or 16-bit.

The PNG is then updated with the new transformations and the new color type is stored into color_type.

For the next step, we’ll add a helper function to decode the PNG image data into raw image data:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

static DataHandle read_entire_png_image(
    const png_structp png_ptr, 
    const png_infop info_ptr, 
    const png_uint_32 height) 
{
    const png_size_t row_size = png_get_rowbytes(png_ptr, info_ptr);
    const int data_length = row_size * height;
    assert(row_size > 0);

    png_byte* raw_image = malloc(data_length);
    assert(raw_image != NULL);

    png_byte* row_ptrs[height];

    png_uint_32 i;
    for (i = 0; i < height; i++) {
        row_ptrs[i] = raw_image + i * row_size;
    }

    png_read_image(png_ptr, &row_ptrs[0]);

    return (DataHandle) {raw_image, data_length};
}

First, we allocate a block of memory large enough to hold the decoded image data. Since libpng wants to decode things line by line, we also need to setup an array on the stack that contains a set of pointers into this image data, one pointer for each line. We can then call png_read_image() to decode all of the PNG data and then we return that as a DataHandle.

Let’s add the last helper method:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

static GLenum get_gl_color_format(const int png_color_format) {
    assert(png_color_format == PNG_COLOR_TYPE_GRAY
        || png_color_format == PNG_COLOR_TYPE_RGB_ALPHA
        || png_color_format == PNG_COLOR_TYPE_GRAY_ALPHA);

    switch (png_color_format) {
        case PNG_COLOR_TYPE_GRAY:
            return GL_LUMINANCE;
        case PNG_COLOR_TYPE_RGB_ALPHA:
            return GL_RGBA;
        case PNG_COLOR_TYPE_GRAY_ALPHA:
            return GL_LUMINANCE_ALPHA;
    }

    return 0;
}

This function will read in the PNG color format and return the matching OpenGL color format. We expect that after the transformations that we did, the PNG color format will be either PNG_COLOR_TYPE_GRAY, PNG_COLOR_TYPE_GRAY_ALPHA, or PNG_COLOR_TYPE_RGB_ALPHA, so we assert against those types.

To wrap up our image loading code, we just need to add the release method:

1
2
3
4

void release_raw_image_data(const RawImageData* data) {
    assert(data != NULL);
    free((void*)data->data);
}

We’ll call this when we’re done with the raw data and can return the associated memory to the heap.

The benefits of using libpng versus platform-specific code

At this point, you might be asking why we simply didn’t use what each platform offers us, such as BitmapFactory.decode??? on Android, where ??? is one of the decode methods. Using platform specific code means that we would have to duplicate the code for each platform, so on Android we would wrap some code around BitmapFactory, and on the other platforms we would do something else. This might be a good idea if the platform-specific code was better at the job; however, in personal testing on the Nexus 7, using BitmapFactory actually seems to be a lot slower than just using libpng directly.

Here were the timings I observed for loading a single PNG file from the assets folder and uploading it into an OpenGL texture:

iPhone 5, libpng:       ~28ms
Nexus 7, libpng:        ~35ms
Nexus 7, BitmapFactory: ~93ms

 
To reduce possible sources of slowdown, I avoided JNI and had the Java code upload the data directly into a texture, and return the texture object ID to C. I also used inScaled = false and placed the image in the assets folder to avoid extra scaling; if someone has extra insight into this issue, I would definitely love to hear it! I can only surmise that there must be a lot of extra stuff going on behind the scenes, or that the overhead of doing this from Java using the Dalvik VM is just so great that it results in that much of a slowdown. The Nexus 7 is a powerful Android device, so these timings are going to be much worse on slower Android devices. Since libpng is faster than the platform-specific alternative, at least on Android, and since maintaining one set of code is easier than maintaining separate code for each platform, I’ve decided to just use libpng on all platforms for PNG image decoding.

Just for fun, here are the emscripten numbers on a MacBook Air with a 1.7 GHz Intel Core i5 and 4GB 1333 Mhz DDR3 RAM, loading an uncompressed HTML with embedded resources from the local filesystem:

Chrome 28, first time: ~318ms
Chrome 28, reload: ~67ms
Firefox 22: ~27ms

Interestingly enough, the code ran faster when it was compiled without the closure compiler and LLVM LTO.

Wrapping up the rest of the changes to the core folder

Let’s wrap up the rest of the changes to the core folder by adding the following files:

config.h:

1

#define LOGGING_ON 1

We’ll use this to control whether logging should be turned on or off.

macros.h:

1

#define UNUSED(x) (void)(x)

This will help us suppress compiler warnings related to unused parameters, which is useful for JNI methods which get called by Java.

asset_utils.h

1
2
3
4
5

#include "platform_gl.h"

GLuint load_png_asset_into_texture(const char* relative_path);
GLuint build_program_from_assets(
    const char* vertex_shader_path, const char* fragment_shader_path);

We’ll use these helper methods in game.c to make it easier to load in the texture and shaders.

asset_utils.c

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40

#include "asset_utils.h"
#include "image.h"
#include "platform_asset_utils.h"
#include "shader.h"
#include "texture.h"
#include <assert.h>
#include <stdlib.h>

GLuint load_png_asset_into_texture(const char* relative_path) {
    assert(relative_path != NULL);

    const FileData png_file = get_asset_data(relative_path);
    const RawImageData raw_image_data = 
        get_raw_image_data_from_png(png_file.data, png_file.data_length);
    const GLuint texture_object_id = load_texture(
        raw_image_data.width, raw_image_data.height, 
        raw_image_data.gl_color_format, raw_image_data.data);

    release_raw_image_data(&raw_image_data);
    release_asset_data(&png_file);

    return texture_object_id;
}

GLuint build_program_from_assets(
    const char* vertex_shader_path, const char* fragment_shader_path) {
    assert(vertex_shader_path != NULL);
    assert(fragment_shader_path != NULL);

    const FileData vertex_shader_source = get_asset_data(vertex_shader_path);
    const FileData fragment_shader_source = get_asset_data(fragment_shader_path);
    const GLuint program_object_id = build_program(
        vertex_shader_source.data, vertex_shader_source.data_length,
        fragment_shader_source.data, fragment_shader_source.data_length);

    release_asset_data(&vertex_shader_source);
    release_asset_data(&fragment_shader_source);

    return program_object_id;
}

This is the implementation for asset_utils.h. We’ll use load_png_asset_into_texture() to load a PNG file from the assets folder into an OpenGL texture, and we’ll use build_program_from_assets() to load in two shaders from the assets folder and compile and link them into an OpenGL shader program.

Updating game.c

We’ll need to update game.c to use all of the new code that we’ve added. Delete everything that’s there and replace it with the following start to our new code:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22

#include "game.h"
#include "asset_utils.h"
#include "buffer.h"
#include "image.h"
#include "platform_gl.h"
#include "platform_asset_utils.h"
#include "shader.h"
#include "texture.h"

static GLuint texture;
static GLuint buffer;
static GLuint program;

static GLint a_position_location;
static GLint a_texture_coordinates_location;
static GLint u_texture_unit_location;

// position X, Y, texture S, T
static const float rect[] = {-1.0f, -1.0f, 0.0f, 0.0f,
                             -1.0f,  1.0f, 0.0f, 1.0f,
                              1.0f, -1.0f, 1.0f, 0.0f,
                              1.0f,  1.0f, 1.0f, 1.0f};

We’ve added our includes, a few local variables to hold the OpenGL objects and shader attribute and uniform locations, and an array of floats which contains a set of positions and texture coordinates for a rectangle that will completely fill the screen. We’ll use that to draw our texture onto the screen.

Let’s continue the code:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

void on_surface_created() {
    glClearColor(0.0f, 0.0f, 0.0f, 0.0f);
}

void on_surface_changed() {
    texture = load_png_asset_into_texture("textures/air_hockey_surface.png");
    buffer = create_vbo(sizeof(rect), rect, GL_STATIC_DRAW);
    program = build_program_from_assets("shaders/shader.vsh", "shaders/shader.fsh");

    a_position_location = glGetAttribLocation(program, "a_Position");
    a_texture_coordinates_location = 
        glGetAttribLocation(program, "a_TextureCoordinates");
    u_texture_unit_location = glGetUniformLocation(program, "u_TextureUnit");
}

glClearColor() is just as we were doing it before. In on_surface_changed(), we load in a texture from textures/air_hockey_surface.png, we create a VBO from the data stored in rect, and then we build an OpenGL shader program from the shaders located at shaders/shader.vsh and shaders/shader.fsh. Once we have the program loaded, we use it to grab the attribute and uniform locations out of the shader.

We haven’t yet defined the code to load in the actual assets from the file system, since a good part of that is platform-specific. When we do, we’ll take care to set things up so that these relative paths “just work”.

Let’s complete game.c:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

void on_draw_frame() {
    glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);

    glUseProgram(program);

    glActiveTexture(GL_TEXTURE0);
    glBindTexture(GL_TEXTURE_2D, texture);
    glUniform1i(u_texture_unit_location, 0);

    glBindBuffer(GL_ARRAY_BUFFER, buffer);
    glVertexAttribPointer(a_position_location, 2, GL_FLOAT, GL_FALSE, 
        4 * sizeof(GL_FLOAT), BUFFER_OFFSET(0));
    glVertexAttribPointer(a_texture_coordinates_location, 2, GL_FLOAT, GL_FALSE, 
        4 * sizeof(GL_FLOAT), BUFFER_OFFSET(2 * sizeof(GL_FLOAT)));
    glEnableVertexAttribArray(a_position_location);
    glEnableVertexAttribArray(a_texture_coordinates_location);
    glDrawArrays(GL_TRIANGLE_STRIP, 0, 4);

    glBindBuffer(GL_ARRAY_BUFFER, 0);
}

In the draw loop, we clear the screen, set the shader program, bind the texture and VBO, setup the attributes using glVertexAttribPointer(), and then draw to the screen with glDrawArrays(). If you’ve looked at the Java tutorials before, one thing you’ll notice is that it’s a bit easier to use glVertexAttribPointer() from C than it is from Java. For one, if we were using client-side arrays, we could just pass the array without worrying about any ByteBuffers, and for two, we can use the sizeof operator to get the size of a datatype in bytes, so no need to hardcode that.

This wraps up everything for the core folder, so in the next few steps, we’re going to add in the necessary platform wrappers to get this working on Android.

Adding the common platform code

These new files should go in /airhockey/src/platform/common:

platform_file_utils.h

1
2
3
4
5
6
7
8
9

#pragma once
typedef struct {
    const long data_length;
    const void* data;
    const void* file_handle;
} FileData;

FileData get_file_data(const char* path);
void release_file_data(const FileData* file_data);

We’ll use this to read data from the file system on iOS and emscripten. We’ll also use FileData for our Android asset reading code. We won’t define the implementation of the functions for now since we won’t need them for Android.

platform_asset_utils.h

1
2
3
4

#include "platform_file_utils.h"

FileData get_asset_data(const char* relative_path);
void release_asset_data(const FileData* file_data);

We’ll use this to read in assets. For Android this will be specialized code since it will use the AssetManager class to read files straight from the APK file.

platform_log.h

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

#include "platform_macros.h"
#include "config.h"

void _debug_log_v(const char* tag, const char* text, ...) PRINTF_ATTRIBUTE(2, 3);
void _debug_log_d(const char* tag, const char* text, ...) PRINTF_ATTRIBUTE(2, 3);
void _debug_log_w(const char* tag, const char* text, ...) PRINTF_ATTRIBUTE(2, 3);
void _debug_log_e(const char* tag, const char* text, ...) PRINTF_ATTRIBUTE(2, 3);

#define DEBUG_LOG_PRINT_V(tag, fmt, ...) do { if (LOGGING_ON) _debug_log_v(tag, "%s:%d:%s(): " fmt, __FILE__, __LINE__, __func__, __VA_ARGS__); } while (0)
#define DEBUG_LOG_PRINT_D(tag, fmt, ...) do { if (LOGGING_ON) _debug_log_d(tag, "%s:%d:%s(): " fmt, __FILE__, __LINE__, __func__, __VA_ARGS__); } while (0)
#define DEBUG_LOG_PRINT_W(tag, fmt, ...) do { if (LOGGING_ON) _debug_log_w(tag, "%s:%d:%s(): " fmt, __FILE__, __LINE__, __func__, __VA_ARGS__); } while (0)
#define DEBUG_LOG_PRINT_E(tag, fmt, ...) do { if (LOGGING_ON) _debug_log_e(tag, "%s:%d:%s(): " fmt, __FILE__, __LINE__, __func__, __VA_ARGS__); } while (0)

#define DEBUG_LOG_WRITE_V(tag, text) DEBUG_LOG_PRINT_V(tag, "%s", text)
#define DEBUG_LOG_WRITE_D(tag, text) DEBUG_LOG_PRINT_D(tag, "%s", text)
#define DEBUG_LOG_WRITE_W(tag, text) DEBUG_LOG_PRINT_W(tag, "%s", text)
#define DEBUG_LOG_WRITE_E(tag, text) DEBUG_LOG_PRINT_E(tag, "%s", text)

#define CRASH(e) DEBUG_LOG_WRITE_E("Assert", #e); __builtin_trap()

This contains a bunch of macros to help us do logging from our core game code. CRASH() is a special macro that will log the message passed to it, then call __builtin_trap() to stop execution. We used this macro above when we were loading in the PNG file.

platform_macros.h

1
2
3
4
5

#if defined(__GNUC__)
#define PRINTF_ATTRIBUTE(format_pos, arg_pos) __attribute__((format(printf, format_pos, arg_pos)))
#else
#define PRINTF_ATTRIBUTE(format_pos, arg_pos)
#endif

This is a special macro that helps the compiler do format checking when checking the formats that we pass to our log functions.

Updating the Android code

For the Android target, we have a bit of cleanup to do first. Let’s open up the Android project in Eclipse, get rid of GameLibJNIWrapper.java and update RendererWrapper.java as follows:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43

package com.learnopengles.airhockey;

import javax.microedition.khronos.egl.EGLConfig;
import javax.microedition.khronos.opengles.GL10;

import android.content.Context;
import android.opengl.GLSurfaceView.Renderer;

import com.learnopengles.airhockey.platform.PlatformFileUtils;

public class RendererWrapper implements Renderer {  
    static {
        System.loadLibrary("game");     
    }

    private final Context context;  

    public RendererWrapper(Context context) {
        this.context = context;
    }

    @Override
    public void onSurfaceCreated(GL10 gl, EGLConfig config) {       
        PlatformFileUtils.init_asset_manager(context.getAssets());
        on_surface_created();
    }

    @Override
    public void onSurfaceChanged(GL10 gl, int width, int height) {
        on_surface_changed(width, height);
    }

    @Override
    public void onDrawFrame(GL10 gl) {
        on_draw_frame();
    }

    private static native void on_surface_created();

    private static native void on_surface_changed(int width, int height);

    private static native void on_draw_frame();
}

We’ve moved the native methods into RendererWrapper itself. The new RendererWrapper wants a Context passed into its contructor, so give it one by updating the constructor call in MainActivity.java as follows:

1

glSurfaceView.setRenderer(new RendererWrapper(this));

For Android, we’ll be using the AssetManager to read in assets that are compiled directly into the APK file. We’ll need a way to pass a reference to the AssetManager to our C code, so let’s create a new class in a new package called com.learnopengles.airhockey.platform called PlatformFileUtils, and add the following code:

1
2
3
4
5
6
7

package com.learnopengles.airhockey.platform;

import android.content.res.AssetManager;

public class PlatformFileUtils {
    public static native void init_asset_manager(AssetManager assetManager);    
}

We are calling init_asset_manager() from RendererWrapper.onSurfaceCreated(), which you can see just a few lines above.

Updating the JNI code

We’ll also need to add platform-specific JNI code to the jni folder in the android folder. Let’s start off with platform_asset_utils.c:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

#include "platform_asset_utils.h"
#include "macros.h"
#include "platform_log.h"
#include <android/asset_manager_jni.h>
#include <assert.h>

static AAssetManager* asset_manager;

JNIEXPORT void JNICALL Java_com_learnopengles_airhockey_platform_PlatformFileUtils_init_1asset_1manager(
    JNIEnv * env, jclass jclazz, jobject java_asset_manager) {
    UNUSED(jclazz);
    asset_manager = AAssetManager_fromJava(env, java_asset_manager);
}

FileData get_asset_data(const char* relative_path) {
    assert(relative_path != NULL);
    AAsset* asset = 
        AAssetManager_open(asset_manager, relative_path, AASSET_MODE_STREAMING);
    assert(asset != NULL);

    return (FileData) { AAsset_getLength(asset), AAsset_getBuffer(asset), asset };
}

void release_asset_data(const FileData* file_data) {
    assert(file_data != NULL);
    assert(file_data->file_handle != NULL);
    AAsset_close((AAsset*)file_data->file_handle);
}

We use get_asset_data() to wrap Android’s native asset manager and return the data to the calling code, and we release the data when release_asset_data() is called. The advantage of doing things like this is that the asset manager can choose to optimize data loading by mapping the file into memory, and we can return that mapped data directly to the caller.

Let’s add the logging code:

platform_log.c

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

#include "platform_log.h"
#include <android/log.h>
#include <stdio.h>
#include <stdlib.h>

#define ANDROID_LOG_VPRINT(priority)    \
va_list arg_ptr; \
va_start(arg_ptr, fmt); \
__android_log_vprint(priority, tag, fmt, arg_ptr); \
va_end(arg_ptr);

void _debug_log_v(const char *tag, const char *fmt, ...) {
    ANDROID_LOG_VPRINT(ANDROID_LOG_VERBOSE);
}

void _debug_log_d(const char *tag, const char *fmt, ...) {
    ANDROID_LOG_VPRINT(ANDROID_LOG_DEBUG);
}

void _debug_log_w(const char *tag, const char *fmt, ...) {
    ANDROID_LOG_VPRINT(ANDROID_LOG_WARN);
}

void _debug_log_e(const char *tag, const char *fmt, ...) {
    ANDROID_LOG_VPRINT(ANDROID_LOG_ERROR);
}

This code wraps Android’s native logging facilities.

Finally, let’s rename jni.c to renderer_wrapper.c and update it to the following:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

#include "game.h"
#include "macros.h"
#include <jni.h>

/* These functions are called from Java. */

JNIEXPORT void JNICALL Java_com_learnopengles_airhockey_RendererWrapper_on_1surface_1created(
    JNIEnv * env, jclass cls) {
    UNUSED(env);
    UNUSED(cls);
    on_surface_created();
}

JNIEXPORT void JNICALL Java_com_learnopengles_airhockey_RendererWrapper_on_1surface_1changed(
    JNIEnv * env, jclass cls, jint width, jint height) {
    UNUSED(env);
    UNUSED(cls);
    on_surface_changed();
}

JNIEXPORT void JNICALL Java_com_learnopengles_airhockey_RendererWrapper_on_1draw_1frame(
    JNIEnv* env, jclass cls) {
    UNUSED(env);
    UNUSED(cls);
    on_draw_frame();
}

Nothing has really changed here; we just use the UNUSED() macro (defined earlier in macros.h in the core folder) to suppress some unnecessary compiler warnings.

Updating the NDK build files

We’re almost ready to build & test, just a few things left to be done. Download libpng 1.6.2 from http://www.libpng.org/pub/png/libpng.html and place it in /src/3rdparty/libpng. To configure libpng, copy pnglibconf.h.prebuilt from libpng/scripts/ to libpng/ and remove the .prebuilt extension.

To compile libpng with the NDK, let’s add a build script called Android.mk to the libpng folder, as follows:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

LOCAL_PATH := $(call my-dir)

include $(CLEAR_VARS)

LOCAL_MODULE := libpng
LOCAL_SRC_FILES = png.c \
                  pngerror.c \
                  pngget.c \
                  pngmem.c \
                  pngpread.c \
                  pngread.c \
                  pngrio.c \
                  pngrtran.c \
                  pngrutil.c \
                  pngset.c \
                  pngtrans.c \
                  pngwio.c \
                  pngwrite.c \
                  pngwtran.c \
                  pngwutil.c
LOCAL_EXPORT_C_INCLUDES := $(LOCAL_PATH)
LOCAL_EXPORT_LDLIBS := -lz

include $(BUILD_STATIC_LIBRARY)

This build script will tell the NDK tools to build a static library called libpng that is linked against zlib, which is built into Android. It also sets up the right variables so that we can easily import this library into our own projects, and we won’t even have to do anything special because the right includes and libs are already exported.

Let’s also update the Android.mk file in our jni folder:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

LOCAL_PATH := $(call my-dir)
PROJECT_ROOT_PATH := $(LOCAL_PATH)/../../../
CORE_RELATIVE_PATH := ../../../core/

include $(CLEAR_VARS)

LOCAL_MODULE    := game
LOCAL_CFLAGS    := -Wall -Wextra
LOCAL_SRC_FILES := platform_asset_utils.c \
                   platform_log.c \
                   renderer_wrapper.c \
                   $(CORE_RELATIVE_PATH)/asset_utils.c \
                   $(CORE_RELATIVE_PATH)/buffer.c \
                   $(CORE_RELATIVE_PATH)/game.c \
                   $(CORE_RELATIVE_PATH)/image.c \
                   $(CORE_RELATIVE_PATH)/shader.c \
                   $(CORE_RELATIVE_PATH)/texture.c \

LOCAL_C_INCLUDES := $(PROJECT_ROOT_PATH)/platform/common/
LOCAL_C_INCLUDES += $(PROJECT_ROOT_PATH)/core/
LOCAL_STATIC_LIBRARIES := libpng
LOCAL_LDLIBS := -lGLESv2 -llog -landroid

include $(BUILD_SHARED_LIBRARY)

$(call import-add-path,$(PROJECT_ROOT_PATH)/3rdparty)
$(call import-module,libpng)

Our new build script links in the new files that we’ve created in core, and it also imports libpng from the 3rdparty folder and builds it as a static library that is then linked into our Android application.

Adding in the assets

The last step is to add in the assets into /airhockey/assets, which includes the textures and the shaders. To do this, download the assets from https://github.com/learnopengles/airhockey/tree/article-2-loading-png-file/assets and place them in your airhockey folder. To have them automatically included in the APK, follow these steps:

  1. Delete the existing assets folder from the project.
  2. Right-click the project and select Properties. In the window that appears, select Resource->Linked Resources and click New….
  3. Enter ‘ASSETS_LOC’ as the name, and ‘${PROJECT_LOC}/../../../assets’ as the location. Once that’s done, click OK until the Properties window is closed.
  4. Right-click the project again and select New->Folder, enter ‘assets’ as the name, select Advanced, select Link to alternate location (Linked Folder), select Variables…, select ASSETS_LOC, and select OK, then Finish.

You should now have a new assets folder that is linked to the assets folder that we created in the airhockey root. More information can be found on Stack Overflow: How to link assets/www folder in Eclipse / Phonegap / Android project?

Running the app

We should be able to check out the new code now. If you run the app on your Android emulator or device, it should look similar to the following image:

Texture on the Nexus 7

The texture looks a bit stretched/squashed, because we are currently asking OpenGL to fill the screen with that texture. With a basic framework in place, we can start adding some more detail in future lessons and start turning this into an actual game.

Debugging NDK code

While developing this project, I had to hook up a debugger as something was going bad in the PNG loading code, and I just wasn’t sure what. It turns out that I had confused a png_bytep* with a png_byte* — the ‘p’ in the first one means that it’s already a pointer, so I didn’t have to put another star there. I had some issues using the debugging at first, so here are some tips that might help you out if you want to hook up the debugger:

  1. Your project absolutely cannot have any spaces in its path. Otherwise, the debugger will inexplicably fail to connect.
  2. The native code needs to be built with NDK_DEBUG=1; see “Debugging native applications” on this page: Using the NDK plugin.
  3. Android will not wait for gdb to connect before executing the code. Add SystemClock.sleep(10000); to RendererWrapper’s onSurfaceCreated() method to add a sufficient delay to hit your breakpoints.

Once that’s done, you can start debugging from Eclipse by right-clicking the project and selecting Debug As->Android Native Application.

Exploring further

The full source code for this lesson can be found at the GitHub project. For a “friendlier” introduction to OpenGL ES 2 that is focused on Java and Android, see Android Lesson One: Getting Started or OpenGL ES 2 for Android: A Quick-Start Guide.

What could we do to further streamline the code? If we were using C++, we could take advantage of destructors to create, for example, a FileData that cleans itself up when it goes out of scope. I’d also like to make the structs private somehow, as their internals don’t really need to be exposed to clients. What else would you do?

Further reading

In the next two posts, we’ll look at adding support for iOS and emscripten. Now that we’ve built up this base, it actually won’t take too much work!

19 comments and 5 pingbacks to “Loading a PNG into Memory and Displaying It as a Texture with OpenGL ES 2, Using (Almost) the Same Code on iOS, Android, and Emscripten”

  1. Pingback: Developing a Simple Game of Air Hockey Using C++ and OpenGL ES 2 for Android, iOS, and the Web | Learn OpenGL ES

  2. Pingback: Loading a PNG into Memory and Displaying It as a Texture with OpenGL ES 2: Adding Support for iOS | Learn OpenGL ES

  3. Pingback: Calling OpenGL from C on the Web by Using Emscripten, Sharing Common Code with Android and iOS | Learn OpenGL ES

  4. Pingback: Loading a PNG into Memory and Displaying It as a Texture with OpenGL ES 2: Adding Support for Emscripten | Learn OpenGL ES

  5. BK

    Hi, I really appreciate your fantastic explanation of loading Texture through Open GL ES 2.0.
    And really thank you to get code of your projects by GIT.

    But I have a beginner level-problem. That is, I don’t know how to make ‘png.h’

    I downloaded ‘libpng’ and extract the list of files that is written in your example code/…./3rdParty/…/android.mk.

    Then I try to build ‘static library’, but I got nothing.

    Could you give me some hints or advice to let me do right way to get ‘png.h’ which is used in your explanation.

    Really thank you for posting amazing tutorial and saving me, a beginner at Open GL ES 2.0

    1. Kevin

      Hi BK,

      The “png.h” file will come with libpng, so there will be nothing to build. If you are getting errors about that file, it sounds like it might be an include path problem. You just need to do the following to include libpng in your NDK build:

      1) Copy pnglibconf.h.prebuilt from libpng/scripts/ to libpng/ and remove the .prebuilt extension.
      2) Create a new file called “Android.mk” and place it in the libpng/ folder. That file should have the following contents:
      LOCAL_PATH := $(call my-dir)

      include $(CLEAR_VARS)

      LOCAL_MODULE := libpng
      LOCAL_SRC_FILES = png.c \
      pngerror.c \
      pngget.c \
      pngmem.c \
      pngpread.c \
      pngread.c \
      pngrio.c \
      pngrtran.c \
      pngrutil.c \
      pngset.c \
      pngtrans.c \
      pngwio.c \
      pngwrite.c \
      pngwtran.c \
      pngwutil.c
      LOCAL_EXPORT_C_INCLUDES := $(LOCAL_PATH)
      LOCAL_EXPORT_LDLIBS := -lz

      include $(BUILD_STATIC_LIBRARY)

      3) To actually call this static library from your build script, you need to add the following to your jni Android.mk:

      LOCAL_STATIC_LIBRARIES := libpng

      …

      And at the very end of the file:

      $(call import-add-path,$(PROJECT_ROOT_PATH)/3rdparty)
      $(call import-module,libpng)

      Replace $(PROJECT_ROOT_PATH)/3rdparth with wherever you placed the libpng folder. If you want to use PROJECT_ROOT_PATH, you have to define it at the top of the file like this:

      PROJECT_ROOT_PATH := $(LOCAL_PATH)/../../../

      Adjusting that to match your path.

      I think the easiest way is to just clone everything from Github and build it like that, as that way you shouldn’t need to change anything. I just tried cloning the github repo for this lesson (https://github.com/learnopengles/airhockey.git), downloaded libpng 1.6.5 (http://www.libpng.org/pub/png/libpng.html) and I was able to compile the code with ndk-build run in the jni directory. What errors are you seeing?

      1. Kevin

        When you clone the project from github, you will already have a libpng folder in 3rdparty which contains the Android.mk file. When you download and unzip libpng from the Internet, just paste all the files directly in that libpng folder, and not in a subfolder. I’m thinking that might be the cause, too.

  6. BK

    Thank you so much about your help. I downloaded your project then linking the folders that we needed. Then, it works. Thank you!!!!!!!!:)

  7. skadush

    Hi,

    Me again..

    Got some question again.. In chapter 6.6 you have a variable like this
    m[0] = a/ aspect;
    m[1] = 0f;
    m[2] = 0f;
    m[3] = 0f;

    m[4] = 0f;
    m[5] = a;
    m[6] = 0f;
    m[7] = 0f;

    m[8] = 0f;
    m[9] = 0f;
    m[10] = -((f + n) / (f – n));
    m[11] = -1f;

    m[12] = 0f;
    m[13] = 0f;
    m[14] = -((2f * f * n) / (f – n));
    m[15] = 0f;

    Although you explain whats the use of it. You havent explain why you put the computation on a certain m[i]. Like this one m[5]=a then majority of it is value of 0f.

    1. Kevin

      Hi Skadush,

      I just wouldn’t worry about this too much. It’s like if you start learning how to repair a car, you don’t need to know the math behind the combustion of a certain air/fuel mixture; you just need to know that engines burn fuel in order to work. If you’re curious, there is a good derivation of the math available on this website: http://www.songho.ca/opengl/gl_projectionmatrix.html. This will explain the derivation of each part of the matrix in detail.

  8. skadush

    No dont mind the question.. i cant delete it. BTW i realize that you have a math error on chapter 6.7 on matrix matrix multiplication.

    the answer should
    8 5
    20 16(not 13 because 4 X 1 = 4, and 12 + 4 = 16) 😀

    Is that correct or my calculation is wrong?

  9. Pingback: Finishing Up Our Native Air Hockey Project With Touch Events and Basic Collision Detection | Learn OpenGL ES

  10. Linker Tinker

    I receive this error message when running on the iPhone IOS simulator.

    Undefined symbols for architecture i386:
    “_png_create_info_struct”, referenced from:
    _get_raw_image_data_from_png in image.o
    “_png_create_read_struct”, referenced from:
    _get_raw_image_data_from_png in image.o
    “_png_destroy_read_struct”, referenced from:
    _get_raw_image_data_from_png in image.o
    “_png_get_IHDR”, referenced from:
    _read_and_update_info in image.o
    “_png_get_color_type”, referenced from:
    _read_and_update_info in image.o
    “_png_get_io_ptr”, referenced from:
    _read_png_data_callback in image.o
    “_png_get_rowbytes”, referenced from:
    _read_entire_png_image in image.o
    “_png_get_valid”, referenced from:
    _read_and_update_info in image.o
    “_png_read_end”, referenced from:
    _get_raw_image_data_from_png in image.o
    “_png_read_image”, referenced from:
    _read_entire_png_image in image.o
    “_png_read_info”, referenced from:
    _read_and_update_info in image.o
    “_png_read_update_info”, referenced from:
    _read_and_update_info in image.o
    “_png_set_add_alpha”, referenced from:
    _read_and_update_info in image.o
    “_png_set_expand_gray_1_2_4_to_8”, referenced from:
    _read_and_update_info in image.o
    “_png_set_longjmp_fn”, referenced from:
    _get_raw_image_data_from_png in image.o
    “_png_set_packing”, referenced from:
    _read_and_update_info in image.o
    “_png_set_palette_to_rgb”, referenced from:
    _read_and_update_info in image.o
    “_png_set_read_fn”, referenced from:
    _get_raw_image_data_from_png in image.o
    “_png_set_scale_16”, referenced from:
    _read_and_update_info in image.o
    “_png_set_tRNS_to_alpha”, referenced from:
    _read_and_update_info in image.o
    “_png_sig_cmp”, referenced from:
    _get_raw_image_data_from_png in image.o
    ld: symbol(s) not found for architecture i386
    clang: error: linker command failed with exit code 1 (use -v to see invocation)

  11. iam

    I downloaded the project and compiled it (after adding the libpng files) but it does not run….

    01-14 22:24:09.382: A/libc(17902): Fatal signal 11 (SIGSEGV) at 0x00000000 (code=1), thread 17915 (Thread-9486)

    I have other Android NDK OpenGL apps that work on my Nexus 7 but this one fails

  12. Alex

    Textures draws black if I save it via photoshop File->Save For Web.
    But they works perfectly if I save it just via File->Save As.
    Do you know how to solve this problem? I really like Save For Web.

    1. Kevin

      Hi Alex,

      This sounds like an issue with the alpha channel being saved differently between the two options. You could ignore it in your shader or just make sure that the saved file has the data you expect.

      Alternatively, it could be an issue with 256-color paletted files, which also needs to be accounted for when you load in the texture data.

  13. Lee

    Hi,

    I’m curious why are you asserting the results of glGenTextures is not equal to zero? I recall reading in the specs a long time ago that glGenTextures could very well return any value, and the zero is not a reserved value. In fact you don’t have to call glGenTextures, you can bind to any value you want including zero, so you can use your own ID system for textures. Is my understanding mistaken?

    1. Kevin

      After re-reading the man page for glGenTextures, you may be right. A possible area of the code to improve. 🙂

  14. Jai

    Hi, thanks for such a wonderful tutorial. It really helped me understand the process. I am trying to build an app for android which processes images using a C++ and OpenGL ES 2 based native plugin. This tutorial is well written and is easy to follow ,however, I want to be able to read multiple formats and not just .png . I found out that SOIL2 (Simple OpenGL Image Library 2) can help me but I have idea how to go around it. Any help will be appreciated. Thanks in advance.

    1. Patrik

      Hi Jai, I think it would be easiest to use Java to open and decode these various files. You can then pass a pointer to the raw data to native code use JNI, process it and go back to Java. The NDK is really giving you low-level access in the first place and high-level interfaces are mostly missing.

Comments are closed. This site is kept as a historical archive.