I know my so-called "engine" has many flaws but it's just a prototype to just test things out for now. I was going to update them all because I thought I could make it easier if for example I have an InventoryState and then I push it in the vector. That way the animations from the game will still play, but only the Inventory's events will be managed. But again, that's just an "idea".
What you could possibly do instead is add some
pause and
resume functions to your state, and give your states access to your state manager (pass a reference on each function call). What this could allow you to do is check if the newest state is an inventory state (via using
dynamic_cast on it's pointer), and rather that halting the gameplay (which you could do if the state is something else), you could call some special function your inventory state has to pass a reference to your in-game state and have your inventory manually update your in-game state itself, but under special conditions (such as disabling input to your player while in the inventory menu, darkening things around the inventory menu, or whatever).
It's a bit of a "hack", don't recall ever trying it, so I might be missing something.
About the Win32 functions. I think you're referring to the splashscreen class. I found that implementation on google a while ago (not too sure but I guess there was a topic about that on SFML's forum). Basically it allows transparency. Since it's impossible to do that with SFML I only found some solutions using OpenGL and this one that I use.
The win32 API isn't portable. Even if you're only planning on using it on Windows, adjusting something like transparency isn't worth giving up platform-independent code.
I'm not sure exactly what your goals were, but to adjust an image's transparency, use this function (sorry if it doesn't work properly, just quickly wrote it with little testing):
/*
Takes an image and sets it's transparency relative to the parameter "level".
For parameter "level":
0.0f means no transparency, 1.0f means normal transparency, 2.0f means double transparency
This is non-reversible if set to 0. Setting transparency to 0 will make it invisible and will no amount
of multiplication can bring it back.
*/
void setImageTransparancy(sf::Image& image, float level)
{
for (unsigned x = 0; x < image.getSize().x; x++)
{
for (unsigned y = 0; y < image.getSize().y; y++)
{
sf::Color pixel_color = image.getPixel(x, y); //Retrieve the pixel color
float fval = (pixel_color.a / 255.0f); //Convert the 0-255 range integer to a 0-1 range float
fval *= level; //Scale the float alpha with the level
fval = fval < 0.0f ? 0.0f : fval > 1.0f ? 1.0f : fval; //Ensure the new value isn't below 0 or above 1
pixel_color.a = (uint8_t)(fval * 255.0f); //Convert it back to a 0-255 integer and set it as the alpha
image.setPixel(x, y, pixel_color); //Change the pixel to it's new color
}
}
}
However, I'd recommend simply drawing an
sf::RectangleShape and setting it's fill color to whatever transparency you need, as it wont actually change the texture itself.
Also, I don't know why would I prefer the "new" keyword over the "std::make_unique" since that's a nice feature C++14 brings. Maybe I'm missing someting, I will research more about it.
IIRC
std::make_unique can allocate the smart pointer (I believe the reference counter variable, not the smart pointer itself, which is on the stack) and your object in the same allocation, possibly providing better performance. But for small objects, the stack is always the best option. For things like textures, while storing them on the stack is not necessarily a good idea (if it'd even fit), I'm pretty sure SFML allocates it's memory for them on the heap, avoiding this problem.
