SFML community forums
Bindings - other languages => DotNet => Topic started by: NinjaFighter on May 23, 2012, 06:05:22 am
-
I have updated my own engine implementation to the new SFML2 RC, and I figured that runs a bit slow for me. :(
I had a game prototype that was running at 150 fps, and now with the new implementation (without change the way) I have 60 ~ 70 fps. :-\
If I turn on Vsync, my game looks very bad because cannot keep 60 fps. :-\
I see that the bottleneck is when I render my textures, so, there's not a logic problem.
Any suggestion?
-
It's hard to suggest anything without knowing what you do in your code :)
-
I'm trying to figure where's the bottleneck. I started a single project for each version, to trying focus on the problem, but drawing single sprites with shaders have the same results in fps. I'm a little confused :P.. the old version works very fast with my game, but this new does not, however, on the other hand... the two minimal testing project have very accuracy results ???
I will continue trying, I hope to have something soon.
-
I have a lot of questions about the new version:
1) What's the optimal way to do SetPixel and GetPixel from a Texture? (in the previous versions I only use "Images" (there's no Textures), and for create some basic images, I use SetPixel method)
2) How I must use Texture.Bind method? Why the old version doesn't have this method and draw faster anyway?
3) I notice that if I use "Texture.Bind" on every image that I load, these images may sometimes overrides my RenderTextures. Is it ok?
-
1) What's the optimal way to do SetPixel and GetPixel from a Texture? (in the previous versions I only use "Images" (there's no Textures), and for create some basic images, I use SetPixel method)
setPixel is slow and shouldn't be used extensivly.
The fastest method would be, as Laurent has been writing all over the forum, using your own pixel array and call the update(...) function on a texture.
2) How I must use Texture.Bind method? Why the old version doesn't have this method and draw faster anyway?
3) I notice that if I use "Texture.Bind" on every image that I load, these images may sometimes overrides my RenderTextures. Is it ok?
Do you even know what this method does and why and when you should call it? Or do you just call it at random?
-
1) If you're updating the texture continuously, then use the method described by eXpl0it3r. Otherwise, if it's only at load time, use whatever you want (like an Image instance) and load the texture from that.
2) and 3) Bind has always existed, you don't need it more now than you needed it before; read the documentation carefully :)
-
I know that SetPixel is slow, but I only use it at load time, to make some small basic default textures.
I'm testing a lot of things and I can not found the bottleneck :-\, but I know that exists, because the same game runs slower with the new version.
I will no rest, until I find the answer! >:(
I will keep you informed if I found something relevant.
-
I'm testing a lot of things and I can not found the bottleneck :-\
Just run a profiler and you'll have you're answer asap... ;)
-
I don't have a profiler in my visual studio express :'(
But I think I can found this... I keep trying... now I have some theories that can explain this, but I'm testing it.
-
There are any way to know the amount of texture memory that I have used?
-
There are any way to know the amount of texture memory that I have used?
Yes: counting the total number of pixels that you put in sf::Texture :)
-
I think I found a strange behaviour here, when I was trying to find my bottleneck:
using System;using SFML.Window;using SFML.Graphics;using System.Diagnostics;namespace SFMLImplementation
{ public static class SFMLSpeedTest
{ public static void Start
() { RenderWindow app
= new RenderWindow
(VideoMode
.DesktopMode,
""); RenderTexture surface
= new RenderTexture
(640,
480); app
.Closed += OnAppClosed
; Stopwatch timer
= new Stopwatch
(); timer
.Start(); int updateCount
= 0; Texture img
= new Texture
("sprite.png"); Texture img2
= new Texture
("sprite2.png"); Sprite spr
= new Sprite
(img
); while(app
.IsOpen()) { app
.DispatchEvents(); #region DRAWING IMAGES surface
.Clear(); for(int i
= 0; i
< 3000; i
++) { if(i
% 2 == 0) { spr
.Texture = img
; spr
.Rotation = 45f
; spr
.Position = new Vector2f
(100,
100); spr
.Scale = new Vector2f
(2f, 2f
); surface
.Draw(spr
); } else { spr
.Texture = img2
; spr
.Rotation = 0f
; spr
.Position = new Vector2f
(0,
0); spr
.Scale = new Vector2f
(1f, 1f
); surface
.Draw(spr
); } } surface
.Display(); spr
.Position = new Vector2f
(); spr
.Rotation = 0f
; spr
.Scale = new Vector2f
(1f, 1f
); spr
.Texture = surface
.Texture; app
.Draw(spr
); #endregion app
.Display(); updateCount
++; if(timer
.ElapsedMilliseconds > 1000) { app
.SetTitle("FPS: " + updateCount
); timer
.Restart(); updateCount
= 0; } } img
.Dispose(); img2
.Dispose(); app
.Dispose(); return; } static void OnAppClosed
(object sender, EventArgs e
) { Window app
= sender
as Window
; app
.Close(); } }}
I think the img2 must be visible, but in this case, does not? ???
I don't know if I discovered something here or it was a fallen asleep... I think can be both things :P
-
I don't know if it has something to do with your problems, but... when you change the texture of a sprite, if the new texture has a different size than the previous one, you must adjust the TextureRect too.
And you shouldn't create non-fullscreen windows that have the same size as the desktop: with the decorations added, the window will be bigger than the screen, and some OSes (at least Windows) don't like that.
-
Ok, I never use this manner, it's only because I'm testing.
Related to sprite, I must say that these two images ("sprite.png" and "sprite2.png") have the same exact size.
If you test this code... how many images do you see?
Edit: I must say too, that in an old version of SFML2, I can see the TWO images, and in the new version, only render one of them. This is not what I was searching for, but I think that is worthy of mention.
-
Ok, I figured what is the problem... it's because what you say about the rectangle. It's not a strange behaviour, it's a mine nonsense. Sorry ;D
(the surface was drawing with the image source rectangle)
-
I don't have a profiler in my visual studio express :'(
Hmmm is there a profiler in Visual Studio? I'm using the Ultimate version although I don't really use its power. For profiling there are free options, like the AMD CodeAnalyst Performance Analyzer (http://developer.amd.com/tools/CodeAnalyst/Pages/default.aspx).
Although it's from AMD for AMD chipsets it also works fine on intel proccessor. ;)
-
Actually, I can said that I see some tiny perfomance differences between my SFML2 versions: one of them is that sets window's maximum fps works better than vsync in the new version. For example, I have a Game running at 100~120 fps, I notice that if I activate vsync, the movement looks very bad, otherwise, if I set maximun fps, it looks much better, but if I count the real frames per second, I notice that stuck at 61~63, but not 60. (instead of, the old version works better with vsync, instead limit the fps up to 60)
Another strange thing that I have figured, is the sound of my video card fan cooler, seems like the new version, doesn't overheat mi videocard, but in my game, works more slow in certain circumstances.
I found my bottleneck, but I don't know what is the reason of this slowdown. I write various minimal tests, but I could never show a slowdown, even... the new version works faster on minimal repetitive codes.
Anyway, it's been four days that I cannot figure how to show us,( in a minimal code) that the new SFML works more slow in my game, but for some strange reason, only in my game, and not in my minimal tests =S
I only want to say, that is when (in my game), I set a shader and draw sprites in a surface with it. There's no "bad practices" in my code, I repeat that my game works perfect on olds versions of SFML2. I'm very frustrated now :-\
If you can figure a theory that can explain what can be, please tell me, because I'm very confused, and I cannot figure how to fix it.
-
Upload the source code if it's not gigantic - I'd like to take a look at it
-
It's gigant, believe me ;D
Anyway, I figure that I can live with that, however... if I deactivate vsync on window mode, the framerate don't suffer too much, and I think that my videocard be grateful, because I can't listen my fan cooler with this new version... I can modify the matrix too, a and draw with vertex. I hope I can find the answer someday, but at least, the performance is ok for my game if I use a fps limit, instead of vsync on window mode.