Re: [pygame] SDL-ctypes progress
On Tue, 2006-06-06 at 01:29 +1000, Alex Holkner wrote: > I've uploaded a new snapshot of my work: > http://pygame.org/ctypes/SDL-ctypes-0.02.tar.gz Progress is looking strong. Having the documentation is a big bonus, far more than I was expecting for SoC. I've got a couple notes, but nothing urgent. I'd drop SDL_opengl.h from the constant. The only constant we are getting from it is WIN32_LEAN_AND_MEAN. I found all the keysyms in their own .py file, at first I thought they were not included. I'd agree that SDL_syswm is useful from Python. The best solution may be to create three versions of the class and select one based on "sys.platform". It might be nice if the unicode attribute on SDL_keysym was already mapped to a single or zero character unicode string. I don't know if having the unicode ordinal number ever helps from Python. I thought the PyOpenGL ctypes could take arguments from any of the array modules, but always returned a new array with a globally registered type. If this is true, it would be good if the SDL code could accept arrays from any type of array. I couldn't find the right package for numpy on my Dapper system. (Tried all manner of scipy and friends). It seems like numpy is the most hopeful number array package out there. Unfortunately it's also the newest and not as widely distributed. I'm eager for the other SoC project to build a base generic array type into the standard libs. I'm wondering if we can just always have SDL functions return new "ctypes" style arrays. Then provide convenience functions for wrapping those into array types for other libraries. pal = mysurf.format.palette palette = SDL.numpy.Convert(pal.ncolors, pal, colors) Then again, we may prefer more specific array building functions. palette_array = SDL.numeric.PaletteArray(mysurf.format.palette) pixel_array = SDL.numeric.PixelsArray(mysurf) We probably want to support 8bit arrays for the 24bit and 32bit Surfaces (the "3d" array types in pygame.surfarray). This would work well for palette arrays too. In current Pygame, when building an array that references the pixel data of a Surface, a pair of SDL_LockSurface and SDL_UnlockSurface are tied to the lifetime of the array. If there is an easy way to implement this, that may help prevent segfault locking problems. I'm not sure how much bullet proofing we want to worry about at this SDL level of the binding. I also couldn't import the package because of SDL_GetKeyRepeat on my SDL version 1.2.9. We need to make sure we avoid the import time exceptions like this in our version handling scheme.
Re: [pygame] Re: pygame networking
Hello, You can't kill a thread in python. Check out the sockets page in the docs for some ways around blocking. http://docs.python.org/lib/socket-objects.html There's some options on python sockets for settimeout, and setblocking. So you can use non blocking stuff inside a thread too. For debugging threaded programs it is useful to be able to run all of the code within one thread if possible. That way you can take the threading issues out of the debugging. As with one thread, your program is serial again. Check out flup for one example of a threaded server... http://svn.saddi.com/flup/ It uses a threadpool. On 6/6/06, Bryce Allen <[EMAIL PROTECTED]> wrote: I have Trac/svn for my pygame networking project, courtesy of webfaction.com. Here is the URL: http://pygamenetworking.python-hosting.com I haven't had much time to work on the project, but I did post some code. At the moment I'm trying to figure out how to properly kill off a thread that's blocking on socket calls. Does anyone have a simple example of threading with the python socket API? Thanks, Bryce
Re: [pygame] SDL-ctypes progress
Hi,
I get an error the examples...
I think you could catch these exceptions and perhaps make a function
which raises NotImplementedError when it is called instead? Otherwise
if one function is removed, then that whole module becomes unusable.
Either that or do some version checks.
try:
... normal definition goes here...
except AttributeError:
def SDL_GetKeyRepeat():
return NotImplementedError("need SDL >= 1.2.10")
OR...
if """sdl_version <= 1.2.10""", version check goes here.:
def SDL_GetKeyRepeat():
return NotImplementedError("need SDL >= 1.2.10")
else:
... normal definition goes here...
This is the exception with debian unstable, SDL 1.2.9+cvs.
Traceback (most recent call last):
File "pixels_numpy.py", line 15, in ?
from SDL import *
File "../SDL/__init__.py", line 32, in ?
from SDL.events import *
File "../SDL/events.py", line 12, in ?
import SDL.keyboard
File "../SDL/keyboard.py", line 70, in ?
SDL.dll._dll.SDL_GetKeyRepeat.argtypes = [POINTER(c_int), POINTER(c_int)]
File "/usr/lib/python2.4/site-packages/ctypes/__init__.py", line
313, in __getattr__
return self.__getitem__(name)
File "/usr/lib/python2.4/site-packages/ctypes/__init__.py", line
316, in __getitem__
func = self._FuncPtr(name, self)
AttributeError: /usr/lib/libSDL.so: undefined symbol: SDL_GetKeyRepeat
On 6/6/06, Alex Holkner <[EMAIL PROTECTED]> wrote:
Hello all those interested,
I've uploaded a new snapshot of my work:
http://pygame.org/ctypes/SDL-ctypes-0.02.tar.gz
Basically everything in SDL 1.2.10 is wrapped now, except for the audio
and joystick submodules. Other changes are:
* Complete HTML API documentation (in doc/).
* No more error return codes; SDL_Exception is raised instead, just
like PyOpenGL does.
* A numpy interface to SDL_Surface.pixels
* A few more test scripts, but nothing to get excited about
The most exciting thing you can do with this snapshot is run
tests/pixels_numpy.py (assuming you have numpy installed), which
implements one of those old-school plasma effects.
I welcome input as to how to implement the numpy interface. Currently
I've just defined a method on SDL_Surface, "get_pixels_numpy()". There
are a few more places where something like this is needed, especially in
audio. I'm happy to have the library provide separate functions for
each type of array interface (possibly string, list, ctypes array,
numpy, python array, ...). Alternatively, there could be a global
interface selected during initialisation (this is how PyOpenGL works,
but I'm not too keen on it).
I'm not planning to wrap the following SDL headers, because I don't
think they provide anything useful to Python programmers. Let me know
if you disagree:
SDL_cpuinfo.h
SDL_endian.h
SDL_loadso.h
SDL_main.h
SDL_mutex.h
SDL_syswm.h
SDL_thread.h
What's left for SDL wrapping?
* Not yet tested on anything other than Linux/AMD64.
* Currently works only with 1.2.10; I need to provide binary
compatibility with earlier (and later?) SDL versions.
* Not all enums have been wrapped, and I've possibly missed a few
constants.
* The aforementioned numpy/array interface
* Classes and their fields are not yet documented
* Some isolated functions not yet implemented, mainly because I'm
waiting on a decision on the numpy/array interface before proceeding.
* Implementing the remaining test programs provided with SDL, and
writing some more to give better coverage.
Alex.
[pygame] Re: pygame networking
I have Trac/svn for my pygame networking project, courtesy of webfaction.com. Here is the URL: http://pygamenetworking.python-hosting.com I haven't had much time to work on the project, but I did post some code. At the moment I'm trying to figure out how to properly kill off a thread that's blocking on socket calls. Does anyone have a simple example of threading with the python socket API? Thanks, Bryce
Re: [pygame] SDL-ctypes progress
Hello, probably some stuff in SDL_syswm.h would be useful. For accessing the system events. eg, the windows event, or the X event. On 6/6/06, Alex Holkner <[EMAIL PROTECTED]> wrote: Hello all those interested, I've uploaded a new snapshot of my work: http://pygame.org/ctypes/SDL-ctypes-0.02.tar.gz Basically everything in SDL 1.2.10 is wrapped now, except for the audio and joystick submodules. Other changes are: * Complete HTML API documentation (in doc/). * No more error return codes; SDL_Exception is raised instead, just like PyOpenGL does. * A numpy interface to SDL_Surface.pixels * A few more test scripts, but nothing to get excited about The most exciting thing you can do with this snapshot is run tests/pixels_numpy.py (assuming you have numpy installed), which implements one of those old-school plasma effects. I welcome input as to how to implement the numpy interface. Currently I've just defined a method on SDL_Surface, "get_pixels_numpy()". There are a few more places where something like this is needed, especially in audio. I'm happy to have the library provide separate functions for each type of array interface (possibly string, list, ctypes array, numpy, python array, ...). Alternatively, there could be a global interface selected during initialisation (this is how PyOpenGL works, but I'm not too keen on it). I'm not planning to wrap the following SDL headers, because I don't think they provide anything useful to Python programmers. Let me know if you disagree: SDL_cpuinfo.h SDL_endian.h SDL_loadso.h SDL_main.h SDL_mutex.h SDL_syswm.h SDL_thread.h What's left for SDL wrapping? * Not yet tested on anything other than Linux/AMD64. * Currently works only with 1.2.10; I need to provide binary compatibility with earlier (and later?) SDL versions. * Not all enums have been wrapped, and I've possibly missed a few constants. * The aforementioned numpy/array interface * Classes and their fields are not yet documented * Some isolated functions not yet implemented, mainly because I'm waiting on a decision on the numpy/array interface before proceeding. * Implementing the remaining test programs provided with SDL, and writing some more to give better coverage. Alex.
Re: [pygame] My prototype - testers needed
On 05/06/06, Adeola Bannis <[EMAIL PROTECTED]> wrote: Okay..Now, could people test this code for me please? Tell me if it runssmoothly... no flicker, slowdown etc... and take out the clock ingame.py and tell me how many fps you get, if possible...I would especially like if someone runs it on the oldest machine [with colour monitor :) ] possible. Looking for about 200MhzThanksIf you can wait a week or twoish, I hope :p I should be able to test on a 166.
Re: [pygame] Transparent PNGs / Flipped Images
Can you send a small sample where alpha doesn't work + the images used?
On 6/5/06, Kris Schnee <[EMAIL PROTECTED]> wrote:
Strangely, it doesn't seem to work -- still.
tiles[1] = pygame.image.load("tile1.png").convert_alpha()
Re: [pygame] Transparent PNGs / Flipped Images
Peter Shinners wrote:
On Fri, 2006-06-02 at 18:03 -0400, Kris Schnee wrote:
foo = pygame.image.load( filename ).convert()
Calling convert() with no arguments will change the surface pixel format
to match what is on the screen. This will give the fastest blit calls,
but also means pixel alpha will be removed.
There is a similar convert_alpha() which will convert the image into the
best format for the screen, but adding or keeping the per pixel alpha.
Strangely, it doesn't seem to work -- still.
tiles[1] = pygame.image.load("tile1.png").convert_alpha()
Re: [pygame] SDL-ctypes progress
On Tuesday 06 June 2006 01:29, Alex Holkner wrote: > * Currently works only with 1.2.10; I need to provide binary > compatibility with earlier (and later?) SDL versions. Ubuntu Dapper (the latest) ships with 1.2.9 Richard
RE: [pygame] Fullscreen on second monitor.
I’m not sure if this answers exactly what you’re asking, but I was able to run my pygame mini-projects (all in pygame 1.7.1) and move their window to my secondary monitor manually (in WinXP) and they seemed to run fine. Apparently, pygame doesn’t have a built in way to move windows around the screen (see http://aspn.activestate.com/ASPN/Mail/Message/pygame-users/783606). But, I could be wrong From: owner-pygame-users@seul.org [mailto:owner-pygame-users@seul.org] On Behalf Of Mikael Moutakis Sent: Sunday, June 04, 2006 12:03 PM To: pygame-users@seul.org Subject: Re: [pygame] Fullscreen on second monitor. That's not a newbie question. SDL automatically draws to the primary monitor, so you may find an environment variable where you can tell SDL to draw to the secondary monitor, but I'm 95% sure that one doesn't exist and SDL just always uses the primary monitor. So it's not a limitation of pygame but rather of the underlying C library. Thank you. Would it be possible to display a PyGame window on a second monitor if you don't use fullscreen mode? /Mikael Moutakis
Re: [pygame] My prototype - testers needed
Okay.. Now, could people test this code for me please? Tell me if it runs smoothly... no flicker, slowdown etc... and take out the clock in game.py and tell me how many fps you get, if possible... I would especially like if someone runs it on the oldest machine [with colour monitor :) ] possible. Looking for about 200Mhz Thanks On 6/4/06, andrew baker <[EMAIL PROTECTED]> wrote: First off, congrats on your progress. Second off, why don't you use udp or tcp libs rather than sockets? Sockets can be an interesting challenge, but if you're just trying to get things done, I'd suggest going with a higher-level lib. On 6/4/06, Adeola Bannis <[EMAIL PROTECTED]> wrote: > I finally have some usable code. I want to start a sourceforge project > but I doubt I have enough original content to warrant it. Anybody have > a place where I can host my code? Awardspace won't let me. *pout* > > Yes I know it is VERY poorly commented... > > I am in the middle of doing the whole unpassable tiles thing, but what > I really need is a little help implementing sockets. I want to be able > to have my program send messages to another program about the player > position. Eventually I want to get a server-client thing going. > > When I tried to implement sockets in my program it didn't work. Does > my socket have to be defined globally? Isn't that messy? > > > -- Andrew Ulysses Baker "failrate"
[pygame] SDL-ctypes progress
Hello all those interested, I've uploaded a new snapshot of my work: http://pygame.org/ctypes/SDL-ctypes-0.02.tar.gz Basically everything in SDL 1.2.10 is wrapped now, except for the audio and joystick submodules. Other changes are: * Complete HTML API documentation (in doc/). * No more error return codes; SDL_Exception is raised instead, just like PyOpenGL does. * A numpy interface to SDL_Surface.pixels * A few more test scripts, but nothing to get excited about The most exciting thing you can do with this snapshot is run tests/pixels_numpy.py (assuming you have numpy installed), which implements one of those old-school plasma effects. I welcome input as to how to implement the numpy interface. Currently I've just defined a method on SDL_Surface, "get_pixels_numpy()". There are a few more places where something like this is needed, especially in audio. I'm happy to have the library provide separate functions for each type of array interface (possibly string, list, ctypes array, numpy, python array, ...). Alternatively, there could be a global interface selected during initialisation (this is how PyOpenGL works, but I'm not too keen on it). I'm not planning to wrap the following SDL headers, because I don't think they provide anything useful to Python programmers. Let me know if you disagree: SDL_cpuinfo.h SDL_endian.h SDL_loadso.h SDL_main.h SDL_mutex.h SDL_syswm.h SDL_thread.h What's left for SDL wrapping? * Not yet tested on anything other than Linux/AMD64. * Currently works only with 1.2.10; I need to provide binary compatibility with earlier (and later?) SDL versions. * Not all enums have been wrapped, and I've possibly missed a few constants. * The aforementioned numpy/array interface * Classes and their fields are not yet documented * Some isolated functions not yet implemented, mainly because I'm waiting on a decision on the numpy/array interface before proceeding. * Implementing the remaining test programs provided with SDL, and writing some more to give better coverage. Alex.
