Multiple SDL Windows again

SDL Development
21

David Olofson wrote:

Yeah… However, it’s not as simple as “send all events to the window under
the mouse pointer…”

The usual solution seems to be to add the concepts “focused window”, “mouse
capture” and a few other, rather simple “filters”, and then provide an API
for that, for toolkits and to some extent, applications, to use. Every window
would have some kind of “event port”.

Idea: If a window isn’t equipped with an event port, the events can fall
through to it’s parent, or something… Would make it possible to use the
same window abstraction like a more lightweight overlapping + clipping
rendering control primitive; an advanced cliprect object.

This is all true, and I agree with all of it. My point here though is
mostly that events in SDL are (currently) global. They are not
attached to a window in any way. And the event data doesn’t tell
you which window it is sent for either.
So, to support events for multiple windows, we will need some
way to change the SDL event API.

So I just thought that going “around” SDL for the moment would
be a hack (although very nasty) that makes anything possible.
It means that one will have to respond to native OS events -
but at least it makes multiple windows with events and all
possible :slight_smile:

Considering that there already are things like flags for borderless windows,
fullscreen mode etc, it sounds like supporting multiple screen surfaces is
just another step - which could be extended with some way of snapping in
window managers for fullscreen modes and that kind of stuff. (In that case,
the fullscreen window manager would do the event dispatching, pretty much
like the target’s WM does with “normal” windows. No difference for SDL
applications.)

It would be logical that these fullscreen window managers would show up
behind the existing window manager API, of course. In fact, the current SDL
WM code could probably use the same “plugin” API as the fullscreen window
managers.

It might be a good idea to make sure that “WM inside WM” is possible, though.
Most importantly, that would allow a custom WM to be used inside a normal
window on windowed target.

Well, again - I’m not looking for the “Right Solution ™” at the
moment… just something that will get the job done, without having
to abandon all the great stuff in SDL :slight_smile:

Maybe what you are thinking of would be the right way in the
long term, but… I just want something that "works for now"
and doesn’t break anything in SDL - until the right design
comes around :slight_smile:

BTW, note that I’m thinking in terms of what may make sense for SDL 1.3, but
might be messy to hack into 1.2. Without multiple screen surface support and
complex region clipping, only half of the features can be done right… And
why mess with it if it’s going to be done right anyway? :slight_smile:

Well, the deadline for SDL 1.3 just seems too long - and naturally
it’s better to spend enough time to get 1.3 right than to
make it yet another hack… but until then, a good and useful
hack might be a good idea :slight_smile:

It’s probably possible to come up with some shortcut, but I’m failing to see
one that both provides something truly useful, and is still clean and
portable…

It’s not portable - nor intended to be. But I still think it can be
quite clean. And having access to interoperating with the native
OS sounds useful to me… There are times where an OS have features
which are just too special for a crossplatform API…

I’ll give a very quick idea of what I have in mind:

For Win32:----------
SDL_Surface SDLWin32_CreateRGBSurfaceForHWND
(Uint32 flags, int width, int height, int depth,
Uint32 Rmask, Uint32 Gmask, Uint32 Bmask, Uint32 Amask,
HWND alreadyCreatedWindow
/ + some more SDL/Win32 specific parameters? */ );

HWND SDLWin32_CreateWindow(/* Standard SDL params for an SDL_Surface /
Uint32 flags, int width, int height, int
depth,
Uint32 Rmask, Uint32 Gmask, Uint32 Bmask,
Uint32 Amask,
/ These are just the standard parameters for
the Win32 API function CreateWindow… /
LPCSTR lpClassName, / name of window
class /
LPCSTR lpWinName, / title of window
/
DWORD dwStyle, / type of window /
int X, int Y, / top-left
co-ordinates /
/ This is redundant with the SDL params…
int Width, int Height, / /
dimensions of window /
HWND hParent, / handle of parent
window /
HINSTANCE hThisInst, / handle of
creator /
LPVOID lpszAdditional / pointer to
additional info */
);

HWND SDLWin32_CreateWindowLikeSurface(SDL_Surface compatible,
/ The CreateWindow params goes
here like above… */
);

For X-Windows etc., you could add similar functions…

Cheers

http://www.HardcoreProcessing.com

22

David Olofson wrote:

Yeah… However, it’s not as simple as “send all events to the window
under the mouse pointer…”

The usual solution seems to be to add the concepts “focused window”,
“mouse capture” and a few other, rather simple “filters”, and then
provide an API for that, for toolkits and to some extent, applications,
to use. Every window would have some kind of “event port”.

Idea: If a window isn’t equipped with an event port, the events can fall
through to it’s parent, or something… Would make it possible to use the
same window abstraction like a more lightweight overlapping + clipping
rendering control primitive; an advanced cliprect object.

This is all true, and I agree with all of it. My point here though is
mostly that events in SDL are (currently) global. They are not
attached to a window in any way. And the event data doesn’t tell
you which window it is sent for either.
So, to support events for multiple windows, we will need some
way to change the SDL event API.

Yes, and I’m suspecting that this, from an API POV, would come as a rather
natural result of supporting more than one screen surface…

So I just thought that going “around” SDL for the moment would
be a hack (although very nasty) that makes anything possible.
It means that one will have to respond to native OS events -
but at least it makes multiple windows with events and all
possible :slight_smile:

Makes sense if you really need it right now (which I don’t - I need to finish
some other stuff before digging into new stuff for once heh), but it still
seems messy to bypass the SDL event system… How about pumping them all in
the normal way, but adding some “source” field to the event struct? (What I’m
after is something that would be more similar to the future API than not
using anything SDL at all.)

Considering that there already are things like flags for borderless
windows, fullscreen mode etc, it sounds like supporting multiple screen
surfaces is just another step - which could be extended with some way of
snapping in window managers for fullscreen modes and that kind of stuff.
(In that case, the fullscreen window manager would do the event
dispatching, pretty much like the target’s WM does with “normal” windows.
No difference for SDL applications.)

It would be logical that these fullscreen window managers would show up
behind the existing window manager API, of course. In fact, the current
SDL WM code could probably use the same “plugin” API as the fullscreen
window managers.

It might be a good idea to make sure that “WM inside WM” is possible,
though. Most importantly, that would allow a custom WM to be used inside
a normal window on windowed target.

Well, again - I’m not looking for the “Right Solution ™” at the
moment… just something that will get the job done, without having
to abandon all the great stuff in SDL :slight_smile:

Maybe what you are thinking of would be the right way in the
long term, but… I just want something that "works for now"
and doesn’t break anything in SDL - until the right design
comes around :slight_smile:

Ok, makes sense, although I’ve experienced the "too simple becomes too messy"
effect quite a few times… Why you try to make something work really
quick, without even trying to cover the kludges with some kind of sensible
API, you often end up wasting a lot more time messing with your application
code than you would have needed to hack better solution in the first place.

In short, don’t make the quick hack too simple. :slight_smile:

BTW, note that I’m thinking in terms of what may make sense for SDL 1.3,
but might be messy to hack into 1.2. Without multiple screen surface
support and complex region clipping, only half of the features can be
done right… And why mess with it if it’s going to be done right anyway?
:slight_smile:

Well, the deadline for SDL 1.3 just seems too long - and naturally
it’s better to spend enough time to get 1.3 right than to
make it yet another hack… but until then, a good and useful
hack might be a good idea :slight_smile:

Yes.

Actually, if things would turn out the way I want for once, I’d need that
hack before the SDL 1.3 deadline, but something tells me that won’t happen…
(Yes, The Source is failing me, and there’s nothing much I can do about it
right now… :-/ )

It’s probably possible to come up with some shortcut, but I’m failing to
see one that both provides something truly useful, and is still clean and
portable…

It’s not portable - nor intended to be. But I still think it can be
quite clean. And having access to interoperating with the native
OS sounds useful to me… There are times where an OS have features
which are just too special for a crossplatform API…

Sure, I’m just not sure if that applies in the case of multiple "screen"
surfaces… I have a simple idea, though. (More below…)

I’ll give a very quick idea of what I have in mind:

For Win32:

SDL_Surface SDLWin32_CreateRGBSurfaceForHWND
(Uint32 flags, int width, int height, int depth,
Uint32 Rmask, Uint32 Gmask, Uint32 Bmask, Uint32 Amask,
HWND alreadyCreatedWindow
/ + some more SDL/Win32 specific parameters? */ );

Yeah, that’s somewhat like what I figured. However, how about:

SDL_Surface *SDL_CreateRGBSurfaceFromWindow
(Uint32 flags, int width, int height, int depth,
Uint32 Rmask, Uint32 Gmask, Uint32 Bmask, Uint32 Amask,
SDL_Window *window);

where SDL_Window is an “opaque” struct (actually just one that’s
implementation dependant, but public for now, in case you have to fiddle with
it in application code), containing the HWND, pipe handle or whatever, any
additional info (ie your SDL/Win32 specific parameters) and so on.

Then, instead of this very Win32 specific call:

HWND SDLWin32_CreateWindow(/* Standard SDL params for an SDL_Surface /
Uint32 flags, int width, int height, int
depth,
Uint32 Rmask, Uint32 Gmask, Uint32 Bmask,
Uint32 Amask,
/ These are just the standard parameters for
the Win32 API function CreateWindow… /
LPCSTR lpClassName, / name of window
class /
LPCSTR lpWinName, / title of window
/
DWORD dwStyle, / type of window /
int X, int Y, / top-left
co-ordinates /
/ This is redundant with the SDL params…
int Width, int Height, / /
dimensions of window /
HWND hParent, / handle of parent
window /
HINSTANCE hThisInst, / handle of
creator /
LPVOID lpszAdditional / pointer to
additional info */
);

use something like:

SDL_Window SDL_CreateWindow(
/ SDL_SetVideoMode style arguments */
int width, int height, int bpp, Uint32 flags,

	/* Window position */
	int xpos, int ypos,

	/* Window title (or preferably, use SDL_WM_SetCaption()...) */
	const char *title,
	const char *icon,

	/* Parent window */
	SDL_Window *parent
	);

Of course, one could easilly implement funcs like SDL_CreateWindowFromHWND()
and other Win32 specific stuff, as a shortcut in case the portable
SDL_CreateWindow() can’t be made to do the right thin in any sensible way.

HWND SDLWin32_CreateWindowLikeSurface(SDL_Surface compatible,
/ The CreateWindow params goes
here like above… */
);

SDL_Window SDL_CreateWindowFromWindow(
/ SDL_SetVideoMode style arguments */
int width, int height, int bpp, Uint32 flags,

	/* Window position */
	int xpos, int ypos,

	/* Window title (or preferably, use SDL_WM_SetCaption()...) */
	const char *title,
	const char *icon,

	/* "Source" window */
	SDL_Window *window
	);

perhaps?

Taking this another step, it might even be possible to hook the SDL_Window
struct up to the SDL_Surface struct, to get rid of the additional step of
creating a window before creating a surface. (In other words; to get it to
work more like SDL_SetVideoMode(). Maybe SDL_CreateWindow() could just take a
few extra parameters, and return an SDL_Surface directly?)

For X-Windows etc., you could add similar functions…

Of course; I’m just thinking that it might be a good idea to hide the
platform specific formats and datatypes of stuff from the application source,
until you really need to mess with the directly - which doesn’t seem to be
the case if you just want to open another window on the desktop.

Either way, I guess the biggest job is still actually getting the inner
workings of SDL to keep track of more than one “screen” surface… That done,
the rest is “just” about setting “screen” surface instances up, and keeping
track of them. (Just a though: Requiring that all “screen” surfaces have the
same pixel format might simplify things a lot… Not sure, though.)

//David

.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------> http://www.linuxaudiodev.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |--------------------------------------> david at linuxdj.com -'On Saturday 12 May 2001 20:12, Anoq of the Sun wrote:

23

David Olofson wrote:

Ok, makes sense, although I’ve experienced the "too simple becomes too messy"
effect quite a few times… Why you try to make something work really
quick, without even trying to cover the kludges with some kind of sensible
API, you often end up wasting a lot more time messing with your application
code than you would have needed to hack better solution in the first place.

In short, don’t make the quick hack too simple. :slight_smile:

I know that this happens - and I agree :slight_smile:
But it is intended to be good enough to keep in SDL at least :slight_smile:

Yeah, that’s somewhat like what I figured. However, how about:

SDL_Surface *SDL_CreateRGBSurfaceFromWindow
(Uint32 flags, int width, int height, int depth,
Uint32 Rmask, Uint32 Gmask, Uint32 Bmask, Uint32 Amask,
SDL_Window *window);

where SDL_Window is an “opaque” struct (actually just one that’s
implementation dependant, but public for now, in case you have to fiddle with
it in application code), containing the HWND, pipe handle or whatever, any
additional info (ie your SDL/Win32 specific parameters) and so on.

Then, instead of this very Win32 specific call:
…
use something like:

SDL_Window SDL_CreateWindow(
/ SDL_SetVideoMode style arguments */
int width, int height, int bpp, Uint32 flags,

            /* Window position */
            int xpos, int ypos,

            /* Window title (or preferably, use SDL_WM_SetCaption()...) */
            const char *title,
            const char *icon,

            /* Parent window */
            SDL_Window *parent
            );

Of course, one could easilly implement funcs like SDL_CreateWindowFromHWND()
and other Win32 specific stuff, as a shortcut in case the portable
SDL_CreateWindow() can’t be made to do the right thin in any sensible way.

HWND SDLWin32_CreateWindowLikeSurface(SDL_Surface compatible,
/ The CreateWindow params goes
here like above… */
);

SDL_Window SDL_CreateWindowFromWindow(
/ SDL_SetVideoMode style arguments */
int width, int height, int bpp, Uint32 flags,

            /* Window position */
            int xpos, int ypos,

            /* Window title (or preferably, use SDL_WM_SetCaption()...) */
            const char *title,
            const char *icon,

            /* "Source" window */
            SDL_Window *window
            );

perhaps?

This looks OK for a crossplatform API - but then
you still don’t get the opportunity to bypass SDL :slight_smile:

For instance, if at some point I need arbitrary
shaped Windows - or to draw outside the borders of
a window (like on the desktop etc.), then unless
there’s explicit support for it in SDL, there are
only 2 ways:

  1. Modify SDL (again…)
  2. Don’t use SDL at all.

But I would prefer:

  1. Use SDL almost everywhere - but bypass it a few places.

Either way, I guess the biggest job is still actually getting the inner
workings of SDL to keep track of more than one “screen” surface… That done,
the rest is “just” about setting “screen” surface instances up, and keeping
track of them. (Just a though: Requiring that all “screen” surfaces have the
same pixel format might simplify things a lot… Not sure, though.)

Yes that’s true… I’m sure it’s all do-able :slight_smile:

Cheers–
http://www.HardcoreProcessing.com

24

[…API ideas…]

This looks OK for a crossplatform API - but then
you still don’t get the opportunity to bypass SDL :slight_smile:

Why not? Not the use of the SDL_Window struct; in the normal case, it should
be opaque (ie don’t touch it, because it’s contents are platform dependent),
but if you have to mess with the details in application code, you can get
access to all the platform specific stuff via this struct. You could even
create your own window, using platform specific code, and then fill in an
SDL_Window struct yourself, or (preferably), use some non portable "SDL"
function calls to do it.

Likewise for event handling; just publish the platform specific events -> SDL
event pump “hook” so that you can keep SDL from connecting your custom window
to the event system. That way, you can either set “hook” up yourself, adding
some intermediate event processing code, or just don’t connect it at all.

But I would prefer:

  1. Use SDL almost everywhere - but bypass it a few places.

Exactly! I just want to make “few” as few as possible. :slight_smile: Preferably to the
extent that you can write fully portable multi-window SDL code, as long as
you don’t have to fiddle with platform specific details to get the job
done. I think this could be done with the following API changes:

1) Add aforementioned open/close functions for extra windows.

2) Add an SDL_SelectWindow() call, to avoid changing other SDL
   calls. (This function would affect *everything*, including
   which event queue the SDL event management calls operate on.
   That is, each window get's it's own event queue.)

3) Optional: Add calls to deal with multiple windows. (Most
   importantly event management calls, so you don't *have to*
   resort to polling just because you have more than one
   window.)

Alternatively, for 2) and 3), one could go the way I suggested earlier, and
add a “source” field to the event struct. The above solution seems cleaner,
safer and more compatible with the current API, though. (The usual “I could
be missing something” applies, of course. :wink:

Now, if you have to do non-portable hacks, you shouldn’t need to use an
alternative “SDL” API that’s only 50% source code compatible with the normal
API or something. Plugging your custom code in where required (init, cleanup,
event handling… anything else?), to replace the default SDL code should be
enough. (Per window, obviously; not application wide.) That’s what the
SDL_Window struct would be used for, in addition to serving as a window
instance + parameters wrapper.

//David

.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------> http://www.linuxaudiodev.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |--------------------------------------> david at linuxdj.com -'On Wednesday 16 May 2001 12:06, Anoq of the Sun wrote:

25

David Olofson wrote:

Why not? Not the use of the SDL_Window struct; in the normal case, it should
be opaque (ie don’t touch it, because it’s contents are platform dependent),
but if you have to mess with the details in application code, you can get
access to all the platform specific stuff via this struct. You could even
create your own window, using platform specific code, and then fill in an
SDL_Window struct yourself, or (preferably), use some non portable "SDL"
function calls to do it.

Likewise for event handling; just publish the platform specific events -> SDL
event pump “hook” so that you can keep SDL from connecting your custom window
to the event system. That way, you can either set “hook” up yourself, adding
some intermediate event processing code, or just don’t connect it at all.

OK - it actually seems like a quite well-conceived plan :slight_smile:

  1. Use SDL almost everywhere - but bypass it a few places.

Exactly! I just want to make “few” as few as possible. :slight_smile: Preferably to the
extent that you can write fully portable multi-window SDL code, as long as
you don’t have to fiddle with platform specific details to get the job
done. I think this could be done with the following API changes:

    1) Add aforementioned open/close functions for extra windows.

This sounds OK…

    2) Add an SDL_SelectWindow() call, to avoid changing other SDL
       calls. (This function would affect *everything*, including
       which event queue the SDL event management calls operate on.
       That is, each window get's it's own event queue.)

This sounds really bad :slight_smile:

    3) Optional: Add calls to deal with multiple windows. (Most
       importantly event management calls, so you don't *have to*
       resort to polling just because you have more than one
       window.)

Alternatively, for 2) and 3), one could go the way I suggested earlier, and
add a “source” field to the event struct. The above solution seems cleaner,
safer and more compatible with the current API, though. (The usual “I could
be missing something” applies, of course. :wink:

Something like this sounds better :slight_smile:

Now, if you have to do non-portable hacks, you shouldn’t need to use an
alternative “SDL” API that’s only 50% source code compatible with the normal
API or something. Plugging your custom code in where required (init, cleanup,
event handling… anything else?), to replace the default SDL code should be
enough. (Per window, obviously; not application wide.) That’s what the
SDL_Window struct would be used for, in addition to serving as a window
instance + parameters wrapper.

It all sounds quite OK…

It could be done quite nicely with something like this:

  1. Create the SDL_window struct you mentioned and
    the create / destroy functions + maybe some non-
    portable functions for accessing platform-specific
    stuff. Organize the SDL_window struct so that
    all platform dependant stuff is inside a nested
    struct in a field called “native” or something -
    just to keep things cleaner.

  2. For event handling, add new SDL functions like this:

    int SDL_WaitWindowEvent(SDL_event *ev, SDL_window *win)
    int SDL_PollWindowEvent(SDL_event *ev, SDL_window *win)
    etc.

    The returned win parameter tells you which window
    had the event. This is just so that I won’t have to
    change the event structures - so that these API
    changes doesn’t make incompatible API changes to SDL.

  3. Add a non-portable function to allow you to capture
    native events. This would at least be the way to do
    it for Win32…

  4. It would even be nice to be
    able to override the behaviour of repainting the
    screen so that one could even just do native
    Win32 drawing instead of having to use an
    SDL framebuffer for all windows…

Cheers–
http://www.HardcoreProcessing.com

26 
    2) Add an SDL_SelectWindow() call, to avoid changing other SDL
       calls. (This function would affect *everything*, including
       which event queue the SDL event management calls operate on.
       That is, each window get's it's own event queue.)

This sounds really bad :slight_smile:

Yep, but keep in mind that it’s the only way to avoid adding a screen surface
argument to some SDL calls, because this…

Alternatively, for 2) and 3), one could go the way I suggested earlier,
and add a “source” field to the event struct. The above solution seems
cleaner, safer and more compatible with the current API, though. (The
usual “I could be missing something” applies, of course. :wink:

…may sound better, and probably is superior in many ways, but only deals
with the event system! You could do both, of course; handle the event
system using a source field, but use SDL_SelectWindow() instead of changing
the offending calls. Or just make the required API changes to make it work
the Right, but incompatible way, and guarantee that the patch will never go
into SDL 1.2. :slight_smile:

Another solution would be to add new versions of the offending calls with the
extra screen surface argument, wrapping the SDL_SelectWindow() mess. However,
that wouldn’t exactly help standard<->multi-window portability…

Now, if you have to do non-portable hacks, you shouldn’t need to use an
alternative “SDL” API that’s only 50% source code compatible with the
normal API or something. Plugging your custom code in where required
(init, cleanup, event handling… anything else?), to replace the default
SDL code should be enough. (Per window, obviously; not application
wide.) That’s what the SDL_Window struct would be used for, in addition
to serving as a window instance + parameters wrapper.

It all sounds quite OK…

It could be done quite nicely with something like this:

  1. Create the SDL_window struct you mentioned and
    the create / destroy functions + maybe some non-
    portable functions for accessing platform-specific
    stuff. Organize the SDL_window struct so that
    all platform dependant stuff is inside a nested
    struct in a field called “native” or something -
    just to keep things cleaner.

Yep, probably a good idea. Alternatively, one could use a pointer to the
native struct, instead of nesting it in, but that’s really a solution meant
for preserving binary compatibility accross versions. Not very useful if the
"native" struct is to be considered an interface, and totally pointless if
the library is meant for static linking…

  1. For event handling, add new SDL functions like this:

    int SDL_WaitWindowEvent(SDL_event *ev, SDL_window *win)
    int SDL_PollWindowEvent(SDL_event *ev, SDL_window *win)
    etc.

    The returned win parameter tells you which window
    had the event. This is just so that I won’t have to
    change the event structures - so that these API
    changes doesn’t make incompatible API changes to SDL.

It’s normally not a problem adding a field to a struct, as long as you don’t
require binary compatibility…

  1. Add a non-portable function to allow you to capture
    native events. This would at least be the way to do
    it for Win32…

I’d guess it applies to any target. One way or another, SDL code is going to
get hold of every event, and may consult an application specified callback
function after that, instead of translating or handling the event itself.
Just move on to the default code if the callback pointer is NULL.

  1. It would even be nice to be
    able to override the behaviour of repainting the
    screen so that one could even just do native
    Win32 drawing instead of having to use an
    SDL framebuffer for all windows…

Well, yeah, you kind of get that as a bonus feature if you capture the events
early enough in the SDL code, at least on some targets. :slight_smile:

However, I don’t think all events that result in SDL events come from the
same place on all targets: For example, not all targets have a single,
standard “message” system that’s used for nearly all IPC, but use callbacks,
pipes, various IPC interfaces etc. It might be necessary to have multiple
callbacks for some targets.

(Well, one could just insert the callback after SDL has translated the events
into SDL events, but that would require that SDL understands everything
that it could possibly get. Doesn’t sound like a sensible solution.)

//David

.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------> http://www.linuxaudiodev.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |--------------------------------------> david at linuxdj.com -'On Thursday 17 May 2001 13:41, Anoq of the Sun wrote:

27

David Olofson wrote:

Yep, probably a good idea. Alternatively, one could use a pointer to the
native struct, instead of nesting it in, but that’s really a solution meant
for preserving binary compatibility accross versions. Not very useful if the
"native" struct is to be considered an interface, and totally pointless if
the library is meant for static linking…

Hmm - I guess it would be nice with binary compatibility too -
but of course - binary compatibility between multiple
OS’es will probably not be useful for anything, but
there’s of course the compatibility for multiple
backends on the same OS (like DirectX vs. Win32 DIB)…

Cheers–
http://www.HardcoreProcessing.com

28

David Olofson wrote:

Yep, probably a good idea. Alternatively, one could use a pointer to the
native struct, instead of nesting it in, but that’s really a solution
meant for preserving binary compatibility accross versions. Not very
useful if the “native” struct is to be considered an interface, and
totally pointless if the library is meant for static linking…

Hmm - I guess it would be nice with binary compatibility too -
but of course - binary compatibility between multiple
OS’es will probably not be useful for anything,

Not to mention next to impossible to achieve, at least accross CPUs types. :slight_smile:

but
there’s of course the compatibility for multiple
backends on the same OS (like DirectX vs. Win32 DIB)…

Yes, that’s pretty much required - we still want to be able to use all
targets available without switching application binary.

However, what I was thinking about was binary compatibility between different
SDL versions (as long as they have the new SDL_Window struct, obviously) and
application code.

Note that this could matter even if SDL is linked statically to the
application! If an application can load “plugins” that talk directly to SDL,
it’s possible to use the same plugins with host applications linked with
different SDL versions… (Does that make any sense? heh Plugins shouldn’t
rely on libraries imported by the host if it can be avoided, IMHO.)

Oh well, better do it the right way (pointer, rather than nesting), just in
case. :slight_smile:

//David

.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------> http://www.linuxaudiodev.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |--------------------------------------> david at linuxdj.com -'On Friday 18 May 2001 10:12, Anoq of the Sun wrote: