Messages

1306

SFML projects / Re: TGUI: a c++ GUI for SFML (with Form Builder)

« on: June 29, 2012, 01:40:56 am »

The GUI looks nice and the code is easy to understand.

I tested SFGUI and TGUI.
On my Windows 7 PC (30% lesser CPU usage then SFGUI? -> Without the sf::sleep(sf::milliseconds(100)); in TGUI Loop).

Why this? is SFGUI to complex? Or because of RenderWindow slower? Or just my imagination?

On the contrary. You see more CPU usage with SFGUI because indeed more CPU time is being used because we optimized the library to the point where we offload certain portions of the processing from the GPU to the CPU and therefore the CPU and GPU times are equal. Search for my many other posts and you will see my statements about how SFML is bottlenecked by GPU processing power and bus transfer bandwidth. We eliminate this in SFGUI and so the application will pump out more frames per second but also make more use of the CPU which is expected. You can test this by observing the framerate of your test benchmark for both libraries.

It might be possible that at a lower widget count the overhead that SFGUI is associated with won't make it worth using, however it is amortized at higher, more typical widget counts which is what we optimized for.

1307

Window / Re: FPS are falling down

« on: June 27, 2012, 12:10:30 pm »

sf::String and sf::Text contain STL containers which make use of the standard new allocator. If you declare those variables in the scope of the while loop you are constantly allocating and freeing memory every frame. Depending on how the OS allocator works this can be stable even after a long time or it can miserably fail due to memory fragmentation which is likely in your case. This is the main reason why all those big name games often make use of memory pools. The standard allocators were not made for such aggressive allocation schemes like is needed in many applications nowadays.

If you were to move the declaration of those 2 variables outside of the while loop you would limit the execution of the loop body to only making use of the stack (ignoring the clock.getElapsedTime().asMicroseconds() because there is no way to avoid that). That should theoretically increase the short-term and long-term performance.

It's not required if object that I create with new is used to the end. It isn't memory leak. All allocated memory is freed automatically when application is closed.
If I lose last pointer to the object then it's memory leak.

Turn off the virtual memory manager of your operating system and eventually it will leak to death. It is true that this practice is rooted back in the days of real-mode operating systems, however it is still considered good programming practice to free everything anyways. It is technically considered a leak even if the operating system frees it at the end of execution and any leak tracer like valgrind will report it as such.

1308

General / Re: Cannot add text to window

« on: June 23, 2012, 07:29:44 pm »

Try putting

sf::Font font;
font.loadFromFile("arial.ttf");
sf::Text text("Crystallibrium", font, 50);

inside your main().

Calling class methods ( font.loadFromFile(...) ) in global scope is illegal C++ at least in some languages (Visual C++ always manages to prove me wrong).

1309

SFML projects / Re: SFGUI

« on: June 12, 2012, 05:14:46 pm »

Hi guys,

How do you load a *.theme file? I noticed the entire GUI looks Steam by default 

After reading the documentation and the samples, i guess it would be something like this :

sfg::Context::Get().GetEngine().LoadThemeFromFile("/path/to/your/file");

That would only apply the theme to the context active at that point in time. If you use sfg::Desktop(s) you might have multiple contexts, in which case you would use m_desktop.LoadThemeFromFile( "/path/to/your/file" ); just like in the example eXpl0it3r provided a link to (it isn't really an example, more a test bench).

Btw, i was wondering, have you got any idea about the release date of the new engine ? BREW is efficient but i had like to customize the differents widgets with images.

Bob as it is known is being developed by Iteem. If you want more info or just want to motivate him to work harder you can drop by IRC. With Bob it is possible to theme widgets using images as you have mentioned. Iteem ran into difficulties continuing development after we made the switch to VBO-based rendering. Further he had real-life obligations that prevented him from having much free time right after we made the switch so Bob has been hanging in the air since.

You're doing a great and useful job guys, keep it up

Nice to know another person who uses the library. We should have a guestbook-like feature somewhere but Tank is reluctant to make unneeded changes to the website .

1310

General discussions / Re: Broken stuff

« on: May 11, 2012, 01:16:42 am »

So.... after reviewing the commits from the last month I didn't notice glDeleteRenderbuffersEXT getting fixed.. and did you get around to test it on your AMD card?

1311

General discussions / Re: SFML 2.0 Disable Screensaver

« on: April 17, 2012, 09:18:01 pm »

Windows: SetThreadExecutionState()
Linux: XResetScreenSaver()
Mac OS X: UpdateSystemActivity()

1312

General discussions / Re: sf::Thread and know if it's running?

« on: April 17, 2012, 11:22:08 am »

It doesn't make a variable thread-safe, but it is not completely useless.

You are correct. It is not useless. It is in fact far worse, counter-productive.

If one thread only reads a value while the other writes it, volatile will be required so that the compiler doesn't optimize away the read operations in the first thread -- because it wrongly thinks that the variable never changes.

Citing from http://kernel.org/doc/Documentation/volatile-considered-harmful.txt:

The key point to understand with regard to volatile is that its purpose is to suppress optimization, which is almost never what one really wants to do.

Consider a typical block of kernel code:

    spin_lock(&the_lock);
    do_something_on(&shared_data);
    do_something_else_with(&shared_data);
    spin_unlock(&the_lock);

If all the code follows the locking rules, the value of shared_data cannot change unexpectedly while the_lock is held.  Any other code which might want to play with that data will be waiting on the lock.  The spinlock primitives act as memory barriers - they are explicitly written to do so - meaning that data accesses will not be optimized across them.  So the compiler might think it knows what will be in shared_data, but the spin_lock() call, since it acts as a memory barrier, will force it to forget anything it knows.  There will be no optimization problems with accesses to that data.

Moral of the story? Proper usage of synchronization objects almost always takes care of compiler optimization issues without completely suppressing all forms of optimization.

If anyone thinks they can be lazy and just toss in a volatile keyword without proper synchronization to take care of strange multi-threading behavior: You are playing a very dangerous game.

And for those of you who wondered, I was interested and had time on my hands so I did read all the web references in the article Tank mentioned.

1313

General discussions / Re: GLEW and not exporting the GLEW symbols in SFML

« on: April 16, 2012, 08:30:02 pm »

Like I said, marking exported symbols is mandatory on Windows. So I've just implemented the same feature on Linux and OS X. So actually it now works consistently across compilers.

Please tell me you are not trying to duplicate the quirks of Windows on Linux . And I think you meant operating systems and not compilers . The fact that exported symbols have to be explicitly marked in Windows is already annoying enough. If you ask me it's much simpler the Linux way and keeping things "consistent" with Windows is a bad idea. They are the ones who follow the standards the least anyway.

And I still don't know how this thing relates to the initial problem. It's about shared SFML libs on Unix, whereas Mars_999 was talking about static libs and GLEW on Windows

Actually it has very little if anything at all to do with the initial problem . It was somewhat of a false deduction we made when trying to figure out why using GLEW in specific configurations didn't work. When I posted about it on SFGUI forums I was too lazy to dig out the logs again and was just recalling from memory. Now I have determined that the reason we don't use GLEW is because as you already stated using SFML as a static library and any other library (that also links to GLEW statically) as a dynamic library fails. Because this wasn't an option for us we opted to use GLee.

1314

General discussions / Re: GLEW and not exporting the GLEW symbols in SFML

« on: April 16, 2012, 07:54:26 pm »

And what exactly does this thing break? It just fills the hole that was behind the SFML_XXX_API macro on Linux (the Windows equivalent is mandatory, at least for VC++).

I still don't get your point. I don't have a lot of time to waste in philosophical discussions (although I'd truly like to), so please just say what you want to say -- simple and fast: what's wrong with this visibility thing?

Quite simply, it isn't supported on all compilers and if some compilers/versions export everything then you might as well export everything on all compilers. I also don't regard this is an optimization regarding performance (if it wasn't regarding performance then I didn't get the point obviously) because it is just supposed to speed up loading the shared object because of a reduction of the symbol table. Maybe this makes up for a not even noticeable speedup during the initial loading of the library but this gain gets amortized during runtime anyway. And yes I did read that GCC article and most of the points covered there cannot be applied to SFML IMHO.

1315

General discussions / Re: GLEW and not exporting the GLEW symbols in SFML

« on: April 16, 2012, 02:48:45 pm »

Have you read this?
http://gcc.gnu.org/wiki/Visibility
https://github.com/SFML/SFML/issues/111
Seems like the roles are inverted now, you're against a small optimization in favor of less complexity

I optimize for every case and only if it doesn't break anything or brings around strange behavior, and if it does then I make it purely optional. As an example, I could optimize completely for GCC but what would that mean for MSVC? Nothing so I don't do it at all.

About static linking? I don't remember issues that would have been discussed in the past.

http://en.sfml-dev.org/forums/index.php?topic=7276.0

1316

General discussions / Re: GLEW and not exporting the GLEW symbols in SFML

« on: April 15, 2012, 11:00:51 pm »

More support for what? Are you just talking about the INCLUDE_STATIC_LIBS CMake option, or something else?

More flexibility regarding static linking whether on Linux or Windows. This includes INCLUDE_STATIC_LIBS as well as choosing the link type of other libraries at will (which includes possibly linking GLEW dynamically, which as you mentioned is a known problem).

What's broken? What would you improve?

All those previous discussions you, me and Tank have had.

"must" is used here because it has to match what's used in the code.

I meant the fvisibility thing all together including the part in Config.hpp. I find that hiding symbols isn't really needed.

He has to do it anyway, there's nothing to decide. So why not do it for them?

I know SFML isn't licensed under GPL, but the idea here is freedom. Let the user decide what is best for them. In case a new version of GLEW or one of those other libraries comes out let the user decide whether they want to use that new library or not. Or on the contrary, if he wants to use a far older version of the library that is stable and does exactly what he needs he would want to link against that himself too.

Why would I export internal classes and functions? In case you didn't notice, this flag is used only when building shared libraries.

Because it doesn't hurt if you don't provide the interface for them anyway? And not to mention you go through a lot of effort to not export them.
It's like putting a knife in a safe on a tall table rather than just leaving it on a tall table so that a child can't reach it.

No. The first thing has nothing to do with the second. I include dependencies in SFML static libraries so that users don't have to do it theirselves. The result is the same though.
By the way, what do you mean with "export them"? It's a static library, everything which is in it is accessible, isn't it?

Code: [Select]

#include <SFML/Window.hpp>
#include <GL/GLEW.h>

int main()
{
sf::Context context;

glewInit();
return 0;
}This code fails to link with:

Code: [Select]

undefined reference to _imp__glewInitalthough I link to sfml-graphics-s-d and have SFML_STATIC defined.

Sifting through the nm dump of libsfml-graphics-s-d.a you find:

Code: [Select]

glew.c.o
...
00016f7c T _glewInit
...
T meaning the symbol is in the text section.
This is expected because you include GLEW into sfml-graphics, however above that entry you also find:

Code: [Select]

GLCheck.cpp.obj:
...
         U _glewInitU meaning the symbol is undefined.
I do not know what causes glewInit to be redefined but as an answer to your question, this is how you "not export symbols" in a static library. I don't know how I would do this because I have never had to do this but this is quite annoying and it would be nice to find a fix for it.

edit: I realized I forgot to define GLEW_STATIC which makes the linker error disappear. And I also assume that the same symbols are used at different places, some of them being undefined until the linker resolves them inside the same static library archive. I will try to construct an example where the GLEW linking problem we had in SFGUI is displayed in a simpler way.

1317

SFML projects / Re: SFGUI

« on: April 15, 2012, 10:15:19 pm »

Yeah the RC released today is based of the current master at GitHub which should work the last time I checked. What speaks against downloading SFGUI and trying it out yourself? Either it's you or me who finds out first whether it works or not As always if you find anything you have a feeling is a bug don't mind reporting it, favorably on our forum in other to reduce activity in this one thread.

1318

General discussions / Re: GLEW and not exporting the GLEW symbols in SFML

« on: April 15, 2012, 06:37:17 pm »

It would be crazy if every library exported all the functions and classes from the libraries that they use internally. Nobody does that.

It would also be crazy if every library included the static library archives they depend on into their own and not export them don't you think? The only reason I see that sfml-graphics includes the GLEW lib into itself is so that people don't have to type a (for me quite acceptable) -lGLEW in every one of their SFML projects. Static libraries don't go through the link step for a reason: they are just archives of precompiled code ready to be integrated somewhere. The final link step which is done when an executable is built looks for the dependencies and links them properly. Pretending that GLEW is always there without it being in a separate archive makes it even more confusing than just saying "by the way SFML depends on GLEW so you will have to link against it also". Sure it is simpler for those who have no idea what we are talking about here, but for those who do need to use GLEW, we have to link against it in out final app anyway so why not be friendly and share the archive among libraries? That's what they are for after all.

# this macro adds external dependencies to a static target,
# compensating for the lack of a link step when building a static library.
# every compiler has its own way of doing it:
# - VC++ supports it directly through the static library flags
# - MinGW/gcc doesn't support it, but as a static library is nothing more than an archive,
#   we can simply merge the external dependencies to our generated target as a post-build step
# - for other compilers and OSes, static build is not encouraged so we don't try to
#   pre-link dependencies, we just "link" them so that the SFML samples can compile
#   out-of-the-box (CMake forwards the dependencies automatically)

Just a warning, just because MSVC does something, it doesn't mean that that is the standard way of doing it. This quoted comment has me worried a bit. I assume you already know the difference between true linking and just including archives into each other. You said for other compilers and OSes static build isn't encouraged because you can't perform this archive inclusion for them. Don't you think they have a reason for that? It's because it isn't the standard way of doing things. I assume MinGW/gcc/ar has this functionality for totally different reasons (I've even combined all SFML libraries into one before just to speed up building) but forcing it when building SFML? I'd leave that to the user to decide. Maybe something like INCLUDE_STATIC_LIBS in CMake or something. And in case anybody didn't know you can disable that archive inclusion functionality in MSVC too although enabled by default.

And just for the record, I am (and Tank is also) against all simplifications that are made to cater to people not willing to learn how compiling and linking works. But you should have figured that out by now

And about fvisibility,

# If using gcc >= 4.0 or clang >= 3.0 on a non-Windows platform, we must hide public symbols by default

Is that a miswording? Because saying "must" to me means there is no other way to do it. You probably have all the alleged performance improvements in mind, but remember this varies from case to case and looking at the size of the symbol tables in the SFML libraries I don't see why this is needed.

Reading through the SFML CMake configuration I also can't help but have this strange feeling that SFML really encourages one to link dynamically on Linux and Windows at all costs. Being a fan of static linking on Windows and seeing how many things are broken when static linking SFML I can only hope that the situation improves in the future. While performing my profiling on Windows and Linux, static linking everything makes it so much easier, which is why I also like to static link on Linux just for that purpose. I'd like to see more support for this too in the future.

1319

General discussions / Re: Broken stuff

« on: April 12, 2012, 11:22:22 pm »

Windows 7

With a Windows 98 theme?

You make it sound like it's something bad... I am a Linux user too btw. ^^ an ArchLinux user... on openbox.

1320

General discussions / Re: Broken stuff

« on: April 12, 2012, 11:09:32 pm »

AMD Radeon HD 5850 with Catalyst 12.1 on Windows 7