[etoys-dev] Handling keyboard events

Ricardo Moran richi.moran at gmail.com
Sat Jul 31 22:55:50 EDT 2010

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,


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>

More information about the etoys-dev mailing list