Move Window BEFORE Appearing

[Tenry]

Why can't I move the window before it appears on the screen? I'd like to create a window being at a certain position, but when creating the window it is centered first. When using SetPosition() immetiately after creating I still might see flashing the window on the screen center for a very short moment. That is annoying.

I don't want to use WinAPI or something to create the window at the prefered position.

So, what's about the feature either to choose window position on creating function or creating window hidden first to move it somewhere for example?

[Nexus]

I would find it comfortable to specify whether the sf::Window is initially hidden. This covers also the case where the programmer wants to create windows that are invisible at startup.

This could be either achieved through a default parameter in the constructor and Create(), or a Create() call paying attention to parameters that have been set in advance. I prefer the first option, since 1. it's more intuitive when Create() completely overwrites the current state, and 2. it avoids the need to default-initialize the window just to set one parameter and call Create().

[Laurent]

It could be interesting, I'll think about it. Thanks for your feedback.

[Tenry]

I think it's also quite easy to implement as looking in the source in the Win32 part.

[Laurent]

Nothing is really hard to implement in SFML

[Tenry]

Nothing is really hard to implement in SFML

Nothing? So what's about 8-bit sprites, sprites having palettes so that I can switch between them easily without needing much memory?

I was planning a game with a different library using some of those sprites, and now I found SFML. But it doesn't seem to have such a feature.

[Nexus]

Nothing is really hard to implement in SFML

Nothing? So what's about ...

The difficulty of a feature implementation is rarely the decisive factor when it comes to the choice of providing a new functionality or not. Much more important are points like: How many users really benefit from the feature, how well it integrates into the rest of the library, whether it is beyond the scope of a basic multimedia framework, and so on.

In summary: Don't add a feature only because it's easy to add.

... 8-bit sprites, sprites having palettes so that I can switch between them easily without needing much memory?

Can't you achieve this with sf::Image? Switching an image referenced by a sprite is very efficient, if it already exists.

[Laurent]

Nothing? So what's about 8-bit sprites, sprites having palettes so that I can switch between them easily without needing much memory?

SFML doesn't support 8-bits images with palettes, but it has nothing to do with the difficulty of implementing it.

Do you really need this feature? I think it was good 20 years ago when video memory was counted in KB, but now with the gigabytes of memory available, who cares?

[Tenry]

Do you really need this feature? I think it was good 20 years ago when video memory was counted in KB, but now with the gigabytes of memory available, who cares?

I just really like it  :roll:

[Laurent]

Ok, but you can achieve the same effect with sf::Image and a little bit more coding.

[_LB]

It's been four years. I'm looking at SFML 2.2 and I don't see a way to create a window initially hidden - am I missing the obvious? Surely it got added years ago?

[zsbzsb]

It's been four years. I'm looking at SFML 2.2 and I don't see a way to create a window initially hidden - am I missing the obvious? Surely it got added years ago?

Still does not exist and is not really high on the feature list. Feel free however to investigate it yourself 

[Mario]

Not sure it's that easy to be done, but I wouldn't call this complicated either.

How about a flag "sf::Style::Hidden"? There'd have to be some way to make it visible again though. Or just some "SetVisible()"? There are some discussions to allow minimizing/maximizing/restoring windows, so all these things might fit into the same general topic.

[eXpl0it3r]

I don't know exactly where, but we've already had this discussion of changing how window "states" and window "styles" are managed. Though that would probably be API breaking...

[Mario]

Yeah, it was a discussion about styles being something static that won't change at "runtime" (or more specific after window creation) and states that could change without recreating the window. Not sure where it's been either though.