[pygame] keyboard layout problems
I'm using pygame on a computer with a German keyboard on a Windows machine. On this keyboard y and z keys are exchanged for example. Now - on my machin - event.key == K.z gets True if I pressed the y key and vice versa. How can I overcome this? (I know that this problem doesn't occur atleast on some Linux Boxes.) Regards, Gregor
Re: [pygame] keyboard layout problems
Gregor Lingl wrote: I'm using pygame on a computer with a German keyboard on a Windows machine. On this keyboard y and z keys are exchanged for example. Now - on my machin - event.key == K.z gets True if I pressed the y key and vice versa. How can I overcome this? (I know that this problem doesn't occur atleast on some Linux Boxes.) It looks like on Linux that SDL wants "kbd_lang=de". I don't know if setting this environment variable will help on windows? It sounds like SDL's international keyboard support is poor. You can also check event.unicode to get a unicode string of the letter pressed. This will likely be the correct letter, but it is also effects by things like shift, capslock, and other modifiers.
Re: [pygame] keyboard layout problems
If worst comes to worst, you could just set K_z, K_y, and so on. That's obviously not an ideal solution; I hope fixing it like Peter says works. Ian
Re: [pygame] extending mask module?
Regarding shared (dynamic) libraries I am have only used Windows DLLs. Unix shared libraries are similar. Michael George wrote: The part I was and am still a bit confused about is name clashes. If I understand correctly, python extension modules are supposed to only export the initmodule method in order to avoid name clashes, which is why the docs say everything should be static. But if bitmask is linked in to the module, then won't it's functions be exported? If not, then is it possible for me to call them, or do I need to link bitmask into my code as well? And how is bitmask different than SDL in terms of how it's linked, if at all? Name clashes were a concern in the past when extension modules were statically linked to the Python interpreter, as was necessary with DOS. I assume no modern operating system requires this, so name clashes are no longer an issue. (See below.) If anyone is still statically linking the Pygame extension modules they haven't complained about name conflicts yet. Besides, all the bitmask names are mangled with a prefix. As to accessing the bitmask functions it depends on what you want. See below. There is no difference between bitmask and SDL when it comes to name clashes. SDL function names are resolved by the linker at build time, just as with bitmask. SDL functions appear in the mask namespace just as bitmask functions do. See below. Sorry, I feel like I'm saying a bunch of nonsense, but I'm having a hard time making sense of all this dynamic linking stuff. Shared (dynamic) libraries are somewhat like programs. Just as with a program, non-static functions and global variables can be local to the library. But where as a program has a single entry point, a main function, a shared library can have many. These are the exported functions and variables of the library. They form the API. Only these can be directly accessed by other programs or shared libraries. For Windows shared libraries (Dynamic Link Libraries or DLLs) the linker has to be told which non-static functions and global variables get exported. Everything else remains local to the DLL. For Unix shared libraries I believe all non-static functions and global variables are exported by default. I think gcc has ways around this though. But for Python extension modules this is not a problem. There are two ways to use a shared library. The first is to load the library dynamically during program execution. Explicit system calls are made to load the library and get pointers to its exported functions and data. This is how the Python interpreter loads extension modules. No name conflicts between extension modules are possible in this case. The ctypes package, introduced in Python 2.5, wraps the dynamic load mechanism, so any shared library is accessible from within Python. The second way to use a shared library is to have the program loader do the linking at startup. An import library, a proxy to the shared library, stands in for the library when building a program. The import library looks just like any static module. Exported functions and data look just like non-static functions and global variables to the program. So name clashes are possible with other non-static names in the program. Exported names are resolved dynamically at program load time rather than statically at build time. A shared library is loaded only once, when the first program that uses it is loaded. Other programs share the library's memory image. This is how mask and other Pygame extension modules link to SDL. I don't suggest making bitmask a shared library. The only shared libraries Python's distutils knows how to build are extension modules. What I'm doing now is adding a CObject to the mask module for the PyMask_Type, and then compiling my code against bitmask.h (which I'm leaving as-is) and mask.h (which looks like some of the other header files, and exports a C API with a bunch of #defines). So I'm assuming I'll need to use CObjects to get at stuff in mask.c (the Type in particular), but I can link directly to the stuff in bitmask. If you are just extending the mask module itself then the bitmask functions will be visible to your code. Just add any new C files to the mask entry in Setup.in. They will be compiled and linked to mask and bitmask automatically. Remember to run config.py after any changes to Setup.in. Name the non-static functions with a prefix like bitmap_. Any new Python functions go into mask.c itself and remain static. If you are adding a new extension module then the simplest solution is to just include bitmask.c in that module as well. If you are concerned about name clashes then copy the bitmask.c file as bitmask2.c and rename the functions: bitmap2_* maybe. Also unused code can be removed. The third option is to do as you suggest and export pointers to mask's bitmask functions using the PyCObject mechanism. On an unrelated note, I'm looki
Re: [pygame] extending mask module?
Just something more I noticed. Lenard Lindstrom wrote: Regarding shared (dynamic) libraries I am have only used Windows DLLs. Unix shared libraries are similar. Michael George wrote: The part I was and am still a bit confused about is name clashes. If I understand correctly, python extension modules are supposed to only export the initmodule method in order to avoid name clashes, which is why the docs say everything should be static. [snip] Name clashes were a concern in the past when extension modules were statically linked to the Python interpreter, as was necessary with DOS. I assume no modern operating system requires this, so name clashes are no longer an issue. (See below.) If anyone is still statically linking the Pygame extension modules they haven't complained about name conflicts yet. Besides, all the bitmask names are mangled with a prefix. I see that the distutils package has an option for exporting names from an extension module on Windows. So if only the init function is non-static why provide a way to export other non-static names? I would like to know where in the Python documentation is says that only init functions be non-static. It is apparently outdated advice. -- Lenard Lindstrom <[EMAIL PROTECTED]>
[pygame] patch to export mask api
I've attached a patch that exposes the mask api in a separate header file. Right now it only provides the type object. It follows the same convention as the other exported apis. --Mike /* Copyright (C) 2002-2007 Ulf Ekstrom except for the bitcount function. This wrapper code was originally written by Danny van Bruggen(?) for the SCAM library, it was then converted by Ulf Ekstrom to wrap the bitmask library, a spinoff from SCAM. This library is free software; you can redistribute it and/or modify it under the terms of the GNU Library General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. This library is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Library General Public License for more details. You should have received a copy of the GNU Library General Public License along with this library; if not, write to the Free Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA */ /* a couple of print debugging helpers */ /* #define CALLLOG2(x,y) fprintf(stderr, (x), (y)); #define CALLLOG(x) fprintf(stderr, (x)); */ #define PYGAMEAPI_MASK_INTERNAL 1 #include "mask.h" #include "pygame.h" #include "pygamedocs.h" #include "structmember.h" #include "bitmask.h" #include #ifndef M_PI #define M_PI 3.14159265358979323846 #endif staticforward PyTypeObject PyMask_Type; /* mask object methods */ static PyObject* mask_get_size(PyObject* self, PyObject* args) { bitmask_t *mask = PyMask_AsBitmap(self); if(!PyArg_ParseTuple(args, "")) return NULL; return Py_BuildValue("(ii)", mask->w, mask->h); } static PyObject* mask_get_at(PyObject* self, PyObject* args) { bitmask_t *mask = PyMask_AsBitmap(self); int x, y, val; if(!PyArg_ParseTuple(args, "(ii)", &x, &y)) return NULL; if (x >= 0 && x < mask->w && y >= 0 && y < mask->h) { val = bitmask_getbit(mask, x, y); } else { PyErr_Format(PyExc_IndexError, "%d, %d is out of bounds", x, y); return NULL; } return PyInt_FromLong(val); } static PyObject* mask_set_at(PyObject* self, PyObject* args) { bitmask_t *mask = PyMask_AsBitmap(self); int x, y, value = 1; if(!PyArg_ParseTuple(args, "(ii)|i", &x, &y, &value)) return NULL; if (x >= 0 && x < mask->w && y >= 0 && y < mask->h) { if (value) { bitmask_setbit(mask, x, y); } else { bitmask_clearbit(mask, x, y); } } else { PyErr_Format(PyExc_IndexError, "%d, %d is out of bounds", x, y); return NULL; } Py_INCREF(Py_None); return Py_None; } static PyObject* mask_overlap(PyObject* self, PyObject* args) { bitmask_t *mask = PyMask_AsBitmap(self); bitmask_t *othermask; PyObject *maskobj; int x, y, val; int xp,yp; if(!PyArg_ParseTuple(args, "O!(ii)", &PyMask_Type, &maskobj, &x, &y)) return NULL; othermask = PyMask_AsBitmap(maskobj); val = bitmask_overlap_pos(mask, othermask, x, y, &xp, &yp); if (val) { return Py_BuildValue("(ii)", xp,yp); } else { Py_INCREF(Py_None); return Py_None; } } static PyObject* mask_overlap_area(PyObject* self, PyObject* args) { bitmask_t *mask = PyMask_AsBitmap(self); bitmask_t *othermask; PyObject *maskobj; int x, y, val; if(!PyArg_ParseTuple(args, "O!(ii)", &PyMask_Type, &maskobj, &x, &y)) { return NULL; } othermask = PyMask_AsBitmap(maskobj); val = bitmask_overlap_area(mask, othermask, x, y); return PyInt_FromLong(val); } static PyObject* mask_overlap_mask(PyObject* self, PyObject* args) { int x, y; bitmask_t *mask = PyMask_AsBitmap(self); bitmask_t *output = bitmask_create(mask->w, mask->h); bitmask_t *othermask; PyObject *maskobj; PyMaskObject *maskobj2 = PyObject_New(PyMaskObject, &PyMask_Type); if(!PyArg_ParseTuple(args, "O!(ii)", &PyMask_Type, &maskobj, &x, &y)) { return NULL; } othermask = PyMask_AsBitmap(maskobj); bitmask_overlap_mask(mask, othermask, output, x, y); if(maskobj2) maskobj2->mask = output; return (PyObject*)maskobj2; } static PyObject* mask_fill(PyObject* self, PyObject* args) { bitmask_t *mask = PyMask_AsBitmap(self); bitmask_fill(mask); Py_RETURN_NONE; } static PyObject* mask_clear(PyObject* self, PyObject* args) { bitmask_t *mask = PyMask_AsBitmap(self); bitmask_clear(mask); Py_RETURN_NONE; } static PyObject* mask_invert(PyObject* self, PyObject* args) { bitmask_t *mask = PyMask_AsBitmap(self); bitmask_invert(mask); Py_RETURN_NONE; } static PyObject* mask_scale(PyObject* self, PyObject* args) { int x, y; bitmask_t *input = PyMask_AsBitmap(s