Menu
▾
▴
pysdl-devel
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
|
Apr
(57) |
May
(30) |
Jun
(44) |
Jul
(37) |
Aug
(9) |
Sep
(59) |
Oct
(21) |
Nov
|
Dec
(4) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
|
Dec
|
|
From: Peter N. <pn...@ya...> - 2000-10-02 06:57:27
|
--- Peter Nicolai <pn...@ya...> wrote: > > Hi, > > I've been trying to do 2D bump mapping Oops... neither of those will run unless you change the line: hMap = hBmp.pixels[:] >> 8 to: hMap = transpose(array(hBmp[:])) >> 8 it's line 27 in bump1 and 33 in bump2. __________________________________________________ Do You Yahoo!? Yahoo! Photos - 35mm Quality Prints, Now Get 15 Free! http://photos.yahoo.com/ |
|
From: Peter N. <pn...@ya...> - 2000-10-01 09:09:46
|
Hi, I've been trying to do 2D bump mapping... I haven't figured out how to do it efficiently, I think I'm probably missing an obvious better way (besides just learning C, and proper math). Here are 2 bad attempts. The first one is faster, but I can't figure out how to move the computation out of the loop without making the choose() statement take forever. Also I think something is wrong because sometimes it looks raised and sometimes recessed. --peter nicolai __________________________________________________ Do You Yahoo!? Yahoo! Photos - 35mm Quality Prints, Now Get 15 Free! http://photos.yahoo.com/ |
|
From: Ray K. <rh...@ne...> - 2000-09-29 23:54:52
|
Pete Shinners wrote: > > there's been talk of splitting the python source into > something more manageable. after chatting a bit, it seems > to reinforce that a good idea might be to break pysdl into > submodules. these modules all being kept in a pysdl package. You know I'm all for it! -Ray |
|
From: Ray K. <rh...@ne...> - 2000-09-29 23:51:00
|
Pete Shinners wrote: > > after chewing on the "single binary" idea, i've grown > to dislike it. the main reason that it ties the compile > process way to tightly to its dependencies. there's a > better way. > > so i'm putting all that aside and have created a > new, extremely simple distutil for pysdl that gets > pysdl compiled and linked to its dependencies. > it's pretty cool, and i'll release that here soon. > > in the meantime. if you haven't tried it before, > getting all the pysdl dependencies compiled under WIN > is a major chore. none of the packages compile > 'out of the box', but need paths changed and flags > altered to get each library happy. i've got a different > compiling script almost done that compiles each library > into its own .DLL and .LIB on windows. i'm just going > to add a little optional glue between this build and > what the pysdl distutil script can use. I've got patches for most of those libs (jpeg, gif, zlib, and freetype) to allow a cross compile of a DLL from linux -> win32. The same patches will also work with Sam's new mingw32 win32 native package. Binaries of the .dll/.a files are at http://www.libsdl.org/Xmingw32 and I can make the patches available to anyone who wants them. I believe that mingw32 is going to become the "officially supported" SDL win32 compile environment, from what Sam's been saying on IRC. It should also not be too difficult to build a VC .lib file from the dll using a tool like implib. -Ray |
|
From: Peter N. <pn...@ya...> - 2000-09-29 23:24:30
|
--- DIDIO Salvatore BRX/FTLD wrote:> Hello,> > This just a test to see if I can join the mailing> list.> I've coded a lens effect in PySDL, but it moves very> slowly> Is there a way to accelerate the loop in Surface> object pixelIf the math is what's slowing it down, it might not help much. If you can use the Numeric module for that part it could really help, though. I did a simple gradient function that went from 30 seconds to around .5 seconds when I redid it using Numeric. Pete Shinners is working on a companion module for pysdl that will allow direct transfers between SDL surfaces and numpy arrays, but for now you can just use the surface[:]=someArray way. Here's a link to my old post with that code attached. (Funny, in looking for that I found my first post to this list where I said I wouldn't post to this list much because I don't know much programming... I guess that didn't stop me.) Also I'd love to see the code for your lens effect. --Peter --------------------------------- Do You Yahoo!? Yahoo! Photos - 35mm Quality Prints, Now Get 15 Free! |
|
From: DIDIO S. BRX/F. <sal...@fr...> - 2000-09-29 11:41:57
|
Hello, This just a test to see if I can join the mailing list. I've coded a lens effect in PySDL, but it moves very slowly Is there a way to accelerate the loop in Surface object pixel Thanks |
|
From: Pete S. <pe...@vi...> - 2000-09-28 20:43:58
|
> Ok, this seems to work for me, but only with the
> SDL-1.1.4 stuff -- the new versions give a lot of
> errors, some I think from the clipping changes. Also,
> with Python 2.0 I had to change Py_Free and Py_Malloc
> to PyMem_Free and PyMem_Malloc. Is this ok to do?
yeah, pysdl needs to be updated a little.
i'm glad to hear it worked outside my little lab,
what compiler are you using? i just did some checking,
and distutils seems to work really well with borland's
free compiler (once it is configured)
> Also I think my problems before with image loading
> might have been just that libPNG and so on were not
> included in the source. Although, my attempts to
> include them have not made a difference, so either I'm
> doing it wrong or that's not the problem.
you should be able to add it easy enough to the whole
compiling. (good luck! :])
extract libpng into the build directory, then you need
to add a config file for libpng (just make a copy of
one of the other config files and change as needed)
then you'll also need to add the following define into
the image config file, "('LOAD_PNG', None)"
all these config files are in the "config" directory.
ps, if you can hack the 280MB downloading, it appears
you can get the MSVC commandline compiling tools for
free.
http://x69.deja.com/[ST_rn=ps]/threadmsg_ct.xp?AN=674707884.1&mhitnum=0&CONTEXT=97016734
2.257359894
|
|
From: Peter N. <pn...@ya...> - 2000-09-28 19:34:45
|
Ok, this seems to work for me, but only with the SDL-1.1.4 stuff -- the new versions give a lot of errors, some I think from the clipping changes. Also, with Python 2.0 I had to change Py_Free and Py_Malloc to PyMem_Free and PyMem_Malloc. Is this ok to do? Also I think my problems before with image loading might have been just that libPNG and so on were not included in the source. Although, my attempts to include them have not made a difference, so either I'm doing it wrong or that's not the problem. __________________________________________________ Do You Yahoo!? Yahoo! Photos - 35mm Quality Prints, Now Get 15 Free! http://photos.yahoo.com/ |
|
From: Pete S. <pe...@vi...> - 2000-09-28 01:14:44
|
there's been talk of splitting the python source into
something more manageable. after chatting a bit, it seems
to reinforce that a good idea might be to break pysdl into
submodules. these modules all being kept in a pysdl package.
i see three main benefits from a breakup like this.
first, dependencies are less of an issue. since you only
import the modules you need, you end up only linking to
the dependencies you need. if you don't have SDL_mixer
on your system, that's ok, if you don't import the
"sdl.mixer" module you'll never need the base library.
second, it gives external (3rd party) modules equal
footing. i can go and write a Numeric/Surface extension
class and people can use (or not use) it as needed. it
doesn't need to even come with the base pysdl package,
since it can be downloaded and installed as a separate
module. (same with the SDL_gui module out there)
thirdly, it allows for an easy mix of python and C code.
face it, some quick little routines in python can
end up as monsters on the C extension end. the Numeric
package does this very well, mixing C and python code.
there could also be python class wrappings around the
C extension objects. (UserSurface, UserRect, etc)
whew. well, there it is. the idea has me pretty interesting.
if there's any enthusiasm for something like this i'll code
it up and we can try playing with it.
on the python end, things could still be used with little
change if you wanted. of course "from sdl.constants import *"
might be a big change. each module could also be imported
right to the global namespace,
import sdl
sdl.video.set_mode(xxx)
import sdl.video as video
video.set_mode(xxx)
anyways, what are the thoughts? it seems a nice cleanup
to me. anyone want to see it done? i could probably get it
together faster than you think ;]
|
|
From: Pete S. <pe...@vi...> - 2000-09-28 00:50:38
|
ok, this has been rattling around my head all day. i've got to get some ideas out, or my head will bust. after chewing on the "single binary" idea, i've grown to dislike it. the main reason that it ties the compile process way to tightly to its dependencies. there's a better way. so i'm putting all that aside and have created a new, extremely simple distutil for pysdl that gets pysdl compiled and linked to its dependencies. it's pretty cool, and i'll release that here soon. in the meantime. if you haven't tried it before, getting all the pysdl dependencies compiled under WIN is a major chore. none of the packages compile 'out of the box', but need paths changed and flags altered to get each library happy. i've got a different compiling script almost done that compiles each library into its own .DLL and .LIB on windows. i'm just going to add a little optional glue between this build and what the pysdl distutil script can use. i think this is a great way to make everything work. it doesn't change things too much from how it is now, the whole process is just simpler and more streamlined how is the compiling scene under linux? i know it is a lot smoother, since that's where all the packages are originally meant to compile (plus linux is much more compiler friendly). it looks pretty easy to just do a "./configure;make install" or grab a 'devel' package. is there any room for improvement getting pysdl started from scratch? in any event i'll have distutils working really well with pysdl, and a cleaner compile pipeline for us WIN users before the week is out. |
|
From: Peter N. <pn...@ya...> - 2000-09-28 00:09:20
|
hi, no attachment? __________________________________________________ Do You Yahoo!? Yahoo! Photos - 35mm Quality Prints, Now Get 15 Free! http://photos.yahoo.com/ |
|
From: Pete S. <pe...@vi...> - 2000-09-27 17:08:19
|
blarg. here's the attachment! |
|
From: Pete S. <pe...@vi...> - 2000-09-27 16:37:41
|
(note, i tried posting this last night, but no show.
here is my next attempt, sorry if this is your 2nd read)
I've got distutils working with for pysdl. I've mentioned that
i think using distutils is the way to go for pysdl. it handles
a ton tasks, yet currently is still poorly documented (2.02b
docs are barely improved, but wrong keyword arg names are fixed!)
anyways, this definitely needs to go up for testing and
discussion. i figured now with python 2.02b out people will
want to go and get their modules recompiled anyways.
ok, here's the area for controversy :]
the way this build works is to gather all the dependencies
(SDL, SDL_image, etc) into one directory. i've setup the
distutils to then compile the whole kit and kaboodle in
one shot. the result is a single shared object with all
dependent libraries built in.
the single shared object has a list of strong pros and
cons. i think it could be a good idea. with (nearly) nightly
releases of SDL coming out, pysdl can still be using the
version of pysdl it was meant to be using. of course, this
goes totally against the reason for shared libraries in the
first place. anyways. i'd like to see discussion on that. i'm
not sold either way, but this seems easiest for now, and it
might be worth sticking to?
anyways, right now it is setup to compile on win32 with MSVC.
distutils can handle a lot of compile environments. besides
mac and unix, on win32 it can use MSVC, borland's free compiler,
cygnus and mingw. it should take someone less than 5 minutes to
add linux info to my special 'config' files.
the way it works. unzip the attached archive. it will create
a directory named sdlbuild. you need to copy or extract the
source for all the pysdl dependecies (including pysdl) into
this directory. for example, my lovely win directory looks
like this...
-----------------------------------------------------------
C:\src\sdlbuild>dir
Volume in drive C is SYSTEM
Volume Serial Number is 3831-C38D
Directory of C:\src\sdlbuild
. <DIR> 09-14-00 9:04p .
.. <DIR> 09-14-00 9:04p ..
SETUP PY 1,301 09-27-00 1:32a setup.py
CONFIG PY 2,972 09-27-00 1:30a config.py
FREETYPE <DIR> 09-14-00 9:04p freetype
SDL-1 1 <DIR> 09-14-00 9:04p SDL-1.1
SDL_IM~1 10 <DIR> 09-14-00 9:04p SDL_image-1.0.10
SDL_MI~1 6 <DIR> 09-14-00 9:04p SDL_mixer-1.0.6
SDL_TT~1 2 <DIR> 09-14-00 9:04p SDL_ttf-1.2.2
SMPEG-~1 0 <DIR> 09-14-00 9:04p smpeg-0.4.0
PYSDL-~1 7 <DIR> 09-15-00 12:44a pysdl-0.0.7
CONFIG <DIR> 09-27-00 1:24a config
2 file(s) 4,273 bytes
10 dir(s) 320.33 MB free
-----------------------------------------------------------
if you've got win32&msvc you're ready to go, just issue the
standard distutils command
"python setup.py install"
this will verbosely compile all the needed source and
create a new "sdl.pyd" in your python directory.
if you're using a different setup. it is fairly straightforward
how it works. in the "config" directory is a small module for each
dependency. it contains several optional lists of compile info.
if you look at the ones in there, it is really self-explanatory.
a quick look at config/sdl.py should be all the docs you need
(hopefully??)
hopefully people can try this out and report results. if any
of you have distutil experience from the past, it could be of
great help right now.
what's nice about this setup is you can drop in a new
version of a library, and this setup will compile in the
highest versioned directory it finds for that library and
compile it in. no extra work like rearranging include paths.
on my cel-400, the compile takes about 4 minutes and creates
a 500kb sdl.pyd
if anyone wants to hear me pimp all the great features of
distutils again, i'll be glad :]
PS. and finally, it looks like python2.0b2 is binary
compatible with python2.0b1 (at least on my machine)
so you don't really have to go recompiling all your
extensions
|
|
From: Pete S. <pe...@sh...> - 2000-09-27 09:06:48
|
I've got distutils working with for pysdl. I've mentioned that
i think using distutils is the way to go for pysdl. it handles
a ton tasks, yet currently is still poorly documented (2.02b
docs are barely improved, but wrong keyword arg names are fixed!)
anyways, this definitely needs to go up for testing and
discussion. i figured now with python 2.02b out people will
want to go and get their modules recompiled anyways.
ok, here's the area for controversy :]
the way this build works is to gather all the dependencies
(SDL, SDL_image, etc) into one directory. i've setup the
distutils to then compile the whole kit and kaboodle in
one shot. the result is a single shared object with all
dependent libraries built in.
the single shared object has a list of strong pros and
cons. i think it could be a good idea. with (nearly) nightly
releases of SDL coming out, pysdl can still be using the
version of pysdl it was meant to be using. of course, this
goes totally against the reason for shared libraries in the
first place. anyways. i'd like to see discussion on that. i'm
not sold either way, but this seems easiest for now, and it
might be worth sticking to?
anyways, right now it is setup to compile on win32 with MSVC.
distutils can handle a lot of compile environments. besides
mac and unix, on win32 it can use MSVC, borland's free compiler,
cygnus and mingw. it should take someone less than 5 minutes to
add linux info to my special 'config' files.
the way it works. unzip the attached archive. it will create
a directory named sdlbuild. you need to copy or extract the
source for all the pysdl dependecies (including pysdl) into
this directory. for example, my lovely win directory looks
like this...
-----------------------------------------------------------
C:\src\sdlbuild>dir
Volume in drive C is SYSTEM
Volume Serial Number is 3831-C38D
Directory of C:\src\sdlbuild
. <DIR> 09-14-00 9:04p .
.. <DIR> 09-14-00 9:04p ..
SETUP PY 1,301 09-27-00 1:32a setup.py
CONFIG PY 2,972 09-27-00 1:30a config.py
FREETYPE <DIR> 09-14-00 9:04p freetype
SDL-1 1 <DIR> 09-14-00 9:04p SDL-1.1
SDL_IM~1 10 <DIR> 09-14-00 9:04p SDL_image-1.0.10
SDL_MI~1 6 <DIR> 09-14-00 9:04p SDL_mixer-1.0.6
SDL_TT~1 2 <DIR> 09-14-00 9:04p SDL_ttf-1.2.2
SMPEG-~1 0 <DIR> 09-14-00 9:04p smpeg-0.4.0
PYSDL-~1 7 <DIR> 09-15-00 12:44a pysdl-0.0.7
CONFIG <DIR> 09-27-00 1:24a config
2 file(s) 4,273 bytes
10 dir(s) 320.33 MB free
-----------------------------------------------------------
if you've got win32&msvc you're ready to go, just issue the
standard distutils command
"python setup.py install"
this will verbosely compile all the needed source and
create a new "sdl.pyd" in your python directory.
if you're using a different setup. it is fairly straightforward
how it works. in the "config" directory is a small module for each
dependency. it contains several optional lists of compile info.
if you look at the ones in there, it is really self-explanatory.
a quick look at config/sdl.py should be all the docs you need
(hopefully??)
hopefully people can try this out and report results. if any
of you have distutil experience from the past, it could be of
great help right now.
what's nice about this setup is you can drop in a new
version of a library, and this setup will compile in the
highest versioned directory it finds for that library and
compile it in. no extra work like rearranging include paths.
on my cel-400, the compile takes about 4 minutes and creates
a 500kb sdl.pyd
if anyone wants to hear me pimp all the great features of
distutils again, i'll be glad :]
PS. and finally, it looks like python2.0b2 is binary
compatible with python2.0b1 (at least on my machine)
so you don't really have to go recompiling all your
extensions
|
|
From: Peter N. <pn...@ya...> - 2000-09-26 22:37:17
|
> if you're using global variables to point to your > surfaces, then > there's a really good chance they're not being > cleaned up. also if > the images are class members (not class instance > members, big diff) > they won't be getting cleaned up either. you must > use "del" on > variables like these when you are done with the > images, or just > reassign the variables to "None" or something else. Thanks for that information -- I know it's probably covered in the Python docs but it might be nice to have a note about it in the PySDL docs as well, since it seems like an easy mistake to make. __________________________________________________ Do You Yahoo!? Send instant messages & get email alerts with Yahoo! Messenger. http://im.yahoo.com/ |
|
From: Pete S. <psh...@me...> - 2000-09-26 16:57:51
|
> Whoa, so this could be what makes my app eat most of my 256Mb? I had an > loop which just polled the event mechanism for new events and just waited > for a keypress, and it leaked 5Mb/s. Not too funny. I converted to using > wait instead, and now it consumes a lot less memory, but still chews up *a > lot*, compared to what the app does (30Mb). (shoot, sourceforge seems down this mornin. there goes my second brain located in the pysdl mail archives) according to Mark Baker. this leak was spotted and fixed up a couple releases ago. it managed to sneak its way back into the 0.0.7 release, and is fixed up for the next release. it's an easy one-line fix if you're prepared to go in and get it yourself. in the sdl_events_poll routine, you can see the call to allocate the "s_event_ref" object. before returning -1, you need to free "s_event_ref", because it's not being used. The way you have it now, there will be no leak when there are events waiting to be polled, you will leak memory each time you call events_poll() and there are no events. i'm not sure what you're app is doing, but if it's GUI, and no animations going on, you can use sdl_events_wait, which will only return when an event is ready. > Btw, is it my responsibilty to explicitely delete surfaces etc I don't > need anymore? I have a few of these, and they are not circularly > referenced, so thay should be garbage collected, but my app never seems to > release any memory. Thememory usage keeps increasing as I "surf" through > my dialogs your assumption is definitely correct. coming from so much 'C' i occasianally feel a bit uncomfortable just leaving that surface go inside my funcion. (knowing it's the last reference) if you're using global variables to point to your surfaces, then there's a really good chance they're not being cleaned up. also if the images are class members (not class instance members, big diff) they won't be getting cleaned up either. you must use "del" on variables like these when you are done with the images, or just reassign the variables to "None" or something else. if you compile SDL with "CHECK_LEAKS" defined, it will do its own surface reference counting and memory tracking. it might be worth your time to recompile SDL this way and run your app. when you exit you should get extra information about leaked surfaces. hmm, other than that, really doublecheck for those circular references. although now with the 2.0 Garbage Collection, that might not even matter? |
|
From: Jan E. <ch...@in...> - 2000-09-26 09:25:44
|
On Tue, 26 Sep 2000, David Clark wrote: >Pete Shinners writes: > > david clark mentioned to me there was a known memory leak in the > > rectangle object stuff i put out recently. i've been attaching the > > new distutils to my little rect object and am pleased with all that. > >My apologies for the misunderstanding. I meant there was a known >memory leak in the pySDL code, not in your rect object. I'm referring >to the leak in the event poll/wait code mentioned in Mr. Kelm's >posting on the 17th. Whoa, so this could be what makes my app eat most of my 256Mb? I had an loop which just polled the event mechanism for new events and just waited for a keypress, and it leaked 5Mb/s. Not too funny. I converted to using wait instead, and now it consumes a lot less memory, but still chews up *a lot*, compared to what the app does (30Mb). Btw, is it my responsibilty to explicitely delete surfaces etc I don't need anymore? I have a few of these, and they are not circularly referenced, so thay should be garbage collected, but my app never seems to release any memory. Thememory usage keeps increasing as I "surf" through my dialogs (I have a *simple* widget library, and create a few fullscreen surfaces). Any idea as to what that could be? I probably do something which can be considered fubar. :-) Chakie --------------------+-------------------------------------------------------- Jan 'Chakie' Ekholm | Balrog New Media http://www.balrog.fi/ Linux Inside | I'm the blue screen of death, nobody hears your screams |
|
From: David C. <si...@te...> - 2000-09-26 08:44:32
|
Pete Shinners writes: > david clark mentioned to me there was a known memory leak in the > rectangle object stuff i put out recently. i've been attaching the > new distutils to my little rect object and am pleased with all that. My apologies for the misunderstanding. I meant there was a known memory leak in the pySDL code, not in your rect object. I'm referring to the leak in the event poll/wait code mentioned in Mr. Kelm's posting on the 17th. -- David Clark si...@te... Preliminary pySDL Documentation: http://www3.telus.net/futility/futility/docs/pysdl/index.html |
|
From: Pete S. <pe...@sh...> - 2000-09-26 06:04:25
|
david clark mentioned to me there was a known memory leak in the rectangle object stuff i put out recently. i've been attaching the new distutils to my little rect object and am pleased with all that. i'm soon to release a newly packaged version, but would like to prune out this leak. i never saw anything on it, and went back through the pysdl-devel archives and didn't see any mention of it either. if someone did see a leak in the code, lemme know and i'll patch it up quick. thanks. ps. distutils is quite good. distutils documentation is quite bad. the only thing holding me back from getting it working with pysdl are all the dependency libraries. at this point i'm sure it can be handled, just a matter of wrestling the info out of it. pps. python2.0b2 expected tomorrow and sdl1.1.5 is in beta, expected soon |
|
From: Peter N. <pn...@ya...> - 2000-09-25 22:30:06
|
Ok that was maybe the dumbest question I've posted yet -- I am sorry. (you need to lock hardware surfaces) --Peter --- Peter Nicolai <pn...@ya...> wrote: > Hi, > > I've recently noticed that using the slice notation > to > set pixels (mySurface[y][x] = xxx) is not working in > fullscreen hardware-surface mode (Win98). It seems > like it worked for me before but I can't remember. > Should it work, or should it only work for software > surfaces? --Peter Nicolai > > __________________________________________________ > Do You Yahoo!? > Send instant messages & get email alerts with Yahoo! > Messenger. > http://im.yahoo.com/ > _______________________________________________ > PySDL-devel mailing list > PyS...@li... > http://lists.sourceforge.net/mailman/listinfo/pysdl-devel __________________________________________________ Do You Yahoo!? Send instant messages & get email alerts with Yahoo! Messenger. http://im.yahoo.com/ |
|
From: Pete S. <pe...@vi...> - 2000-09-25 21:17:31
|
> I've recently noticed that using the slice notation to > set pixels (mySurface[y][x] = xxx) is not working in > fullscreen hardware-surface mode (Win98). It seems > like it worked for me before but I can't remember. > Should it work, or should it only work for software > surfaces? --Peter Nicolai hardware surfaces need to be locked for pixel access. (same for RLEACCEL and/or ASYNCBLIT surfaces too) in SDL, the code for SDL_LockSurface won't do anything if the surface doesn't need locking. it's an inexpensive call to wrap your pixel-access code with lock/unlock calls. Then your code works with HW and SW surfaces. of coarse, you can be really, really sure by calling the surface's mustlock() method. i'm pretty sure the time taken to check 'mustlock' outweighs it's benefit though. anyone want to test? anyways, this is just my guess to your problem. |
|
From: Peter N. <pn...@ya...> - 2000-09-25 20:39:14
|
Hi, I've recently noticed that using the slice notation to set pixels (mySurface[y][x] = xxx) is not working in fullscreen hardware-surface mode (Win98). It seems like it worked for me before but I can't remember. Should it work, or should it only work for software surfaces? --Peter Nicolai __________________________________________________ Do You Yahoo!? Send instant messages & get email alerts with Yahoo! Messenger. http://im.yahoo.com/ |
|
From: bmbros <bm...@ma...> - 2000-09-25 15:23:17
|
Hello, I needed to access unicode character translation in keyboard events. This variable was omitted in pysdl. I added 2 functions in the key event: get_unicode(): returns a string containing a single char (the 8 lower bits of the unicode char). set_unicode(): change the unicode char and 1 function in the module: events_enable_unicode(int): enable/disable character translation. I made it v0.0.8 (the patch in included in this mail). I hope this is what you want. I tested it on linux and it worked. Could someone compil it on windows? The program I'm building must run under this os.. and I can't build pysdl. Thanks. |
|
From: Ray K. <rh...@ne...> - 2000-09-19 01:59:12
|
Pete Shinners wrote: > > > Is the source to pysdl ever going to end up in cvs? > > > Attached is a patch for what appears to be a memory leak in the > > event polling/waiting functions. > > this is a good question. i saw this leak also, and reported it > as a bug to Mark last week. i've got another submittal waiting > with no response as well. for now i've decided to wait off on > working with the "core" pysdl, since development seems backed up. At this point, I have a bit of a dilemma. Mark, Pete, and anyone else who is interested, read on: I'm the author of SDL_gui, and one of the intentions of SDL_gui is to allow it to be mixed with "normal" SDL code to provide GUI capability in multimedia applications. I've written a python binding for the library, and wish to provide support for using pysdl to access those "normal" SDL functions. If I don't allow the use of pysdl to do that, then I have to duplicate much of the functionality that it has, which is something I don't really want to do. I want to be able to pass in pysdl surfaces and such to my gui functions. The python bindings for SDL_gui are being used in a project for my day job, so I *have* to provide this kind of support to it. In order to do this, I need access to internal functions and structures that are defined in sdlmodule.h, of which many are declared static. I've done this before with other python modules, with a pretty good success rate. The only problem I've had in the past is that you need to import the module that is being referenced BEFORE importing the module that needs to reference it (In this case, import sdl, then SDL_gui). I had another idea for how to implement it, but it involves making a shared lib that lives in /usr/lib (or wherever) that contains the common code. Regardless of how it's implemented, it could mean some large scale changes to pysdl, so I thought it would be best to ask you guys, specifically Mark, if this is something that you'd like to see happen, or am I stepping out of place here? -Ray |
|
From: Pete S. <pe...@vi...> - 2000-09-19 01:29:22
|
I've completed the rect object. I've also converted a version of pyaliens to use the new rectangles as an example. (also a precompiled binary for 1.5.2 on windows) Download It From: http://www.shinners.org/pete/rect.zip here's the readme.txt file included with the package: Rectangle Object for pySDL. Pete Shinners (pe...@sh...) September 18th, 2000 ---------------------------------------------------- This is the first semi-official release. As far as I've tested everything is working as expected. I've also included my latest version py PyAliens, changed to use the new rect object. There is full (and I do mean full) documentation available in the RectDocs.html file. (David Clark, I would be glad if you added it to your current pysdl docs). There is a MAKEFILE.win for compiling with MSVC, but you'll likely need to change the paths for the python include directory and python.lib file. I've included a binary precompiled for python1.5.2 on windows. For the rest of you, it's a simple compile, you can handle it. I'll provide a python2.0b1 binary for windows upon request. My hope is that soon this can be incorporated into the the base pySDL module. But for now it must be loaded as a separate module. There's a soup-load of features, read the docs for a full understanding of what you can do with it. Checking out the Rectaliens code is a good place to start also. ----------------------------------------------------- Wow, all this, and I get to release my first game with the word "rectal" in the title, HA! Best to report any bugs or feature enhancements to me directly or the pysdl-devel mailing list. (even the docs) Use it and abuse it, I hope it helps whatever you're working on. It already has for me. Pete |
