| Re: [AD] Platform specific functions in A5 [was Re: Windows Addition for Message Parsing] |
[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
On 8 Oct 2008, at 15:50, Trent Gamblin wrote:
A possible compromise would be having all the platform specifics of
window events encapsulated in a union, since I'm sure X11/Win/OSX
events are all too different to force into the same structure:
struct ALLEGRO_WINDOW_MESSAGE {
union {
#ifdef ALLEGRO_WINDOWS
struct {
HWND window;
UINT message;
WPARAM wParam;
HPARAM hParam;
} win;
#endif
// unix
// osx
};
};
(well, you get the idea...)
We could have a function to add these messages to an event queue.
There is a problem with this though. Windows requires specific
return codes, different for each message, to be returned from the
wndproc. If you're just firing off events into an event queue and
then letting the default window procedure handle the event, that may
and most likely will be a big problem. So I think the patch stands
as being better than this method.
It also doesn't actually solve the problem, because with that setup
you'd need to parse the messages differently on different platforms.
In that case, yes, a platform specific function would be better.
Something else I'd like to say is, portability is good, but removing
platform specific features only hurts the end user. If a user wants
to make a game for X11 only, so be it. However I myself make every
effort to make my games portable across Windows and Linux (as those
are the two OSs I have access to). Does this mean I don't use any
non-portable code? No. In my current game I'm using Direct3D pixel
shaders. When I get around to the Linux port I will use OpenGL
shaders. Where would I be if those two things weren't possible? Some
portable hacky shader API? No shaders at all?
Hmm. Ok, fair enough I guess. Although the correct answer would of
course be, use a shader front end that could use either of those as a
backend.
Again: we have an opportunity to make a clean platform-neutral design
and we should try to make the best of it. Platform specific functions
are a last resort (but yes, sometimes they may be necessary).
Every platform has unique features and I think it's reasonable in
some cases to allow access to those features.
Sure, but where do you draw the line? It's a very slippery slope to
get onto.
So anyway, there's two questions here:
1. do we want a platform specific function for Windows that allows
the user to intercept the Windows messages?
2. specific to this particular patch, do we provide this for the few
people who want to do something like support multiple mice?
The answer to the first question, I think, is maybe, or a cautious
and well thought-out yes. The answer to the second question is no. If
we want to provide people with the option of using multiple mice,
then this is not the way to go. Or in other words, adding it for that
reason is adding it for the wrong reason.
Evert