SFML community forums

Help => Graphics => Topic started by: Mörkö on January 14, 2015, 05:34:57 pm

Title: sf::Texture load from memory
Post by: Mörkö on January 14, 2015, 05:34:57 pm

Hi. I'm having trouble figuring out how sf::Texture::loadFromMemory works. I would be grateful if you could demonstrate a complete minimal working example how to use it.

If you don't want to generate your own image, then you may take one of these:

(click to show/hide)

static unsigned int width = 19;
static unsigned int height = 19;
 
/*  Call this macro repeatedly.  After each use, the pixel data can be extracted  */
 
#define HEADER_PIXEL(data,pixel) {\
pixel[0] = (((data[0] - 33) << 2) | ((data[1] - 33) >> 4)); \
pixel[1] = ((((data[1] - 33) & 0xF) << 4) | ((data[2] - 33) >> 2)); \
pixel[2] = ((((data[2] - 33) & 0x3) << 6) | ((data[3] - 33))); \
data += 4; \
}
static char *header_data =
        "`^B3`^B3`^B3`^B3`^B3!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!`^B3`^B3"
        "`^B3`^B3`^B3`^B3`^B3`^B3`^B3!!!!!!!!!!!!`^B3`^B3`^B3`^B3`^B3!!!!"
        "!!!!!!!!`^B3`^B3`^B3`^B3`^B3`^B3`^B3!!!!!!!!`^B3`^B3`^B3`^B3`^B3"
        "`^B3`^B3`^B3`^B3!!!!!!!!`^B3`^B3`^B3`^B3`^B3!!!!!!!!`^B3`^B3`^B3"
        "`^B3`^B3`^B3`^B3`^B3`^B3`^B3`^B3!!!!!!!!`^B3`^B3`^B3!!!!!!!!`^B3"
        "`^B3`^B3`^B3`^B3`^B3`^B3`^B3`^B3`^B3`^B3`^B3`^B3!!!!!!!!`^B3!!!!"
        "!!!!`^B3`^B3`^B3`^B3`^B3`^B3`^B3`^B3`^B3`^B3`^B3`^B3`^B3`^B3`^B3"
        "!!!!!!!!!!!!!!!!`^B3!!!!!!!!!!!!!!!!!!!!!!!!`^B3!!!!!!!!!!!!!!!!"
        "!!!!!!!!`^B3!!!!!!!!!!!!`^B3`^B3`^B3`^B3!!!!!!!!!!!!`^B3`^B3`^B3"
        "!!!!!!!!!!!!`^B3`^B3`^B3`^B3!!!!!!!!`^B3`^B3`^B3`^B3`^B3!!!!`^B3"
        "`^B3`^B3`^B3`^B3!!!!`^B3`^B3`^B3`^B3`^B3!!!!!!!!`^B3`^B3`^B3`^B3"
        "`^B3`^B3`^B3`^B3`^B3`^B3`^B3`^B3`^B3`^B3`^B3`^B3`^B3!!!!!!!!`^B3"
        "`^B3`^B3`^B3`^B3`^B3`^B3`^B3`^B3`^B3`^B3`^B3`^B3`^B3`^B3`^B3`^B3"
        "!!!!!!!!`^B3`^B3`^B3!!!!`^B3`^B3`^B3`^B3`^B3`^B3`^B3`^B3`^B3!!!!"
        "`^B3`^B3`^B3!!!!!!!!!!!!`^B3`^B3`^B3!!!!`^B3`^B3`^B3`^B3`^B3`^B3"
        "`^B3!!!!`^B3`^B3`^B3!!!!!!!!!!!!!!!!`^B3`^B3`^B3`^B3!!!!!!!!!!!!"
        "!!!!!!!!!!!!!!!!`^B3`^B3`^B3`^B3!!!!!!!!`^B3!!!!!!!!`^B3`^B3`^B3"
        "`^B3`^B3`^B3`^B3`^B3`^B3`^B3`^B3`^B3`^B3!!!!!!!!`^B3`^B3`^B3!!!!"
        "!!!!`^B3`^B3`^B3`^B3`^B3`^B3`^B3`^B3`^B3`^B3`^B3!!!!!!!!`^B3`^B3"
        "`^B3`^B3`^B3!!!!!!!!`^B3`^B3`^B3`^B3`^B3`^B3`^B3`^B3`^B3!!!!!!!!"
        "`^B3`^B3`^B3`^B3`^B3`^B3`^B3!!!!!!!!!!!!`^B3`^B3`^B3`^B3`^B3!!!!"
        "!!!!!!!!`^B3`^B3`^B3`^B3`^B3`^B3`^B3`^B3`^B3!!!!!!!!!!!!!!!!!!!!"
        "!!!!!!!!!!!!!!!!`^B3`^B3`^B3`^B3`^B3";
 

(click to show/hide)

static const struct {
  unsigned int   width;
  unsigned int   height;
  unsigned int   bytes_per_pixel; /* 2:RGB16, 3:RGB, 4:RGBA */
  unsigned char  pixel_data[19 * 19 * 4 + 1];
} gimp_image = {
  19, 19, 4,
  "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\377\0\0\0\377\0\0\0\377\0"
  "\0\0\377\0\0\0\377\0\0\0\377\0\0\0\377\0\0\0\377\0\0\0\377\0\0\0\0\0\0\0"
  "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\377\0\0"
  "\0\377\0\0\0\377\377\330R\377\377\330R\377\377\330R\377\377\330R\377\377"
  "\330R\377\0\0\0\377\0\0\0\377\0\0\0\377\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"
  "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\377\0\0\0\377\377\330R\377\377\330R\377\377"
  "\330R\377\377\330R\377\377\330R\377\377\330R\377\377\330R\377\377\330R\377"
  "\377\330R\377\0\0\0\377\0\0\0\377\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"
  "\0\0\0\377\0\0\0\377\377\330R\377\377\330R\377\377\330R\377\377\330R\377"
  "\377\330R\377\377\330R\377\377\330R\377\377\330R\377\377\330R\377\377\330"
  "R\377\377\330R\377\0\0\0\377\0\0\0\377\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\377"
  "\0\0\0\377\377\330R\377\377\330R\377\377\330R\377\377\330R\377\377\330R\377"
  "\377\330R\377\377\330R\377\377\330R\377\377\330R\377\377\330R\377\377\330"
  "R\377\377\330R\377\377\330R\377\0\0\0\377\0\0\0\377\0\0\0\0\0\0\0\377\0\0"
  "\0\377\377\330R\377\377\330R\377\377\330R\377\377\330R\377\377\330R\377\377"
  "\330R\377\377\330R\377\377\330R\377\377\330R\377\377\330R\377\377\330R\377"
  "\377\330R\377\377\330R\377\377\330R\377\377\330R\377\0\0\0\377\0\0\0\377"
  "\0\0\0\377\0\0\0\377\377\330R\377\0\0\0\377\0\0\0\377\0\0\0\377\0\0\0\377"
  "\0\0\0\377\0\0\0\377\377\330R\377\0\0\0\377\0\0\0\377\0\0\0\377\0\0\0\377"
  "\0\0\0\377\0\0\0\377\377\330R\377\0\0\0\377\0\0\0\377\0\0\0\377\377\330R"
  "\377\377\330R\377\377\330R\377\377\330R\377\0\0\0\377\0\0\0\377\0\0\0\377"
  "\377\330R\377\377\330R\377\377\330R\377\0\0\0\377\0\0\0\377\0\0\0\377\377"
  "\330R\377\377\330R\377\377\330R\377\377\330R\377\0\0\0\377\0\0\0\377\377"
  "\330R\377\377\330R\377\377\330R\377\377\330R\377\377\330R\377\0\0\0\377\377"
  "\330R\377\377\330R\377\377\330R\377\377\330R\377\377\330R\377\0\0\0\377\377"
  "\330R\377\377\330R\377\377\330R\377\377\330R\377\377\330R\377\0\0\0\377\0"
  "\0\0\377\377\330R\377\377\330R\377\377\330R\377\377\330R\377\377\330R\377"
  "\377\330R\377\377\330R\377\377\330R\377\377\330R\377\377\330R\377\377\330"
  "R\377\377\330R\377\377\330R\377\377\330R\377\377\330R\377\377\330R\377\377"
  "\330R\377\0\0\0\377\0\0\0\377\377\330R\377\377\330R\377\377\330R\377\377"
  "\330R\377\377\330R\377\377\330R\377\377\330R\377\377\330R\377\377\330R\377"
  "\377\330R\377\377\330R\377\377\330R\377\377\330R\377\377\330R\377\377\330"
  "R\377\377\330R\377\377\330R\377\0\0\0\377\0\0\0\377\377\330R\377\377\330"
  "R\377\377\330R\377\0\0\0\377\377\330R\377\377\330R\377\377\330R\377\377\330"
  "R\377\377\330R\377\377\330R\377\377\330R\377\377\330R\377\377\330R\377\0"
  "\0\0\377\377\330R\377\377\330R\377\377\330R\377\0\0\0\377\0\0\0\377\0\0\0"
  "\377\377\330R\377\377\330R\377\377\330R\377\0\0\0\377\377\330R\377\377\330"
  "R\377\377\330R\377\377\330R\377\377\330R\377\377\330R\377\377\330R\377\0"
  "\0\0\377\377\330R\377\377\330R\377\377\330R\377\0\0\0\377\0\0\0\377\0\0\0"
  "\377\0\0\0\377\377\330R\377\377\330R\377\377\330R\377\377\330R\377\0\0\0"
  "\377\0\0\0\377\0\0\0\377\0\0\0\377\0\0\0\377\0\0\0\377\0\0\0\377\377\330"
  "R\377\377\330R\377\377\330R\377\377\330R\377\0\0\0\377\0\0\0\377\0\0\0\0"
  "\0\0\0\377\0\0\0\377\377\330R\377\377\330R\377\377\330R\377\377\330R\377"
  "\377\330R\377\377\330R\377\377\330R\377\377\330R\377\377\330R\377\377\330"
  "R\377\377\330R\377\377\330R\377\377\330R\377\0\0\0\377\0\0\0\377\0\0\0\0"
  "\0\0\0\0\0\0\0\0\0\0\0\377\0\0\0\377\377\330R\377\377\330R\377\377\330R\377"
  "\377\330R\377\377\330R\377\377\330R\377\377\330R\377\377\330R\377\377\330"
  "R\377\377\330R\377\377\330R\377\0\0\0\377\0\0\0\377\0\0\0\0\0\0\0\0\0\0\0"
  "\0\0\0\0\0\0\0\0\0\0\0\0\377\0\0\0\377\377\330R\377\377\330R\377\377\330"
  "R\377\377\330R\377\377\330R\377\377\330R\377\377\330R\377\377\330R\377\377"
  "\330R\377\0\0\0\377\0\0\0\377\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"
  "\0\0\0\0\0\0\0\0\0\377\0\0\0\377\0\0\0\377\377\330R\377\377\330R\377\377"
  "\330R\377\377\330R\377\377\330R\377\0\0\0\377\0\0\0\377\0\0\0\377\0\0\0\0"
  "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\377"
  "\0\0\0\377\0\0\0\377\0\0\0\377\0\0\0\377\0\0\0\377\0\0\0\377\0\0\0\377\0"
  "\0\0\377\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0",
};
 

Thanks.

Title: Re: sf::Texture load from memory
Post by: Laurent on January 14, 2015, 07:33:08 pm

This function is simple, it acts the same as loadFromFile except that the file contents are in memory rather than on the disk.

Sorry I haven't got the time to write a minimal example for it, maybe later.

Title: Re: sf::Texture load from memory
Post by: Jesper Juhl on January 14, 2015, 09:44:51 pm

Here's a quick and dirty example that I just quickly threw together:

#include <SFML/System.hpp>
#include <SFML/Window.hpp>
#include <SFML/Graphics.hpp>
#include <iostream>
#include <fstream>
#include <cstdlib>

int main()
{
    sf::ContextSettings glsettings;
    glsettings.antialiasingLevel = 2;
    sf::RenderWindow window{sf::VideoMode{300, 80}, "loadFromMemory Example", sf::Style::Titlebar | sf::Style::Close, glsettings};

    const auto desktop = sf::VideoMode::getDesktopMode();
    window.setPosition({static_cast<int>(desktop.width / 2 - window.getSize().x / 2),
                       static_cast<int>(desktop.height / 4 - window.getSize().y / 4)});

    window.setMouseCursorVisible(false);
    window.setVerticalSyncEnabled(true);
    window.setKeyRepeatEnabled(false);

    std::ifstream texture_file{"example-texture.png", std::ifstream::binary};
    std::vector<char> buffer;
    if (texture_file) {
        // get length of file:
        texture_file.seekg(0, texture_file.end);
        const auto length = texture_file.tellg();
        if (!length) {
            std::cerr << "Cannot load zero byte texture file" << std::endl;
            return EXIT_FAILURE;
        }
        buffer.resize(length); // reserve space

        texture_file.seekg(0, texture_file.beg);

        auto start = &*buffer.begin();
        texture_file.read(start, length);
        texture_file.close();
    } else {
        std::cerr << "Could not open texture file" << std::endl;
        return EXIT_FAILURE;
    }

    sf::Texture texture;
    if (!texture.loadFromMemory(&buffer[0], buffer.size())) {
        std::cerr << "Texture load failed" << std::endl;
        return EXIT_FAILURE;
    }

    sf::Sprite sprite;
    sprite.setTexture(texture);

    while (window.isOpen()) {
        sf::Event event;
        while (window.pollEvent(event)) {
            if (event.type == sf::Event::Closed)
                window.close();
        }

        window.clear(sf::Color::Black);
        window.draw(sprite);
        window.display();
    }

    return EXIT_SUCCESS;
}
 

The "example-texture.png" image I used is here:
(http://i.imgur.com/MKeYIIS.png)
And here's a screenshot of the result:
(http://i.imgur.com/Opn07bD.png)

Title: Re: sf::Texture load from memory
Post by: Mörkö on January 14, 2015, 11:43:11 pm

Yeah, I guess that will do it, but it's not quite what I was after  ;D

I should have mentioned my goal is to embed some images in the executable, so obviously loading the data from a file defeats the purpose. Sorry my bad.

How would you do it with C formatted data?

Title: Re: sf::Texture load from memory
Post by: Jesper Juhl on January 14, 2015, 11:49:52 pm

Whether or not you load a file from disk to a memory buffer and then loadFromMemory() from that buffer or have a memory buffer already embedded in the executable (like an array or similar) makes no difference what-so-ever. As long as you can pass loadFromMemory() the address of the start of your memory buffer as well as the size, it doesn't care how that data got to be in memory - it'll just load it.
So, if your data is in an array named "foo" embedded in the executable, then just do

Code: [Select]

loadFromMemory(foo, sizeof(foo / sizeof(foo[0])); or similar.

Title: Re: sf::Texture load from memory
Post by: Hapax on January 15, 2015, 01:13:16 am

The memory that loadFromMemory loads from should still be in a recognised file format (http://www.sfml-dev.org/documentation/2.0/classsf_1_1Image.php#aaa6c7afa5851a51cec6ab438faa7354c).
If you require to load a texture from raw pixel data, you would use sf::Image directly and create one from the data (http://www.sfml-dev.org/documentation/2.0/classsf_1_1Image.php#a1c2b960ea12bdbb29e80934ce5268ebf). Then, you load the sf::Texture from the sf::Image (http://www.sfml-dev.org/documentation/2.0/classsf_1_1Texture.php#abec4567ad9856a3596dc74803f26fba2).

Title: Re: sf::Texture load from memory
Post by: grok on January 15, 2015, 06:21:59 am

Mörkö,
am I right you want to embed your encrypted images into the executable and then load them normally using loadFromMemory into sf::Texture?
if yes, then it is possible, but requires a few more steps to be performed:
1) load your image in the memory
2) perform some encryption
3) save that chunk of memory into somewhere (probably on disk)
4) copy that chunk of bytes from disk to some static array in your program
5) when your program runs you decrypt that array
6) load image normally from the decrypted chunk of memory you got from 5).

Or did I miss your point?  8)

Title: Re: sf::Texture load from memory
Post by: Laurent on January 15, 2015, 07:55:43 am

static const char embeddedImageData[] =
{
    /* content generated by one of the hundreds
        of programs that do it, or by your own small utility
       (doesn't take more than 10 lines of C++ code) */
};

texture.loadFromMemory(embeddedImageData, sizeof(embeddedImageData));

Example of code that generate such an array:

#include <fstream>
#include <iomanip>

int main(int argc, char** argv)
{
    std::ifstream in("image.png", std::ios_base::binary);
    std::ofstream out("header.hpp");

    out << "const char imageData[] =" << std::endl;
    out << "{" << std::endl;
    do
    {
        out << "    ";
        for (int i = 0; (i < 20) && in; ++i)
            out << "0x" << std::hex << std::setw(2) << std::setfill('0') << in.get() << std::dec << ", ";
        out << std::endl;
    }
    while (in);
    out << "};" << std::endl;

    return 0;
 

Note that it can be more concise if you don't care about the pretty formatting.

Quote

loadFromMemory(foo, sizeof(foo / sizeof(foo[0]));

This one is wrong, we really want the size in bytes, not the number of elements.

Title: Re: sf::Texture load from memory
Post by: Jesper Juhl on January 15, 2015, 07:59:36 am

Of course. Stupid late at night mistake.

Title: Re: sf::Texture load from memory
Post by: Jesper Juhl on January 15, 2015, 09:08:16 am

Quote from: grok on January 15, 2015, 06:21:59 am

am I right you want to embed your encrypted images into the executable and then load them normally using loadFromMemory into sf::Texture?
if yes, then it is possible, but requires a few more steps to be performed:

You are overcomplicating things.

First of all, the easiest way to get a C array from an image is to just use the 'convert' tool from ImageMagick (http://www.imagemagick.org/) or one of a ton of other similar tools.

And there is certainly no need to use any encryption as you wrote.

Title: Re: sf::Texture load from memory
Post by: Mörkö on January 15, 2015, 05:24:40 pm

Thanks all, and esp Jesper and Laurent for the examples, it's clear now, and I got it to work.

Quote from: grok

am I right you want to embed your encrypted images into the executable and then load them normally using loadFromMemory into sf::Texture?

Nope, like Jesper Juhl said, embedding is enough.

Title: Re: sf::Texture load from memory
Post by: eXpl0it3r on January 20, 2015, 04:02:14 pm

Just in case someone runs into this topic again and doesn't fully understand how it got resolved.

GIMP exports files in the pixel format, meaning that you get an array of char with each char representing a pixel component and each 4 chars representing a full pixel in the RGBA format. If you want to use this kind of format, you can call the sf::Image::create(width, height, pixels) function (http://www.sfml-dev.org/documentation/2.2/classsf_1_1Image.php#a1c2b960ea12bdbb29e80934ce5268ebf). This is also optimal for direct usage with the sf::Window::setIcon() function.

However if you want to use the loadFromMemory() function, you actually need to have the full binary data of the image in memory. It needs to be in a supported format like PNG, JPEG or similar. So basically a file from your disk, but in memory.

Title: Re: sf::Texture load from memory
Post by: Austin J on January 22, 2015, 06:18:52 am

Yeah, the only time I've seen the call for loadFromMemory() is if you loaded the file with another lib, then passed it on, which does arise for some people.

Title: Re: sf::Texture load from memory
Post by: shadowmouse on January 25, 2015, 10:52:48 pm

Is this what I would use if I wanted to load a texture from a resource file that had been compiled into the exe?

Title: Re: sf::Texture load from memory
Post by: Ixrec on January 25, 2015, 11:06:08 pm

Yes.

Title: Re: sf::Texture load from memory
Post by: shadowmouse on January 25, 2015, 11:06:55 pm

So how would I reference the image in the resource file? I should say I have very little experience with resource files so I don't know how to write them or reference the images within them, though I have been using SFML for quite a while.

Title: Re: sf::Texture load from memory
Post by: Ixrec on January 25, 2015, 11:15:40 pm

To my knowledge resource files are a Windows-specific thing; at least I was never able to find any evidence that Mac and/or Linux support anything similar.  So you'll have to look at Windows documentation and tools to figure that out. SFML definitely doesn't support it directly.  Of course, that would make your code no longer cross-platform.

Title: Re: sf::Texture load from memory
Post by: eXpl0it3r on January 25, 2015, 11:41:19 pm

Yes, resource files are Windows specific and I'm not sure how easily you can pass them on to SFML classes.

What we've here been talking about however, is converting an image into C++ code data, which you directly link/include into your application. This also works for any C++ compiler on any platform.

The main confusion on this thread was about the format you'd convert the image into. If you want to use the loadFromMemory function, your data must be a conversion from the binary file. If you want to use the create function, your data must be in the RGBA format.

In my small application (http://en.sfml-dev.org/forums/index.php?topic=17188.msg124699#msg124699) I've used GIMP to generate the header file and then created an image out of it.

Incomplete example:

logo.hpp

#pragma once

#include <SFML/Config.hpp>

static const struct {
        sf::Uint32      width;
        sf::Uint32      height;
        sf::Uint32      bytes_per_pixel; // 2:RGB16, 3:RGB, 4:RGBA
        sf::Uint8       data[250 * 43 * 4 + 1];
} IMG_LOGO = {
    250, 43, 4,
    "\33\32\31\377\33\32\31\377\33\32\31\377\33\32\31\377\33\32\31\377\33\32\31"
    "\377\33\32\31\377\33\32\31\377\33\32\31\377\33\32\31\377\33\32\31\377\33"
    "\32\31\377\33\32\31\377\33\32\31\377\33\32\31\377\33\32\31\377\33\32\31\377"
    "\33\32\31\377\33\32\31\377\33\32\31\377\33\32\31\377\33\32\31\377\33\32\31"
    "\377\33\32\31\377\33\32\31\377\33\32\31\377\33\32\31\377\33\32\31\377\33"
        // etc.

Application.cpp

#include "logo.hpp"

Application::Application()
{
        sf::Image img;
        img.create(IMG_LOGO.width, IMG_LOGO.height, IMG_LOGO.data);
        m_tex_logo.loadFromImage(img);
        // etc.

Title: Re: sf::Texture load from memory
Post by: shadowmouse on January 26, 2015, 09:29:25 pm

Thanks, that's been working really well with my 4x4, 8x8 and 16x16 images. However I now need to include my 500x100 images into my code and when I export them from Gimp, the code is literally 10800 lines long, per image, and c++ doesn't allow strings that long. Is there any way around that?

Title: Re: sf::Texture load from memory
Post by: Jesper Juhl on January 26, 2015, 09:31:48 pm

Sure. Split it into multiple parts in the source, combine into one in memory and load. If you insist on building them into the executable. But, to be honest, I don't really see the point. Why not keep the resources in a seperate resource file?

Title: Re: sf::Texture load from memory
Post by: shadowmouse on January 26, 2015, 09:36:22 pm

I'm already doing that, I have several images that are about 500 x 1000 and I was already splitting each into 10. I read on stack overflow that you can convert it into a hex array, but I don't know how to do that or how to use it with sfml. Is this where I'd use Laurent's earlier post about a converter? I must confess when I first read it I didn't understand it and I hadn't been back through this discussion.

Title: Re: sf::Texture load from memory
Post by: Laurent on January 26, 2015, 10:54:22 pm

Quote

Is this where I'd use Laurent's earlier post about a converter?

Yes, using a byte array instead of a string should remove any compiler limitation.

Title: Re: sf::Texture load from memory
Post by: M74 on January 26, 2015, 11:55:46 pm

Here`s how i load Textures which are stored as Resources in Visual Studio 2013 on Windows:

1. Add the images to resource.rc file:

IDR_TEXTURE0    RCDATA  ".\\..\\Graphics\\Texture0.png"
IDR_TEXTURE1    RCDATA  ".\\..\\Graphics\\Texture1.png"
IDR_TEXTURE2    RCDATA  ".\\..\\Graphics\\Texture2.png"
IDR_TEXTURE3    RCDATA  ".\\..\\Graphics\\Texture3.png"
 

2. Add them to resource.h file:

#ifndef IDC_STATIC
#define IDC_STATIC (-1)
#endif

#define IDI_ICON1 101
#define IDI_TEXTURE0 102
#define IDI_TEXTURE1 103
#define IDI_TEXTURE2 104
#define IDI_TEXTURE3 105
#define IDI_FONT0 106
#define IDI_FONT1 107
 

3. Load them in code:

        const int TEXTURES_COUNT = 4;
        sf::Texture textures[TEXTURES_COUNT];
        sf::Sprite sprites[TEXTURES_COUNT];
        for (int i = 0; i < TEXTURES_COUNT; i++)
        {
                std::wstring numString = L"IDR_TEXTURE" + std::to_wstring(i);
                HRSRC rsrcData = FindResource(NULL, numString.c_str(), RT_RCDATA);
                LPVOID firstByte = LockResource(LoadResource(NULL, rsrcData));
                textures[i].loadFromMemory(firstByte, SizeofResource(NULL, rsrcData));
                sprites[i].setTexture(textures[i]);
                textures[i].setSmooth(true);
        }
 

Title: Re: sf::Texture load from memory
Post by: Laurent on January 27, 2015, 07:39:49 am

What's the advantage of using a platform-specific solution when there's a simple and portable way to embed resources in the executable?

Title: Re: sf::Texture load from memory
Post by: Jesper Juhl on January 27, 2015, 07:56:18 am

I was not advocating Windows/VS resource files. Just that using a seperate  data file (in whatever format) is usually more managable than adding resources to the executable.

Title: Re: sf::Texture load from memory
Post by: Laurent on January 27, 2015, 08:44:41 am

Win32 resource files are compiled into the executable ;)

Title: Re: sf::Texture load from memory
Post by: shadowmouse on January 27, 2015, 05:38:12 pm

Just been using the converter to convert the images into const char arrays and I'm getting lots of warnings of narrowing conversion from 'int to 'const char' is ill-formed in c++ 11. Is there any way around that? I've tried converting the array into int but then img.create doesn't work.

Title: Re: sf::Texture load from memory
Post by: eXpl0it3r on January 27, 2015, 05:56:02 pm

Where do these warnings get raised and what is "lots of"?
Have you taken a look at the header file generated?

Laurent's code add an extra "0xffffffff" at the end of the array (not sure why). I think you can safely remove that.

Title: Re: sf::Texture load from memory
Post by: shadowmouse on January 27, 2015, 05:59:37 pm

Just tried removing the 0xfffffff and it hasn't helped, yes I've looked at the header because I've taken the code out of it and put in in my own header alongside some other image code. Lots of warnings is 750. The compiler log says that the warnings are all on the line of the curly brace that closes the array.

EDIT: I've realised that I was using img.create rather than loadFromMemory and changing that has got rid of the errors. I'm not sure why that gets rid of errors in the header file containing the image data, not the one with the img.loadFromMemory but it seems to have done.

EDIT2: No, it turns out my compiler was just not warning me about things it had warned me about before. When I added another image with exactly the same syntax as before it came out with another 1000 warnings.

Title: Re: sf::Texture load from memory
Post by: Hapax on January 27, 2015, 06:38:33 pm

image.create() wants pixel data whereas image.loadFromMemory() requires the data to still be in a recognisable file format.

Title: Re: sf::Texture load from memory
Post by: shadowmouse on January 27, 2015, 06:48:46 pm

What about the -Wnarrowing warnings? Is that just something that I need to put up with an wait a few minutes for it to compile every time I add a new image, or is there something I can do about it?

Title: Re: sf::Texture load from memory
Post by: eXpl0it3r on January 27, 2015, 09:10:19 pm

We don't know where and why it happens, as such we can't give you any answer. I just know, if you do it correctly, it does work without warnings.

Title: Re: sf::Texture load from memory
Post by: shadowmouse on January 27, 2015, 09:14:42 pm

Sorry for not being specific. My code goes like this:
static const char image[]
{
    "0x83, 0x91, 0x23, ...
(rest of image here)
     ... , 0xffffff"
};
My compiler then comes up with approximately one thousand Wnarrowing warnings of converting from int to const char* all said to be on the line of the closing curly brace, in the first column.

Title: Re: sf::Texture load from memory
Post by: Hapax on January 27, 2015, 09:39:33 pm

You probably don't want the two double-quotes (").

Title: Re: sf::Texture load from memory
Post by: shadowmouse on January 27, 2015, 10:11:48 pm

Ah sorry, I need to remember never to quote my code if it isn't right in front of me but I didn't have access to it at the time and I'd been looking at it for so long I thought I could remember it. Those double-quotes are from the method I was using for storing small images (gimp exported c source code) and they were at the start and end of every line. I got rid of them when I started using const char arrays instead. Other than the quotes, the code I posted is what I've got at the moment apart from the fact that they aren't static (I've just checked). I've disabled all warnings on my compiler and now and it isn't coming up with the -Wnarrowing, but warnings are useful for other things so I would prefer to fix it rather than leave it with the compiler just ignoring it and other potential problems. Sorry for being such a persistent problem, I just want to get this to work.

Title: Re: sf::Texture load from memory
Post by: eXpl0it3r on January 27, 2015, 11:15:50 pm

Provide a complete and minimal example. Without it we can just make random guesses.

Title: Re: sf::Texture load from memory
Post by: Hapax on January 27, 2015, 11:26:06 pm

Does it work if you change char to unsigned char?

Also, googling that error suggests that making sure your compiler is up-to-date may solve it.


Apart from those, what eXpl0it3r said.

Title: Re: sf::Texture load from memory
Post by: Jesper Juhl on January 28, 2015, 12:05:31 am

Quote from: shadowmouse on January 27, 2015, 10:11:48 pm

I've disabled all warnings on my compiler and now and it isn't coming up with the -Wnarrowing

That certainly is not a fix for anything.
Compiler warnings are there to help you. Just disabling them changes nothing.

Title: Re: sf::Texture load from memory
Post by: shadowmouse on January 28, 2015, 02:23:04 pm

eXpl0it3r:
The image code (ButtonImages.hpp)

(click to show/hide)

const char DtoB[] =
{
    0x89, 0x50, 0x4e, 0x47, 0x0d, 0x0a, 0x1a, 0x0a, 0x00, 0x00, 0x00, 0x0d, 0x49, 0x48, 0x44, 0x52, 0x00, 0x00, 0x01, 0xf4,
    0x00, 0x00, 0x00, 0x64, 0x08, 0x02, 0x00, 0x00, 0x00, 0xff, 0xa5, 0x55, 0x2a, 0x00, 0x00, 0x00, 0x01, 0x73, 0x52, 0x47,
    0x42, 0x00, 0xae, 0xce, 0x1c, 0xe9, 0x00, 0x00, 0x00, 0x04, 0x67, 0x41, 0x4d, 0x41, 0x00, 0x00, 0xb1, 0x8f, 0x0b, 0xfc,
    0x61, 0x05, 0x00, 0x00, 0x00, 0x09, 0x70, 0x48, 0x59, 0x73, 0x00, 0x00, 0x0e, 0xc3, 0x00, 0x00, 0x0e, 0xc3, 0x01, 0xc7,
    0x6f, 0xa8, 0x64, 0x00, 0x00, 0x07, 0xdc, 0x49, 0x44, 0x41, 0x54, 0x78, 0x5e, 0xed, 0xdd, 0x3b, 0x56, 0xdc, 0x3c, 0x1c,
    0x87, 0x61, 0xf8, 0xd6, 0x32, 0xa4, 0xc8, 0xc9, 0x0a, 0xc8, 0x0a, 0x80, 0x86, 0x8a, 0x36, 0xdd, 0x50, 0x42, 0x93, 0x2e,
    0x65, 0x3a, 0x1a, 0x28, 0x99, 0x2e, 0x6d, 0xaa, 0x34, 0x61, 0x56, 0x10, 0x56, 0x90, 0x93, 0x22, 0xcc, 0x5e, 0xf8, 0x7c,
    0xd3, 0x65, 0x6c, 0x59, 0x96, 0x2c, 0xd9, 0x8c, 0xff, 0x79, 0x9f, 0x73, 0x38, 0x19, 0x12, 0x7b, 0x7c, 0x91, 0xf4, 0xb3,
    0x2c, 0x5f, 0x72, 0x04, 0x00, 0x90, 0xe7, 0xb8, 0xf8, 0x79, 0x7d, 0x7d, 0xad, 0x7f, 0x01, 0x00, 0x08, 0x70, 0x7c, 0x7c,
    0xfc, 0x5f, 0xf3, 0x11, 0x00, 0x20, 0x08, 0xe1, 0x0e, 0x00, 0x02, 0x11, 0xee, 0x00, 0x20, 0x10, 0xe1, 0x0e, 0x00, 0x02,
    0x11, 0xee, 0x00, 0x20, 0x10, 0xe1, 0x0e, 0x00, 0x02, 0x11, 0xee, 0x00, 0x20, 0x10, 0xe1, 0x0e, 0x00, 0x02, 0x11, 0xee,
    0x00, 0x20, 0x10, 0xe1, 0x0e, 0x00, 0x02, 0x11, 0xee, 0x00, 0x20, 0x10, 0xe1, 0x0e, 0x00, 0x02, 0x11, 0xee, 0x00, 0x20,
    0x10, 0xe1, 0x0e, 0x00, 0x02, 0x11, 0xee, 0x00, 0x20, 0x10, 0xe1, 0x0e, 0x00, 0x02, 0x11, 0xee, 0x00, 0x20, 0x10, 0xe1,
    0x0e, 0x00, 0x02, 0x11, 0xee, 0x00, 0x20, 0x10, 0xe1, 0x0e, 0x00, 0x02, 0x11, 0xee, 0x00, 0x20, 0x10, 0xe1, 0x0e, 0x00,
    0x02, 0x11, 0xee, 0x00, 0x20, 0x10, 0xe1, 0x0e, 0x00, 0x02, 0x11, 0xee, 0x00, 0x20, 0x10, 0xe1, 0x0e, 0x00, 0x02, 0x11,
    0xee, 0x00, 0x20, 0x10, 0xe1, 0x0e, 0x00, 0x02, 0x11, 0xee, 0x00, 0x20, 0x10, 0xe1, 0x0e, 0x00, 0x02, 0x11, 0xee, 0x00,
    0x20, 0x10, 0xe1, 0x0e, 0x00, 0x02, 0x11, 0xee, 0x00, 0x20, 0x10, 0xe1, 0x0e, 0x00, 0x02, 0x11, 0xee, 0x00, 0x20, 0x10,
    0xe1, 0x0e, 0x00, 0x02, 0x11, 0xee, 0x00, 0x20, 0x50, 0x72, 0xb8, 0xef, 0x1e, 0x3e, 0x1e, 0xf7, 0xba, 0xde, 0x36, 0x53,
    0xb9, 0x79, 0xe7, 0xad, 0x7c, 0x7c, 0xd8, 0x35, 0xd3, 0x3a, 0x38, 0x66, 0x77, 0x4d, 0xbf, 0xbd, 0xae, 0xff, 0xad, 0xbd,
    0x32, 0xfb, 0xb3, 0x0f, 0xac, 0xaa, 0xb6, 0x37, 0xd7, 0xd0, 0x4c, 0x6a, 0xd1, 0x85, 0xc0, 0x5d, 0xe1, 0xdd, 0xe0, 0x54,
    0xd5, 0x12, 0xc2, 0xf4, 0xad, 0x87, 0xb5, 0x45, 0xc6, 0x44, 0x2b, 0xed, 0xab, 0x1e, 0xfd, 0xbb, 0x33, 0xa4, 0xb8, 0xfb,
    0xe7, 0xd6, 0x53, 0x0d, 0x94, 0x57, 0x7c, 0xc9, 0xba, 0x38, 0x66, 0xd5, 0x93, 0x7b, 0x76, 0x6a, 0xc8, 0x34, 0x40, 0x72,
    0xb8, 0xbf, 0xfc, 0x79, 0x6e, 0x3e, 0x39, 0x6c, 0xce, 0xbd, 0x55, 0xd0, 0x3b, 0xaf, 0x4f, 0x5d, 0xbb, 0x4f, 0x6e, 0x3b,
    0xb3, 0x3f, 0xdf, 0x9e, 0x04, 0xd7, 0xf9, 0xfd, 0xa5, 0x6f, 0xbe, 0x06, 0xcd, 0xb4, 0xbd, 0xb3, 0x17, 0xba, 0xf9, 0xe1,
    0x6d, 0xd8, 0xdb, 0x1f, 0x9b, 0xe6, 0xd3, 0xe0, 0xa4, 0x87, 0xaf, 0x8e, 0xb3, 0x73, 0xb3, 0x45, 0x46, 0xcc, 0x5e, 0xcf,
    0xa4, 0xaa, 0x59, 0x51, 0x4b, 0xb4, 0x8b, 0x7b, 0x73, 0x9e, 0xb8, 0xb2, 0x99, 0x4a, 0xd6, 0xb1, 0x15, 0xab, 0x8b, 0xab,
    0xd3, 0xea, 0xc3, 0xf3, 0xed, 0x5d, 0xcf, 0xf7, 0xea, 0x3a, 0xb8, 0xfe, 0x72, 0xb3, 0xaa, 0x3e, 0x00, 0x0e, 0xd9, 0x86,
    0x65, 0xd6, 0x4f, 0xaf, 0x2d, 0x2f, 0xf7, 0x75, 0x2d, 0xad, 0xda, 0xbe, 0xb7, 0x31, 0x9d, 0xde, 0xbf, 0x34, 0xf3, 0xb4,
    0xfd, 0xea, 0xd6, 0xde, 0x32, 0xd8, 0x55, 0xac, 0xb7, 0x17, 0xfa, 0xb4, 0xae, 0xfe, 0xba, 0x58, 0xe0, 0x40, 0x77, 0xca,
    0xa1, 0xbf, 0x31, 0x19, 0xbb, 0x87, 0xaf, 0x55, 0xa3, 0x3e, 0x3d, 0x6d, 0x36, 0xcd, 0xcb, 0x4e, 0x80, 0x83, 0x48, 0xf7,
    0x66, 0x2f, 0x69, 0xcd, 0xee, 0x72, 0x94, 0x5d, 0x6b, 0xc7, 0x97, 0xc1, 0xae, 0x62, 0xbd, 0x3d, 0xf1, 0x5e, 0x31, 0xc7,
    0xef, 0xf6, 0x00, 0x9d, 0xea, 0xa1, 0xd6, 0xfb, 0xf9, 0xf6, 0xd3, 0xd8, 0x8c, 0x0e, 0x29, 0xed, 0x7e, 0x63, 0x4a, 0xd6,
    0xb3, 0x15, 0x27, 0x76, 0xeb, 0x58, 0xdd, 0x7c, 0x69, 0xfe, 0xc1, 0xdd, 0xdf, 0x50, 0x75, 0xb0, 0xf8, 0xc2, 0xcf, 0x67,
    0xd5, 0x07, 0xc0, 0x69, 0xc2, 0x31, 0xf7, 0xd5, 0xcd, 0x2f, 0xd3, 0xf4, 0x47, 0xe5, 0xad, 0xc3, 0xf6, 0xba, 0x09, 0xf6,
    0xaa, 0xad, 0x3c, 0xb6, 0x6a, 0xf7, 0xd9, 0xa3, 0xdd, 0x6a, 0x02, 0x9d, 0xde, 0xdf, 0xd7, 0x33, 0x0c, 0x36, 0xd2, 0xdd,
    0xcf, 0xef, 0xd5, 0xb2, 0xd7, 0x57, 0x57, 0xd5, 0xef, 0x7e, 0x4d, 0x02, 0x98, 0xaf, 0x0f, 0x3b, 0x37, 0x38, 0x38, 0xc5,
    0xd1, 0xb4, 0x09, 0x76, 0xe7, 0x3e, 0xaf, 0x8a, 0x59, 0xed, 0xf2, 0xe4, 0x2e, 0x71, 0x90, 0xa2, 0x98, 0x9b, 0x05, 0x8e,
    0xc8, 0x68, 0x75, 0x60, 0x4e, 0x28, 0x8e, 0x3c, 0x25, 0x5b, 0x6c, 0x85, 0x6e, 0x1d, 0xdf, 0x7f, 0x5a, 0x5f, 0x70, 0xf6,
    0x59, 0x37, 0x9a, 0xee, 0xd6, 0xd1, 0x6d, 0x47, 0xa8, 0xa9, 0x2f, 0xa8, 0x16, 0x4d, 0x5f, 0xd5, 0xe0, 0xcd, 0x79, 0x72,
    0xbc, 0x6f, 0xaf, 0x9b, 0x98, 0x59, 0x3f, 0x39, 0xfa, 0xf4, 0x4a, 0x19, 0xf1, 0xed, 0x08, 0xf2, 0xba, 0xb8, 0x0c, 0x4a,
    0x77, 0xd5, 0xae, 0xd6, 0x97, 0x17, 0xd5, 0xef, 0x7e, 0x2a, 0x01, 0xae, 0x2e, 0x6e, 0x9a, 0xaf, 0xdf, 0x6f, 0xc2, 0x4b,
    0x61, 0xd2, 0xc4, 0xb3, 0xcf, 0xcf, 0x1e, 0xcd, 0x51, 0x3c, 0xa5, 0x4b, 0x1c, 0xec, 0xac, 0xd9, 0xa7, 0x47, 0xbf, 0xff,
    0x46, 0xee, 0xd3, 0x0f, 0x5f, 0x9a, 0x9e, 0xf1, 0xe8, 0x35, 0xcd, 0x57, 0xb2, 0x66, 0x0c, 0x66, 0xef, 0x0b, 0xfa, 0x3b,
    0xef, 0x74, 0xdb, 0x11, 0x6e, 0xea, 0x70, 0x2f, 0x0c, 0x9d, 0x67, 0x86, 0x53, 0x67, 0xc3, 0xd9, 0x6b, 0xb6, 0x8a, 0x0a,
    0xef, 0x0a, 0xea, 0xfe, 0x5a, 0xd0, 0xc2, 0x4d, 0x02, 0xac, 0xf4, 0xd7, 0x2f, 0x30, 0xdd, 0x75, 0x9a, 0xac, 0x9f, 0xfc,
    0xc7, 0x4b, 0xab, 0x94, 0xdf, 0x7e, 0xfc, 0xc9, 0x4f, 0xf7, 0x8c, 0xc7, 0xd5, 0xc7, 0x9c, 0x25, 0xbb, 0x7a, 0xf7, 0xa1,
    0xf9, 0xb4, 0xaf, 0xa7, 0xf3, 0xae, 0x4e, 0x1d, 0xe9, 0xb6, 0x23, 0xc0, 0x0c, 0xe1, 0x6e, 0x57, 0xd5, 0x94, 0x74, 0x33,
    0x39, 0x93, 0xbf, 0x66, 0x0f, 0x37, 0x52, 0x3d, 0xdc, 0x5e, 0xb6, 0xe9, 0x41, 0xad, 0xa9, 0x17, 0x9b, 0xee, 0x26, 0x4d,
    0x2e, 0x07, 0x8f, 0x68, 0x6a, 0x23, 0x67, 0x49, 0xf7, 0xdd, 0xdf, 0xdf, 0xf5, 0x87, 0x0f, 0xef, 0xe2, 0xeb, 0x82, 0x3e,
    0x10, 0x8d, 0x18, 0xb4, 0xcf, 0x5b, 0xb2, 0xbd, 0x9b, 0xe1, 0x3c, 0x56, 0xaa, 0x93, 0x28, 0xba, 0xed, 0x08, 0x31, 0x4b,
    0xb8, 0x5b, 0xa7, 0x9f, 0x7f, 0x5e, 0xaa, 0x3f, 0xc7, 0x50, 0xb7, 0x3b, 0x9c, 0xbe, 0x3f, 0xa9, 0xfe, 0xcc, 0x4a, 0x1d,
    0x7f, 0xfa, 0xce, 0xd5, 0x55, 0xca, 0x05, 0x66, 0x7b, 0x7b, 0xea, 0xa5, 0xa6, 0x7b, 0xd4, 0x3e, 0xd7, 0xe9, 0x1e, 0x3d,
    0x54, 0x12, 0x2d, 0xe6, 0xa0, 0xe3, 0x72, 0xf6, 0x38, 0x72, 0xd0, 0x3e, 0x6f, 0xc9, 0x9a, 0x21, 0xaf, 0xee, 0x66, 0xe8,
    0x55, 0x54, 0xe7, 0x17, 0x53, 0x76, 0x6e, 0x20, 0xd1, 0x3c, 0xe1, 0x6e, 0x4e, 0x3f, 0xc7, 0xb7, 0xfb, 0xa4, 0xbe, 0xda,
    0x30, 0x7d, 0xfc, 0x71, 0xf6, 0x3b, 0x55, 0x9b, 0x0e, 0x6b, 0x57, 0x8e, 0xa9, 0x75, 0x06, 0xcc, 0x33, 0x24, 0x9d, 0x49,
    0xe4, 0x3e, 0x3f, 0x79, 0x9f, 0x7e, 0x08, 0x0f, 0xb0, 0x7b, 0xf8, 0xd8, 0x5c, 0x55, 0x1f, 0x1a, 0x2b, 0xf2, 0x18, 0x37,
    0x36, 0x93, 0xb1, 0x64, 0xcb, 0xbb, 0xbe, 0xf4, 0x15, 0x24, 0xe7, 0x66, 0xec, 0x77, 0x38, 0xe8, 0xb6, 0x23, 0xd2, 0x4c,
    0xe1, 0xee, 0x57, 0xde, 0x44, 0xe7, 0xb0, 0x7f, 0xfd, 0x75, 0xd2, 0x8e, 0x7b, 0xc1, 0x97, 0xee, 0xe6, 0x52, 0x6a, 0x48,
    0xbb, 0xd2, 0x09, 0x60, 0x4f, 0x6d, 0xc2, 0xe4, 0xd0, 0x87, 0xa4, 0x2d, 0x53, 0xef, 0xf3, 0x30, 0xed, 0xea, 0x51, 0x27,
    0x7b, 0x79, 0x4b, 0xe6, 0xe8, 0x68, 0x2f, 0x58, 0x63, 0x33, 0xc1, 0xa9, 0x9c, 0x52, 0xb2, 0xee, 0xad, 0x28, 0xb2, 0xfa,
    0xa5, 0x77, 0x33, 0xf4, 0x2a, 0x16, 0xdf, 0xac, 0xae, 0x37, 0xd1, 0x6d, 0x47, 0xa8, 0x83, 0x08, 0xf7, 0xc3, 0x60, 0x9a,
    0x52, 0xbb, 0x2f, 0x17, 0x77, 0x29, 0xd5, 0x99, 0x00, 0x43, 0xa7, 0x06, 0x88, 0x15, 0xff, 0x18, 0x53, 0x5b, 0x74, 0xe7,
    0x3d, 0x77, 0xc9, 0x96, 0xc1, 0xee, 0xb9, 0xeb, 0xab, 0xa0, 0x56, 0x71, 0x73, 0x5e, 0x77, 0xf2, 0xe9, 0xb6, 0x23, 0xdc,
    0x41, 0x84, 0x7b, 0xe7, 0xf9, 0x8e, 0x5a, 0x4a, 0xbf, 0x6c, 0x14, 0xf7, 0xf8, 0x69, 0xdc, 0xa5, 0xd4, 0xfe, 0x5e, 0x3e,
    0xe9, 0x3e, 0x92, 0xa3, 0x7a, 0xa8, 0xfb, 0xea, 0x5b, 0x0f, 0x00, 0x45, 0x8a, 0xec, 0xbc, 0xa7, 0x95, 0xac, 0xbd, 0x15,
    0x7a, 0xc0, 0x7f, 0xf0, 0xb1, 0x2f, 0x73, 0x61, 0xb5, 0x44, 0xb7, 0x1d, 0x11, 0xe8, 0xb9, 0xdb, 0x5c, 0xe9, 0xae, 0xba,
    0x6b, 0xa1, 0xd9, 0xae, 0x4e, 0x9f, 0xdb, 0x09, 0xb0, 0xe4, 0x74, 0x9f, 0x78, 0x10, 0x3d, 0x9e, 0xfd, 0x00, 0x50, 0xca,
    0x55, 0x0c, 0xd3, 0x79, 0x1f, 0x7e, 0x08, 0x23, 0x63, 0xc9, 0x5a, 0xab, 0x3f, 0xb8, 0x60, 0xbd, 0x8a, 0x74, 0xdb, 0x11,
    0x67, 0xa6, 0x70, 0xcf, 0x70, 0x35, 0x74, 0x96, 0xab, 0x75, 0xaa, 0x25, 0x99, 0xc4, 0xd0, 0xdd, 0xb5, 0xb0, 0x4e, 0x93,
    0x4a, 0x80, 0x7a, 0xd4, 0xa0, 0x45, 0xbd, 0x35, 0x61, 0x31, 0xe9, 0xae, 0xf6, 0x79, 0xa0, 0x59, 0x87, 0xe8, 0x57, 0x37,
    0xdf, 0x54, 0x3e, 0x26, 0xec, 0x4d, 0xeb, 0x5b, 0x06, 0xc6, 0x66, 0x32, 0x97, 0x6c, 0xf8, 0xea, 0xeb, 0x9b, 0x11, 0xa6,
    0xb9, 0x93, 0x00, 0x62, 0xcd, 0x13, 0xee, 0xaa, 0xf7, 0xeb, 0xea, 0xf5, 0x84, 0xd2, 0x75, 0x7c, 0xd2, 0x64, 0x6c, 0xf7,
    0xc1, 0x3c, 0xdd, 0x35, 0x17, 0x9d, 0x00, 0x03, 0xa2, 0x6e, 0xd1, 0x78, 0x3b, 0x71, 0xfb, 0x5c, 0x6d, 0x7c, 0xe0, 0x39,
    0x4e, 0xb2, 0x0c, 0xb7, 0x60, 0x15, 0x02, 0xc7, 0x66, 0xf2, 0x97, 0xac, 0xa9, 0x6a, 0xcb, 0xa8, 0x0c, 0x58, 0x9a, 0x59,
    0xc2, 0x3d, 0x47, 0xb6, 0x17, 0xbd, 0xea, 0x66, 0xcc, 0x64, 0xc6, 0x74, 0xd7, 0xc3, 0xed, 0x81, 0x27, 0xc4, 0xfa, 0x50,
    0xd0, 0x7d, 0x13, 0x97, 0xa2, 0x86, 0x5b, 0x97, 0x71, 0xc3, 0x7b, 0xcc, 0x3e, 0x9f, 0x3b, 0xdb, 0xb3, 0xb1, 0x2f, 0xac,
    0xf6, 0x9d, 0x15, 0x4e, 0x51, 0xb2, 0xe6, 0xb0, 0xb2, 0x8c, 0xca, 0x80, 0x85, 0x99, 0x21, 0xdc, 0x77, 0x0f, 0x9f, 0xea,
    0x93, 0xd6, 0xd4, 0x31, 0xc3, 0x98, 0x01, 0xd2, 0xf1, 0xac, 0x9b, 0x66, 0xae, 0xef, 0xa2, 0x86, 0xdb, 0x4d, 0x02, 0x78,
    0x8e, 0x61, 0xee, 0x8b, 0xb6, 0x07, 0xcb, 0xa4, 0xfb, 0x40, 0xf7, 0xf2, 0x0d, 0x1e, 0xb1, 0xc9, 0xf6, 0xe4, 0x83, 0xd5,
    0x79, 0xff, 0xfa, 0xbd, 0xfa, 0xd0, 0x36, 0x51, 0xc9, 0xea, 0x59, 0x52, 0xae, 0x1b, 0x00, 0x6e, 0x93, 0x87, 0xbb, 0xf5,
    0x1a, 0xc7, 0x6f, 0xa9, 0xad, 0xde, 0xdc, 0x3a, 0xe0, 0x7d, 0xfb, 0x60, 0xf9, 0x82, 0xda, 0x94, 0xf4, 0xd7, 0x4d, 0x6e,
    0xb3, 0x89, 0xc9, 0x76, 0x13, 0x6f, 0xde, 0xf3, 0x93, 0xa5, 0xa5, 0xbb, 0x79, 0x96, 0xb3, 0xff, 0xbd, 0x9e, 0xe6, 0xb1,
    0xa2, 0x19, 0x2f, 0xfa, 0xa9, 0xab, 0x21, 0x69, 0xe7, 0x83, 0x35, 0xdd, 0x6f, 0x78, 0x7e, 0xae, 0xbf, 0x73, 0xcf, 0x74,
    0x25, 0xab, 0x66, 0x99, 0xf6, 0x6c, 0x14, 0xff, 0xa6, 0x09, 0xc3, 0xbd, 0x7c, 0x04, 0x4f, 0xbf, 0x06, 0xdc, 0xfb, 0x1a,
    0xc7, 0x70, 0xf6, 0xdb, 0x07, 0x4f, 0xba, 0x11, 0xee, 0xf9, 0x0f, 0x25, 0x62, 0xe8, 0x26, 0x57, 0x09, 0xec, 0x8a, 0x06,
    0x8f, 0x3d, 0x2d, 0x2c, 0xdd, 0x4d, 0xbc, 0x57, 0x97, 0x12, 0x3b, 0x07, 0xd5, 0x72, 0x9f, 0xab, 0xeb, 0x89, 0x99, 0x4a,
    0x79, 0x98, 0xf5, 0x78, 0x67, 0x9e, 0xc3, 0x89, 0xe9, 0x37, 0x74, 0x4d, 0x59, 0xb2, 0xa4, 0x3b, 0x26, 0x93, 0x2d, 0xdc,
    0xbb, 0xf7, 0x10, 0xe8, 0x3b, 0x08, 0x06, 0x9f, 0x25, 0x6c, 0x3f, 0xbc, 0x67, 0xe9, 0x74, 0x16, 0xcb, 0xd7, 0x87, 0xab,
    0xb0, 0xe9, 0x2c, 0x54, 0xb7, 0xf7, 0x97, 0xb4, 0x7b, 0xe4, 0xed, 0x74, 0x0f, 0xec, 0x17, 0x46, 0x5c, 0x57, 0xd0, 0xf7,
    0xfd, 0x38, 0x4e, 0xc6, 0xfb, 0x76, 0xc5, 0x1c, 0xaf, 0x49, 0xef, 0x65, 0xdd, 0xb9, 0xd7, 0x5d, 0x41, 0x75, 0x28, 0x2d,
    0xef, 0xe3, 0x9e, 0xe6, 0xc9, 0x04, 0xc7, 0x3e, 0x51, 0x75, 0xab, 0x58, 0x68, 0xae, 0xc3, 0x89, 0x39, 0x86, 0xb5, 0x64,
    0x2a, 0xd9, 0x1e, 0x26, 0xdd, 0xb9, 0xac, 0x8a, 0xbc, 0x92, 0xc3, 0xdd, 0x77, 0xb7, 0x5c, 0xf3, 0xdc, 0x46, 0x6f, 0x93,
    0x8f, 0xbc, 0xd3, 0x4e, 0x2b, 0x5f, 0xd8, 0x6e, 0x1e, 0x64, 0xb1, 0xd5, 0xd7, 0xbb, 0xd2, 0xdb, 0xbb, 0x3e, 0x4d, 0xf7,
    0xf7, 0x0b, 0xcd, 0x3d, 0x7f, 0x31, 0xd7, 0x8c, 0xf5, 0x35, 0xdb, 0x19, 0xde, 0xb0, 0x95, 0x4b, 0xf5, 0x5f, 0x72, 0x98,
    0x88, 0xdf, 0x93, 0x6b, 0xa7, 0x47, 0xa9, 0xeb, 0x56, 0xd6, 0x85, 0xda, 0xf1, 0x6e, 0x8a, 0x71, 0xea, 0x92, 0x35, 0x23,
    0x42, 0x87, 0xf6, 0x30, 0x01, 0x16, 0xee, 0xb8, 0xf8, 0x29, 0x1a, 0x49, 0xfd, 0x0b, 0x00, 0x40, 0x80, 0xe2, 0xfc, 0x76,
    0x86, 0xbb, 0x65, 0x00, 0x00, 0x73, 0x23, 0xdc, 0x01, 0x40, 0x20, 0xc2, 0x1d, 0x00, 0x04, 0x22, 0xdc, 0x01, 0x40, 0x20,
    0xc2, 0x1d, 0x00, 0x04, 0x22, 0xdc, 0x01, 0x40, 0x20, 0xc2, 0x1d, 0x00, 0x04, 0x22, 0xdc, 0x01, 0x40, 0x20, 0xc2, 0x1d,
    0x00, 0x04, 0x22, 0xdc, 0x01, 0x40, 0x20, 0xc2, 0x1d, 0x00, 0x04, 0x22, 0xdc, 0x01, 0x40, 0x20, 0xc2, 0x1d, 0x00, 0x04,
    0x22, 0xdc, 0x01, 0x40, 0x20, 0xc2, 0x1d, 0x00, 0x04, 0x22, 0xdc, 0x01, 0x40, 0x20, 0xc2, 0x1d, 0x00, 0x04, 0x22, 0xdc,
    0x01, 0x40, 0x20, 0xc2, 0x1d, 0x00, 0x04, 0x22, 0xdc, 0x01, 0x40, 0x20, 0xc2, 0x1d, 0x00, 0x04, 0x22, 0xdc, 0x01, 0x40,
    0x20, 0xc2, 0x1d, 0x00, 0x04, 0x22, 0xdc, 0x01, 0x40, 0x20, 0xc2, 0x1d, 0x00, 0x04, 0x22, 0xdc, 0x01, 0x40, 0x20, 0xc2,
    0x1d, 0x00, 0x04, 0x22, 0xdc, 0x01, 0x40, 0x20, 0xc2, 0x1d, 0x00, 0x04, 0x22, 0xdc, 0x01, 0x40, 0x20, 0xc2, 0x1d, 0x00,
    0x04, 0x22, 0xdc, 0x01, 0x40, 0x20, 0xc2, 0x1d, 0x00, 0x04, 0x22, 0xdc, 0x01, 0x40, 0x20, 0xc2, 0x1d, 0x00, 0x04, 0x22,
    0xdc, 0x01, 0x40, 0x20, 0xc2, 0x1d, 0x00, 0x04, 0x22, 0xdc, 0x01, 0x00, 0x00, 0x80, 0xc3, 0x77, 0x74, 0xf4, 0x3f, 0xd5,
    0x2f, 0x26, 0xc4, 0x5f, 0x5c, 0x53, 0x69, 0x00, 0x00, 0x00, 0x00, 0x49, 0x45, 0x4e, 0x44, 0xae, 0x42, 0x60, 0x82, 0xffffffff
};

The function that applies the image (Images.hpp)

(click to show/hide)

#include "ButtonImages.hpp"
void ButtonDectoBin(sf::Texture & texture)
{
    sf::Image img;
    img.loadFromMemory(DtoB, sizeof(DtoB));
    texture.loadFromImage(img);
}

The use of the function:

(click to show/hide)

#include "Images.hpp"

class brain
{
    //This means that the following are accessible by anything
public:
    //I always name textures the same as sprites but with a capital letter (if the name is long, otherwise I just name them (name)sprites and (name)textures)
    //Textures are the image variables stored and displayed by a sprite
    sf::Texture Titlescreen, Menuscreen[2][5], backtextures[6];
    //Sprites are objects that are displayed to the screen
    sf::Sprite titlescreen, menuscreen[2][5], backsprites[70][62], langtonsprite[2], antsprite;

    //These are used for the matrix background
    unsigned char backnumbers[70][62], backID;

    //These are used for the Langton's Ant background
    unsigned char antdir, antx, anty, langtonSpeed;

    bool langtonbools[141][125];

    //This is my titlescreen function, it just displays the titlescreen
    void display_titlescreen(sf::RenderWindow & window);

    //Displays an animated background based on the backgroundID passed to the function
    inline void display_background(sf::RenderWindow & window);

    //Sets the background up to use the desired animation
    void initiate_background(unsigned char backID);

    //My menuscreen function displays the menuscreen, waits for a button to be pressed, then returns a number for which button is pressed
    unsigned char display_menuscreen(sf::RenderWindow & window);
};

unsigned char brain::display_menuscreen(sf::RenderWindow & window)
{
ButtonDectoBin(Menuscreen[0][1]);
}

Hapax: I've tried converting it to unsigned char and that stops most of the Wnarrowing, though it does still display it once per array, but also comes up with large values being truncated (Woverflow)

Jester Juhl: I only turned warnings off because I actually couldn't compile it before because it took far too long to go through all the warnings

Title: Re: sf::Texture load from memory
Post by: Laurent on January 28, 2015, 02:35:06 pm

Anything greater than 0x80 doesn't fit into a signed char, so indeed the type of the array has to be unsigned char[] (or uint8_t[]) if the generator outputs such constants.

As already said, you must also remove the ending 0xffffffff, this should get rid of the truncation warning.

Title: Re: sf::Texture load from memory
Post by: shadowmouse on January 28, 2015, 02:53:46 pm

IT WORKS!!!!!  :)  :)  :)
I turned them all into unsigned chars, I got rid of the 0xfffffff and now it works!!!!

Title: Re: sf::Texture load from memory
Post by: eXpl0it3r on January 28, 2015, 03:23:42 pm

Right, I used sf::Uint8 which is why I never got the errors. Didn't think of that.
Also apparently this is only an "issue" since C++0x/C++11. :)

Title: Re: sf::Texture load from memory
Post by: shadowmouse on January 28, 2015, 03:41:00 pm

So it might be better in c++14? That would be nice, though as far as I know I can only use the version of MinGW that codeblocks was compiled with so I'll have to wait until it is remade.

Title: Re: sf::Texture load from memory
Post by: eXpl0it3r on January 28, 2015, 04:04:18 pm

No, that was meant as, it's only an "issue" start with C++0x/C++11 because of the initializationlists. ;)

Title: Re: sf::Texture load from memory
Post by: lelion on May 21, 2019, 01:34:00 am

Quote from: Laurent on January 15, 2015, 07:55:43 am

static const unsigned char embeddedImageData[] =
{
    /* content generated by one of the hundreds
        of programs that do it, or by your own small utility
       (doesn't take more than 10 lines of C++ code) */
};

texture.loadFromMemory(embeddedImageData, sizeof(embeddedImageData));

Example of code that generate such an array:

#include <fstream>
#include <iomanip>

int main(int argc, char** argv)
{
    std::ifstream in("image.png", std::ios_base::binary);
    std::ofstream out("header.hpp");

    out << "static const unsigned char embeddedImageData[] =" << std::endl;
    out << "{" << std::endl;
    do
    {
        out << "    ";
        for (int i = 0; (i < 20) && in; ++i)
            out << "0x" << std::hex << std::setw(2) << std::setfill('0') << in.get() << std::dec << ", ";
        out << std::endl;
    }
    while (in);
    out << "};" << std::endl;

    return 0;
}
 

Note that it can be more concise if you don't care about the pretty formatting.
(delete last 0xffffffff)

Merci beaucoup Laurent pour ce bou de code,  ca marche a merveille.