Messages

1

Graphics / Re: Screen tearing - forcing vsync (move to the Window section?)

« on: September 11, 2013, 08:33:56 pm »

Ok, thanks for the advice zsbzsb

I'll keep the code to utilise Optimus on Windows anyway, to use stronger GPUs when available.

2

Graphics / Screen tearing - forcing vsync (move to the Window section?)

« on: September 11, 2013, 07:26:00 pm »

Hi, I'm experiencing severe screen tearing in my application.
I've enabled the vertical synchronization with setVerticalSyncEnabled(true) but to no good effect (both on Windows 7 and Ubuntu 12.04).

However, after manually forcing v-sync in nVidia control panel the tearing miraculously disappeared.

Now here's the thing: I have GeForce GT 620M & Intel HD 3000 working in Optimus setup. On Linux I've disabled the nVidia card altogether to save power and on Windows as far I know Intel is still the default one if there's no existing profile for the application.
Forced v-sync works on both GPUs, setVerticalSyncEnabled(true) works on none.

Is there a stronger way to set v-sync programatically?
EDIT3: browsing around, looking for solution, I've established that we're using wglSwapIntervalEXT(1) to enable v-sync in SFML. Why this wouldn't work remains a puzzle to me

And while I'm on it - does anyone know if the solution from http://developer.download.nvidia.com/devzone/devcenter/gamegraphics/files/OptimusRenderingPolicies.pdf to select stronger GPU in Optimus setups works OK with SFML (I'm going to try it out eventually, but perhaps someone has a quick answer)?
EDIT2: Answering myself and anyone interested: yes, it works I ended up with this code:

#ifdef __MINGW32__
#include <windows.h>
extern "C" {
 __declspec(dllexport) DWORD NvOptimusEnablement = 0x00000001;
}
#endif // __MINGW32__
 

Thanks

EDIT: I think this should actually go to the Window section (http://en.sfml-dev.org/forums/index.php?board=6.0), sorry.

3

Graphics / Re: Trouble with multiple shaders/buffers

« on: July 28, 2013, 06:30:32 pm »

Thanks for reply and the OpenGL docs. Indeed, they wrote that:

When performing a rendering operation to images attached to a Framebuffer Object, attempts to access pixels from those images will result in undefined values. Reads from images that are being written to are not coherent.
OpenGL is actually quite strict about this. It states that the value of a texture being accessed is undefined if it is at all theoretically possible for any texture read to access an image that is being written to by the fragment shader. OpenGL is quite conservative about this.

and I cannot help but be amazed, because it worked for me across 3 machines and two OS 

My theory is that, since I always redraw 1:1 in terms of geometry (and use a fragment shader), it coincidentally happens to give correct (at least visually) results.

4

Graphics / Re: Trouble with multiple shaders/buffers

« on: July 28, 2013, 05:41:26 pm »

If buffer2Sprite uses buffer2's texture, then you're trying to draw a texture on itself, which is forbidden.

@Laurent: Is it strictly forbidden? Because I use it quite a lot to save space in postprocessing and didn't have any problems so far. Of course I display() the texture first before I draw it onto itself.

Can it lead to some undefined behavior in the future or on other machines?

5

Graphics / Re: Loading sf::Font from memory doesn't copy the data, why?

« on: July 24, 2013, 04:17:09 pm »

Thanks Laurent, I forgot the sf::Music. With two justified cases it's fine by me   

6

Graphics / Loading sf::Font from memory doesn't copy the data, why?

« on: July 24, 2013, 03:55:49 pm »

Is there a serious reason for not copying the data into sf::Font, like every other resource type does?
Not that it's a major problem, but it feels inconsistent with the rest of the library. With Shader, Texture, SoundBuffer, Music I can just pass the buffer and delete it afterwards.

In the documentation it reads:
Warning: SFML cannot preload all the font data in this function, so the buffer pointed by data has to remain valid as long as the font is used.

Perhaps it could just make a dumb copy of the buffer and store it, so that we could delete the original?