to access events.
Todd.
--
Todd Showalter, President,
Electron Jump Games, Inc.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
to be more arbitrary as well.
In terms of raw functionality they're similar, but the differences
are large enough (especially in the way they're used) that they are
better treated separately.
Todd.
--
Todd Showalter, Pr
something), so i can't say whether
wireless devices provide useful UNIQ values.
Todd.
--
Todd Showalter, President,
Electron Jump Games, Inc.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
t as I'd like, but I'm
hoping I can get the code up soon.
Todd.
--
Todd Showalter, President,
Electron Jump Games, Inc.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
I've seen a fair number of "multimedia" keyboards
that have a scroll wheel but no other mouse controls.
http://www.techtastic.ca/reviews/xasercombo.html
As an example. Last time I was in the local computer shop they
had two or three keyboards more or less like that.
to spend the money on
proper post-processing, or else it's even harder than it sounds.
In contrast, 4K is just a clearer picture.
4K could tank; nothing is inevitable. But I don't smell the
stench of death hanging around 4K that haunted 3DTV even before it
launched.
the mouse to interact with it at native res.
>
> I think that's supposed to be solved by wl_pointer giving sub-pixel
> accuracy.
I suppose as long as I know the scale factor, I can reverse the scaling.
Todd.
--
Todd Showalter, President,
Electron Jump Games, Inc.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
available to applications, so
(especially in the case of things like games and image editing
programs) they can make judgements about how to size things for
display elements that aren't part of the gui toolkit. Things like
displaying documents or images "actual size", or games trying to
decide how large they should render their GUI text.
Todd.
--
Todd Showalter, President,
Electron Jump Games, Inc.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
ience (integer scale based somewhat on DPI and somewhat
on screen size) rather than solving the real problem. So, we've got
the iPad Mini displaying 160dpi using the same gui as the iPad 2
displaying 130dpi, and we've got TVs displaying pixel-for-pixel the
same gui as desktop displays.
ften is some sort of lockon, where holding
a button down makes player motion relative to a target (so you can
circle-strafe around an opponent, for example). In cases like this
the focus switch is likely to have broken the player's context
anyways.
the client sees the press and the second release,
but not the initial release.
That doesn't work with axis values, but if the client cares about
deltas it's going to have to clear them on focus change anyways, since
it has already been said that the protocol will not be sending
and set absolutely everything in OSX that I
can to confirm-on-close, because otherwise I get burned too often.
I'm dubious about any focus model that requires me to remember
that window A has one kind of focus, and window B has another
simultaneously. It inevitably leads to pilot error.
eed enter/leave events. The client can be responsible
for cleaning up its own state, though if an initial state is sent on
focus gain that makes things much easier.
I don't see anything here that raises any flags for me; at least
at first reading it seems quite usable.
ooking at LEDs, but
IIRC decoding that happens on the host machine; it just gets a stream of
intensity pixmaps from the device and uses that to calculate position. Which
means there are potentially a lot of interesting things you could do with it if
you know a little
boards are the kinds of games you tend to
want access to the mouse. That's not to say that nobody will ever use
a gamepad keyboard in a game on Linux, but I'd argue it's on thin
enough ground that I wouldn't let it drive the design considerations.
Decelerate/accelerate would cover all the cases I can think of.
> But it's also a totally orthogonal discussion. :)
True enough. :)
Todd.
--
Todd Showalter, President,
Electron Jump Games, Inc.
ere.
So, tackling accelerometers as a protocol is a bit of an
interesting balancing act, much harder (or at least, with more
potentially annoying decisions about tradeoffs) than the gamepad one.
Todd.
--
Todd Showalter, President,
Electron Jump Ga
ch of things it would
otherwise need to explicitly support, and it means that things happen
consistently between games. It also means that any bugs in the
process will be addressable without shipping a new build of the game.
Todd.
--
Todd Showalter, Pr
me just physically
unplugging and replugging gamepads than they are figuring out a GUI
they've never (or rarely) seen before.
Todd.
--
Todd Showalter, President,
Electron Jump Games, Inc.
___
wayland-devel mail
On Thu, May 2, 2013 at 5:44 AM, Pekka Paalanen wrote:
> On Tue, 30 Apr 2013 09:14:48 -0400
> Todd Showalter wrote:
>
>> I'm getting set up to write code. Someone kindly gave me a bash
>> script to pull down all the components, so once I get things set up
>>
s to and raise designated window upon home button press"
functionality. That said, the game could just trap the home button
itself and hand off to the BP window, assuming that's possible
somehow.
Todd.
--
Todd Showalter, President,
Electro
tiple local players on the same screen, wl_seat
> would be just a player id.
>
> Does this clarify what I was talking about?
Ok, that makes sense. So, from the game point of view, if each
gamepad lives in its own wl_seat, how does the game detect that new
gamepads have arrived or gone away? I assume there are wl_seat
create/destroy events?
Todd.
--
Todd Showalter, President,
Electron Jump Games, Inc.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
t nobody wants the security nightmare of
arbitrary event filtering. The home button is a system meta event, so it's
reasonable to have other processes watching it.
I suppose it could be a broadcast event...
Todd.
--
Todd Showalter, President
E
Which works
just great, because their pure digital controller buttons always
return 1.0f when touched. At which point the people with pressure
sensitive buttons file bugs saying "why do I have to really hammer the
buttons to get the menu to come up?".
On Mon, Apr 29, 2013 at 9:57 AM, Bengt Richter wrote:
> On 04/27/2013 03:05 AM Todd Showalter wrote:
>> stick.x = ((float)raw_x) / (raw_x>= 0) ? 127.0f : 128.0f;
>> stick.y = ((float)raw_y) / (raw_y>= 0) ? 127.0f : 128.0f;
>>
> I'm not an electronics or game eq
, gamepad settings, and
GUI buttons to do things like quit the game, which is useful in
single-screen environments where the game is running full-screen.
Splitting it off isn't essential.
> I agree with Jason here, the interface can be extended later as needed,
> so no need for a
different problem domain that wants its own protocol, and (2)
I'm not sure there's enough commonality or sanity in rumble hardware
to build a useful protocol.
Todd.
--
Todd Showalter, President,
Electron Jump Games, Inc.
___
apparently spits out piles of quaternions, and also
things like hardcore flightsticks that have things like fixed-range
throttles. I'm not convinced it's needed either, but I figured if I
was making a proposed protocol it was worth throwing it in for the
sake of discussion.
Todd.
--
Todd Showalter, President,
Electron Jump Games, Inc.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
historical hardware) is linearly mapped
signed byte or unsigned byte axis values, I think a protocol that's
going to be relatively future proof needs to handle higher precision
and convert well to float. Most games are going to want the sticks to
map cleanly to either digital up/down/left/right bu
rdinal identifying the event subtype
a -- uint -- first parameter
b -- uint -- second parameter
c -- uint -- third parameter
d -- uint -- fourth parameter
----
On 2013-04-25, at 5:38 AM, Henri Tuhola wrote:
> On Thu, Apr 25, 2013 at 1:29 AM, Todd Showalter wrote:
>>
>> Yes, definitely. Which also leads to the whole device naming
>> question; ie: if someone unplugs a controller and plugs it back in,
>> how do you make s
So, the x and y
buttons are in the swapped and the a and b buttons are swapped. As a
result, I tend to prefer something more abstract.
Actually, IIRC for a while in the original PlayStation libraries
you had the option of referring to the face buttons as if they were a
second dpad; there
as sane and trouble-free as possible,
regardless of what Wayland is sitting on top of. So, I would prefer
things to Just Work on your project as well.
Todd.
--
Todd Showalter, President,
Electron Jump Games, Inc.
This is basically a performance boost
> because input events no longer pass through the compositor.
> However, this mechanism could be easily used to forward any other
> input fd to clients. A wl_gamepad interface could be just empty except
> for this FD-passing logic.
Being able to talk to the gamepads through evdev without elevated
permissions would definitely be a step forward.
Todd.
--
Todd Showalter, President,
Electron Jump Games, Inc.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
evtest:
> http://cgit.freedesktop.org/evtest/
> Was that what you used to check the controller events?
Previously, I'd been dumping data from the libjsw interface, and
then dumping data by going directly through evdev. This time I used
evtest.
with. We're
>> essentially talking about an ordered set of deltas or positions
>> covering a 16.67ms snapshot of time. The timeframe isn't long enough
>> that the intersample time provides any useful nuance, at least not
>> with input from humans.
>
> Are yo
eofday()
at the beginning of that frame update told me, it's good enough for my
purposes. With more mechanical things it's generally safe to assume
the data is evenly spaced across the duration of the timeslice it came
from.
> Therefore we would need a protocol extension to ask in w
ving multiple people their own mouse
pointers on the same screen.
It's only really the standard gamepad case that I would really
like to see solved. The rest is inessential, though nice to have.
Todd.
--
Todd Showalter, President,
Elect
> visible, or moving into a hot-spot and triggering an unexpected effect.
I think edge resistance/edge snapping really wants pointer warping as well.
Todd.
--
Todd Showalter, President,
Electro
On Sat, Apr 20, 2013 at 10:31 PM, Todd Showalter wrote:
I hate it when I fat-finger send.
The data just needs to be something like:
typedef struct
{
float x;
float y;
} VEC2;
typedef struct
{
VEC2 l_stick;
VEC2 r_stick;
floatl_shoulder;
floatr_shoulder
the features of every oddball controller, but I'd far
rather have easy support for standard gamepads than the mess we have
now.
The data just needs to be something like:
typedef struct
{
float x;
} VEC2;
typedef struct
{
} GAMEPAD_DATA;
the
protocol makes things more annoying, but I've a strong suspicion it's
one of those things that if you leave it out you'll find that down the
road there's a lot of pressure to find a way to hack it in.
On Fri, Apr 19, 2013 at 2:55 PM, Todd Showalter wrote:
> I suppose you could also handle this with pointer sensitivity
> modification; if you know the document:view ratio is 10:1, you could
> scale the pointer speed by 0.1 when the scroll wheel was grabbed while
> not allo
imulation clock to a single
> client's monitor refresh rate, so I think you have a good point that this
> can be a downfall of such event delivery.
If it's once per frame, that's good enough. The latency inherent
in online means that 60Hz quantization is the least of
f either a vsync clock (consoles, mostly) or a millisecond clock
(gettimeofday() or the platform equivalent). Anything coming in we
typically try to relate to those. Some sort of timestamp we could
relate to an actual world clock would be important; without it we'd be
into calculating t
field,
> otherwise I'd give it a hacking attempt myself.
>
> So yeah, for now I think SDL should serve you perfectly well =)
SDL works, but it's not ideal; SDL maintains a lot of the desktop
impedance mismatch with games that desktop environments have without
it.
y with the standard desktop model.
Is there a roadmap for input support I can look over? Is there
anything I can do to help make Wayland game-friendly?
Todd.
--
Todd Showalter, President,
Electron Jump
47 matches
Mail list logo
