Messages

1336

General / Distributing SFML games on other websites.

« on: January 30, 2012, 12:37:38 pm »

hat must be the most idiotic thing I have ever heard of.

Why? I don't understand this almost fanatic aversion I sometimes see when it comes to protecting source code or content. I can completely reconstruct that there are people who aren't willing to expose the raw building blocks of which a game was made, either because they don't want to give the possibility to alter the game and claim to be the author, or to keep it original, or whatever.

Whether a developer allows mods of his game, is his personal decision, and not the one and only way. Speaking about "good software development" while ignoring the fact that most commercial games protect their code and resources is a little bit questionable. Sometimes it isn't bad to look beyond the horizon of the holy open-source world.

I was referring solely to the fact that that developer chose to pack his game assets into shared library files, meant for code! If he really packed them with his executable code or if he just used the DLL purely as a container for the assets I do not know. But if he really did cause the whole DLL to get handled by the dynamic linker, then... there are better ways. I have nothing against people protecting their code or assets, but there are more effective ways of doing it than mixing them with the bits and bytes that are needed to get an executable running. Most commercial games also do not pack their resources into one giant DLL file AFAIK.

1337

Graphics / sf::Text problem (bug?)

« on: January 30, 2012, 12:28:02 pm »

Simply put, the default Font is a static variable (not in global scope) initialized at request and destroyed when the dll is unloaded far far after your application terminates.

You could put it this way: Because the font is the last one to leave the room. It has to turn off the lights itself. However it can't reach the light switch itself and the tall AMD driver already left before it because it didn't care much. The nVidia driver however is nicer and sticks around until everyone leaves and so doesn't cause a problem.

AMD could argue that it never said it would stick around and having static OpenGL resources is a bad idea anyway. But because there are other apps/games out there that probably do the same, I would bet that it's something particular about SFML.

1338

SFML projects / SFGUI

« on: January 30, 2012, 12:16:36 pm »

In most use cases this will be useless: one can store the name when it loads the font, or use the sf::Font pointer as an identifier. Problems arise when you write a middleware, like SFGUI, and have no control on font instances. What kind of other use case could it be useful for?

Besides letting others manage the font resource themselves, probably none. I had an implementation with pointer comparisons, however that turned out to be a problem because GetDefaultFont() returns a reference, and to stay consistent all our fonts are passed around as references. We could just get the address of the sf::Font instance but that wouldn't work on temporary objects placed somewhere on the stack.

Out of curiosity, is it really a performance killer to call ResetGLStates once per frame?

We already minimized the state changes needed to be done when rendering the GUI. As such we want to manage the setting and resetting of the states ourselves and omit having to call ResetGLStates to reset things we didn't even touch. Calling ResetGLStates every frame was resulting in noticeably less performance.

but the best results will be achieved if you handle OpenGL states yourself (because you know which states have really changed, and need to be saved and restored)

That's what we want . And since when was a cache part of the OpenGL state machine?

I understand. However it would be weird to have something related to the depth buffer in the graphics module, which doesn't deal with depth at all.

Well you already let people create a depth buffer at Window creation although SFML doesn't make use of it itself. Keeping SFML "depth free" is therefore futile ^^.

I could show my own test app as a starting point, and maybe we could improve it together?

Would be a good starting point.

1339

Window / Window Not Opening

« on: January 30, 2012, 04:36:24 am »

I've looked into compiling SFML statically but it fails, i've tried rebuilding SFML statically, but it still fails, I've tried using the workarounds explained elsewhere, which kinda works, but still fails.
...
Please is there a possible fix, or an easy way to link against SFML statically that actually works? Just adding -s after the -lsfml-XXX doesn't want to work.

Wow, dude... if you think all you need to do is add -s after the -lsfml-XXX without successfully building as a static library you have a lot to learn. I'd look into why it fails building in the first place before trying to use it somewhere else. Saying it fails and not describing how it fails isn't going to help much. Everybody can get SFML to compile statically no matter whether they are a beginner or an advanced programmer. They just need to spend enough time figuring out how to. Static linking is in fact even easier to achieve and use than dynamic linking.

There are probably around one-hundred (100) topics showing this same error, yet no one can answer their questions or provide a way to fix their problems.

Then those 100 topic starters obviously don't know how to do a bit of research before asking the exact same question. The answer is on these forums, and no there is no way to prevent it, just to work around it. Static link or don't use the default font. There is no fix to it, not yet at least. It's that simple.

The ATI/AMD driver implementation on windows obviously displays "non-standard" behavior. Whether the crash is a result of programmer error/false assumptions on the side of SFML or really just a glitchy driver implementation, nobody knows. I put my money on the former. Wgl is known to be poorly documented, so I can't really blame Laurent. I do know however that there are many other open source games out there that use Wgl/OpenGL in almost exactly the same way as SFML and they don't crash on exit on ATI/AMD cards which further supports my previous statement.

Unless you can come up with a fix for this, I would recommend sticking to the workarounds and hope that Laurent fixes it sometime in the foreseeable future. And just so that you know, this issue is also present in SFML 2.0, so upgrading won't make it magically disappear.

1340

SFML projects / SFGUI

« on: January 30, 2012, 01:43:12 am »

From what I can tell reading through the source, it would have been bottlenecked by the CPU instead of the GPU. Thus whether you used VAs, VBOs or IMs it probably wouldn't make any significant difference. Your usage of the word "Batch" to describe the class containing the data for a single drawable is also kind of misleading. They weren't really batched data and so could not profit from batching at all.

Your idea of uploading data into a single buffer and drawing all at once at the end was good. HOWEVER, if you only draw the data one object at a time they will be, as you saw, hardly any better than VAs or even IM.

It would have probably made a big difference if you had stored more relevant data inside the Renderer object and let it manage drawing the objects itself when the time came. That way it would have been able to truly batch multiple objects together if it saw the possibility, saving not only a little GPU time but a massive amount of CPU time. Contrary to what people think most state changes and matrix ops take part on the CPU in the driver and the data gets sent in it's raw form to the GPU. Thus if the CPU is already busy going through all the batches every frame, the FPS will be hurt even more by redundant state changes which were abundant in that version.

Because you changed SFML a lot since then and cache states more effectively now and even use VAs as the primary drawing method, it would be nice to see how that old concept would fare in the current implementation.

And I'm curious, were these problems you speak of bugs/glitches or the flexibility/limitation kind of problems? I couldn't find any reports of problems related to the old drawing method while searching through those old threads.

I've seen some really nice ugly hacks and the even nicer comments associated to them about SFML. If you want to talk about these issues I'm here

Wishlist (among other things to make SFGUI less "hacky"):

1. Some way to identify/compare fonts among each other (name of the face or something).
2. Some way to tell SFML to wipe it's vertex cache.
3. Since you allow asking for a depth/stencil buffer, it would be nice to be able to clear those with RenderTarget::Clear() too instead of just the color. Now users have to resort to calling glClear() themselves which is horribly expensive.
4*. A standard benchmark spec that encompasses all areas of SFML to use as a performance measurement tool while trying to optimize SFML. This is one of those crucial things that I and others would need to know to experiment with making SFML faster. In SFGUI we have our lovely test app (which as some might notice contains all widgets currently available).

1341

SFML projects / SFGUI

« on: January 29, 2012, 09:00:44 pm »

I already have a state cache, I only set the states that changed between two Draw calls.

State changes aren't the only things you can save on although they make up a big piece of the time it takes to draw a frame. Draw calls are almost as expensive overhead-wise as state changes. Drawing 10 Sprites/Rectangle shapes for example requires vertex data for just 40 vertices but causes more than 40 OpenGL calls to be made.

Good point. That reminded me of something, so I checked and found that two years ago I already tried to implement batching in SFML 2.
Here is what I said on 19/01/2010:

The automatic batching system was great, but after using it for a while and collecting feedbacks, I realized that it was creating new problems that were very tricky to solve.

Unfortunately I don't remember what these problems were.

Well... you did change the drawing routines completely and don't use glBegin() glEnd() anymore. So maybe those problems won't carry over to the new drawable API. A link to that thread would be nice.

1342

General / Distributing SFML games on other websites.

« on: January 29, 2012, 05:47:11 pm »

Like, earlier i told you that in this game i had downloaded, they had the maps and models in dll files so there was nothing i could do to change the maps or models.

That must be the most idiotic thing I have ever heard of. Packing resources into dlls in the hope that they won't get modified at the expense of good software development practice is a crime against the user as well as the developer who has to put up with the weird antics of people who come up with such ideas.

If they are able to play the game on their own PC disconnected from the internet then I'm very sorry, but there is ABSOLUTELY NOTHING you can do to prevent them from changing the way the game looks or functions. You really shouldn't care either because as long as they keep it to themselves they don't bother others do they?

If on the other hand you want to play the game in multiplayer, the typical method used by many games out there is to keep a copy of the game state on every player's computer and perform the same calculations every frame on the game state. If a player's state deviates from the other players' states then his game goes out of sync and he is kicked or whatever. This would indicate to the other players that he manipulated his game in some way.

So to keep it simple. In single player, don't give so much effort, it isn't worth it. In multiplayer, there are methods, one of them I described here.

1343

SFML projects / SFGUI

« on: January 29, 2012, 01:09:34 pm »

Like I said, a library has to recognize opportunities to optimize and do it the best it can. Of course you can't optimize in exactly the same way for every single use case there is.

For example some people might not make use of VertexArrays or custom primitive types for whatever reason. Then you can assume that whatever he draws every frame, sprites, text, etc. can be broken down into triangles.

You could also for example batch text draws together. Say the user draws multiple sf::Texts after each other (very common from what I've seen) with the same sf::Font (face and size same), you can also batch those together. It saves you from stopping to check whats next to draw only to find out that it's exactly the same kind of data that you previously drew and even using the same texture.

My tests showed that locking/updating/unlocking a GL_STREAM_DRAW VBO is still slower than a vertex array, which is already slower than immediate mode in such a context.
...
It is definitely not applicable to SFML because I can't batch everything and delay all the rendering until the end of the frame.

Well correct me if I'm wrong, but the user won't see anything on the screen until he calls Display on his window anyway. So whether the drawing takes place right where he calls it or is saved and performed in the same order right before the buffer is swapped, I don't see the difference. The big one though is that you would transfer your data in bigger chunks which is where VBOs start to shine. As long as data runs around host memory or GPU memory it stays fast. When it has to run across the PCIe bus, and that too many times per frame, it becomes the bottleneck which is what you are probably seeing in your comparison between Vertex Arrays and VBOs.

VBOs also don't perform too well if they are too small. So to use them properly you would have to serialize a lot of that primitive data together and draw multiple times using that 1 buffer. I also don't have to stress that VBOs don't have to be drawn completely in 1 pass. They can hold data for different primitive types. Heck they can hold completely different data sets together one after the other. Whatever you can draw using multiple Vertex Arrays you can draw using 1 VBO and multiple draw calls.

1344

General / Distributing SFML games on other websites.

« on: January 29, 2012, 12:59:09 am »

There is no protection, and there will never be one.

Oh, but of course there is... but it is on such a level higher than what is popularly known that it might not even count.

Distribute a thin client that forwards user input to a server and does nothing else but draw the primitive data it receives to the screen. That way, that which is unique to the game (it's mechanics) never gets fully exposed to the end user. Of course the resources that you send the user will be on his system and thus Tank's other points count. But he won't have the game without it's mechanics will he? This will of course only work if your users all have a 1Gbit connection and <1ms network latency, oh wait...

Hope those AAA game companies didn't see this. Ah *$%#, too late :evil:

Why do I release my code under GPL and then write stuff like this? I will never know...

1345

SFML projects / SFGUI

« on: January 29, 2012, 12:41:00 am »

For example, there's a bug in event handling on Windows that will slow down some applications randomly.

Interesting... another bug I didn't know about.

I must design and implement things as if every property of every entity could change every frame.

That's exactly what the GL_STREAM_DRAW usage hint was designed for. It tells the GPU that it can expect buffer data to change between every draw call (even multiple times). The difference is that with a VBO which you update completely every frame the data is in a single buffer on the card. Think of it like calling new int; 1000 times and calling new int[1000];. The second variant would probably complete faster for the exact same reasons. And if you "prepare" the data to be as GPU friendly as possible, it will reward you appropriately.

"Prepare" would mean things like:

1. Converting your geometry data to draw using one primitive type (internally I'm sure GPUs convert almost all primitives to triangles anyway).

2. Reducing state changes (less texture binds, etc.) by batching and reordering the draws on CPU without influencing the final outcome of the frame.

3. Reducing the "useless" processing on the GPU when you know that what it does will have no effect on the frame output (this is more of a problem on older hardware without unified shaders).

4. Trying to make the GPU/Driver go through optimized paths when it can make some assumptions about the data being drawn (e.g. using identity matrices probably skips the whole matrix multiplication step altogether)

What one needs to look for are values which the GPU probably has to calculate every frame but stay exactly the same. They can be calculated when needed on the CPU and passed to the GPU "prepared" so it can save a lot of effort putting those pixels on the screen.

If you want an extreme (and still quite buggy) example of how I prepare data for the GPU, have a look at the texture preblending we do in the new Renderer. It offloads the blending from the GPU to the CPU under the assumption that the blended pixel values stay the same over all frames. I tried it out because 1. GPUPerfStudio was telling me that the GPU was stalling on buffer operations and 2. because I was crazy enough and had too much time. It seemed to harvest more performance and can work under the right circumstances.

The key is really to make a library so intelligent it knows how it can optimize the users data by itself in every situation.

For those who are curious, during the implementation of the new renderer I used gDebugger, GPUPerfStudio, valgrind and of course faithful gprof.

1346

SFML projects / SFGUI

« on: January 28, 2012, 10:12:12 pm »

Good idea... Laurent can decide what he deems worthy to benchmark in every version of SFML ^^. Then just write a spec and that will be the standard of testing. Such areas could be e.g. text rendering, sprite rendering, shape rendering etc.

1347

SFML projects / SFGUI

« on: January 28, 2012, 08:48:22 pm »

Yeah, I know that anything running on my computer could skew the results. I even actually get much lower FPS when running other CPU or GPU intensive applications at the same time as testing. But when I test the real performance of the library I make sure that my test environment is as clean as possible a.k.a CPU and GPU load < 5% which is a decent margin of error.

Browsing the web or using "typical" everyday applications implies the same window management / event handling as anything else running on my computer and that doesn't even load my CPU past 5% which means the same OS overhead would apply to an SFML application too. Which leaves the other 95% of usage purely to the "essential" part of the app (drawing and what not).

We could just shove 1000 buttons into our ScrolledWindow and turn off culling to purposely get the FPS down to 100 FPS if that's what it takes to get reliable test results. But why do so if we can see the difference at much higher FPS values?

Being a hobby physicist I just have to throw in an example:

Consider you want to measure the speed of light. And you would do so by measuring the duration it takes for a laser pulse to travel a certain distance.

You could measure it by getting a 10KM long fiber optic cable and sending a pulse through it and measuring the time it takes through that. Or you could get a 10M long fiber optic cable and measure the time it takes to travel through that with a high precision measuring device. You would resort to the first method because it would seem less susceptible to interference and margin of error of the time measuring device. But because we made sure the test environment was clean and the same in both cases we can also resort to the second method.

The key when testing is making sure you can reproduce your results, which in turn means the environment is fully understood and taken into account. The FPS values stated here are reproducible between system restarts and the relative FPS gain among the testers is also consistent which means that the FPS values themselves are in fact a reliable method of measuring performance, even at such high values.

Also worth reading: Amdahl's law

1348

SFML projects / SFGUI

« on: January 28, 2012, 07:17:19 pm »

I was saying that using such high numbers were irrelevant to show optimization results.

Well regarding optimization results, the more the better right? So if you have a library that runs at 2000 FPS instead of 1000 FPS it is sure to run faster on a slower system, say from 100 FPS to 200 FPS? Until you are sure that your GPU and CPU are both fully loaded you can always optimize no matter what the FPS value is. Optimization is not about maximizing the absolute FPS you get on one system, but rather eliminating the bottlenecks on all systems at the same time to ensure it will run faster (meaning more FPS regardless of the system) on all systems instead of at a given FPS value on one given system.

Therefore high numbers are indeed relevant, they show that a certain optimization does have a positive effect. And that effect will carry over to all systems, not only my own. Not everybody has a modern (in the last 2 years) GPU, and Tank's +2400 FPS might translate to e.g. +100 FPS from 50 FPS for them, which is very desirable.

You have to open up for a wider range of hardware if you really want to support OpenGL ES

1349

SFML projects / SFGUI

« on: January 28, 2012, 03:02:28 pm »

By the way, you my opinion about such high FPS numbers for benchmarks

Software libraries display an unusual property:

1 + 1 = 0.5 (in the worst case)

or in our case more like 1000 FPS + 1000 FPS = 700 FPS or something.

If you were to use 10 libraries which stem from developers who stop optimizing at 1000 FPS what do you think is going to happen to your awesome game? Of course it will run at 1000 FPS too right? Or else they would have optimized it more... because the FPS drop must come solely from their library and they only care about the use case where their library is used by itself.. which would make so much sense with SFGUI.

Sure.. if SFML or SFGUI was used purely by themselves, I would share your opinion 100%, but I didn't find any hidden clause somewhere which tells users that is the only way to make their next awesome game. We (at SFGUI) want the user to get maximum performance no matter how many libraries they want to use and how their performance is, be it 1 or 100. Therefore our view regarding performance.

Hope I could enlighten some people who cared to read my wall of text.

1350

SFML projects / SFGUI

« on: January 27, 2012, 01:03:14 am »

It would mean not calling sf::Font::GetDefaultFont() yourself or leaving the Font property of the widgets blank (which causes them to use the default font automatically). What this also means is, as you already said, that you will have to load a font from a source (file, memory etc.) and use that instead for drawing your SFML stuff and for SFGUI widgets.