Messages

1

General / Re: SFML 2.2 and GLEW

« on: February 10, 2015, 06:07:41 pm »

Cheers people. I had the same problem with SFML 2.2. Adding GLEW_STATIC helped with my x64 build where I need to link glew.lib only. For the x86 one, strangely I need to link glew32.lib AND glew.lib to compile without warnings, yet still have dynamic linkage with GLEW_STATIC (i.e. get missing dll error for glew32.dll on load). I'm still checking my properties to make sure I haven't missed anything. Using MSVC 2010.

2

General discussions / Re: Different implementation for setFramerateLimit

« on: October 07, 2014, 06:27:09 pm »

I have now experimented with this.

Results:

• The MSDN documentation on timerBeginPeriod() and timerEndPeriod() is likely wrong/misleading. These functions should scope the rendering loop (program execution), not the sleep interval, as this much more consistently improves sleep time accuracy, as experimentation shows. Encapsulating Sleep() with these functions also allowed for Sleep() to undersleep, which normally should not happen at all.
• The (Windows Vista and later) desktop is (designed to appear) vertically synced. Swapping buffers (sf::RenderWindow::display()) will show a result only starting after the next v-blank (Definition, Relevancy in OpenGL), so unless you are syncing the point in time that your rendering finishes with the next v-blank, you will drop a frame quite regularly: You are only swapping buffers with the window content, not the screen; you rely on the OS to do the actual swap, and that swap is vertically synced. Trying to time this is by all sane means a pointless effort. Good reads: https://superuser.com/questions/558007/how-does-windows-aero-prevent-screen-tearing and https://answers.microsoft.com/en-us/windows/forum/windows_8-performance/dwm-and-vsync/aec4ef8e-e3ea-4255-a557-640e9c63eccc.
  
  • As a consequence, the best perceived performance and frame stability in windowed mode on Windows is achieved by using the vertical sync extension, all in spite of the resulting perceived input lag.
  • How vertical sync is implemented depends on the system however. My system guarantees 100% CPU usage when using v-sync, as some code spins to check v-blank status. The people who made it didn't know better than us.  There are ways to work that out (kind of).
    
• Improving sync with Sleep() by adding spin-locks may appear to improve perceived performance, and in tests cost ~80ms of spinning per second while rendering at 60Hz. As render time fluctuates however, which it naturally may very well do (especially in dynamic scenes), you will encounter mentioned problem on Windows, when in windowed mode: You are syncing the start of the rendering, not the moment it finishes, and hence frames get dropped entirely, because you might sometimes swap buffers twice between two v-blanks. In fullscreen mode (again, this is all on Windows), it may appear to stabilize the screen tearing line from missing synchronization. This as well, however, may become irrelevant as frame rendering times fluctuate.
• Spin-locking is useful and effective in fullscreen mode when you cannot afford to render extra frames because the GPU happens to be the bottleneck. A big plus would be if you could do some useful work while you need to spin. It is not notably effective otherwise.
• Code to react to long/short sleeping of the sleep-function however can improve framerate-stability reliably by changing the sleep-time given to it. This is neither (too) hard to write, expensive to execute nor difficult to maintain amongst different operating systems, and is the recommended solution from what I have tried. It's also better from a thread-management point of view as your program's CPU-requirements don't fluctuate chaotically. Example. <- This could also be nicely wrapped up in a FramerateTimer class or similar.
  
• The biggest problem in visual quality, when rendering without vertical sync, occurs when two frames which are not one but multiple intervals apart appear right next to each other.
• Assume: You render your scene with an FPS-limit of 90 (11.11ms) to ensure definite fluid motion on your 60Hz (16.66ms) monitor. Although it may fluctuate, it always stays above 60Hz. Frame A is rendered and swapped to the front buffer. As it so happens, a v-blank just occured and then for 11.11ms the upper two thirds of the screen are drawn using frame A. Frame B is then drawn to the lower and upper third, leaving A in the middle. As frame C starts to appear on the screen it draws directly over frame A, which was 22.22ms ago. This is twice as much delay between touching frames than is usually visible, and looks like part of the scene suddenly "jumping" ahead. Had you rendered at exactly 60 FPS, this case wouldn't have happened. A good solution is to target a framerate slightly below screen refresh rate, e.g. 59.7. Then, the tearing line will (ideally) move downwards over the course of some seconds, and not sleeping the correct amount of time won't result in the problem as likely as otherwise.

tl;dr: If a stable framerate matters at all, and your application is windowed, use v-sync, even if it is expensive and introduces input delay. In fullscreen, and when not using v-sync, render as close to slightly below (~ -0.5%) the monitor refresh rate as you can, whereas 1Hz less is better than 10Hz more.

3

General discussions / Re: Different implementation for setFramerateLimit

« on: September 29, 2014, 06:32:31 pm »

Power: Yes. This is a good argument, but only so much for mobile use cases.

Maximization: Yes, obviously. However, if perfect frame times increase perceived product value, spinning does not do nothing. That is all I'm saying. It's not a good solution I agree. I wouldn't have suggested a combination with sleeping if I did. I only set my priorities different than you do, because jitter annoys me, much more so than the idea of having a few % unutilizable cycles on one core.

4

General discussions / Re: Re: SFML 3 - What is your vision?

« on: September 29, 2014, 05:43:27 pm »

code that is depending on a stable FPS

My code does not depend on stable FPS. I do. 

One of the main reasons why sf::sleep is used, is to take away load from the CPU. Suggesting to use a spinlock (which is questionable on its own anyways...) would defeat that purpose.

How does an idle CPU improve the performance of your system? All the threading-mechanisms in the world strive to maximize CPU-usage. The current code even rounds down to nearest millisecond-integer, so you actually render more frames than requested, stressing the graphics card, which is much more susceptible to clocking down at high load/temperature than the CPU is, and that also becomes much more noticable.

The same goes for the Multimedia Timers, what do you do with your thread when waiting for the next timer event? Busy-waiting loop?

This is a GL windowing API. We program highly interactive, highly demanding applications, which are absorbing all of the user's attention. There should be nothing more important than getting that one single application to run well while it is active.

Killing your CPU

Personally, I do not believe in this. If your CPU takes a serious hit in durability from prolonged load, something is wrong.

If there's a better way to implement a frame limiter which takes the load off the CPU

There isn't. This discussion is just about ideology of priority right now, not about scientific determination of the best solution. I might present my solution later. Then you can judge. 

5

General discussions / Re: Re: SFML 3 - What is your vision?

« on: September 29, 2014, 02:43:49 am »

Ever heard of... you know... the master branch of SFML at GitHub?

I might have heard of it. I can't seem to remember? 

The code is better, but for frame timing you should add a spinlock which queries a high precision timer. e.g. sf::sleepSpinMicroseconds(4500) does sf::sleep(4) and then spins till the remaining ~500µs are over. Rather use some cycles for active waiting than not match the requested framerate. Dorky code for a dorky kernel, but it gives better results.

https://github.com/SFML/SFML/blob/master/src/SFML/Window/Window.cpp#L349 Might want to not call sf::sleep() if the argument is <= 0? No time to lose in this case.

@exploiter: Is that how you guys see it? I believe this is important, as I said. Going without v-sync is common, and precise thread-sleeps are a massive programming myth you should not want anyone less than an advanced programmer have to deal with, especially not cross-platform. It's among the top 2 of things I'd expect a GL windowing API to do well, right after getting the rendering to appear on the screen.

6

General discussions / Re: Re: SFML 3 - What is your vision?

« on: September 29, 2014, 12:42:58 am »

Please have a look at the source code

From SFML-2.1\src\SFML\System\Win32\SleepImpl.cpp:

Code: [Select]

#include <SFML/System/Win32/SleepImpl.hpp>
#include <windows.h>


namespace sf
{
namespace priv
{
////////////////////////////////////////////////////////////
void sleepImpl(Time time)
{
    ::Sleep(time.asMilliseconds());
}

} // namespace priv

} // namespace sf
This code relays directly to WinAPI's Sleep-function, which performs a not very accurate sleep.

From SFML-2.1\src\SFML\Window\Window.cpp:

Code: [Select]

void Window::display()
{
    // Display the backbuffer on screen
    if (setActive())
        m_context->display();

    // Limit the framerate if needed
    if (m_frameTimeLimit != Time::Zero)
    {
        sleep(m_frameTimeLimit - m_clock.getElapsedTime());
        m_clock.restart();
    }
}
Here, sf::sleep() is used for simulating delay, relaying to WinAPI Sleep() (in the case of Windows, anyway). The calculation is correct, but the result is fed to a function which can not and will not respect the delay. This reflects what I said. This also reflects what is written in the Tutorial.

7

General discussions / Re: SFML 3 - What is your vision?

« on: September 28, 2014, 07:25:48 pm »

I tried some SDL. I find SFML better for OOP, Documentation and Guides/Tutorials.

2 cents:
- GL core spec should be used by default. Yes I can recompile SFML, but defaults matter. 
- http://www.sfml-dev.org/tutorials/2.0/window-window.php says it uses sf:sleep for managing framerate limit, and that sf:sleep's "resolution depends on the underlying OS, and can be as high as 10 or 15 milliseconds". I find it very important to use the best (most accurate) solution on every OS. i.e. Windows has Multimedia Timers. Using an inaccurate thread-sleep in non-v-synced mode kind of defeats the purpose of a non-v-synced mode (reduced input lag).

Cheers.

8

SFML projects / Re: Volumetric Lighting Experimental Application

« on: April 12, 2014, 06:26:44 pm »

Well strictly speaking it is an exam document and hence any further use would need approval of at least both my examiners.

I don't intend to continue on this specifically. I just fucking hated to see the default distance-lerp-OpenGL-fog in even modern game titles. Just changing the curve from mix() to exp() makes the thing much more authentic, even though your fog is still going to look emissive in dark areas and drastically lessen the visual quality of the scene.

9

SFML projects / Re: Volumetric Lighting Experimental Application

« on: April 12, 2014, 02:46:55 am »

Anti-aliasing is a seperate deal but yeah it should work with a multisampled texture.

Source release mayhaps though it is rather chaotic haha.

Paper is in German so not sure if that will help :p There are papers on this already but mine was to go and benchmark it a bit.

@ unrealistic: Well yea I had to exaggerate to get anything to show up in presentation at all haha. Video beamers are shit :x Trust me in saying you can customize and parametrize the hell out of this to get it fairly realistic or otherwise good-looking.

GPU gems I did read through quite a bit. Picked up some motivation and info from various places.

10

SFML projects / Volumetric Lighting Experimental Application

« on: April 11, 2014, 11:00:54 pm »

Hello,

I finished my B.Sc. in Media IT recently where I wrote an implementation for dynamic volumetric lighting in OpenGL for my thesis. It is mostly fragment shader code Most brain-power went into fragment shader code.

More specifically, this means you want to reflect light from light sources in mid-air because of particles (smoke, fog, dust, etc.) blocking some of the light.

Result and reason was to show it is perfectly ready for use in real-time 3D graphics applications, ranging from 100 (GT540M) to 1200 (GTX640) frames per second in an otherwise basic "rendering engine" (for-loop which renders all VAOs; textured polies with diffuse lighting).

So yeah, just posting some images for motivation. SFML was mostly used for input processing and font rendering (which turned out to be EXTREMELY useful and easy to use! kudos to you!!)

No VL:


With VL:


No VL:


With VL:


No VL:


With VL:


No VL:


With VL:


The In-Program menu which uses font-rendering. You can click and hold, then move mouse up or down to change values:


There are some visible artifacts in some cases, and the shown scenes aren't all polished, but you have many ways to change the way the effect looks and really use it in cool ways.

I think the only feature I ended up #including windows.h for was to check if window was minimized to stop rendering.

All in all a quite demanding project with a load of physics (attenuation, optical depth, rayleigh-scattering) and a nifty algorithmic procedure (interleaved sampling). If images look a bit weird, well there is varying gamma correction since I presented some of these through a beamer.

I learned A TON while doing this, especially because I built this ground up, camera controls, VAO and VBO handling, rendering code and all. Hope you like it and thanks for making SFML!

11

Graphics / Re: Initialize sf::Texture with a GL texture?

« on: January 25, 2014, 12:56:43 am »

blending

Didn't know GL could do this haha. It works perfectly. Thanks!

12

Graphics / Initialize sf::Texture with a GL texture?

« on: January 24, 2014, 06:52:22 pm »

Hello.

Is it possible to init an sf::Texture with a GL texture? I have an advanced OpenGL project and want to add a simple menu over a transparent black rectangle using SFML (mostly because the text rendering functionality spares me a lot of work), so I need to render to texture in my final rendering pass and make an sf::RectangleShape which uses part of that texture for the effect of drawing over it transparently. However, all functions on sf::Texture want to load from file, stream or memory, instead of taking a ready GL texture name/handle.

Is there a way to achieve what I want? Thanks!