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: Charles D. <cd...@sp...> - 2003-10-13 03:14:53
|
SDL is perhaps not the appropriate tool for this; interfering with another program's window (or doing pathed window borders to simulate this effect) is outside of its scope. Perhaps you should consider PyOSD; see its web page at http://repose.cx/pyosd/ Now, if PyOSD does not have all the capabilities you're interested in, here comes the discouraging bit: Note that (last time I was involved in TV work, about 6-8 years ago) most software doing what you suggest produces output with a specific background color which is then overlayed onto a different source via specialized hardware, or is written to utilize hardware which can take advantage of an alpha channel. While I'm by no means saying that what you suggest to do is impossible, if you want capabilities such as alpha-channel mixing, it may be a bit harder than you otherwise expect; X and company were certainly not written with such capabilities in mind. (One rather extreme approach that comes to mind is modifying an Xvfb server to overlay a alpha-channel-enabled video stream over its output; I'm certain, however, that this is far more complex than need be). |
|
From: Sharad B. <sh...@wo...> - 2003-10-13 02:56:32
|
BlankDear All,
Good day, I am New to this SDL stuff,It a very happy =
problem to me,
I am developing a scrolling program to scroll text and imgae,This =
program will run on exiting X11 running program,Means I have to develop =
one program that will run on existing running program like you can see =
on TV channel CNN,Rnning text and image strip,
I have some queries to you all SDL gurus,
(1) How can i make program that will run on exisitng (X11)program.
(2) How can i make that scrolling area Transparent
I will very greatfull to you all,Please try to help me out.
Regards
Sharad Bajaj
WOW Vision Pte Ltd
45 Ubi Road 1, Summit Building #05-03
Singapore 408696
Tel: (65) 6745-7798
Fax: (65) 6749-7728
Website: http://www.wow-vision.com
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D
The information in this e-mail is confidential. It is intended solely =
for the addressee and access to the e-mail by anyone else in =
unauthorised. If you are not a named recipient, any disclosure, copying, =
distribution or any action taken or omitted to be taken in reliance on =
it, is prohibited and may be unlawful. If the notice is not intended for =
you, please notify the sender immediately and delete the e-mail.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D
|
|
From: David C. <si...@te...> - 2000-12-05 05:38:28
|
Ok, I've thought about it a little. Daniel, I agree that sourceforge should stay up - pySDL still has utility for those like you who prefer working with Python 1.52. Besides, it's possible that Mark may return some day, or someone else may want to pick up the project. Nonetheless, I feel that the current situation is confusing people. So I'm going to do the following: 1. I'm going to update the project description text on the front page to warn people that pysdl is now unmaintained, and that the recommended active fork is the pygame project, and I'll provide the url to pygame.seul.org. 2. I'll change my documentation to reflect the pysdl project's stalled status. 3. I'm going to send a message to Sam, asking him to change the python language link on the sdl homepage to point to pygame. -- David Clark si...@te... Preliminary pySDL Documentation: http://www3.telus.net/futility/futility/docs/pysdl/index.html |
|
From: Daniel C. <dan...@ya...> - 2000-12-04 03:22:48
|
Hello, I'm Daniel Clark, I'm 16 years old and I've bean doing python programming for about 8 months and C++ for about 3 1/2 weeks. I use PySDL mainly because all attemps of mine to get pygame going has failed. I have most of my programs in python availble in exe form at http://thingies.dhs.org/~liquidrock/ . As far as PySDL being removed from sourceforge, I think that would be bad in my situation. I've used PySDL for 6+ programs and have found it very useful even in its unfinished state. I would really apreciate having the source code made available and possibly other people and/or myself continueing the project for anyone who has a similar situation. If the source could be made available I'm sure many whould take on the project and possibly use much of pygame, good for having compatibility for python 1.5.2. I do believe that 2 free projects that do the same thing is a bit tedious, but for all the reaqsons above I believe it will be somewhat profitable. Thanks, Daniel Clark --- pys...@li... wrote: > Send PySDL-devel mailing list submissions to > pys...@li... > > To subscribe or unsubscribe via the World Wide Web, > visit > > http://lists.sourceforge.net/mailman/listinfo/pysdl-devel > or, via email, send a message with subject or body > 'help' to > pys...@li... > > You can reach the person managing the list at > pys...@li... > > When replying, please edit your Subject line so it > is more specific > than "Re: Contents of PySDL-devel digest..." > > > Today's Topics: > > 1. Future of pySDL (David Clark) > 2. Re: Future of pySDL (Peter Nicolai) > > --__--__-- > > Message: 1 > From: David Clark <si...@te...> > Date: Sat, 2 Dec 2000 20:55:45 -0800 (PST) > To: pys...@li... > Reply-To: si...@te... > Subject: [Pysdl-devel] Future of pySDL > > > Hi. I'm David Clark; I'm listed as dclark under > Project Admins on the > sourceforge main page. I was responsible for the > documentation on the > pysdl project. I don't know if anyone even reads > this list anymore, > but if anyone is out there, I'd like your opinion on > the status of > pySDL. > > I still get about one e-mail a day asking me how to > get pySDL running > under Python 2, or asking about support and updates > to pySDL. I > generally refer people to Pete Shinners pygame > project > (http://pygame.seul.org), which I describe as a > maintained and very > active fork of the pySDL project. The project > statistics show that > pySDL still gets around twenty views a day, and > around ten downloads a > week, in spite of the fact that it has been > abandoned since July 9th. > > The problem I see is that people are still referred > here by Freshmeat, > Sourceforge's own search engine, the Starship, and > by the SDL > homepage. I wonder if having an abandoned project as > the only > advertised python wrapper to SDL is turning away > people who could > otherwise be writing good code. I was thinking of > doing the following: > > - Asking Sam Lantinga to change the Python wrapper > link at > www.libsdl.org to pygame.seul.org. > > - Asking Sourceforge to take down the pysdl project. > I have no ability > to do this myself; Mark Baker was the one who > created the project and > established sourceforge as its home. > > My question is: Does anyone disagree? Is anyone > using pySDL in > production work? Would anyone care if it went away, > and was officially > replaced by pygame? Am I stepping on any toes here? > > I want to be clear: I love the pySDL project. It was > the first free > software project I got involved in, and I probably > had as much > emotionally invested in it as anyone. There's > probably no-one who was > more unhappy to see it descend to its current state > than me. I don't > know what caused Mr. Baker to abandon pySDL, and I > wish there wasn't a > need for a fork like pygame. I'm just concerned that > people will be > confused by the unexplained presence of two > projects, one relatively > high-profile but unmaintained, the other very active > but unknown. > > Opinions? Flames? Anonymous death threats? > > -- > David Clark > si...@te... > Preliminary pySDL Documentation: > http://www3.telus.net/futility/futility/docs/pysdl/index.html > > > > --__--__-- > > Message: 2 > Date: Sat, 2 Dec 2000 21:52:24 -0800 (PST) > From: Peter Nicolai <pn...@ya...> > Subject: Re: [Pysdl-devel] Future of pySDL > To: pys...@li... > > Hi, > > Whatever happens with pySDL, it seems like it makes > sense for pygame to be linked to from libsdl or > wherever else. Maybe Pete Shinners is holding off > on > that at this stage so he can have a little more > freedom to make sweeping changes in it. > > The modular framework of pygame seems like a good > idea > and Mark Baker pretty much opposed that, so that's > something differentiating the two. also Mark had > some > interesting ideas like making pysdl more accessible > from c code so games could be mostly written in > python/pysdl and then parts could be more easily > moved > to c. too bad it might never happen, but I guess > people disappear from scenes all the time. or maybe > he'll come back and work on it more, who knows. > > One thing about pygame that I appreciate is Pete > Shinners seems to want people to be able to get it > running on different machines without a huge ordeal. > > his effort to get it working with distutils so that > wouldn't have to be a total nightmare is pretty > thoughtful. > > > __________________________________________________ > Do You Yahoo!? > Yahoo! Shopping - Thousands of Stores. Millions of > Products. > http://shopping.yahoo.com/ > > > --__--__-- > > _______________________________________________ > PySDL-devel mailing list > PyS...@li... > http://lists.sourceforge.net/mailman/listinfo/pysdl-devel > > > End of PySDL-devel > Digest_______________________________________________ > PySDL-devel mailing list > PyS...@li... > http://lists.sourceforge.net/mailman/listinfo/pysdl-devel __________________________________________________ Do You Yahoo!? Yahoo! Shopping - Thousands of Stores. Millions of Products. http://shopping.yahoo.com/ |
|
From: Peter N. <pn...@ya...> - 2000-12-03 05:52:38
|
Hi, Whatever happens with pySDL, it seems like it makes sense for pygame to be linked to from libsdl or wherever else. Maybe Pete Shinners is holding off on that at this stage so he can have a little more freedom to make sweeping changes in it. The modular framework of pygame seems like a good idea and Mark Baker pretty much opposed that, so that's something differentiating the two. also Mark had some interesting ideas like making pysdl more accessible from c code so games could be mostly written in python/pysdl and then parts could be more easily moved to c. too bad it might never happen, but I guess people disappear from scenes all the time. or maybe he'll come back and work on it more, who knows. One thing about pygame that I appreciate is Pete Shinners seems to want people to be able to get it running on different machines without a huge ordeal. his effort to get it working with distutils so that wouldn't have to be a total nightmare is pretty thoughtful. __________________________________________________ Do You Yahoo!? Yahoo! Shopping - Thousands of Stores. Millions of Products. http://shopping.yahoo.com/ |
|
From: David C. <si...@te...> - 2000-12-03 04:55:14
|
Hi. I'm David Clark; I'm listed as dclark under Project Admins on the sourceforge main page. I was responsible for the documentation on the pysdl project. I don't know if anyone even reads this list anymore, but if anyone is out there, I'd like your opinion on the status of pySDL. I still get about one e-mail a day asking me how to get pySDL running under Python 2, or asking about support and updates to pySDL. I generally refer people to Pete Shinners pygame project (http://pygame.seul.org), which I describe as a maintained and very active fork of the pySDL project. The project statistics show that pySDL still gets around twenty views a day, and around ten downloads a week, in spite of the fact that it has been abandoned since July 9th. The problem I see is that people are still referred here by Freshmeat, Sourceforge's own search engine, the Starship, and by the SDL homepage. I wonder if having an abandoned project as the only advertised python wrapper to SDL is turning away people who could otherwise be writing good code. I was thinking of doing the following: - Asking Sam Lantinga to change the Python wrapper link at www.libsdl.org to pygame.seul.org. - Asking Sourceforge to take down the pysdl project. I have no ability to do this myself; Mark Baker was the one who created the project and established sourceforge as its home. My question is: Does anyone disagree? Is anyone using pySDL in production work? Would anyone care if it went away, and was officially replaced by pygame? Am I stepping on any toes here? I want to be clear: I love the pySDL project. It was the first free software project I got involved in, and I probably had as much emotionally invested in it as anyone. There's probably no-one who was more unhappy to see it descend to its current state than me. I don't know what caused Mr. Baker to abandon pySDL, and I wish there wasn't a need for a fork like pygame. I'm just concerned that people will be confused by the unexplained presence of two projects, one relatively high-profile but unmaintained, the other very active but unknown. Opinions? Flames? Anonymous death threats? -- David Clark si...@te... Preliminary pySDL Documentation: http://www3.telus.net/futility/futility/docs/pysdl/index.html |
|
From: Pete S. <pe...@sh...> - 2000-10-30 07:44:19
|
newsflash. well, after a small delay, my seul.org host has the new pygame mailing list ready to go. subscription instructions and archives are available directly from http://www.seul.org/archives/pygame/users or reachable from the pygame main page http://pygame.seul.org David Clark has also recently contributed binary and source rpm packages. All available from http://pygame.seul.org (thanks, david) |
|
From: Pete S. <pe...@sh...> - 2000-10-24 06:35:33
|
It hasn't been a real secret, but it's been more work than I imagined... I'm announcing PyGame, version 0.1 This is a brand new python wrapper for the SDL library. It uses a different design than what you are used to with pysdl. Fortunately there is still a pretty much 1-to-1 mapping to the calls to SDL. PyGame is broken into a set of many submodules. This design allows for a breakup of the many dependencies. Aside from Python and SDL, the core of PyGame requires no other dependencies. If you would like to compile the other optional modules, you will need to get only the dependencies they require. This design also allows for a very modular design. All modules are given the same priorities and environment. This allows for 3rd party extension modules to be created easily and integrate into the rest of the PyGame package. This build comes with a rough set of full documentation. All functions and modules have helpful docstrings, and these have been extracted into easily browsable HTML files. The release also contains many useful examples that demonstrate the various modules included with PyGame. PyGame is compiled and installed with the distutils. Distutils ships standard with Python 2.0. This allows for simple compiling and installation on many platforms with various compilers. The included installation instructions should be all that's needed to get PyGame running. (after the dependencies are ready to go) PyGame is hosted on SEUL.ORG, an opensource hosting site. A mailing-list and CVS repository should be finalized this week. For now, nly the sources are available. http://pygame.seul.org/ At this point, the package needs testing and abuse. The included examples all work well under my Win32 and Linux testing, but that is far from authorative. The current schedule is to work towards a 1.0 release within a couple months. Until that point, the interface is very open to discussion. The main goal of the entire package is to offer simplicity for the python developer. If part of the modules doesn't end up easy to use in your situation, let's discuss how it can be made better for everyone. Also at this point, there is room for more examples and documentation. If you end up developing or porting an application that could serve to teach others, submit it and it will likely be included. Thanks to everyone who's helped and provided PySDL. Without PySDL to start from, PyGame would have never ended up where it is. While it's unfortunate to see PySDL in its current state, I think it has all combined to put a lot more knowledge into PyGame. According to seul.org, the mailing list will be ready tomorrow, until then I hope nobody minds if this thread is kept open for discussion? Pete Shinners - pe...@sh... |
|
From: Peter N. <pn...@ya...> - 2000-10-17 21:23:14
|
--- Jan Ekholm <ch...@in...> wrote: > On Mon, 16 Oct 2000, David Clark wrote: > > >It looks like Python 2.0 has been released, and I'm > wondering how this > >will affect pySDL. Mark hasn't been seen for quite > a while and it's > >possible he's lost interest in the project. That > would be a real > >shame, but until he re-appears, I think we have to > operate as if we're > >on our own. > Current pysdl works just fine with 2.0 (release > candidate something), it > needs a recompilation and changed defines for > Py_Malloc and PyFree, such > as: > > #define Py_Malloc PyMem_Malloc > #define Py_Free PyMem_Free Yeah -- I think it would be nice to have an agreed-upon version of the regular pysdl that's updated for the current SDL libs as well as python 2 and the mentioned fixes for memory leaks and such. (seems like everyone's modifying it on their own for their own needs which is cool, but the official one is getting moldy) I guess there are a few things in sdl_ttf that need updating, and the clipping is different now. Also I have had problems with the PNG support that might be a bug in the current SDL_image, or maybe I'm compiling it wrong. (the old SDL_image works fine). The Unicode stuff would be nice to have, but I'm not clear on how much work it would take -- it seems like the rest might be fairly easy (judging by the fact that I've been able to figure some of it out myself) --Peter __________________________________________________ Do You Yahoo!? Yahoo! Messenger - Talk while you surf! It's FREE. http://im.yahoo.com/ |
|
From: Jan E. <ch...@in...> - 2000-10-17 06:11:38
|
On Mon, 16 Oct 2000, David Clark wrote: >It looks like Python 2.0 has been released, and I'm wondering how this >will affect pySDL. Mark hasn't been seen for quite a while and it's >possible he's lost interest in the project. That would be a real >shame, but until he re-appears, I think we have to operate as if we're >on our own. > > Current pySDL We need >SDL 1.1.3 1.1.5 >SDL-image 1.0.9 1.0.10 >SDL-ttf 1.2.1 1.2.2 >SDL-mixer 1.0.6 1.0.6 >Python 1.5.2 2.0.0 Current pysdl works just fine with 2.0 (release candidate something), it needs a recompilation and changed defines for Py_Malloc and PyFree, such as: #define Py_Malloc PyMem_Malloc #define Py_Free PyMem_Free This was mentioned a while ago when I asked about 2.0, and I think Pete told me to do this. Anyway, it works just fine, I've used it quite a lot the last few weeks, without any problems. Well, problems of course, but they are related to my silly coding... Btw, while I'm here, has anybody had any problems with sdl.quit(), especially when running fullscreen? I usually run my desktop as 1600x1200, but my game is run fullscreen at 1024x768, and all works fine until the application is quit. The resolution never changes back to 1600x1200, but leaves at 1024x768. This is a little bit irritating, as everything else works fine. 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-10-17 05:15:02
|
It looks like Python 2.0 has been released, and I'm wondering how this
will affect pySDL. Mark hasn't been seen for quite a while and it's
possible he's lost interest in the project. That would be a real
shame, but until he re-appears, I think we have to operate as if we're
on our own.
Current pySDL We need
SDL 1.1.3 1.1.5
SDL-image 1.0.9 1.0.10
SDL-ttf 1.2.1 1.2.2
SDL-mixer 1.0.6 1.0.6
Python 1.5.2 2.0.0
I guess Pete Shinners has been working on a 2.0-compatible fork of
0.0.7; could we see that cleaned up and promoted to 0.0.8? Pete, is
your setup still windows-only, or is your work with distutils
complete? If you need any help fine-tuning the installation, I'd be
happy to help - I've got a dual-boot system we could test on.
When we do get something worth calling 0.0.8, I can post it to
Sourceforge, where I have admin rights to the file areas. I can't
update any other parts of the sourceforge pages, but at least people
will be able to find it :)
In spite of the license problems, I'd like to get to work with Python
2, and I'm willing to do whatever I can to help. (Hey, I've got to do
something on my vacation :))
Responses, suggestions and vicious personal attacks welcome.
--
David Clark
si...@te...
Preliminary pySDL Documentation:
http://www3.telus.net/futility/futility/docs/pysdl/index.html
|
|
From: Ben S. <be...@ni...> - 2000-10-13 20:42:05
|
Hello, it's been a long time since I've been active on this list. Ever since pysdl 0.0.2 or so I've been working on a UI toolkit. It is looking good, but I want to do a few more things before the initial public release. My todo list includes a few more things, documentation, some finer granularity classes for the "main window", and integration with my friend's text entry work. I'm expecting another six weeks or so of work, depending on what happens in my life, of course. If anyone's interested in more detail I can provide it, currently I feel pretty strongly that the code is not in the state I want it to be for release, but I wanted to mention it in case anybody is currently devoting time to a similar project and would rather wait until I release. Does anyone know if there will be a .8 release in the near future? The current version I have does not build with SDL 1.1.5 due to the new definitions in the SDL_Surface type, which I've just hacked around for now(the UI tk release is a higher priority to me). Also, I would love to get my hands on a copy of pysdl split to multiple modules for dependancy purposes, as I think it would make the mac port of pysdl much easier for me. -b |
|
From: Jan E. <ch...@in...> - 2000-10-12 18:39:14
|
On Thu, 12 Oct 2000, Peter Nicolai wrote: > >> I poll for events from pysdl using the normal >> sdl.events_poll() and handle >> available events. Then when all events are handled I >> check for the current >> time using time.clock(), which according to the docs >> is *the* function to >> use for timing and benchmarking. > >I think a while back we figured out that time.clock() >has more precision on windows and time.time() has more >precision on linux, so maybe it's less likely to get >'interrupted'? I don't know if it will help but maybe >it wouldn't hurt to try -P Yes, it has more precision, and above all: it works too. Thanks a lot for the help. The weird thing is that time.clock() seemed to be suspended while the network connection was open, it game the same value minute after minute, and as soon as the connection was trminated by the remote peer it started counting seconds and 1/10:ths of seconds. The value was always very low a few seconds), so apparently the counter was started when the application was started, or something similar? Anyway, time.time() seems to work ok, I just need to manipulate the float a little bit. Back to work... :-) --------------------+-------------------------------------------------------- Jan 'Chakie' Ekholm | Balrog New Media http://www.balrog.fi/ Linux Inside | I'm the blue screen of death, nobody hears your screams |
|
From: Peter N. <pn...@ya...> - 2000-10-12 17:58:30
|
> I poll for events from pysdl using the normal > sdl.events_poll() and handle > available events. Then when all events are handled I > check for the current > time using time.clock(), which according to the docs > is *the* function to > use for timing and benchmarking. I think a while back we figured out that time.clock() has more precision on windows and time.time() has more precision on linux, so maybe it's less likely to get 'interrupted'? I don't know if it will help but maybe it wouldn't hurt to try -P __________________________________________________ Do You Yahoo!? Get Yahoo! Mail - Free email you can access from anywhere! http://mail.yahoo.com/ |
|
From: Jan E. <ch...@in...> - 2000-10-12 08:41:17
|
Hi, I ran inton an interesting problem, which most likely is caused by ignorance and too much coffee. Anyway. I want to be able to get the current time of the system so that I can keep track ofthe current 'turn'. So, every 5 seconds (approximately, it's not a question of millisecond precision, more like +- a few hundred milliseconds. I poll for events from pysdl using the normal sdl.events_poll() and handle available events. Then when all events are handled I check for the current time using time.clock(), which according to the docs is *the* function to use for timing and benchmarking. The problem is that this method always returns the same value, such as 4.1, even when called thousands of times over several minutes. It seems that this is somehow connected to using select() on sockets, as I manage to get normal values from it after the remote peer has closed the socket i poll using select(). This is weird, but there must be a normal reason for it. It could of course be that Python 2.0b1 is buggy... Anyone else experienced the same problem? --------------------+-------------------------------------------------------- Jan 'Chakie' Ekholm | Balrog New Media http://www.balrog.fi/ Linux Inside | I'm the blue screen of death, nobody hears your screams |
|
From: Pete S. <pe...@vi...> - 2000-10-11 23:08:43
|
last night i was playing with more with optimizations and python. just thought i'd post the results since some of them might be interesting to some of you out there. first, using aliens, i did some side-by-side comparisons between C&SDL and Python&SDL. i took out all the audio from both c-aliens and py-aliens, then replaced the FPS idling with FPS counting. this was all on my Celeron-400, 128MB, TNT2-ultra i also locked the random seed for similar results each run (but couldn't get the same random results between C & Python) generally, the Python version ran about 65% the speed of the C version. So for general gaming, you should know you'll chop out 1/3 of the speed going with python. if you look at the big picture, just imagine your python processor is 1 year behind your C processor. of course, different parts of the code will have different ratios of performance. on the other hand, the Python version had about 1/2 the number of lines of code. it was worlds easier to work with and examine. for example, i was able to change the update algorithm for the Python version in about 5 lines of simple code. this gave me a 15% boost in speed. this would have been a lot more difficult on the C version. as far as getting the python version to work faster, i found the following results... disabling the (2b.0b2) garbage collection gave me no measurable speedup. cranking the sys.setcheckinterval() way up gave me about a 2% speedup, but it was hard to be measure for sure. (i found best results/value to be around 500, but in the end i don't think this tweaking is worthwhile) in a more roundabout tweaking, i tried to crank Windows process/thread scheduler to give me full priority. making minor changes (HIGH_PRIORITY_CLASS) made no noticeable difference, when i cranked things up (REALTIME_PRIORITY_CLASS, and TIME_CRITICAL) i saw a minor 3-4 fps improvement, but was astonished at how unresponsive the rest of the OS was. this type of tweaking is definitely NOT worth the costs on a Win98 system. (linux/NT may see better results? but not likely stellar) also, as usual, running python optimized (-O, -OO) netted no noticeable performance boost. (maybe 1-2 fps) in the end, it seems there's no such thing as a free speedup. there's not even very good ways to tweak python code to get it to run faster. the best advice i've found for optimizing pysdl code is... if you have several refernces to the same global/builtin variable in one routine, make a local reference to it and call that instead. it will only be in tight loops you see the fruit of this change, but local variables are quicker than global/builtin ones. this mainly applies to function calls use Numeric python find a better algorithm well, sadly i have nothing exciting to report with my latest testing, but the information does answer questions, and hopefully keeps other folks on the right track. a good page for general python optimization-ness is here http://www.musi-cal.com/~skip/python/fastpython.html |
|
From: Jan E. <ch...@in...> - 2000-10-09 13:51:01
|
On Sun, 8 Oct 2000, Ray Kelm wrote: >Maybe I didn't explain that well enough. The C code that performs the >blocking functions in python *releases* the lock, so that other threads >can run. One thread doesn't block other threads, unless the C code that >contains a blocking call does not release the lock, which is what pysdl >does right now. It can be fixed. I had a look at the functions in pysdl, and I get what you mean. I also looked at the docs for PyEval_SaveThread/RestoreThread and I start to understand what it is about. I was curious as to wether I could make it work myself, so I added the necessary two functions to the pysdl function sdl_events_wait(), and it kind of worked... :-) It didn't block out my other two threads anymore, but they also didn't block at all, i.e. my thread that was supposed to perform a blocking read() on a socket returned immediately. Well, no harm done, I will try another approach without threads. Thinking about it, polling is ok, as a game is allowed to hog anything it want, including the CPU. Nobody should complain about a game taking too much CPU. Polling it is, then. :-) I added the missing PyMem_Free to sdl_events_poll() and which seems to work quite ok and not leak memory like a pig... Thanks a lot for the patient help in making me understand things! Btw, the current sdlmodule.[c|h] are quite hard to maintain. The header-file is even a lot longer than most of my .c or .cpp files! The discussed split would come in quite handy. Maybe splits into at least separate files for events, video, sound, input, cdrom etc? Regards, 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: Pete S. <pe...@sh...> - 2000-10-08 18:20:30
|
> Ray wrote: > I know there was an patch for 1.5.2 (called "microthreading" I think) > to improve the granularity of the threading in python. It's possible > that 2.0 has incorporated that patch. this is with the stackless python patch. this is not incorporated into the 2.0, yet. http://www.stackless.com i've never used it, but reports were you could get over 1000 microthreads running easy. the way it works, the python interpreter becomes the actual thread timeslice controller. because of 'stackless' and 'continuations' the overhead is extremely low. the problem with this implementation, there is still only one real system thread running. a call to a c extension that doesn't return quickly will stall out the other microthreads. i'd say this isn't going to do a lot for python with sdl. > Jan Wrote > By the way, does anyone know of a good way to get PySDL > key-events translated so that I can get a string/character > with the pressed key? jan, take a look at the SDL_console library. this is doing it somehow with SDL code. if you find there is an SDL way of doing this that isn't available in pySDL, let me know. (i think i remember it's something to do with UNICODE_enable??) also, if there is no easy way to do it, can you post your lookup table? this would be a good thing to incorporate into pysdl. best to use sdl if there is a way, but worthwhile to add our own. |
|
From: Ray K. <rh...@ne...> - 2000-10-08 14:25:13
|
Jan Ekholm wrote: > > On Sat, 7 Oct 2000, Ray Kelm wrote: > > >Actually, at least for version 1.5.2, python threading uses a single > >lock for the interpreter, so only one thread of python code will run > >at a given time. When you enter a blocking call (like read, select, > >etc) the C code for that function has to release the interpreter lock. > > Urgh. Well, I'll try and see anyway. I use 2.0, so there may be some > changes. Personally I'd think it's silly for all threads to be suspended > just because one thread does some blocking call. If it doesn't work out > I've at leats learnt something about Python threading in the process. Maybe I didn't explain that well enough. The C code that performs the blocking functions in python *releases* the lock, so that other threads can run. One thread doesn't block other threads, unless the C code that contains a blocking call does not release the lock, which is what pysdl does right now. It can be fixed. I know there was an patch for 1.5.2 (called "microthreading" I think) to improve the granularity of the threading in python. It's possible that 2.0 has incorporated that patch. -Ray the granulat |
|
From: Jan E. <ch...@in...> - 2000-10-08 08:40:51
|
On Sat, 7 Oct 2000, Ray Kelm wrote: >Actually, at least for version 1.5.2, python threading uses a single >lock for the interpreter, so only one thread of python code will run >at a given time. When you enter a blocking call (like read, select, >etc) the C code for that function has to release the interpreter lock. Urgh. Well, I'll try and see anyway. I use 2.0, so there may be some changes. Personally I'd think it's silly for all threads to be suspended just because one thread does some blocking call. If it doesn't work out I've at leats learnt something about Python threading in the process. >As it works out (and has been discussed on the SDL mailing list) >threading in a game doesn't really work all that well on a single >CPU system. Mainly because the rendering thread can consume 100% cpu >all by itself, which means it will be interrupted by the scheduler >when an event happens, which causes choppiness in the display. Yep, you may be right. But then, I assume they were discussing games where there always is something to do, such as play music, render a complex 3D scene, run AI etc. I'm not doing that kind of game, but instead one that will spend most of its time waiting for the user to do something, or a packet to arrive from the opponent. If I needed ultimate performance I would most likely go with C/C++, as Python is not a real option in these causes (well, if you don't have the entire game as a single C extension). But, thanks for your tips, now I know that this time I *may* be able to blame the 'system', and not my own bugs if the threads don't work... :-) By the way, does anyone know of a good way to get PySDL key-events translated so that I can get a string/character with the pressed key? Such as when K_SPACE is triggered I get a nice string: " "? I need this for reading text from the player. Currently I have one big dictionary which maps K_* to some string, or the empty string if there is no real string-representation of the key, such as K_F1. Some other keys also need to be treated differently, such as K_BACKSPACE. Any ideas? Is there something I've overlooked so far? --------------------+-------------------------------------------------------- Jan 'Chakie' Ekholm | Balrog New Media http://www.balrog.fi/ Linux Inside | I'm the blue screen of death, nobody hears your screams |
|
From: Ray K. <rh...@ne...> - 2000-10-07 21:18:52
|
Jan Ekholm wrote: > > On Fri, 6 Oct 2000, Pete Shinners wrote: > >as far as handling threads, you'll find pysdl does not support > >the SDL threading routines. this is because python already > >comes with great crossplatform threading. (also with it's own > >semaphores/mutexes/locks). your best bet is to peek at the > >'Threading' module > > ...which was exactly the page I had in front of me. I have no problems > using threads, just the general thread-safeness of the system is > interesting. And problems with that tend to be hard to spot, very hard to > debug and otherwise just a PITA. Actually, at least for version 1.5.2, python threading uses a single lock for the interpreter, so only one thread of python code will run at a given time. When you enter a blocking call (like read, select, etc) the C code for that function has to release the interpreter lock. Since pysdl doesn't do this, it probably won't play nice with threading. It's fairly easy to implement (I did it in the python binding for SDL_gui) and works quite well. You basically have to save the thread state before you block (PyEval_SaveThread), then do your blocking call, then restore the thread state (PyEval_RestoreThread). This should at least be put in the SDL_WaitEvent wrapper function. > >because the event objects are written as C extensions, it is > >not easy to modify them much from the python side. your idea > >for a global user-data queue sounds like the best idea for now. > > Yep, it should also be quite simple, as there are ready synchronized > queues etc. > > >just a note here, you might have good results with the 'select' > >module. this works on windows and unix. it allows you to do > >asynchronous networking on a single thread. it even works well > >with multiple sockets. i've never looked into it too far, but > >i've heard good things about it. anyways if the threading gets > >too tricky, it might be a good alternative. > > I don't want to use that one. I'm more confident with splitting up my game > in as many logical modules as possible, and threads are a good idea of a > logical module in my world. Sure, they add complexity and reduce speed > (maybe), but will end up making my main event loop simpler. I can then > just sit an wait for some event to occur (user does something, packet > arrives etc). > As it works out (and has been discussed on the SDL mailing list) threading in a game doesn't really work all that well on a single CPU system. Mainly because the rendering thread can consume 100% cpu all by itself, which means it will be interrupted by the scheduler when an event happens, which causes choppiness in the display. There's more to it, but that covers the common case. -Ray |
|
From: Jan E. <ch...@in...> - 2000-10-07 09:12:05
|
On Fri, 6 Oct 2000, Pete Shinners wrote: >hi jan. most of the things you're asking about largely depend >on how the SDL library handles things. on many platforms (perhaps >all) the event handling is thread safe. in fact on some (like X11) >the event handling is already handled in a separate thread. Ok, sounds fine. >as far as handling threads, you'll find pysdl does not support >the SDL threading routines. this is because python already >comes with great crossplatform threading. (also with it's own >semaphores/mutexes/locks). your best bet is to peek at the >'Threading' module ...which was exactly the page I had in front of me. I have no problems using threads, just the general thread-safeness of the system is interesting. And problems with that tend to be hard to spot, very hard to debug and otherwise just a PITA. >because the event objects are written as C extensions, it is >not easy to modify them much from the python side. your idea >for a global user-data queue sounds like the best idea for now. Yep, it should also be quite simple, as there are ready synchronized queues etc. >just a note here, you might have good results with the 'select' >module. this works on windows and unix. it allows you to do >asynchronous networking on a single thread. it even works well >with multiple sockets. i've never looked into it too far, but >i've heard good things about it. anyways if the threading gets >too tricky, it might be a good alternative. I don't want to use that one. I'm more confident with splitting up my game in as many logical modules as possible, and threads are a good idea of a logical module in my world. Sure, they add complexity and reduce speed (maybe), but will end up making my main event loop simpler. I can then just sit an wait for some event to occur (user does something, packet arrives etc). >good luck with everything It will be needed. I'll return and cry when all fails... :-) Btw, anyone here interested in strategic games with too much time on their hands and an urge to help with some design issues (or coding too, of course)? --------------------+-------------------------------------------------------- Jan 'Chakie' Ekholm | Balrog New Media http://www.balrog.fi/ Linux Inside | I'm the blue screen of death, nobody hears your screams |
|
From: Pete S. <pe...@sh...> - 2000-10-06 14:42:21
|
> I was wondering wether the PySDL library is thread safe, > especially the event mechanism. I'm new to threading in > Python (threads in C are familiar), so I may be asking > stupid things here. hi jan. most of the things you're asking about largely depend on how the SDL library handles things. on many platforms (perhaps all) the event handling is thread safe. in fact on some (like X11) the event handling is already handled in a separate thread. as far as handling threads, you'll find pysdl does not support the SDL threading routines. this is because python already comes with great crossplatform threading. (also with it's own semaphores/mutexes/locks). your best bet is to peek at the 'Threading' module http://www.python.org/doc/current/lib/module-threading.html python is also very thread-safe, just make sure it is configured with --threads-enable. (some platform binaries do not come with threads enabled) > Another thing that I was wondering about was that the USEREVENTs > that are created seem to make it impossible for me to attach own > data to them? Ideally I'd like to send the received data along > with the new USEREVENT I'm creating, which would make it really > easy for the main thread to handle. > > An alternative is to just add USEREVENTs and now data. The main > thread would then when it receives one of them check a separate > synchronized queue of incoming data. because the event objects are written as C extensions, it is not easy to modify them much from the python side. your idea for a global user-data queue sounds like the best idea for now. > As a side > not I must say that it is real fun to develop using PySDL. It is big > complete enough to let me do anything I need while still being small > enough to not get in the way of doing stuff. yes, this is the beauty of SDL. it handles so much of the gruntwork, but is nice and thin. i believe you're out pioneering with pysdl and threads. i haven't seen any code doing it so far, and am interested in seeing with what you come up with. just a note here, you might have good results with the 'select' module. this works on windows and unix. it allows you to do asynchronous networking on a single thread. it even works well with multiple sockets. i've never looked into it too far, but i've heard good things about it. anyways if the threading gets too tricky, it might be a good alternative. good luck with everything |
|
From: Jan E. <ch...@in...> - 2000-10-06 12:27:23
|
Hi all, I was wondering wether the PySDL library is thread safe, especially the event mechanism. I'm new to threading in Python (threads in C are familiar), so I may be asking stupid things here. I'll need to read and write data from/to a socket, and want to do it asynchronously, outside my main event loop. Easiest thing is to have two threads for handling the incoming and outgoing traffic, and have outgoing data put on a synchronized queue and incoming data being added to the main PySDL event loop using: events_add( event_new(USEREVENT) ) My main thread would then know that something was received. Ok, so far so good. Apparently PySDL *is* htreadsafe, as the documentation states: "The thread management in the SDL library is covered in the core Python language, so there is no thread subsystem in pySDL." This makes me believe that I can from any thread add events to the queue, especially as I haven't found any method for locking PySDL or the event queue. Or am I wrong here? Another thing that I was wondering about was that the USEREVENTs that are created seem to make it impossible for me to attach own data to them? Ideally I'd like to send the received data along with the new USEREVENT I'm creating, which would make it really easy for the main thread to handle. An alternative is to just add USEREVENTs and now data. The main thread would then when it receives one of them check a separate synchronized queue of incoming data. How do you others handle these issues in PySDL and Python? I'm a beginner at both, so all ideas/hints/caveats etc are more than welcome! As a side not I must say that it is real fun to develop using PySDL. It is big complete enough to let me do anything I need while still being small enough to not get in the way of doing stuff. Regards, 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: bmbros <bm...@ma...> - 2000-10-03 12:32:51
|
Hello, Could someone build the patch I sent a few days ago on Windows? I need it quite quickly... If you can't, could someone tell me how should I to build it myself? Did you use visual studio? mingwin? cygwin? Thanx, Mike bm...@ma... |
