Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: Some idea's reagarding to window handling  (Read 24816 times)

0 Members and 2 Guests are viewing this topic.

Daevius

  • Newbie
  • *
  • Posts: 12
    • View Profile
Some idea's reagarding to window handling
« on: March 15, 2008, 10:49:52 am »
Hi, I tried to build an application where I would make a loading window, then load everything (into OpenGL) (textures, audio etc etc), then I would create the main window and after that destroy the loading window. The point is that you can only load textures into OpenGL when the window is already opened. So I had to rewrite the window creation part a few times, these were some problems/things I ran into:

1. The second created window (my main window) starts minimalised. I didn't find any function to put maximalise it.

2. When I slightly modified the code, the second created window (my main window) started unfocused. It was behind the first created console in CodeBlocks (for debugging), though in release mode it would not occur, it would still be nice if we could make a window on focus.

3. After small changes, I wanted to load the main window and make it just not shown (loaded but not shown). When I made it not show after initialisation it, ofcourse, displayed for a few milliseconds and then disappeared. It would be nice if we could hide a window from start, and unhide it when needed. This way the window is initialised and can be showed very quickly.

4. After the loading was done, I wanted to destroy the loading window. I now use 'new' and 'delete' for that, but perhaps a function called 'destroy' in the class would be nice too. (I'm quite new to C++, can I call the deconstructor manually?)

5. Error handling. SFML automatically outputs to the console when an error occured. Thats nice, but what if I output printf() to a file and want to use my own error handling? It would be nice if we could use something like 'geterror' and it would return the latest generated error. And eventually 'geterrno' which would return a error code which can be identified and dealt with.

Just some idea's/suggestions, I really like SFML :), would be wonderfull to see it improved even more :).

Thanks,
Daevius

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32498
    • View Profile
    • SFML's website
    • Email
Some idea's reagarding to window handling
« Reply #1 on: March 15, 2008, 11:55:41 am »
Quote
The point is that you can only load textures into OpenGL when the window is already opened

That's not true. There's a dummy window created at program startup to provide a valid OpenGL context.
It's no more true with the latest sources (global initialization + DLL can cause some issues), but if you can still use SFML graphics classes without worrying about creating a window.
In case you just want to use custom OpenGL calls, you can call sf::Window::ForceContextInit() (static function) to force the creation of the OpenGL context before you create any window.

Quote
The second created window (my main window) starts minimalised

You really mean minimalized (ie. hidden in the process bar), or just "not maximized" ?

Quote
It would be nice if we could hide a window from start, and unhide it when needed. This way the window is initialised and can be showed very quickly

Why would you need to create a hidden window ? Just create it when you need to show it.

Quote
After the loading was done, I wanted to destroy the loading window. I now use 'new' and 'delete' for that, but perhaps a function called 'destroy' in the class would be nice too

A Close() function has already been added ;)

Quote
Error handling. SFML automatically outputs to the console when an error occured. Thats nice, but what if I output printf() to a file and want to use my own error handling? It would be nice if we could use something like 'geterror' and it would return the latest generated error. And eventually 'geterrno' which would return a error code which can be identified and dealt with.

SFML doesn't output to the console. It outputs to the standard error stream, which you can easily redirect to whatever you want.
I think providing some error codes would be useless, SFML functions just need to tell if they succeed or fail.

Thanks you very much for your feedback :)
Laurent Gomila - SFML developer

Daevius

  • Newbie
  • *
  • Posts: 12
    • View Profile
Some idea's reagarding to window handling
« Reply #2 on: March 15, 2008, 12:09:01 pm »
Quote from: "Laurent"
Quote
The point is that you can only load textures into OpenGL when the window is already opened

That's not true. There's a dummy window created at program startup to provide a valid OpenGL context.
It's no more true with the latest sources (global initialization + DLL can cause some issues), but if you can still use SFML graphics classes without worrying about creating a window.
In case you just want to use custom OpenGL calls, you can call sf::Window::ForceContextInit() (static function) to force the creation of the OpenGL context before you create any window.


Hmm...I couldn't get it to work. I will play with it again and see what happens.

Quote from: "Laurent"
Quote
The second created window (my main window) starts minimalised

You really mean minimalized (ie. hidden in the process bar), or just "not maximized" ?


I had to click in the bar (the bar at the bottom in windows, don't know what its called) to make it visable.

Quote from: "Laurent"
Quote
It would be nice if we could hide a window from start, and unhide it when needed. This way the window is initialised and can be showed very quickly

Why would you need to create a hidden window ? Just create it when you need to show it.


Since creating windows takes time I thought it might be handy. What if you have an app where you can enable/disable tool windows for the program (small windows with some extra features/information). It looks better and faster if its instantly displayed when you enable it...okay I agree...it just takes 0.12 seconds...ah well...

Quote from: "Laurent"
Quote
Error handling. SFML automatically outputs to the console when an error occured. Thats nice, but what if I output printf() to a file and want to use my own error handling? It would be nice if we could use something like 'geterror' and it would return the latest generated error. And eventually 'geterrno' which would return a error code which can be identified and dealt with.

SFML doesn't output to the console. It outputs to the standard error stream, which you can easily redirect to whatever you want.
I think providing some error codes would be useless, SFML functions just need to tell if they succeed or fail.


Hmm yes, perhaps this is only with debugging and not when you release it. Nevermind then.

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32498
    • View Profile
    • SFML's website
    • Email
Some idea's reagarding to window handling
« Reply #3 on: March 15, 2008, 12:26:53 pm »
Quote
Hmm...I couldn't get it to work. I will play with it again and see what happens.

What are you trying to do ? Using Window::ForceContextInit() to be able to use your OpenGL calls before using any SFML object ? Otherwise you don't need to do anything to make it work.

Quote
I had to click in the bar (the bar at the bottom in windows, don't know what its called) to make it visable.

Can you show us a minimal and complete code which reproduces this behaviour ?

Quote
Since creating windows takes time I thought it might be handy. What if you have an app where you can enable/disable tool windows for the program

Then just use the Show function, no need to destroy and recreate the windows each time ;)
Laurent Gomila - SFML developer

Daevius

  • Newbie
  • *
  • Posts: 12
    • View Profile
Some idea's reagarding to window handling
« Reply #4 on: March 15, 2008, 02:56:10 pm »
Quote from: "Laurent"
Quote
I had to click in the bar (the bar at the bottom in windows, don't know what its called) to make it visable.

Can you show us a minimal and complete code which reproduces this behaviour?


Hmm...couldn't reproduce...must've been me ^^. Sorry for the hassle.

Daevius

  • Newbie
  • *
  • Posts: 12
    • View Profile
Some idea's reagarding to window handling
« Reply #5 on: March 15, 2008, 03:25:59 pm »
Still a slight problem:

Code: [Select]
bool splash_running;
void splash(void *);

int main()
{
    window.create(800, 600, 32, "Window");

    sf::Thread splash_thread(&splash);
    splash_thread.Launch();

    //load();

    splash_running = false;
    splash_thread.Wait();

    bool running = true;
    while (running)
    {
        window.event(&running);
        window.draw();
    }
    return 0;
}

void splash(void *)
{
    int width = 200;
    int height = 120;

    sf::Window *splash = new sf::Window(sf::VideoMode(width, height, 32), "Loading...");

    glClearColor(0.0f, 0.0f, 0.0f, 0.0f);
    glEnable(GL_TEXTURE_2D);
    glEnable(GL_BLEND);
    glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA);

    glViewport(0, 0, width, height);

    glMatrixMode(GL_PROJECTION);
    glLoadIdentity();
    glOrtho(0.0f, width, height, 0.0f, -1.0f, 1.0f);

    glMatrixMode(GL_MODELVIEW);

    splash_running = true;
    while (splash_running)
    {
        glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);

        glBegin(GL_QUADS);
            glVertex2d(0, 0);
            glVertex2d(width, 0);
            glVertex2d(width, height);
            glVertex2d(0, height);
        glEnd();

        splash->Display();
        sf::Sleep(0.001);
    }
    delete splash;
}


This sometimes works and sometimes does not. The problem is that the splash thread opens up including the main window, but the thread never stops the display loop. It keeps going and I have to use Ctrl+Alt+Del to shut the program.

Perhaps I should use mutexes, but the tutorial says that that's not needed for boolean operations...

Aszarsha

  • Full Member
  • ***
  • Posts: 200
    • MSN Messenger - aszarsha@gmail.com
    • View Profile
Some idea's reagarding to window handling
« Reply #6 on: March 15, 2008, 07:25:11 pm »
The rule is that you ALWAYS want a mutex ! If, and only if, a profiling tool tell you that there is a bottleneck with a mutex you should review your code (sometimes, bottleneck through mutex can't be avoided).