0

I have the following function using stbi_load:

void load_texture_from_file(const char *file, bool alpha, const char *name) {
    Texture *tex;
    tex = malloc(sizeof(Texture));
    tex->name = name;

    int width, height, channels;
    unsigned char *data = stbi_load(file, &width, &height, &channels, 0); 
    generate_texture(width, height, data, tex, alpha); 
    
    stbi_image_free(data);
}

File is coming from:

load_texture_from_file("/home/correct_folder/correct_name.png", true, "sprite");

I get no error using stbi_failure_reason() and when checking the contents of data with gdb I see:

Thread 1 "a" hit Breakpoint 2, load_texture_from_file (file=0x555555579d18 "/home/correct_folder/correct_name.png", 
    alpha=true, name=0x555555579d12 "face") at resource_manager.c:25
25          generate_texture(width, height, data, tex, alpha); 
(gdb) print data
$1 = (unsigned char *) 0x7ffff40c1010 ""

What am I missing?

Vitor Hugo
  • 1,106
  • 1
  • 15
  • 35
  • 2
    The image was probably loaded correctly, it just starts with a zero byte. GDB is misprinting it because it thinks it's a string, and it's not. – HolyBlackCat Jul 20 '21 at 20:55
  • 1
    You might want to either pass a positive number as the last argument to `stbi_load`. **Or**, alternatively, take `channels` into account when creating the texture. – HolyBlackCat Jul 20 '21 at 20:56

1 Answers1

1

To expand on @HolyBlackCat's comment, you may not be doing anything wrong at all in terms of loading the data. You should try examining memory with gdb instead of printing it, which is treating data as as string. You can do so in gdb with the following command:

x/nfu <address>

where

  • x/ is the "examine memory" command
  • n is the number of memory units/elements you want to examine
  • f is the display format ('x' for hex, 'd' for decimal, etc. See link below)
  • u is the unit/element format ('b' for bytes, 'w' for words, etc. See link below)
  • address is the address where you want to begin examining memory

For example, to look at the first 5 bytes of data in hex format, you would enter

x/5xb data

To look at the first ten 4-byte words in hex format, you would enter

x/10xw data

See this page for more information and an exhaustive list of all parameter options.

yano
  • 4,827
  • 2
  • 23
  • 35
  • That is very useful, thank you, but somehow I'm still getting: (gdb) x/10xw data 0x7ffff40c1010: 0x00000000 0x00000000 0x00000000 0x00000000 ... All zeros. – Vitor Hugo Jul 20 '21 at 22:07
  • @VitorHugo are you sure that's wrong? I'm not familiar with `stbi` stuff or .png file format. Maybe you can try hexdumping the correct_name.png file and compare that with gdb output if you know where in the file you're reading from. – yano Jul 20 '21 at 22:13
  • 1
    It should be wrong I guess. I mean, I feel like even tho I'm not seeing the image on the screen, it was correctly loaded because height and width were correctly populated. But somehow I can't find the "image data" debugging. I don't think it is supposed to be all zeros tho. For reference, the image is awesomeface.png from: https://learnopengl.com/In-Practice/2D-Game/Rendering-Sprites – Vitor Hugo Jul 21 '21 at 11:52
  • @VitorHugo I assume awesome face is that green face in the black background? Again, I don't know the .png format, but I assume black will be represented by 0s, and there is a lot of black in that picture. Have you looked at _all_ the data? You said yourself the height and width were getting populated correctly, which sounds promising. A couple of things you can try: 1) hexdump the picture on file, are there a lot of 0s there too? Where does the first non-zero byte start? In gdb you could do `x/10xb data+offset`, where `offset` is where the first non-zero byte starts obtained from hexdump. – yano Jul 21 '21 at 14:42
  • @VitorHugo 2) Load the image data as you are, then immediately write it back to a different file. Compare the file you just wrote to the original, via a hash or some other method... see if they're the same. The fact that height and width are correct, and there's no error reported strongly suggests to me the picture is indeed getting loaded correctly, but I can't explain why you can't see it. Maybe you're zoomed in too far or something? Can you try a picture that's more colorful that doesn't have huge areas of black? – yano Jul 21 '21 at 14:45