Messages

46

Feature requests / Double Precision

« on: February 04, 2011, 11:58:47 pm »

(there's a bug with the high-performance timer on Windows with certain configurations)

Sorry what bug?

What's not reliable is a call to sf::Sleep (in case that's what you want to use).

I definitely need Sleep to be as precise as it could get.

I’m having a hard time synchronizing video playback, if there is something unreliable regarding timing, it would make my like much more healthy, because so far, I feel like I’m taking crazy pills.

I made a little test whish almost gave me an heart attack! l_time doesn’t return 0 but ~2 sec… whish doesn’t make any sense.

Code: [Select]

sf::Clock l_clock;
l_clock.Reset();
Float l_time = l_clock.GetElapsedTime();
 :shock:

47

Feature requests / Double Precision

« on: February 04, 2011, 10:55:59 pm »

Nothing prevents you from displaying 29.97 frames per second.

This is mind boggling, AFAIK, when playing video, there is no point exceeding the display calls higher than the monitor refresh rate. I’m also guessing when precision is a must, v-synch should be disable. Otherwise, Swapping buffers will have to wait until the next monitor refresh, even if a frame is ready to display. Thus, adding delay.

I wouldn't rely on SetFramerateLimit for video playback timing. It's far from accurate.

Is GetFrameTime reliable?

Milliseconds precision would be nice indeed!  

48

Feature requests / Double Precision

« on: February 04, 2011, 10:21:39 pm »

Your assuming I’m making a real-time application and you are partially right but, regarding video playback, with this kind of latency, a movie will be 1.8 sec late after playing for a minute. Its seams picky but it’s a huge gap.  

49

Feature requests / Double Precision

« on: February 04, 2011, 09:37:15 pm »

NTSC for instance requires 29.97 frame per seconds.

50

Feature requests / Double Precision

« on: February 04, 2011, 06:45:20 pm »

While you’re at it, Window::SetFramerateLimit should take a real number or micro sec precision, add GetFramerateLimit() would also be useful.

let us know if you made the changes.

51

Feature requests / Double Precision

« on: February 04, 2011, 06:37:07 pm »

even better, go for it!

52

Feature requests / Double Precision

« on: February 04, 2011, 06:16:10 pm »

Hi Laurent,

Would it be possible to convert any reference to time like Clock::GetElapseTime and sf::Sleep from float to double?

53

Feature requests / provide x64 external libs

« on: February 04, 2011, 04:21:35 pm »

Good, let us know when it is ready?

54

Window / Optimizing Window->Display() - SwapBuffers

« on: February 04, 2011, 06:01:48 am »

Greetings,

To make a long story short, I’m working on a video player using SFML and I found what appears to be the bottle neck of rendering HD video. So far, I found that the problem reside within Swapping OpenGL buffers.

My application does its work on time, no delay, without using Window->Display(). But when turned on, I’m getting about 10%-30% latency when playing 1080p video, which is unacceptable. I’ve tried about any combinations of Window->EnableVerticalSync() and Window->SetFramerateLimit():

EnableVerticalSync(true) and SetFramerateLimit(30): (60hz LCD monitor) seams to give de best result. Playing fullscreen also helps. But still need optimization.

My first concern is the OpenGL context. ContextSettings offers very limited tweaking and I’m wondering what’s under the hood. Maybe someone can help clear a few questions:

How can we turn off double buffering?

How is the SwapBuffers handled? Are the buffers being swap or the back buffer is being copied to the front buffer? I’d like to test which one offers the best performance. (In Windows, this means setting the dwFlags in the PIXELFORMATDESCRIPTOR to PFD_SWAP_COPY.) I’m guessing it is a copy because playing 720p is very smooth.

Is there a way to optimize and/or synchronize the SwapBuffers to get minimal pipe blocking?

EDIT: Using SFML 2.0 on windows 7 x64 + GForce 8800

Thx,

55

Feature requests / provide x64 external libs

« on: February 03, 2011, 07:13:09 pm »

Hi, it would be great to have the same setup for x64 that we already have for x86. Having to compiling dependency libraries is quite annoying.

56

Feature requests / Support for portable device?

« on: January 16, 2011, 08:54:44 pm »

I read there is a way to compile C++ API for Android, but that will have to be confirmed. In any case, It would be very awesome to port SFML for mobiles.

57

Feature requests / Support for portable device?

« on: January 15, 2011, 07:09:29 pm »

Hi, is there in plans to support SFML on portable OS like Android?

58

Feature requests / Enabling/Disabling config file

« on: December 03, 2010, 11:55:52 pm »

You mean that the "native" pixel format on the GPU is BGR? How do you know that?

Storing 8-bit textures in a BGRA layout in system memory and use the GL_BGRA as the external format for textures to avoid swizzling.

http://http.download.nvidia.com/developer/Papers/2005/Fast_Texture_Transfers/Fast_Texture_Transfers.pdf

But anyway, here I'm first interested about the differences between SFML 1 and SFML 2, not general optimizations.

Well, keep that in mind then because this kind of optimization will make SFML from great to kickass.

59

Feature requests / Enabling/Disabling config file

« on: December 03, 2010, 06:16:02 pm »

I also suspect that RGB format takes a significant amount of process... BGR should be used to avoid unnecessary swizzling on the GPU.

60

Feature requests / Enabling/Disabling config file

« on: December 03, 2010, 07:03:39 am »

Alright, never mind the last post I got it to work... unfortunately, the frame rate with 1080p is unusable… I’m back to square one.