performance drop linux vs. vista

[93interactive]

Hello,

i have noticed that on the same machine there is a major difference in drawing performance.

the game is tilebased and in the moment i am blitting tile for tile, but try to only blit tiles that are visible, it does end up with a lot if small blits per redraw.

if i run the game on my notebook under linux, everything is fine, but as soon as i run it on the same notebook under windows vista, its eating away 90% cpu in a stage, where almost no logic takes place (its a simple countdown before the game)

a few ideas came up, how to increase performance, but in the current stage this would be major work, maybe someone here already tried similar and can tell the results:

i have heard, that newer windows (>= vista) do not support opengl well, is there a way to tell sfml (2) which driver to use? (directx)

would it be faster to reduce number of blits by building a huge bitmap with all static tiles blitted on it (would result in a very large bitmap in my case, something around 6000x6000)

is there a way, similar to sdl, to mark images as 'this is something to hold preferable in video ram'?

any other ideas how to optimize such a situation?

[K-Bal]

Have you installed a new driver from your vendor or are you using the windows default driver?

[93interactive]

yes, its a nvidia 8800m with newest drivers, everything else seems to work fine and fast.

[Laurent]

if i run the game on my notebook under linux, everything is fine, but as soon as i run it on the same notebook under windows vista, its eating away 90% cpu in a stage, where almost no logic takes place (its a simple countdown before the game)

Is it just eating more CPU, or is it really slower? If so, can you give some numbers?

i have heard, that newer windows (>= vista) do not support opengl well

Absolutely wrong for Vista

is there a way to tell sfml (2) which driver to use? (directx)

SFML has no DirectX back-end. It would require a major rewrite of the graphics and window modules.

would it be faster to reduce number of blits by building a huge bitmap with all static tiles blitted on it (would result in a very large bitmap in my case, something around 6000x6000)

It would, but the size of images is limited by your graphics card's capabilities. So you wouldn't be able to build 6000x6000 images anyway (it would be more like 1024x1024).

is there a way, similar to sdl, to mark images as 'this is something to hold preferable in video ram'?

SFML uses hardware through OpenGL, nothing is done on software.

any other ideas how to optimize such a situation?

If it's already fast on Linux then maybe the problem is not from SFML?

[Julien_v42]

Just my 2cts...
My own project is tile-based (using code found in old revisions of SFML, so it's made of display lists of quads, OpenGL code), runs with no perceivable differences on Vista vs XP. Haven't tried any Linux box though.

You say you're 'blitting', are you using OpenGL textures on quads or sf::Sprite or ...?

[93interactive]

if i run the game on my notebook under linux, everything is fine, but as soon as i run it on the same notebook under windows vista, its eating away 90% cpu in a stage, where almost no logic takes place (its a simple countdown before the game)

Is it just eating more CPU, or is it really slower? If so, can you give some numbers?

it's eating away more cpu... and therefor drops fps

i just tried the following: i have one level, which runs on 60 fps on linux and with about 40 on windows. in the background there is a particle effect. it does only go through a vector with maybe 100 objects and calls a function that updates position (simple float addition on x+y), then checks if its on screen and draws if so. if i disable this function call, it does run on windows with 60 fps too.

one thing comes up to mind here. for checking if its on screen, i get the current views position and size for every particle, this is maybe a bad idea and i will change this soon, but maybe it is not necessary at all... is sfml checking if the sprite is on screen by itself?

If it's already fast on Linux then maybe the problem is not from SFML?

well, on the starting countdown there is only code for drawing (and updating particle positions), the countdown itself and a sound that is played every second.

[93interactive]

You say you're 'blitting', are you using OpenGL textures on quads or sf::Sprite or ...?

sf::Sprite

[Laurent]

is sfml checking if the sprite is on screen by itself?

No it doesn't.

Would you be able to try the sfml2 branch from SVN? This could be interesting.

[93interactive]

i was using svn2 branch, just updated to the newest svn and now its segfaulting.

unfortunately its not segfaulting when started with gdb (just hangs), so i cant tell you what is happening, it is initializing the screen, but thats it.

i am running it on two different machines, one a notebook with intel graphics, which suffered the glx problems like described in this topic:

http://www.sfml-dev.org/forum/viewtopic.php?t=1426&start=105

now the glx problems are gone, but its segfaulting (on the other machine, nvidia card too)

i know that the intel driver has major problems with opengl 2 (leading to crashes and memory leaks), maybe thats a little hint. can i disable opengl 2 or 3?

[Laurent]

Which revision are you using? I made some updates to the OpenGL contexts code yesterday.

can i disable opengl 2 or 3?

OpenGL 3 is already disabled on Linux, and versions < 3.0 are handled the same way (i.e. there's no difference between 1.x and 2.x when creating the context).

[93interactive]

i think i somehow messed my svn and lib versions up, i now cleanly checked everything out again and made sure, its using the right libraries and now it does not segfault anymore, although the intel version is completely messed up, image loading wise. it loads random images, and it seems really depending on the intel driver. i can take the compiled code including libraries and run it on a non intel system without problem.