RenderWindow's .setVerticalSyncEnabled() resets when .create() is called #371

Closed
santiaboy opened this Issue Mar 23, 2013 · 9 comments

Comments

Projects
None yet
9 participants
@santiaboy

Making an options menu I realized .setVerticalSyncEnabled() resets when .create() is called.
I think this may be a bug, because for example setFramerateLimit doesnt reset at all
Below I provide small examples to show what I mean.

this is the code to show setFramerateLimit doesn't reset (to "unlimited" FPS) when create() is called http://codepad.org/XIIt4KkE

This is the code to show that setVerticalSyncEnabled does reset to false if create() is called
http://codepad.org/cyjmnPqH

a simple fix is to set setVerticalSyncEnabled to true, every time you call .create(), like this:

app.create(VideoMode(800, 600, 32), "SFML Test");
app.setVerticalSyncEnabled(true);

@ghost ghost assigned LaurentGomila Mar 23, 2013

@coolhome

This comment has been minimized.

Show comment
Hide comment
@coolhome

coolhome Mar 29, 2013

Actually when you call the create function non of the previous settings are transferred over besides framerate limit. I don't think it's a bug but would defiantly be something worth mentioning in the documents.

The only setter function that doesn't get reset is setFramerateLimit.
The setSize, setTitle, setIcon, setVisible, setVerticalSyncEnabled, setMouseCursorVisible, setKeyRepeatEnabled, setJoystickThreshold, setActive all get reset because they are working directly with m_impl and m_context.

Actually when you call the create function non of the previous settings are transferred over besides framerate limit. I don't think it's a bug but would defiantly be something worth mentioning in the documents.

The only setter function that doesn't get reset is setFramerateLimit.
The setSize, setTitle, setIcon, setVisible, setVerticalSyncEnabled, setMouseCursorVisible, setKeyRepeatEnabled, setJoystickThreshold, setActive all get reset because they are working directly with m_impl and m_context.

@LaurentGomila

This comment has been minimized.

Show comment
Hide comment
Member

LaurentGomila commented Mar 29, 2013

Yep.

@abodelot

This comment has been minimized.

Show comment
Hide comment
@abodelot

abodelot Mar 29, 2013

Contributor

So, instead of simply stating in the documentation that these properties are reset, could they be saved and automatically reapplied after the window (re)creation?

And there's the setPosition property as well.
Saving position would be a useful feature, given the following scenario:

Let's say I want to center my window on the desktop when I create/recreate my render window, for which I need to place the window at a given position.

  • setting the window position doesn't work if applied before the window creation
  • if setPosition is called after, the window is already created, thus the window is visible at its default position for a fraction of seconds, which is not very nice to the eye
Contributor

abodelot commented Mar 29, 2013

So, instead of simply stating in the documentation that these properties are reset, could they be saved and automatically reapplied after the window (re)creation?

And there's the setPosition property as well.
Saving position would be a useful feature, given the following scenario:

Let's say I want to center my window on the desktop when I create/recreate my render window, for which I need to place the window at a given position.

  • setting the window position doesn't work if applied before the window creation
  • if setPosition is called after, the window is already created, thus the window is visible at its default position for a fraction of seconds, which is not very nice to the eye
@santiaboy

This comment has been minimized.

Show comment
Hide comment
@santiaboy

santiaboy Mar 30, 2013

When I created the issue I though that the standard thing was that the settings were transferred, but I only tested with those two, so..my bad :)

More on topic, maybe let the programmer decide? I don't know how difficult is this to code(or if you even want to implement something like this) but creating a funciton propertiesReset(bool) that is enabled to true by default, and if it is set to false all the setSize, setTitle, etc don't reset.

When I created the issue I though that the standard thing was that the settings were transferred, but I only tested with those two, so..my bad :)

More on topic, maybe let the programmer decide? I don't know how difficult is this to code(or if you even want to implement something like this) but creating a funciton propertiesReset(bool) that is enabled to true by default, and if it is set to false all the setSize, setTitle, etc don't reset.

@coolhome

This comment has been minimized.

Show comment
Hide comment
@coolhome

coolhome Apr 3, 2013

I'm willing to push a few commits for reapplying the settings.

I would simple save all settings into properties of the class and reapply on a create. If we do this then we should also have a reset method. The only cons of this is more memory usage and slightly more cpu.

coolhome commented Apr 3, 2013

I'm willing to push a few commits for reapplying the settings.

I would simple save all settings into properties of the class and reapply on a create. If we do this then we should also have a reset method. The only cons of this is more memory usage and slightly more cpu.

@FRex

This comment has been minimized.

Show comment
Hide comment
@FRex

FRex Jul 21, 2013

Contributor

What about just actually removing framerate limit on create() too? Principle of least surprise.. it's a fresh window, everything is reset, the effect would be similar to creating new sf::RenderWindow instance and throwing away the old - 'this is your window, it's in default state, do whatever you please', no wondering if this or that got cached or set to different value or whatnot. This is made into potential trap as it is now if someone turns on vsync on created window that had the limit before(ie switching to fullscreen and vsync from windowed with fps limit).

Contributor

FRex commented Jul 21, 2013

What about just actually removing framerate limit on create() too? Principle of least surprise.. it's a fresh window, everything is reset, the effect would be similar to creating new sf::RenderWindow instance and throwing away the old - 'this is your window, it's in default state, do whatever you please', no wondering if this or that got cached or set to different value or whatnot. This is made into potential trap as it is now if someone turns on vsync on created window that had the limit before(ie switching to fullscreen and vsync from windowed with fps limit).

@Foaly

This comment has been minimized.

Show comment
Hide comment
@Foaly

Foaly Aug 30, 2013

Contributor

I have to agree. It would make a lot of sense, that if you create a new window the old properties are thrown away and you get the default ones.
But the way I see it, especially for game programming, 99% of the time .create() is used to switch between windowed mode and fullscreen (in the running app i.e. not at setup). Of course it's anoying if you then have to reset all the properties. I think for all other cases, if you .create() a window, you'd expect it to be new and set to the default properties.
So I'd say everything should stay as it is, but there should be a method that allows switching to fullscreen mode, without having to recreate the window (as far as I know there is already a method that does that in the implementation for sf::Window, it would just have to be exposed)

Contributor

Foaly commented Aug 30, 2013

I have to agree. It would make a lot of sense, that if you create a new window the old properties are thrown away and you get the default ones.
But the way I see it, especially for game programming, 99% of the time .create() is used to switch between windowed mode and fullscreen (in the running app i.e. not at setup). Of course it's anoying if you then have to reset all the properties. I think for all other cases, if you .create() a window, you'd expect it to be new and set to the default properties.
So I'd say everything should stay as it is, but there should be a method that allows switching to fullscreen mode, without having to recreate the window (as far as I know there is already a method that does that in the implementation for sf::Window, it would just have to be exposed)

@Ixrec

This comment has been minimized.

Show comment
Hide comment
@Ixrec

Ixrec Aug 30, 2013

In my program it so happens that the main thing I have to manually reset after each create() call is my views, so that's (arguably) yet another set of window properties to consider here.

Would it even be possible to have a recreate()/changeMode()/whatever function that preserves views (which may involve automatically scaling the viewports) as well as all the obvious window properties?

Ixrec commented Aug 30, 2013

In my program it so happens that the main thing I have to manually reset after each create() call is my views, so that's (arguably) yet another set of window properties to consider here.

Would it even be possible to have a recreate()/changeMode()/whatever function that preserves views (which may involve automatically scaling the viewports) as well as all the obvious window properties?

@retep998

This comment has been minimized.

Show comment
Hide comment
@retep998

retep998 Aug 31, 2013

I would totally love a way to change the video mode and toggle between fullscreen and windowed without recreating the entire thing.

I would totally love a way to change the video mode and toggle between fullscreen and windowed without recreating the entire thing.

@Bromeon Bromeon modified the milestones: 2.2, 2.x Mar 18, 2014

@Bromeon Bromeon assigned Bromeon and unassigned LaurentGomila Mar 18, 2014

@Bromeon Bromeon added the resolved label Apr 6, 2014

@Bromeon Bromeon closed this in 18bbd23 Apr 6, 2014

MarioLiebisch added a commit to MarioLiebisch/SFML that referenced this issue Apr 15, 2014

jcowgill added a commit to jcowgill/SFML that referenced this issue Sep 22, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment