1
General / SFML2: Bundling for linux release
« on: September 26, 2010, 12:51:36 am »
You could use cmake to create static libraries and link against those.
Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
2
General / SFML in Eclipse
« on: November 16, 2009, 06:52:07 pm »
Look under
Project->Properties->C/C++-Build->Settings->GCC C++ Linker->Libraries
I think Eclipse is one of the best IDEs around (and I definitely prefer it over Code::Blocks), so don't give up on it yet.
Project->Properties->C/C++-Build->Settings->GCC C++ Linker->Libraries
I think Eclipse is one of the best IDEs around (and I definitely prefer it over Code::Blocks), so don't give up on it yet.
3
General discussions / Automatic batching in sfml2 branch
« on: October 04, 2009, 01:50:44 pm »
Well, here's the result: it still happens, although it's a lot less noticable than it used to be.
I'm now runnig the latest Ubuntu beta, the graphics card is a nvidia 8800gtx. The driver version is 185.18.36.
Everytime it happens, the cpu usage goes down in the process viewer.
The application now shows up with 64% cpu (I think they changed to relative cpu usage to core usage) usage which drops to ~40% every time it happens (used to show around 15% with drops to 1-2%, this probably explains why its less noticable now). The opengl sample now uses 44% and drops to 30% cpu.
But lets wait if someone else notices the same (and who knows, the problem may disappear before a final 2.0 release
.
I'm now runnig the latest Ubuntu beta, the graphics card is a nvidia 8800gtx. The driver version is 185.18.36.
Everytime it happens, the cpu usage goes down in the process viewer.
The application now shows up with 64% cpu (I think they changed to relative cpu usage to core usage) usage which drops to ~40% every time it happens (used to show around 15% with drops to 1-2%, this probably explains why its less noticable now). The opengl sample now uses 44% and drops to 30% cpu.
But lets wait if someone else notices the same (and who knows, the problem may disappear before a final 2.0 release
.
4
General discussions / Automatic batching in sfml2 branch
« on: October 03, 2009, 10:00:36 pm »
I see. I'm going to make a fresh Linux install.
I'll let you know if it makes any difference (new drivers etc.).
I'll let you know if it makes any difference (new drivers etc.).
5
General discussions / Automatic batching in sfml2 branch
« on: September 27, 2009, 07:15:19 pm »
It only seems to happen on Linux.
I made a Windows build, but I'm unable to reproduce the problem (the hardware is the same).
I made a Windows build, but I'm unable to reproduce the problem (the hardware is the same).
6
General discussions / Automatic batching in sfml2 branch
« on: September 27, 2009, 04:16:04 pm »
Lets take the opengl sample: most of the time the cube rotates smoothly, but sometimes it stops and for a short time, as if it was rendered at a very low framerate (like if you're playing a game that your pc cannot handle, you can actually see the single frames).
7
General discussions / Automatic batching in sfml2 branch
« on: September 27, 2009, 12:43:42 pm »
The FPS are not the problem (I usually cap them and use VSync if possible), but the framedrops definitely are. They occur at random times.
I wonder why it doesn't take full cpu. I know that this could be scheduler related, but it didn't happen witholder revisions.
I noticed that same happens with the example applications (the cpu stays at about 10% on a quad). Although the framedrops are not noticable as they are when scrolling a map, they also occur (this can be noticed best in the opengl sample).
I thought so. There should be a note in the docs or even range checking if the performance penalty isn't too high.
I wonder why it doesn't take full cpu. I know that this could be scheduler related, but it didn't happen witholder revisions.
I noticed that same happens with the example applications (the cpu stays at about 10% on a quad). Although the framedrops are not noticable as they are when scrolling a map, they also occur (this can be noticed best in the opengl sample).
Quote
This part of the code is very critical, and even a slight modification has a huge impact on performances. And in this case, using a fixed-size array is faster than using a dynamic one.
I thought so. There should be a note in the docs or even range checking if the performance penalty isn't too high.
8
General discussions / Automatic batching in sfml2 branch
« on: September 26, 2009, 10:22:28 pm »
Now that I've had some time to test the new revision, I found some problems.
For me, performance has decreased a lot.
FPS have dropped from around ~6900 to ~900 (using the same OpenGL-code) or ~700 (the OpenGl code replaced with RenderQueue-code) when rendering a 2D tilemap + a few sprites.
For some odd reason the cpu usage stays at ~10-15% (instead of 25%), with drops to 1-2% which cause massive framedrops.
Older binaries linked aganst sfml 1.5 still work fine, as the previous revision of sfml2 did.
I've tried a few things like manually using the immediate mode renderer or getting rid of saving and restoring the GL-states.
I really don't know whats causing that slowdown...even if the batch renderer was slower, the GL code shouldn't be affected that much from the changes (I've looked through all files that changed in that revision and couldn't find any hint).
Even profiling with Valgrind gave no results.
Something else:
Why is the stack of render states (myStatesStack) of sf::RenderQueue fixed 16 elements?
It will cause the following code to segfault (I know that it is an artificial test case, but still)
I hope that those initial problems can be sorted out, since I really like the new batch rendering interface.
For me, performance has decreased a lot.
FPS have dropped from around ~6900 to ~900 (using the same OpenGL-code) or ~700 (the OpenGl code replaced with RenderQueue-code) when rendering a 2D tilemap + a few sprites.
For some odd reason the cpu usage stays at ~10-15% (instead of 25%), with drops to 1-2% which cause massive framedrops.
Older binaries linked aganst sfml 1.5 still work fine, as the previous revision of sfml2 did.
I've tried a few things like manually using the immediate mode renderer or getting rid of saving and restoring the GL-states.
I really don't know whats causing that slowdown...even if the batch renderer was slower, the GL code shouldn't be affected that much from the changes (I've looked through all files that changed in that revision and couldn't find any hint).
Even profiling with Valgrind gave no results.
Something else:
Why is the stack of render states (myStatesStack) of sf::RenderQueue fixed 16 elements?
It will cause the following code to segfault (I know that it is an artificial test case, but still)
Code: [Select]
#include <SFML/Graphics.hpp>
#include <iostream>
class TestDrawable : public sf::Drawable
{
public:
TestDrawable(int id) : mId(id)
{
}
void Render(sf::RenderTarget& target, sf::RenderQueue& queue) const
{
std::cout << mId << std::endl;
if (mId < 15)
{
TestDrawable nestedDrawable(mId + 1);
target.Draw(nestedDrawable);
}
}
private:
int mId;
};
int main()
{
sf::RenderWindow window(sf::VideoMode(800, 600, 32), "SFML Window");
TestDrawable test(0);
window.Draw(test);
window.Display();
}I hope that those initial problems can be sorted out, since I really like the new batch rendering interface.
10
Window / Window Icon doesn't show properly
« on: August 20, 2009, 12:27:02 pm »
The following code works:
The memory location of the img_icon isn't the location of the array of pixels.
I don't think that it's a good idea to create a new sf.net project just to upload some files. There are enough other free uploading services available.
Code: [Select]
App.SetIcon( img_icon.GetWidth(), img_icon.GetHeight(), img_icon.GetPixelsPtr());
The memory location of the img_icon isn't the location of the array of pixels.
Quote
I've uploaded the code hier:
http://sfml15-seticont.sourceforge.net
I don't think that it's a good idea to create a new sf.net project just to upload some files. There are enough other free uploading services available.
11
General discussions / Vector2f vs FloatRect
« on: June 24, 2009, 11:21:15 pm »
I'd suggest
IntVector2 / FloatVector2 / IntRectangle / FloatRectangle
I think it fits the SFML naming convention most (like RenderTarget, WindowSettings, VideoMode etc.).
The *f and *i seem stange without a number (like 2f).
What are "Rectanglei" and "Rectanglef"?
If you read
you already know that it is a rectangle of integers;
If you read something like
it would not be that obvious. (I would have to think for a short time if those were simple typedefs or types on their own or whatever...I hope you get what I mean to say.)
Naming the vector typedefs FloatVector2 and IntVector2 would only be consistent. (Even if I like Vector2f, it just doesn't feel right in SFML).
I'd also decide against the short forms "Vec" and "Rect" and go with the full names.
But it's up to you to decide.
IntVector2 / FloatVector2 / IntRectangle / FloatRectangle
I think it fits the SFML naming convention most (like RenderTarget, WindowSettings, VideoMode etc.).
The *f and *i seem stange without a number (like 2f).
What are "Rectanglei" and "Rectanglef"?
If you read
Code: [Select]
IntRectangle Rectangle;
you already know that it is a rectangle of integers;
If you read something like
Code: [Select]
Recti Rectangle;
Rectanglei Rectangle;
it would not be that obvious. (I would have to think for a short time if those were simple typedefs or types on their own or whatever...I hope you get what I mean to say.)
Naming the vector typedefs FloatVector2 and IntVector2 would only be consistent. (Even if I like Vector2f, it just doesn't feel right in SFML).
I'd also decide against the short forms "Vec" and "Rect" and go with the full names.
But it's up to you to decide.
12
Window / Invisable title bar
« on: April 14, 2009, 02:39:30 pm »
It's more likely a bug in the graphics driver, since I don't experience any Compiz/OpenGL/SFML issues.
13
Feature requests / SocketXXX::Receive(Packet&) wait max
« on: February 21, 2009, 10:23:04 am »
There is a "receive-with-timeout" function in the selector tutorial.
Maybe thats what you are looking for.
And its unlikely that you receive a packet unless you send one (sf::SocketTCP::Send(Packet& PacketToSend) sends the packet size before the data).
Maybe thats what you are looking for.
And its unlikely that you receive a packet unless you send one (sf::SocketTCP::Send(Packet& PacketToSend) sends the packet size before the data).
14
General / Trying to center horizontally a String on screen...
« on: February 04, 2009, 09:15:23 pm »
How about
(note the braces)
I don't want to sound rude, but judging from your other threads, maybe you should try to learn at least some basic C++ first (go read a book or something...).
Code: [Select]
textToDisplay.GetCenter()
(note the braces)
I don't want to sound rude, but judging from your other threads, maybe you should try to learn at least some basic C++ first (go read a book or something...).
15
General / Loud Fan Noise When Drawing Sprite
« on: January 06, 2009, 12:24:57 pm »
The examples don't limit the framerate and as a single sprite is almost nothing for a modern GPU, you get a very high framerate that causes your GPU temperature to increase.
To solve the problems, you can try to:
1. set a framerate limit (sf::RenderWindow::SetFramerateLimit)
2. enable vertical synchronization (sf::RenderWindow::UseVerticalSync)
3. write your own framelimiting code (sf::Sleep)
I hope that helps.
To solve the problems, you can try to:
1. set a framerate limit (sf::RenderWindow::SetFramerateLimit)
2. enable vertical synchronization (sf::RenderWindow::UseVerticalSync)
3. write your own framelimiting code (sf::Sleep)
I hope that helps.