Is there a well-defined range of SDL_Keycode values which are (or
could be) reserved for application use?
My use-case is that I would like to uniformly represent “real” keys
and synthesised keys that come from user-defined key bindings. That
is, the user will be able to bind one or more keys to the virtual
"Fire Lasers" key, and the binding layer will synthesise key events
for that Fire Laser key, which are then dispatched through the same
mechanism as real SDL key events.
SDL_Keycode has a 32-bit range (31-bit if you particularly want to
avoid negative values for some reason), so it has plenty of space I
think, but to avoid potential problems, I’d like to pick a range that
I can be confident won’t be touched in the future if SDL_Keycode is
extended.
2013/10/31 John Bartholomew <jpa.bartholomew at gmail.com>
Is there a well-defined range of SDL_Keycode values which are (or
could be) reserved for application use?
My use-case is that I would like to uniformly represent “real” keys
and synthesised keys that come from user-defined key bindings. That
is, the user will be able to bind one or more keys to the virtual
"Fire Lasers" key, and the binding layer will synthesise key events
for that Fire Laser key, which are then dispatched through the same
mechanism as real SDL key events.
SDL_Keycode has a 32-bit range (31-bit if you particularly want to
avoid negative values for some reason), so it has plenty of space I
think, but to avoid potential problems, I’d like to pick a range that
I can be confident won’t be touched in the future if SDL_Keycode is
extended.
John B
Why do you have to abuse the key event structure for this? Can’t you
just queue a “fire lasers event” when the respective key(s) are pressed?
Sure I could, but then I’d be duplicating a whole load of general
event dispatch code because I would have two different event types
that are doing exactly the same thing (just with different value
ranges). Since I don’t like code duplication, I would prefer not to do
that.
John BOn Thu, Oct 31, 2013 at 6:59 PM, Jonas Kulla wrote:
Why do you have to abuse the key event structure for this? Can’t you
just queue a “fire lasers event” when the respective key(s) are pressed?
2013/10/31 John Bartholomew <jpa.bartholomew at gmail.com>> On Thu, Oct 31, 2013 at 6:59 PM, Jonas Kulla <@Jonas_Kulla> wrote:
Why do you have to abuse the key event structure for this? Can’t you
just queue a “fire lasers event” when the respective key(s) are pressed?
Sure I could, but then I’d be duplicating a whole load of general
event dispatch code because I would have two different event types
that are doing exactly the same thing (just with different value
ranges). Since I don’t like code duplication, I would prefer not to do
that.
? I assume you have some handler inside your SDL event polling loop that
listens for those key events. Is it so much code to change that to listen
for
custom SDL events instead?
I’m sorry, I’m not really interested in having an extended discussion
of Pioneer’s event dispatch code. If you really care, the relevant
code is at:
Please feel free to come and fix it for us.
In the mean time, perhaps we could return to my actual question.
Is there any range of SDL_Keycode values which could be safely used
for application-specific purposes? If not, then how would the SDL
maintainers feel about defining such a range?
John BOn Thu, Oct 31, 2013 at 8:03 PM, Jonas Kulla wrote:
? I assume you have some handler inside your SDL event polling loop that
listens for those key events. Is it so much code to change that to listen
for custom SDL events instead?
Alright, so lets say for some reason you really want to do this.
SDL_keycode is a signed int32, the lowest value of which is currently
defined as 0 (SDLK_UNKNOWN), take any value lower than 0 and you
should be safe.
However, I remind you, there is virtually no valid reason to do so.On Thu, Oct 31, 2013 at 5:02 PM, Andre D <@Andre_D> wrote:
Alright, so lets say for some reason you really want to do this.
SDL_keycode is a signed int32, the lowest value of which is currently
defined as 0 (SDLK_UNKNOWN), take any value lower than 0 and you
should be safe.
Quoth John Bartholomew <jpa.bartholomew at gmail.com>, on 2013-10-31 17:33:24 +0000:
My use-case is that I would like to uniformly represent “real” keys
and synthesised keys that come from user-defined key bindings.
I would say this is not part of SDL’s job. SDL core events correspond
to device events. If you need to translate them to a different kind
of events inside your application, make your own data structure and
use that. If you need to stuff that structure back into the SDL event
loop, use SDL_RegisterEvents to get your own event code. If you need
to handle both “physical” and “binding-oriented” keycodes in the same
place for some reason, have your data structure include a toggle.
Unless the SDL folks proper disagree, I would say screw around with
the values at your own risk.
Quoth Jonathan Dearborn , on 2013-11-01 08:53:57 -0400:
I agree that a user event is a good approach, but I don’t think John’s
approach is going to break anything.
Unless there’s a compatibility guarantee as part of the library
interface that (say) no new keycodes will be defined in a particular
region—and I don’t see that there is—one should assume that it may
break things in the presence of a future SDL version or perhaps even
different hardware or such.
One could compensate for this with other forms of input mangling, by
just “muting” those codes as physical codes, or insisting that if
those physical keycodes exist that they be bound a certain way. That
would be environmentally suboptimal, because if everyone does that in
different ways, eventually, users, hardware manufacturers, etc. may be
practically unable to define new keys without having to look up what
every application developer is doing first. (Admittedly the practical
risk in this particular case is not high because keyboard layouts are
not presently in constant flux, but to me it’s a matter of principle
of not littering the space.)
If there is such a part of the interface that I’ve missed, then of
course I am wrong about that, in which case that should be brought up
specifically and then the OP should take advantage of that and conform
to it.