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

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.


Messages - golgoth

Pages: [1] 2 3 ... 7
1
Window / Re: SFML and Qt5
« on: February 19, 2013, 09:55:38 pm »
setFocusPolicy(Qt::StrongFocus) might have worked for SFML 1.6 but it does not work with version 2.0.

Any other idea what might prevent keyPressed events to be passed to SFML?

2
Window / Re: SFML and Qt5
« on: February 14, 2013, 10:47:36 pm »
Oh, thank you very much for your inputs eXpl0it3r;

I'll try the:
setFocusPolicy(Qt::StrongFocus);

3
Window / Re: SFML and Qt5
« on: February 13, 2013, 04:17:40 am »
Any hint would be welcome!

4
Window / Re: SFML and Qt5
« on: February 11, 2013, 05:09:42 pm »
Hi Laurent, Windows 7 & 8 that is.

5
Window / SFML and Qt5
« on: February 11, 2013, 03:17:27 am »
Greetings everyone,

Im have the same issue as this fella:

Quote
I'm not sure. I'll just looked at the source of SFML, and this is what it looks like:
1.Qt creates the window
2.Qt gives me the HWND
3.I give SFML the HWND Window
4.SFML attaches it's own WndProc callback function to it, but saves the previous (Qt's) WndProc.
5.SFML receives the messages, processes them, then forwards them to the previous (Qt's) WndProc.

So it looks like SFML gets to process the Win32 events before Qt. I don't know why SFML is not processing the key presses (but is receiving mouse messages) then, but why it was previously with Qt 4.8.

Any idea what could cause SFML not to process the MouseButtonPressed anymore?

6
Window / Re: When does a Window delete its Opengl Context?
« on: January 26, 2013, 04:27:57 pm »
Yes of course,

int main()
{
        sf::Window window(sf::VideoMode(800, 600), "SFML window", sf::Style::Default);

        glewInit();

        UINT l_id = glCreateProgram();

        while (window.isOpen())
        {
                sf::Event event;
                while (window.pollEvent(event))
                {
                        if (event.type == sf::Event::Closed)
                                window.close();
                }
                window.display();
        }

        glDeleteProgram(l_id);

        return EXIT_SUCCESS;
}

Run this with:
http://www.gremedy.com/download.php

and you get:
Debug String: Detected error: The debugged process asked for an extension function pointer (glCreateProgram) from one render context, but called this function pointer in another render context (context #3)
SNIP...
Debug String: Detected error: The debugged process asked for an extension function pointer (glDeleteProgram) from one render context, but called this function pointer in another render context (context #2)

7
Window / Re: When does a Window delete its Opengl Context?
« on: January 26, 2013, 04:41:26 am »
There is definitely something fishy with the contexts, It seems like there's a swap of context after the Window is created that might cause this issue. And it would be very handy to know what triggers the swap before we make GL calls.

gDEBugger returns:

Debug String: Detected error: The debugged process asked for an extension function pointer (glCreateProgram) from one render context, but called this function pointer in another render context (context #3)
Debug String: Detected error: The debugged process asked for an extension function pointer (glBindAttribLocation) from one render context, but called this function pointer in another render context (context #3)
Debug String: Detected error: The debugged process asked for an extension function pointer (glCreateShader) from one render context, but called this function pointer in another render context (context #3)
Debug String: Detected error: The debugged process asked for an extension function pointer (glShaderSource) from one render context, but called this function pointer in another render context (context #3)

SNIP...

OpenGL Render Context 3 Deleted
Debug String: Detected error: The debugged process asked for an extension function pointer (glDeleteBuffers) from one render context, but called this function pointer in another render context (context #2)
Debug String: Detected error: The debugged process asked for an extension function pointer (glUseProgram) from one render context, but called this function pointer in another render context (context #2)
Debug String: Detected error: The debugged process asked for an extension function pointer (glDetachShader) from one render context, but called this function pointer in another render context (context #2)
Debug String: Detected error: The debugged process asked for an extension function pointer (glDeleteShader) from one render context, but called this function pointer in another render context (context #2)
Debug String: Detected error: The debugged process asked for an extension function pointer (glDeleteProgram) from one render context, but called this function pointer in another render context (context #2)

It would help if:
- The dummy contexts could be destroyed leaving only the main one... or
- We could track which context is the main one (the one that uses glswapbuffers) and/or...
- A way to set the main context active before making gl calls. (I'm guessing that is "set active window" but it does not seems to do any good here).


8
Window / Re: When does a Window delete its Opengl Context?
« on: January 26, 2013, 01:47:39 am »
I finally found the leaks, quite a catch and you were right, sharing context seems to work fine.

9
Window / Re: When does a Window delete its Opengl Context?
« on: January 25, 2013, 10:19:46 pm »
Very well thank you for your support Laurent,

Quote
The internal context handling in SFML is complicated. Hidden contexts are created. You shouldn't care about that, it's implementation details.

Once the first Window is created, SFMF has created 3 different contexts. I understand resources are being shared between contexts but regarding to GL gDEBugger, it does not like it.

From:
http://www.opengl.org/sdk/docs/man/xhtml/glDeleteShader.xml

Quote
If a shader object to be deleted is attached to a program object, it will be flagged for deletion, but it will not be deleted until it is no longer attached to any program object, for any rendering context (i.e., it must be detached from wherever it was attached before it will be deleted)

I try to "set Active Window" before creation and before deletion but I’m having the same issue, any ideas?

10
Window / Re: When does a Window delete its Opengl Context?
« on: January 25, 2013, 09:01:45 pm »
Hi Laurent,

To answer your question, I use SFML mainly for the window creation and user inputs, threading and networking. I’m very happy with this but my problem is that SFML seems to takes over my graphic pipeline and I believe it might be causing very hard to find bugs that I’m trying to solve.

The reason behind my last question is that gDEBugger GL is telling me that 3 GL contexts are being created and it spits out memory leaks as some VBOs are being deleted on a context that did not created them. Why do I end up whit 3 GL Contexts is beyond my understanding right now and I’m trying to investigate why is this happening.

My guess is that SFML Window is creating its own proc addresses like this one:

        PFNWGLCREATECONTEXTATTRIBSARBPROC wglCreateContextAttribsARB = reinterpret_cast<PFNWGLCREATECONTEXTATTRIBSARBPROC>(wglGetProcAddress("wglCreateContextAttribsARB"));

…and it might not play well as I also have to do it before SFML does.

I also noticed in WindowImplWin32.cpp:

#include <SFML/Window/glext/wglext.h>
#include <SFML/Window/glext/glext.h>

I might be missing something, but this is not needed over there.

The bottom line is, I’m trying to strip down any OpenGL calls from SFML Window and make sure there is no mumbo jumbo name mangling issues of some sort.

regards,

11
Window / Re: When does a Window delete its Opengl Context?
« on: January 25, 2013, 07:19:01 pm »
hum, would it be possible to create a Window without SFML dealing with the creation of the OpenGL Context and especially, loading the OpenGL libraries?

I'm asking because I don't need SFML doing any OpenGL related stuff as I would like to handle this on my own, like creating the Context and swapping buffers?

12
Window / Re: When does a Window delete its Opengl Context?
« on: January 25, 2013, 06:52:04 pm »
Marvellous, merci Laurent for your input!

cheers,

13
Window / When does a Window delete its Opengl Context?
« on: January 25, 2013, 06:20:37 pm »
Hello SFML Wizards,

Quick question, once you've created a GL Context in a Window, is there a time where this context is being delete/replace before the window is finally destroy? What about resizing the Window, is the Context kept?

THX

14
General discussions / Re: Any workaround for Lion OpenGL 3.2 Support?
« on: January 07, 2013, 08:14:58 pm »
Hiura, you are right, I see how it could be interpreted. My apologies if I hurt anyone.

That said, I didn't see that limitation coming and it sets me back a great deal. I hope it will be addressed sooner then later.  I'd be willing to test any work made in that direction if that could help.

15
General discussions / Re: Any workaround for Lion OpenGL 3.2 Support?
« on: January 07, 2013, 06:30:17 pm »
Would have been faster to fix the issue on the spot than writing the ticket... go mantognini go!

Pages: [1] 2 3 ... 7
anything