Hi
Does SDL 1.3 require rendering to be done in the same thread as that which initialised SDL, as 1.2 did?
A client has an interesting system which “hooks” into D3D and takes over the window, but it requires my app to just render the screen every now and then.
Sadly, their system actually pauses my app process at the OS level, so my app knows nothing about it, and no rendering happens! Doh.
Thanks
Ed
I believe most renders will not be happy if you use a separate thread.
We’ll probably need some more information to help you out a bit more, but it
sounds like you could just use one thread, and update on some sort of SDL
user-defined event.
Take care,
-OzOn Tue, May 3, 2011 at 7:43 AM, ebyard <e_byard at yahoo.co.uk> wrote:
Hi
Does SDL 1.3 require rendering to be done in the same thread as that which
initialised SDL, as 1.2 did?A client has an interesting system which “hooks” into D3D and takes over
the window, but it requires my app to just render the screen every now and
then.
Sadly, their system actually pauses my app process at the OS level, so my
app knows nothing about it, and no rendering happens! Doh.Thanks
Ed
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Oz
Thanks for the help - there isn’t really too much else I can tell you.
Their system does actually tell the game it’s going to be “paused” just before it happens, and supplies you with some parameters about how often to refresh the screen, etc but then my app’s render thread (which currently doesn’t exist!) is meant to carry on. I know that other pure D3D systems have a render thread, clearly these guys are expecting the same thing. It’s quite a massive re-write of my game framework, hence trying to find work-arounds. I don’t think there are any though.
Ed
What game are you making a client for?On Tue, May 3, 2011 at 9:02 AM, ebyard <e_byard at yahoo.co.uk> wrote:
Oz
Thanks for the help - there isn’t really too much else I can tell you.
Their system does actually tell the game it’s going to be “paused” just
before it happens, and supplies you with some parameters about how often to
refresh the screen, etc but then my app’s render thread (which currently
doesn’t exist!) is meant to carry on. I know that other pure D3D systems
have a render thread, clearly these guys are expecting the same thing. It’s
quite a massive re-write of my game framework, hence trying to find
work-arounds. I don’t think there are any though.Ed
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
MrOzBarry wrote:
What game are you making a client for?
I develop what are basically slot machines, though nowhere near the Vegas style of games. They’ve just told me I can re-write my game using OpenGL as they have another solution for that. So now I need to check out what is involved in that vs. making it multithreaded, if that’s even possible. Ah the fun of being a developer!
Can you describe more of the setup you have for making this client, and how
the server behaves? It sounds like you may just be over-complicating your
graphics approach.
-OzOn Tue, May 3, 2011 at 9:24 AM, ebyard <e_byard at yahoo.co.uk> wrote:
MrOzBarry wrote:
What game are you making a client for?
I develop what are basically slot machines, though nowhere near the Vegas
style of games. They’ve just told me I can re-write my game using OpenGL as
they have another solution for that. So now I need to check out what is
involved in that vs. making it multithreaded, if that’s even possible. Ah
the fun of being a developer!
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Not much I can tell you, other than I get an API DLL with some “documentation”.
They have this “D3D hook” that somehow hijacks the game and pauses it’s process when a certain event happens (user input). Your game has no knowledge of this happening other than a callback function which is called just before the game is about to be paused. That callback gives you a frame rate for your render thread to use.
I don’t have a render thread.
Their API takes over and does whatever it needs to, theoretically my render thread would be updating the screen (calling SDL_RenderPresent, I imagine) during this time and therefore displaying whatever stuff they’ve injected into display memory, until an event happens and my game process is re-awakened, after which a callback is triggered telling my game that it can continue.
Mad? Yep.
why don’t I envy you right now?On Tue, May 3, 2011 at 6:49 PM, ebyard <e_byard at yahoo.co.uk> wrote:
Not much I can tell you, other than I get an API DLL with some
"documentation".
They have this “D3D hook” that somehow hijacks the game […]