Messages

1

Window / Re: Windows gains focus only at borded

« on: August 24, 2013, 09:21:27 pm »

Hey, when did reporting SFML bugs become such fun to do?  Anyway nice work xzbobzx, in meantime it's going to be probably my choice of 'fix' too. (Might even create fork including this.. or just really fix it.)

2

Window / Windows gains focus only at borded

« on: August 22, 2013, 12:59:44 am »

I've noticed that my windows only gain focus (understand producing sf::Event::GainedFocus and bringing input to that window) only when clicking at it's border, not inside o the window. It's a little annoying and I'm somewhat sure it didn't happen in previous SFML versions (but it's too late for another testing.. ). Other means of gaining focus work fine (alt-tabing, picking up from taskbar,..).

I'm using SFML 2.1 32bit on Windows 8 64bit and can bring up more details if needed, like minimum code to reproduce, however it happens with 2 of my programs using SFML, so it looks like consistent issue.

3

System / Re: A correct way to multithread OGL context?

« on: April 20, 2012, 03:58:30 pm »

Thanks for link, I didn't know about such variable type before. One learns something new every day..

I'm already rewriting my app to use thread poll as you proposed, however there will be still a vector of threads for CPU parallel computing created (because of dynamic number of threads that can be input) and those threads will be launched and terminated on each benchmark start. It is not a big deal though as I don't need OGL context in those threads and therefore rerunning them shouldn't be so expensive.

4

System / Re: A correct way to multithread OGL context?

« on: April 19, 2012, 10:42:18 pm »

Ah, I thought you were talking about thread-local variables.

Actually they're thread-local.. Let me clarify:

fun(){
   static int i;
   for(int j = 0; j < 10; j++)
      i++;
}

Now, it is very unlikely that when this thread would be run from 2 places, the i++ would begin to be incremented while it is already incremented in other launch but you can't deny the fact that it can happen. This is simplified and you can imagine how many bad things could've happened if I used whole context instead of simple int. As I said one approach is to lock mutex before incrementing but in the end, it's better to pass by parameter (that static won't be going anywhere even if you'll destroy all the threads, so if that was a big resource you get a lot of memory lost). But that is for another discussion and varies with what you want to actually implement, and actually I realized that also passed variable would have need guards so it's irrelevant for this topic.

Why would you have so many threads?

Well later in development I could have a lot of functions with different purpose - loading, processing, ... So I would run all these threads on program start and most of them would be just sitting there because loading scene is infrequent, big space battles are infrequent,.. I hope you get my point. Anyway I would be left with many threads, most of them unused most of the time and signalizer (variable responsible for "awaking" the thread) would need to be passed around. I don't know if I would ever do such thing as there is always more ways to do the same, some of them much less complicated.. But I got a feeling from your message that you would make e.g. 5 threads (optimal) and make universal function for all the threads with big switch for loading, processing, .. ?

5

System / Re: A correct way to multithread OGL context?

« on: April 19, 2012, 09:14:39 pm »

What kind of pitfalls?

Imagine a situation where you run same thread from 2 places in program. Voila - as the variable is static, it is common for all the launches and thus it can be corrupted easily. One way to solve this is using mutexes but I try to avoid static variables in threads in first place

A good strategy is to allocate a pool of worker threads (size depending on the underlying hardware capabilities), and dispatch work to them on demand.

I don't think so, but why is it a problem if your thread is not destroyed and recreated thousands times? Like I said, it should ultimately be done only once.

Ahh I see what you are trying to tell me. I should've created and launch my threads at start of program and just signalize them to work when needed, right? This way everything's created and destroyed on start/end of program. Not a bad approach.  It's still better to have a thread sitting in my memory whole time than to get my memory occupied by OGL contexts. Only problem I see would be that when there are more and more threads added to program, things can get messy (Delphi's make everything global approach).

Background you asked for and I tried to avoid due details:
Take a look at my library www.unishader.g6.cz. In short, it makes working with shaders in OGL much easier. I'm now benchmarking CPU vs GPU in parallel computing contest. For that I've built GUI with SFGUI that is quite neat and I would like to keep that GUI somehow responsive (to break computations, etc.) although due benchmarking it will be slowed down ofc.

The threads are used for both CPU and GPU computing. I need to stress my CPU, so I compute in parallel on as many threads as user inputs (this way multicore CPUs can be fully benchmarked). For GPU only one thread with it's own context is created where my library gets initialized and does its job but as I said, this has to be different thread to keep GUI responsive. And as we already noticed in this test case, the lag and memory leaks are so bad that my real code is currently unusable.. I believe that was the same approach as Ceylo here mentioned (substitute playing movie with running computations).

In the past I've already used combination my library + SFML and I have to say they're working nicely together but those threads got me to dead end. I'm now thinking about reading some pages on traditional ways of multithreading so I get more familiar with the whole concept.

PS: you may notice on my web page that I'm talking about small SFML problem connected with creating pure OGL context on Linux, but I didn't try the new release so I won't start a topic for it now ..

6

System / Re: A correct way to multithread OGL context?

« on: April 19, 2012, 10:40:31 am »

Ok I get it now, I didn't expect thread to be such big resource. I'll have to redesign my code a bit but it should be ok.

Btw, as far as I know, thread created variables are dangerous and so creating static context for thread would have many pitfalls. I was thinking about creating Context and RenderWindow in main thread, deactivating Context immediately (that would leave main thread still with RenderWindow context active, right?) and passing it to thread on launch (Indeed, my real code launches it just once for button press, so it isn't 60 FPS for sure).

Only problem I have is your statement:

SFML never leaves a thread without an active OpenGL context

. It is connected with a question - does every new thread have its own internal OpenGL context created? If so, and SFML is using shared contexts ( = every context same data, what happens to one modifies the others ), it would mean that I wouldn't have to pass any context and render as in my example code and things would work, but green point isn't drawn in that case. Or is it the way that ONCE there was context presented explicitly, upon deactivation implicit context is created? I think later is the case, because if one never uses SFML in his main thread, OpenGL context shouldn't be created for it.

Anyway if I would run that sample not for every frame and would use extra context for second thread, there would be still problem in second thread with deactivating it, because SFML would step in and create internal.. but I don't want that as I'm already leaving thread and nothing really is done afterwards. Can be this behaviour altered?

And thanks for time and effort!

7

System / Re: A correct way to multithread OGL context?

« on: April 19, 2012, 12:30:40 am »

The point is that I would except it to work flawlessly.. no huge lags and memory leaks.. I got over 100 mb of RAM occupied by this small app after running it for 5 minutes. If I can't get it right here, the real code would be catastrophe!

And in fact I'm creating benchmarking program for something of mine that will display progress in RenderWindow and will use another context for running my pure openGL things. So this is very simplified and I'm missing one context here, but still it would answer my questions.

I thought you might see a problem in this code (not meant in way that you are my personal debugger) but if not.. Well and maybe it is concept conflict between my and SFML thinking, so if there really isn't a catch (but those leaks ?!), how would be things done in real code?

Edit: So to be at least usefull for something, I debuged into sfml code. The lag is caused by single function

Code: [Select]

win.setActive(true) which is reactivating context after returning from thread. After debugging it gets to single function that causes trouble:

bool WglContext::makeCurrent()
{
    return m_deviceContext && m_context && wglMakeCurrent(m_deviceContext, m_context);
}

The same function causes memory leaks but this time it's called from second thread while activating. After every activation in thread the consumed RAM gets ~800 kb bigger.

8

System / A correct way to multithread OGL context?

« on: April 19, 2012, 12:05:40 am »

I've found plenty of stuff out there about multithreading, OGL and SFML, yet I had only partial success in inmplementing it. I'm currently working in test project to comprehend things and I actually managed to get it done..

Wait I didn't tell what.. I setup my raw OGL view, then in main loop I draw green point through thread, I switch back render a red point, display window.. Before switching to thread I deactivate window context in main thread, activate it in second thread, do my drawing, deactivate, get back to main thread and reactivate. Everything is synchronized with glFinish in second thread and sf::Thread::Wait in main thread so I'm sure nothing gets corrupted.. And it works, I get green point, a red point, but it is sloooooow as.. well I can't really expres that.

Basically it displays a frame then get stucked for about 5 seconds (everything.. even whole event system is frozen so I can't move a window). I noticed this behaviour in the dark age of mine when I recreated whole context on every launch of second thread. Also it had serious memory leaks. And the same behaviour (both leaks and long jumps to/from thread) I get now with only activating or deactivating.

This is my test code:

#include <GL\glew.h>
#include <GL\GLU.h>
#include <GL\GL.h>
#include <SFML\Window.hpp>
#include <SFML\System.hpp>
#include <SFML\Graphics.hpp>

void fun(sf::RenderWindow* win){
        win->setActive(true);

        glBegin(GL_POINTS);
                glVertex2f(50,50);
        glEnd();
        glFinish();

        win->setActive(false);
}

int main(){
        sf::RenderWindow win(sf::VideoMode(200,200), "Context sharing", sf::Style::Close);

        //setup view
        gluOrtho2D(0,200,200,0);
        glPointSize(10);

        sf::Thread tr(fun,&win);       
        sf::Event ev;

        while(win.isOpen()){
                while(win.pollEvent(ev)){
                        switch(ev.type){
                        case sf::Event::Closed:
                                win.close();
                                break;
                        default:
                                break;
                        }
                }

                //clear buffer
                glClearColor(1,1,1,1);
                glClear(GL_COLOR_BUFFER_BIT);

                //render green point from thread
                glColor3f(0,1,0);
                win.setActive(false);
                tr.launch();
                tr.wait();
                win.setActive(true);

                //render red point to check if working
                glColor3f(1,0,0);
                glBegin(GL_POINTS);
                        glVertex2f(75,75);
                glEnd();

                //display it
                win.display();
        }

        return 0;
}

If I get it right I might give that code to wiki if you like as only resource on this "Loading images in a thread (and displaying progress)" is now greyed out and can't be accessed.

9

General discussions / SFML-like library system

« on: January 17, 2012, 11:49:32 pm »

Many thanks for reply.

I've heard about pimpl idiom before, in fact I had to use such things in one of my projects, but they're really messy. I've inspected the glew.h to get some details about GL types, and it seems they won't be changed any time soon (they're in section GL_VERSION_1_1), and only difference for native data types comes with 64bit integers that I don't use. But it was good way to confirm my assumption.

The later is more interesting information. It helped me with a dilema I was facing - why would dynamic libraries exist if we had to create also static ones every time I'm going to search something about import libraries, but I feel you saved me from days of frustration

10

General discussions / New naming convention

« on: January 17, 2012, 11:30:09 pm »

What about different view angle?
Ask a question, what notation you were teached? I could find just two naming conventions for C++: some_function and SomeFunction. The first is used by standard and we can find this convention also in cplusplus.com tutorials. The later is wide-spread in c++ books, but there are still some that stick with some_function. But I never saw anyone teaching camelCase notation. It seems to me as a crazy attempt to shorten some_function.

My argument would be that in my case I use openGL alot with SFML. Their notation is based on camelCode, but the first word is always gl, rendering the rest as CamelCode notation. When writing wrappers around some openGL functions, it was always convenient just to omit gl. It's still my personal preference though.

As already wrote, ambiguity will always exist by not using underlines.. either between classes and functions or functions and variables. There's no gain in changing this. QT have strong user base, but so does have SFML and many projects that decided to align with it's style. It's not a question of laziness, but of wasted time that could be spent better (as with the time I spent to write this   ). SFML might change it's notation, but I'll be really interested in how other projects will answer to this issue. And I'm fully aware that SFML 2.0 is only for testing and indeed some changes break the code every time, but this will be huge.

As for the gets/is/sets the advantage of uniform working with member data is too small as it can be compared with fast navigation in intellisense/discovery/(whatever..), but there is great comprehensive value in those few characters. If we'd like to go down to standard we should really think about what bastien posted about quasi classes. Indeed the std::string has .length() and not .GetLength(), but it doesn't use .length(int newLength) [as opposed to .SetLength() ]  but .resize() . I think omitting those few characters will just confuse people, and add more visits to your site  

11

General discussions / SFML-like library system

« on: January 17, 2012, 08:06:58 pm »

Hello.. this is quite a bit off-topic, but still SFML related so I'll give it a try.
I'm building my own library to concentrate many source files and headers that I'm now just copying between projects and compiling them over and over again, getting lost in where is the last modified version etc. I haven't previous experience with doing so, therefore I've chose to copy someone's else. Well and as I'm big fan of SFML and pretty impressed of how that word Simple fits in there, I tried to copy this one. I was particularly successful in creating similar file system and compiling library. However, I encountered few problems that I'd like to ask about, because SFML doesn't have such. For now I'm compiling my library with Visual Studio 10 and I don't have CMake solution yet, only visual studio project.

- GLEW include path needs to be specified in project using my library
This is biggest catch. When starting a project that should use my library, I include main include file (something like SFML/window.hpp). That file includes glew.h, thus the project that want to use just my library needs to know also about GLEW. I've noticed you're solving this by creating GLcheck.hpp and including it only to .cpp files. This way the user project doesn't have to know about glew. However, I'm using some GL data types defines (GLint) in declarations in headers, therefore I need to have GLEW included also in header. Is there any other work-arround than changing those to native data types?

- Static library size
My library is much smaller than SFML (number of lines, files, etc.), but still size of the resulting static library is greater than all SFML libraries together. I tried to play with project setting so I would get the same as SFML have, but it didn't do big difference. I think there might be problem connected with previous paragraph. If whole GLEW would be linked to static library, it could create such big libraries. (Note that my testing libraries don't exhibit such problem)

- Building both dll and lib whit single configuration(Release, Debug, ..)
I'm pretty interested in how is this possible, because I can only make configuration that produce static library or dynamic (project properties-> configuration properties-> general, configuration type [options: makefile, exe, dll, lib, utility]). This way I need to create one configuration for compiling static(lib) and one for dynamic(dll) library. SFML visual studio project created with Cmake produce both in single configuration e.g Release. Do I have to use Cmake for such option?

I don't know how much you (or people willing to input something to this topic) are familiar with visual studio, I just want to test everything out and solve major problems before getting my hands on Cmake. Anyway, I believe that you're more than competent to answer my questions as similar problems must have been addressed when creating SFML(or any other library). Also if you had some very good source where you learned something about building more advanced libraries (not just sample ones), I'd be more than interested in those.

12

General / How do I bring an SFML game out on the Internet?

« on: October 22, 2011, 07:09:04 pm »

Only Javascript and Flash (as far as I know -- there are probably others) can do this.

I believe that Java can do very well also (it's nothing like javascript). For example Minecraft can be run in browser using java:
http://www.minecraft.net/classic/play.

However let me tell my point of view as student. I'm in 4th year of highschool (Slovakia) and I'm using c/c++ just because I learned it by myself. My schoolmates are however learning Pascal (which I see as ancient language) but they can indeed play and have fun doing just some simple things as 2D terrain generation. Making games is quite time demanding work and it's useless unless the students give in their free time.

But even if they really want to make game, I can't see a reason why to make it browser one.. Basically, I find browser games much slower and simpler than those run in PC directly. There's only one serious game other than minecraft being developed for playing in browser (some world war 2 FPS). I believe that most of the games was, are and will be played from your HDD and not through browser. It brings just too many unnecessary complications to developing a game and gain is really small as games played on PC directly can still be enough small to take just sec to download and with SFML it's guaranteed they'll be portable.

13

General / Closing window causes access violation

« on: October 21, 2011, 03:48:58 pm »

Thanks for the help.

And one more thing, though this might be already known. I didn't want to have to include font with my program and as the built-in arial was pretty good, I just did:

Code: [Select]

sf::Font font = sf::Font::GetDefaultFont();
and this one I passed into sf::Text constructor. The result is same as before, but no crash anymore. As I read in that other thread, you got problems with those global variables, that can't be initialized before entering main function. Maybe you could have a class inside SFML that groups all the globals and something like sf::Init() that would user call from body of his main? It's the very same as glewInit() I need to call before I can use many of openGL calls, and there probably isn't better way to do this.

14

General / Closing window causes access violation

« on: October 21, 2011, 03:26:24 pm »

Closing the console terminates the program in a very ugly way -- nothing gets destructed properly. So no "crash", but memory leaks etc.

That's quite disturbing as I'm planning to use console in final release.. when we are at it, is there any way to disable all the options to close console?

15

General / Closing window causes access violation

« on: October 21, 2011, 02:22:34 pm »

Then it should be true, that default font is loaded only if no other font is bind to sf::Text while calling sf::RenderWindow::Draw ? If so, would loading my own font to sf::Font and using this one prevent the crash?

And why closing console window doesn't result it crash? The console window, however, stays stuck for some time, and at last the programs ends returning exit code -1073741510 (but at the end of main I return 0).