[etoys-dev] Handling keyboard events

[Ricardo Moran]

Well, it seems I was being very naive when trying to implement this... :)

I really like your single-key morph idea. It would allow you to configure
your keyboard before running the game, so it will work on any platform,
right?

Cheers
Richo

On Sat, Jul 31, 2010 at 4:52 PM, Bert Freudenberg <bert at freudenbergs.de>wrote:

> [moving to a more appropriate list]
>
> Unfortunately, keyUp/keyDown event codes are different between VMs on
> different platforms. They are supposed to refer to physical keys. E.g. the
> Windows VM produces keycode 65 when you press "A", independent of the shift
> key. On Linux I think you get either 65 or 97 depending on caps lock and the
> shift key. On an American Apple keyboard you get 0 for "A", 1 for "S",  2
> for "D" (*). It gets even more funny on all platforms when you involve
> modifier keys (like Alt-A makes Ä etc). Or  in countries which do not use
> latin scripts, you might get values way outside the ASCII range anyway.
>
> So up/down events are generally not used in Squeak (except for a few
> games). There is a reason we have not exposed this in Etoys yet, because we
> can't, unless we change the VMs or rewrite the keyboard handling code in the
> system. We might borrow the latter from Pharo, I know Michael worked on it,
> but I haven't actually looked yet.
>
> Your approach with an array won't work anyway because keycodes can be much
> larger than a byte. A Set of the currently pressed key codes would be more
> appropriate (that's how we implemented keyboard support in our games at
> impara).
>
> My suggestion would be to make a single-key morph. When you click it, it
> would allow you to press the key you want. It would have only a single slot
> named "pressed" to be used in tile scripts. You would make as many of these
> as you want scripts to expose.
>
> For your particular purpose, you could just add cursor-key handling to the
> Joystick morph. Map the arrow keys to the eight directions, and space to
> button 1 and return to button 2.
>
> - Bert -
>
> (*) google for "mac virtual keycode"
>
> On 29.07.2010, at 01:03, Ricardo Moran wrote:
>
> Mmm... I really don't know. I didn't think there would be so much
> difference between platforms. I guess I was wrong... I won't be able to test
> on a Mac, but tomorrow I'll test in a linux computer and I'll see how
> different it is from Windows.
>
> Cheers
> Richo
>
> On Thu, Jul 29, 2010 at 1:38 AM, Randall Caton <rcaton at cnu.edu> wrote:
>
>> Dear Richo,
>>
>> Great tools. They don't work on the Mac. How hard is it to make it work on
>> the Mac or is there a key mapping? I tried to change the up key to the a key
>> and still couldn't move the ship. Maybe I did something wrong.
>>
>> Randy
>>
>>
>> On Wed, Jul 28, 2010 at 12:38 PM, Ricardo Moran <richi.moran at gmail.com>wrote:
>>
>>> Hi guys,
>>>
>>> I may have diverged from the actual GSoC requirements but yesterday I was
>>> looking at Morphic events and I made this simple object called KeyboardMorph
>>> which I believe it could be useful to handle keyboard events better than
>>> what we currently have.
>>>
>>> I made an Asteroids remake to test it:
>>> http://tecnodacta.com.ar/gira/gsoc/Asteroids.051.pr. I did this project
>>> some time ago and I felt really dissapointed at that time because Etoys
>>> keyboard support wasn't enough to play with it so I made it work with a
>>> joystick. Now you can choose between joystick or keyboard :)
>>>
>>> Please note that to handle multiple keys simultaneously the KeyboardMorph
>>> has a set of boolean slots to test if a specific key is currently pressed or
>>> not. I only added support for number, letters, and a few special keys
>>> (space, enter, arrows). I think this is more than enough for most purposes.
>>> I also added a currentKeyValue slot which returns the key value of the
>>> currently pressed key.
>>>
>>> I know different keyboards have different layouts, maybe we can make
>>> specific KeyboardMorphs for each supported layout. What do you think?
>>>
>>> Cheers
>>> Richo
>>>
>>
>>
>>
>> --
>> The views expressed in this email are my own
>> and not necessarily those of CNU.
>>
>> Randall Caton
>> 41596 Bald Eagle Drive
>> Bigfork, MN 56628
>> 218-832-3490
>>
>> email: rcaton at cnu.edu
>> web: www.pcs.cnu.edu/~rcaton
>>
>
>
>
>
> _______________________________________________
> etoys-dev mailing list
> etoys-dev at squeakland.org
> http://lists.squeakland.org/mailman/listinfo/etoys-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakland.org/pipermail/etoys-dev/attachments/20100731/4436a13d/attachment.html>