Messages

16

General discussions / Less formats vs less dependencies ?

« on: November 01, 2007, 02:39:38 pm »

Also get loading from memory too as part of it, nice. Can load from archives and such with it. I converted my local copy of SFML to use SOIL and it was very simple.

17

General discussions / Less formats vs less dependencies ?

« on: November 01, 2007, 03:05:22 am »

That sounds great.

18

General discussions / Less formats vs less dependencies ?

« on: October 31, 2007, 05:06:01 pm »

Laurent, what library specifically were you thinking of using? I'm very interested.

19

Graphics / Renderwindow from an existing process

« on: October 30, 2007, 04:53:09 pm »

After playing with it a bit it looks like I can give control back to the main game with a bit of wglMakeCurrent hackery, and saving and restoring the contexts before creating the window, since that wants to override the context, Now the problem is that the SFML window doesn't render, because my context code has overridden it, and the if (Window::SetCurrent()) isn't doing anything because it thinks it already has the context set.

It looks like what I need is to modify SFML to respect an existing context.

If I comment out the

ourCurrent = this;

in

WindowImpl::SetCurrent()

so it doesn't track its own context it seems to work correctly, and both the game and the SFML window render properly it seems. Is wglMakeCurrent expensive to call so often? Is there an alternative to achieve the same effect or is this the only option to address this?

Any recommendations on how this can be cleanly addressed? Is this something that should be handled internal to SFML? Or is it too special case and I should just hack around it?

Thanks
J

20

General discussions / Less formats vs less dependencies ?

« on: October 30, 2007, 04:18:34 pm »

I'm trying to get away from dependencies, as I have a somewhat unique project where I can't depend on an installer to install files to the path, and since no dependencies ever allow you to control what folder they load from I need to avoid them. I would very much like to see a version stripped of its external dependencies(dlls), even if that meant slightly reduced functionality.

21

Graphics / Renderwindow from an existing process

« on: October 30, 2007, 04:16:27 pm »

I posted this on the SDL mailing list, but in an effort to find an alternative to SDL I found SFML, and as much as I like it, it too suffers from the same problem I'm getting with SDL. I'm hoping this time there will be a workaround for the problem.

Hi all, new subscriber here.

This request might sound a bit odd but please bear with me.

Suppose you have a pre-existing program, in this case an existing game. Enemy Territory to be precise, or slightly more generically the Quake3 and Quake4 engine.

I've set up SFML to allow me to open an additional window from the same process to provide a canvas for debug tools and an attached gui for debugging and such. When I spawn the window, using sf::RenderWindow,  from within the game process the game stops rendering, presumably because it's an OpenGL powered game already, and maybe there can only be 1 OpenGL window to a process by default?

The question is, is there a way around this so one can spawn multiple OpenGL windows from a single process(and still have both render)? In my case I just want to prevent my SFML RenderWindow from breaking the game rendering. The game keeps running, I can break in the code and such, it's just the rendering appears to stop.

Any help greatly appreciated.