A question on whether I can replace SDL with SFML

[jeroen clarysse]

Hi all,

i'm new to SFML, but have quite some experience with SDL, which I use for the software that we program at our faculty of psychology. Since SDL seems to be dying off slowly, and support dwindling with Sam taking a leave, i'm looking for an alternative and SFML seems like a great alternative, especially since its code looks a lot more readable & crossplatform. However there is one issue that is pretty important for me :

I really need to be able to use dual monitors !

in our labs, all machines have 2 monitors, one of which is a 200Hz CRT on which the experiments are run (with human subjects looking at these screens), and the other one is an LCD on which the researcher is following the experiment (debug info, measured analog signals, etc etc, al from within our own software)

what I need to be able to program is :

- the software should use the CRT monitor as a fullscreen display, using hardware acceleration of the video card to quickly display images at speeds up to 5msecs per image (1 image per frame. Although we never do display timings this short, we do want to be able to start & stop a visual stimulus with the greatest timing accuracy possible and the least delay).  


* Can SFML use hardware acceleration ? (note : i'm talking about 2D blitting here)
      * can I use SFML calls to specify the monitor that I want to run on ?


- the software should also be able to draw debug info & visuals on the 2nd LCD monitor. Preferably fullscreen, but this can be just a maximized window too


* can SFML draw on a 2nd monitor ?



- the app is multithreaded.

     
* Is SFML thread safe ?




- i'm experienced with VisualC, not much with mac, but I want to invest time in this and port my application to XCode.

     
* is SFML crossplatform in the above problems ?

many thanks in advance !


(edit : formatting)

[Laurent]

Can SFML use hardware acceleration ? (note : i'm talking about 2D blitting here)

SFML uses hardware acceleration (through OpenGL) but it won't help much if what you do is to transfer pixels to the graphics card.
However I don't know what could make this kind of things faster (except OpenGL's PBOs, which SFML doesn't use).

can I use SFML calls to specify the monitor that I want to run on ?

Nop.

can SFML draw on a 2nd monitor ?

SFML can draw to a second window, which can be moved to a second monitor

Is SFML thread safe ?

You can easily use multiple threads together with SFML. But almost no SFML class is thread-safe itself.

is SFML crossplatform in the above problems ?

Yes.

[jeroen clarysse]

Can SFML use hardware acceleration ? (note : i'm talking about 2D blitting here)

SFML uses hardware acceleration (through OpenGL) but it won't help much if what you do is to transfer pixels to the graphics card.
However I don't know what could make this kind of things faster (except OpenGL's PBOs, which SFML doesn't use).

well, in SDL you can preload an image in VRAM, which is a lot faster to blit to the display then images in ordinary ram. Is this possible in SFML ?

can I use SFML calls to specify the monitor that I want to run on ?

Nop.

but I can use platform API (cocoa on OSX, .NET on windows) to do so ? What happens if I create a fullscreen app on a multimonitor computer ? Which monitor will be chosen ? Randomly ? Always the main monitor ? (where the taskbar/dock resides) ?

[Laurent]

well, in SDL you can preload an image in VRAM, which is a lot faster to blit to the display then images in ordinary ram. Is this possible in SFML ?

Yes of course. I thought you were talking about updating the same image with new piwels, every frame. If you can preload all the images before drawing them, then of course there's no problem with SFML.

but I can use platform API (cocoa on OSX, .NET on windows) to do so ?

Probably. SFML gives access to the internal, OS-specific window handle.

What happens if I create a fullscreen app on a multimonitor computer ?

It will show on the primary monitor.

[Ceylo]

but I can use platform API (cocoa on OSX, .NET on windows) to do so ? What happens if I create a fullscreen app on a multimonitor computer ? Which monitor will be chosen ? Randomly ? Always the main monitor ? (where the taskbar/dock resides) ?

Dunno for Windows. On Mac OS X you can programmatically move the window to any screen, but you'll probably need to resize it too (if the screens resolution isn't the same as for the main screen). And I'm almost sure it's always the main monitor (with the dock) that is chosen by default. Would need to do a quick test to be positive.

[jeroen clarysse]

but I can use platform API (cocoa on OSX, .NET on windows) to do so ? What happens if I create a fullscreen app on a multimonitor computer ? Which monitor will be chosen ? Randomly ? Always the main monitor ? (where the taskbar/dock resides) ?

Dunno for Windows. On Mac OS X you can programmatically move the window to any screen, but you'll probably need to resize it too (if the screens resolution isn't the same as for the main screen). And I'm almost sure it's always the main monitor (with the dock) that is chosen by default. Would need to do a quick test to be positive.

does this affect the blitting speed ? I always thought that fullscreen apps could bypass the doublebuffering that happens when drawing to a window (in OSX at least) ?

Like I said : the main reason for me to use SFML is that it encapsulates OpenGL, which in turn wraps around drivers for the graphics card. Together this gives an API around hardware acceleration (or so I hope)

but you're not sure about this, am i right ?

[Ceylo]

Never tested (performance on different screens), but I don't think so. Also note that I had tested drawing to real fullscreen or drawing in a fullscreen window, and the results were the same. What is going to slow down the rendering is having two monitors connected (and more pixels to render) to the same graphics card, but most probably not moving the window to any of the screens.

And for sure SFML 2D drawing is hardware accelerated, but if you really are in need of rendering performance, you should have a closer look at direct OpenGL programming. SFML is quite simple but has to adapt to many cases, and cannot be as fast (I've no numbers to tell you how much you'd gain though). In the later case you can still use SFML to ease your work though (like loading images).

[jeroen clarysse]

Never tested (performance on different screens), but I don't think so. Also note that I had tested drawing to real fullscreen or drawing in a fullscreen window, and the results were the same. What is going to slow down the rendering is having two monitors connected (and more pixels to render) to the same graphics card, but most probably not moving the window to any of the screens.

And for sure SFML 2D drawing is hardware accelerated, but if you really are in need of rendering performance, you should have a closer look at direct OpenGL programming. SFML is quite simple but has to adapt to many cases, and cannot be as fast (I've no numbers to tell you how much you'd gain though). In the later case you can still use SFML to ease your work though (like loading images).

cool. Thanks for the info. I'm pretty confident that on a modern graphics card 2D blitting, if accelerated and from VRAM, is never a performance issue. Even the smallest GPU has 128MB of VRAM nowadays. (i remember when I had to write version 1.0 of our software 10 years ago, and 16MB of VRAM was very hig end  :shock:  )

i've done extensive testing (in DirectX, via SDL) with an optical sensor attached to a logic analyser, that also could read TTL signals via parallel port, and blitting was always within 1msec, even fullscreen 1280 x 1024). But the effort of coding such stuff on my own was horrible. Since using SDL I never ever want to go back to hand-coding these things, especially since the performance penalty on modern machines is negligible for my purposes.

the only thing that I now still have to be sure of, is that I can drive 2 monitors. Apparently SFML can do it, but some hacking is involved to get the right picture on the right monitor and to simulate true fullscreen behavior. But that's solvable no doubt.

[Hiura]

Apparently SFML can do it, but some hacking is involved to get the right picture on the right monitor and to simulate true fullscreen behavior. But that's solvable no doubt.

To give some precision about fullscreen stuff on Mac OS X.

First, like Ceylo said, windowed or fullscreen rendering should have the same performance. I don't have the reference on hand but Apple says so in its documentation (probably the OpenGL Programming Guide or something like that).

Then, yes, as Ceylo and Laurent also said, SFML 2 will render by default on the primary screen. This is guaranteed. However, to be very accurate the primary is not defined by the dock but by the menu bar. For example if you set up an additional screen on a MacBook you can set it up as primary in the system preference panel (Display>Drag the white bar to the desired physical screen).

Now, if you need to render stuff on the secondary screen or both should not be hard. SFML 2 allows you to create your own customized window (NSWindow or NSView) and use it for SFML rendering. (See sf::Window::Create(handle) in documentation.)

You can very quickly create a NSView and put it in fullscreen with -enterFullScreenMode:withOptions: message. The first argument lets you choose the screen.

This should (never tested) work just fine on OS X 10.6 and you'll need a little trick to make it work on OS X 10.5 (which is explain in the Apple documentation – really no big deal). However, with OS X 10.7 you might have some troubles with fullscreen application : from my experience and a lot of people multiscreen is a MESS with Lion. For example, you cannot use your secondary screen with a fullscreen application. You can find more literature on the web if you want.

Despite that, I think (I'll have to try) default SFML fullscreen windows won't suffer from this lack of flexibility and still allow the users to use all their screens efficiently.

Now you know everything about SFML on Mac.  :wink:

[jeroen clarysse]

awesome. Thanks for the detailed explanation. I assume that the windows side is similar ? With SDL, dual monitor support was less of a hassle in windows than on mac (i never got it working on mac reliably with SDL)

but then again that was DirectX where SetCooperativeMode() could simply be passed a GUID handle to a monitor identifier and be fullscreen on a specific monitor. Doing this once for each monitor got me a dual monitor fullscreen setup with just a few lines of code.

[Ceylo]

Then, yes, as Ceylo and Laurent also said, SFML 2 will render by default on the primary screen. This is guaranteed. However, to be very accurate the primary is not defined by the dock but by the menu bar. For example if you set up an additional screen on a MacBook you can set it up as primary in the system preference panel (Display>Drag the white bar to the desired physical screen).

I don't really understand what you mean.. doesn't the Dock always follow the menu bar when you change its screen?

[Hiura]

Nop. For example if you have setup your dock to be on the left side and the menu bar on your right screen then they are on different screens.

I assume that the windows side is similar ?

There's a lot of W/windows doing around there so just to be sure : you're talking here about Microsoft OS, right ? If so sf::Window::Create(handle) is also available on Windows (and Linux, of course). I'm not a Windows user so I can't tell you how you can do what you want but I'm sure you can.

[slotdev]

Hi

As a one time commercial user of SDL, I can say for sure that SFML is MUCH better than SDL in terms of ease of use.

My games use 2 monitors, running at 1680x1050, doing crazy fullscreen graphics, and I get excellent performance from SFML with this, 60fps isn't a problem. You should be able to get frame rates MUCH higher than this doing more simple stuff. Of course it depends on the hardware.

Setting up the multi monitor stuff is literally this:

Code: [Select]


window1.SetSize(scr1Data.right,scr1Data.bottom);
window1.SetPosition(scr1Data.left,scr1Data.top);
window1.EnableVerticalSync(true); // Sync with monitor refresh rate
window1.Clear(sf::Color::Black);

window2.SetSize(scr2Data.right,scr2Data.bottom);
window2.SetPosition(scr2Data.left,scr2Data.top);
window2.EnableVerticalSync(true); // Sync with monitor refresh rate
window2.Clear(sf::Color::Black);


Then you just specify which monitor to draw your objects to, and that's it.

If you have any specific questions about SDL vs SFML, please ask me, as I know SDL 1.2 and SDL 1.3 very well. I'm a Windows user, not Mac  

Ed[/code]