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-06-09 06:46:10
|
> > This is interesting. Results under Unix: > > avg smallest difference between two calls to time(): > 8.32080841064e-06 seconds. > avg smallest difference between two calls to > clock(): 0.01 seconds. > Whoa! 8 microseconds??? Something weird is happening, here, though. Look, I ran it again (this is maybe 3 hrs later than the first post...) avg smallest difference between two calls to time.time(): 0.0549999952316 seconds. avg smallest difference between two calls to time.clock(): 1.24038284412e-005 seconds. I don't know what I did but I'm gaining on you, uh, inversely. I remember reading about a bug that literally depended on the phase of the moon... I'm gonna go for a beer :) > To wit: opposite results in terms of precision. I guess a smart program would do this test before starting up the game. Are there any other timing functions available? It seems like someone would have written a more solid time module by now if the regular one is so goofy. > The issue, of course, is whether or not it works on > the Mac. Does > anyone on list have a Mac we could try this code out > on? > I can try it tomorrow, I'll let you know. They have both old and new Macs at school, and now I'd like to try it on a Unix machine too. Weird. > Incidently, you're missing an 'import time' line at > the top :) ha ha but actually I didn't need the 'sys' there I guess PS -- tried the test again, back to the old scores!!! What is going on??? __________________________________________________ Do You Yahoo!? Yahoo! Photos -- now, 100 FREE prints! http://photos.yahoo.com |
|
From: David C. <D. C. <si...@te...> - 2000-06-09 05:46:17
|
Peter Nicolai writes: > I think I have something useful to share, which gives > me a little lump in my throat...:) > > on win98: > > avg smallest difference between two calls to > time.time(): 0.0550000071526 seconds. > avg smallest difference between two calls to > time.clock(): 0.00199969828525 seconds. > > Does time.clock() work on all platforms? if so 2ms > accuracy isn't too awful, is it? I attached the > script, tell me if I'm missing something --P > <Code Snipped> This is interesting. Results under Unix: avg smallest difference between two calls to time(): 8.32080841064e-06 seconds. avg smallest difference between two calls to clock(): 0.01 seconds. To wit: opposite results in terms of precision. The issue, of course, is whether or not it works on the Mac. Does anyone on list have a Mac we could try this code out on? Incidently, you're missing an 'import time' line at the top :) David Clark si...@te... Preliminary pySDL Documentation: http://www3.telus.net/futility/futility/docs/pysdl/index.html |
|
From: Peter N. <pn...@ya...> - 2000-06-09 05:30:16
|
I think I have something useful to share, which gives me a little lump in my throat...:) on win98: avg smallest difference between two calls to time.time(): 0.0550000071526 seconds. avg smallest difference between two calls to time.clock(): 0.00199969828525 seconds. Does time.clock() work on all platforms? if so 2ms accuracy isn't too awful, is it? I attached the script, tell me if I'm missing something --P __________________________________________________ Do You Yahoo!? Yahoo! Photos -- now, 100 FREE prints! http://photos.yahoo.com |
|
From: David C. <D. C. <si...@te...> - 2000-06-09 01:05:48
|
Pete Shinners writes: > > i believe you'll find the python "time" module will handle > your timing needs just fine. the only thing that the SDL timing > routines give you is the ability to get callback events after > a certain amount of time. Really? I looked at 'time' first, of course, but rejected it after reading this (from the library docs): "on most Unix systems, the clock ``ticks'' only 50 or 100 times a second, and on the Mac, times are only accurate to whole seconds" Obviously, if time.time() returns values accurate only to whole seconds on the Mac, it's unsuitable for arcade gaming use. Thus my search for another, more accurate timer module. Strangely, I remember reading a thread on this topic a while ago in c.l.p, but I can't locate it now. David Clark si...@te... Preliminary pySDL Documentation: http://www3.telus.net/futility/futility/docs/pysdl/index.html |
|
From: Pete S. <pe...@vi...> - 2000-06-08 23:47:16
|
> computer is. This is The Right Thing. I chose not to port that section > of code ( wait_frame() for anyone who wants to write a patch ), > partially because I wanted to see how performance varied over > different systems and different video flags, but mostly because I > didn't want to bother learning Python timing techniques last > night. You see, SDL has a timing-specific subsystem, but Mark has > decided (rightly, IMO) not to incorporate that subsystem into pySDL, > instead leaving timing issues up to the python library. I may write > the appropriate code tonight; we'll see how motivated I am. i believe you'll find the python "time" module will handle your timing needs just fine. the only thing that the SDL timing routines give you is the ability to get callback events after a certain amount of time. there isn't anything like this in the python "time" module, but it wouldn't be hard to make a quick python version of it, or wrap around SDL's. the only thing i wonder is if anyone really uses timing callbacks in game environments. the most useful place for timing callbacks is inside GUI mainloops, where the user has limited control over a programs main event loop. this is hardly the case when developing games with SDL. one has full control over the event loops and the overall timing of the game as well. i question if timer callbacks are really useful in game environments. can't wait to try battling aliens tonight from home! :] |
|
From: Mark B. <mb...@0x...> - 2000-06-08 23:37:42
|
On Thu, 08 Jun 2000, "David Clark wrote: > > Does the speed limitation of the Python > > interpreter mean that it runs at somewhat similar > > speed on different-speed cpus? > > My guess about the source of the speed limitation is apparently > incorrect. Running on the same system using HWSURFACE vs. SWSURFACE > results in a huge speed difference, as you comment. Thus, the > limitation in speed is due to SDL and/or pySDL. I suspect it's due to > SDL, since running the C version of aliens without the frame rate > limiter results in a similar jump when going from software to video > memory. I'd blame all three at least a little. ;-) The PySDL version is quite a bit slower than the C version, however. I'm apt to blame Python for this, but with SVGAlib, it's still quite speedy. You did an excellent job of porting the little game, regardless of the failings of PySDL and Python. > Nonetheless, you're right - different systems will play my pyAliens at > vastly different speeds. The reason is simple. Sam's aliens is speed > limited - it can never get above 50 fps, no matter how fast your > computer is. This is The Right Thing. I chose not to port that section > of code ( wait_frame() for anyone who wants to write a patch ), > partially because I wanted to see how performance varied over > different systems and different video flags, but mostly because I > didn't want to bother learning Python timing techniques last > night. You see, SDL has a timing-specific subsystem, but Mark has > decided (rightly, IMO) not to incorporate that subsystem into pySDL, > instead leaving timing issues up to the python library. I may write > the appropriate code tonight; we'll see how motivated I am. I don't mean to belittle Sam Lantinga, but his approach is also flawed, and I imagine he only did it for simplicity. Certainly for this sort of game it doesn't matter, but when designing games, you shouldn't attempt to frame lock, for any number of good reasons. A superior approach is to work in terms of delta t. Each portion of game logic takes a certain amount of time, and the functions used to implement them should work in terms of this. Each time your heart beat pulses, you should update your game state using the amount of time that has passed. You move your sprites whatever percentage they've gone, you increase velocities whatever percentage they've accelerated, etc. |
|
From: David C. <D. C. <si...@te...> - 2000-06-08 23:11:18
|
> Does the speed limitation of the Python > interpreter mean that it runs at somewhat similar > speed on different-speed cpus? My guess about the source of the speed limitation is apparently incorrect. Running on the same system using HWSURFACE vs. SWSURFACE results in a huge speed difference, as you comment. Thus, the limitation in speed is due to SDL and/or pySDL. I suspect it's due to SDL, since running the C version of aliens without the frame rate limiter results in a similar jump when going from software to video memory. Nonetheless, you're right - different systems will play my pyAliens at vastly different speeds. The reason is simple. Sam's aliens is speed limited - it can never get above 50 fps, no matter how fast your computer is. This is The Right Thing. I chose not to port that section of code ( wait_frame() for anyone who wants to write a patch ), partially because I wanted to see how performance varied over different systems and different video flags, but mostly because I didn't want to bother learning Python timing techniques last night. You see, SDL has a timing-specific subsystem, but Mark has decided (rightly, IMO) not to incorporate that subsystem into pySDL, instead leaving timing issues up to the python library. I may write the appropriate code tonight; we'll see how motivated I am. David Clark si...@te... Preliminary pySDL documentation: http://www3.telus.net/futility/futility/docs/pysdl/index.html |
|
From: Peter N. <pn...@ya...> - 2000-06-08 17:15:08
|
Oops == sorry Michael!! duhh... I think I did that to Pete Shinners too (don't hit reply...don't hit reply...)--P BTW about the speed thing, try setting it to HWSURFACE and see what happens... eek. __________________________________________________ Do You Yahoo!? Yahoo! Photos -- now, 100 FREE prints! http://photos.yahoo.com |
|
From: Michal W. <sa...@ma...> - 2000-06-08 05:31:26
|
On Wed, 7 Jun 2000, David Clark <David Clark wrote: > pyAliens version 1.0 is now available from: > > http://www3.telus.net/futility/futility/warez/pyaliens-1.0.tar.gz > > pyAliens is my port of Sam Lantinga's Aliens demo to pySDL. It is > feature complete, but is not frame-rate limited like Aliens - > performance on very fast computers may get out of hand (although it's > my feeling that the speed of the python interpreter is the limiting > factor). Performance on my computer is excellent. Hey David, Wow! I'm really surprised how fast this runs. I was worried that python wouldn't be up to the challenge of an arcade style game, but this puts my fears to rest. I'm actually working on a tetris rip-off at the moment, but I haven't gotten past drawing a block on the screen, so I haven't really had a chance to see pySDL show off until now.. BTW: your docs have been a great help... :) Cheers, - Michal ------------------------------------------------------------------------ Zike Interactive http://www.zike.net/ http://zike.sourceforge.net/ ------------------------------------------------------------------------ |
|
From: David C. <D. C. <si...@te...> - 2000-06-08 03:41:09
|
pyAliens version 1.0 is now available from: http://www3.telus.net/futility/futility/warez/pyaliens-1.0.tar.gz pyAliens is my port of Sam Lantinga's Aliens demo to pySDL. It is feature complete, but is not frame-rate limited like Aliens - performance on very fast computers may get out of hand (although it's my feeling that the speed of the python interpreter is the limiting factor). Performance on my computer is excellent. I wanted to port this demo because Aliens is a frequently reused learning tool for new SDL programmers - I thought something similar would be useful for us. Enjoy! David Clark si...@te... Preliminary pySDL documentation: http://www3.telus.net/futility/futility/docs/pysdl/index.html |
|
From: Pete S. <pe...@sh...> - 2000-06-06 15:26:28
|
not sure how many are subscribed to the SDL mailing list, but either way, it's good news for pysdl! SDL 1.1.3 has been released. here's the full list of changes. shouldn't be too much work on the pysdl end. looks like there's a couple more constants and event type involved with the resizeable windows. everything else looks mainly internal. also good news, SMPEG should be ready for windows soon. there is a beta version with seems to run fine on my machine, but i don't think it has made the official release. once ready, this will allow for MP3 music, and full MPEG video playback through SDL on windows. 1.1.3: Use timeGetTime() instead of GetTickCount() on Win32 1.1.3: Release mouse when popped out of fullscreen on X11 1.1.3: IRIX 6.5 and FreeBSD 4.0 are now officially supported 1.1.3: Added optimization flags when compiling on x86 with gcc 1.1.3: On BeOS, change to app directory when launched by Tracker 1.1.3: Hold the option key on launch to get dialog on MacOS 1.1.3: Added DrawSprockets on MacOS (thanks Darrell Walisser) 1.1.3: Added support for Linux 2.4 input interface (HID) 1.1.3: Fixed 24-bpp blits on big-endian systems (thanks Mattias) 1.1.3: Don't try to use DGA mouse support on XFree86 4.00 1.1.3: Don't create an X11 shared memory buffer for GL displays 1.1.3: Framebuffer console acceleration disabled (broken) on G200 1.1.3: Allow maximize on resizable Win32 surfaces (thanks Randi) 1.1.3: Much faster RLE colorkey blit (thanks Xark and Mattias) 1.1.3: Fixed some problems with iconification and focus in X11 1.1.3: Added IMPS/2 protocol support for framebuffer console 1.1.3: Added user-resizable video mode support 1.1.3: Added arbitrary scaling of YUV overlay surfaces 1.1.3: Added support for semaphores and condition variables 1.1.3: Added SDL_ASYNCBLIT flag for asynchronous video updates 1.1.3: Don't let the WM place window in X11 fullscreen mode 1.1.3: Unload GL library after X11 display has closed 1.1.3: Fixed X11 error when a clipped rectangle is updated 1.1.3: Fixed crash when surface memory can't be allocated 1.1.3: Added a check for DirectX 5 audio (thanks Markus) 1.1.3: Added inline MMX assembly for YUV -> RGB conversion 1.1.3: Fixed startup crash in X11_RefreshDisplay() 1.1.3: SDL_Init(SDL_INIT_AUDIO) no longer fails with no soundcard 1.1.3: Initial YUV video overlay support (supports XvImages) 1.1.3: Fixed BadMatch X11 error with GLX 1.3 1.1.3: Worked around incompatibilities with XFree86 4.0 vidmode 1.1.3: The audio Makefile no longer takes forever to create 1.1.3: The joystick hat positions changed to constants 1.1.3: Fixed overlapping copy blit with odd widths 1.1.3: Fix for SDL_WINDOWID crash contributed by Mattias 1.1.3: Speeded up 32-bit alpha channel blits by nearly 100% 1.1.3: Added experimental DGA 2.0 support (set SDL_VIDEODRIVER) |
|
From: Mark B. <mb...@0x...> - 2000-06-03 21:42:30
|
On Sat, 03 Jun 2000, Pete Shinners wrote: > Numeric Python speeds this up by forcing all members of the array > to be the same type (although it does allow arrays of PyObjects). > Some of the operations are not 'intuitive'. the documentation > is good, but everything is still pretty 'technical'. Could you explain where this will be beneficial? > down the line i think the best interface would be creating a > new class, pysurface(?). it would be a wrapper around the numpy > array and offer the same calls as the current surface object. Why exactly would you create a new surface type, to use this array? PySDL's surface object utilizes SDL's SDL_Surface. Its pixel data is just a block of memory, either allocated from the heap, or mapped from a video card. All of the routines involving the manipulation of pixel data directly access this memory. I'm simply having a hard time attempting to determine how this will help. Someone please open my eyes. > > A command buffer for operations will most likely be a bit of work. It'd > > probably be a bit awkward in comparison to what people are generally used to > > as well, in order to make it efficient. > > do you imaging the buffer caching all blit and get_at, set_at style > operations? perhaps it would be a class that takes a surface object > as an initializer. then you call the standard surface operations on > it which end up putting a function object into a list. then some call > like commit() or flush() would just execute every function on the list? > hmm, i haven't thought the whole thing through, but it seems something > like that might be the way to go. > better yet, the commit() function could take an argument of the surface > to operate on. then you could just build a bunch of these command lists > and call them when needed. > (maybe taking an image and on x,y offset as args?) I was thinking of a command object that has surface methods. It could then convert these methods into some binary format, which then could be interpreted when the command object is 'executed.' I've been tossing some other ideas around, as well, but their interfaces aren't as intuitive. > cool. i think there are already some SDL libraries for doing this. > are you leaning towards our own implementation, or another dependency? I think most of these libraries also implement functionality we already have, or have already gotten from companion libraries. I'ven't really decided. For just simple primitives, the algorithms are simple, but I'ven't made any formal decisions. |
|
From: Mark B. <mb...@0x...> - 2000-06-03 21:23:29
|
On Sat, 03 Jun 2000, Mark Baker wrote: > Also note that I never used any locking For this to make sense, I should probably inform you that I used HWSURFACE with SVGAlib. I also forgot to comment on the numbers... All in all, I think this shows, if anything, that PySDL isn't very good at trying to write plasma, flame, or any other kind of per-pixel drawing 'demo.' Though I didn't include it, because of the lack of usefulness, s[:] = [[white] * 640] * 480 is the fastest in-Python test. The next is the slice test. The slice test only gets about 1/15th of the performance of the above. The fill_rect function, which is a C SDL function, achieved the highest of them all. About 22x the slice test. |
|
From: Mark B. <mb...@0x...> - 2000-06-03 21:01:29
|
Things to note: Certain variables are intentionally reinitialized inside of the timing loops. The purpose of this is to make the comparisons fairly equal. This only tests filling and single pixel drawing. There's no random access drawing test, because I got tired of writing the silly things ;-) I tested these on a slightly slower machine with an old S3 Trio64. SVGAlib: set_at pixel test: 0.000156 seconds. set_at pixel test with update: 0.000207 seconds. slice pixel test: 0.006275 seconds. slice pixel test with update: 0.006403 seconds. Rect fill test: 0.259660 seconds. Rect fill and update test: 0.259850 seconds. set_at fill test: 18.82996 seconds. set_at fill test with update: 15.39156 seconds. precopy fill test: 14.26057 seconds. precopy fill test with update: 14.26150 seconds. precopy fill using for in: 7.501874 seconds. precopy fill using for in with update: 7.495715 seconds. slice fill: 7.357192 seconds. slice fill with update: 7.360393 seconds. XFree86 3.3.4's S3 server: set_at pixel test: 0.000231 seconds. set_at pixel test with update: 0.075426 seconds. slice pixel test: 0.000787 seconds. slice pixel test with update: 0.076292 seconds. Rect fill test: 0.051827 seconds. Rect fill and update test: 0.317348 seconds. set_at fill test: 18.93499 seconds. set_at fill test with update: 19.12787 seconds. set_at fill test using for in: 15.81800 seconds. set_at fill test using for in, and updating: 15.86797 seconds. precopy fill test: 12.21884 seconds. precopy fill test with update: 12.06970 seconds. precopy fill using for in: 4.900853 seconds. precopy fill using for in with update: 5.126229 seconds. slice fill: 4.726172 seconds. slice fill with update: 4.650985 seconds. I've altered the formatting for brevity in this message. Also note that I never used any locking |
|
From: Pete S. <pe...@sh...> - 2000-06-03 20:21:59
|
> I've not used "Numerical Python", but here's a few things to consider: > The manipulation of multidimensional chunks of surfaces is already handled by > blitting. > Numerical Python may offer something other than array operations, but if that's > all it does, it's not going to help per-pixel manipulation. > The rest of Python's math is abysmally slow. This is the price of implementing > integers as objects, and requiring several function calls and conditionals for > each operation. Numeric Python speeds this up by forcing all members of the array to be the same type (although it does allow arrays of PyObjects). Some of the operations are not 'intuitive'. the documentation is good, but everything is still pretty 'technical'. I've been thinking about the best interface between numpy and sdl. for now i'm thinking stuff like get_array to complement get_at, etc. at that point i'll really be able to test out the speed and see if it's worth extending further and/or committing with the offical pysdl. down the line i think the best interface would be creating a new class, pysurface(?). it would be a wrapper around the numpy array and offer the same calls as the current surface object. the other neat thing about the numpy array is it can be accessed from their C API as a simple C array of whatever datatype it is. > A command buffer for operations will most likely be a bit of work. It'd > probably be a bit awkward in comparison to what people are generally used to > as well, in order to make it efficient. do you imaging the buffer caching all blit and get_at, set_at style operations? perhaps it would be a class that takes a surface object as an initializer. then you call the standard surface operations on it which end up putting a function object into a list. then some call like commit() or flush() would just execute every function on the list? hmm, i haven't thought the whole thing through, but it seems something like that might be the way to go. better yet, the commit() function could take an argument of the surface to operate on. then you could just build a bunch of these command lists and call them when needed. (maybe taking an image and on x,y offset as args?) > Before that, though, I think I'll work on some drawing primitives for the > existing surfaces. Circles, lines, etc. We'll see. cool. i think there are already some SDL libraries for doing this. are you leaning towards our own implementation, or another dependency? whew! enough mail from me, i need lunch! |
|
From: Pete S. <pe...@sh...> - 2000-06-03 20:12:43
|
From: "Peter Nicolai" <pn...@ya...> > Also I think it's really > important to keep things simple because that's the > whole reason to use Python instead of C anyway. yes, i try not to lose sight of this myself. i much prefer game engine/api's that are very thin. some of the free game engines on the net are so 'overbearing', they seem to take over every aspect of the game. while this might be better in the long run (? very debatable ?) it makes for a huge rampup time to get using an engine that is too generic, or too focused for one area. i think this is why i'm pleased with SDL. not only is it cross-platform, but it's really thin! my app handles everything it needs to, SDL just has the functions to make it easy. > I doubt anyone is ever going to use PySDL for hardcore > mindblowing demo graphics, but it would be great to > have a reasonably easy way to implement simple effects > and not be totally limited to the sprite paradigm. "ever" is a long time :] after reading Game Developer Magazine's port mortem of Gabriel Knight 3, they stressed the value of building a scripting engine into the game. The interviewee said that for their next game, scripting was going to even more important and even more embedded into the engine. |
|
From: David C. <D. C. <si...@te...> - 2000-06-03 20:01:30
|
Mark Baker writes: > No, it's not slower. It's slower for plotting a single pixel, but that's to be > expected. For many things, it's about 4x faster. > I'll put together a small benchmark of various styles, and you'll all be able > to see for yourself. > This is pretty clear. Slice operators are great for those drawing operations that can be expressed in terms of x or y constants: horizonal and vertical lines. Put_pixel is ideal for single pixel plotting. Standard rectangular blits should be used for everything else. > > A command buffer for operations will most likely be a bit of work. It'd > probably be a bit awkward in comparison to what people are generally used to > as well, in order to make it efficient. > > Before that, though, I think I'll work on some drawing primitives for the > existing surfaces. Circles, lines, etc. We'll see. My feeling is that the current discussion is overemphasizing direct pixel plotting as opposed to sprite operations and rectangular blits. This is to be expected, since we're learning by doing the simpler demos, which don't use sprites at all. However, I think that the destiny of pySDL is in the sprite area - people who want arbitrary pixel addressing based on complex math will probably always use C, and pySDL will be used for tile-based games, such as RPGs and strategy games. Mark's a busy guy; I'm not sure this low-level stuff is worth his time. Comments? -- David Clark si...@te... Preliminary pySDL Documentation http://www3.telus.net/futility/futility/docs/pysdl/index.html |
|
From: Mark B. <mb...@0x...> - 2000-06-03 19:34:26
|
On Sat, 03 Jun 2000, Peter Nicolai wrote: > So there is also the slice operator, but that turns > out even slower: No, it's not slower. It's slower for plotting a single pixel, but that's to be expected. For many things, it's about 4x faster. I'll put together a small benchmark of various styles, and you'll all be able to see for yourself. > >Why Numerical Python? > >If x and y are Numerical Python arrays, then the > >speed of the operation x + y is close to the speed of > >doing it in C if the arrays are big enough. Thus, > >Python can be extended with a full scientific array > >language with sophisticated indexing and shaping > >operations and yet be closer to the speed of a > >compiled language than to the speed of Python itself. I've not used "Numerical Python", but here's a few things to consider: The manipulation of multidimensional chunks of surfaces is already handled by blitting. Numerical Python may offer something other than array operations, but if that's all it does, it's not going to help per-pixel manipulation. The rest of Python's math is abysmally slow. This is the price of implementing integers as objects, and requiring several function calls and conditionals for each operation. > This is deep water for me but it seems like Pete > Shinners' idea of numpy-arrays that could be treated > as 'fake' software surfaces that could then use the > blit operation would be a decent solution to these > kinds of problems, if it can be done. The > execute-buffer thing sounds like it would be better & > faster but also a lot more work to implement, though I > have no idea if this is true. Also I think it's really > important to keep things simple because that's the > whole reason to use Python instead of C anyway. A command buffer for operations will most likely be a bit of work. It'd probably be a bit awkward in comparison to what people are generally used to as well, in order to make it efficient. Before that, though, I think I'll work on some drawing primitives for the existing surfaces. Circles, lines, etc. We'll see. |
|
From: Peter N. <pn...@ya...> - 2000-06-03 18:58:51
|
Ok I cut and pasted a lot here: > Mark Baker writes: > > right now in pysdl, there's no way to go mess with > > pixels aside from the get_at and put_at. > This is inaccurate. You can manipulate surfaces > using the slice operator. So there is also the slice operator, but that turns out even slower: "David Clark <David Clark" <si...@te...> wrote: > A note: in my testing, writing individual pixels by > using the surface > object's "list of lists" structure is about 25% > slower than by using > set_at() (as expected). --- Pete Shinners <pe...@vi...> wrote: > i've been spending time with Numeric, and it > should be really simple to make some functions > to transfer between surfaces and arrays. once > this is done the fire demo should run swift > under python. (i would hope) From the NumPy page - http://numpy.sourceforge.net/ : >Why Numerical Python? >If x and y are Numerical Python arrays, then the >speed of the operation x + y is close to the speed of >doing it in C if the arrays are big enough. Thus, >Python can be extended with a full scientific array >language with sophisticated indexing and shaping >operations and yet be closer to the speed of a >compiled language than to the speed of Python itself. This is deep water for me but it seems like Pete Shinners' idea of numpy-arrays that could be treated as 'fake' software surfaces that could then use the blit operation would be a decent solution to these kinds of problems, if it can be done. The execute-buffer thing sounds like it would be better & faster but also a lot more work to implement, though I have no idea if this is true. Also I think it's really important to keep things simple because that's the whole reason to use Python instead of C anyway. I doubt anyone is ever going to use PySDL for hardcore mindblowing demo graphics, but it would be great to have a reasonably easy way to implement simple effects and not be totally limited to the sprite paradigm. --Peter __________________________________________________ Do You Yahoo!? Yahoo! Photos -- now, 100 FREE prints! http://photos.yahoo.com |
|
From: David C. <D. C. <si...@te...> - 2000-06-03 17:55:51
|
Mark Baker writes: > > In order to get the behavior you're looking for, you'd need to do something > like: > > y_list = video[100] > y_list[100] = video.map_rgb((255, 255, 255)) > video[100] = y_list > > Cleary for one pixel, it's advantegous to use set_at. > Got it. Is it your plan to eventually switch to a video[y][x] = color scheme, or is the current system as far as you want to take this? A note: in my testing, writing individual pixels by using the surface object's "list of lists" structure is about 25% slower than by using set_at() (as expected). While waiting for 0.0.6, I'll be porting Sam's aliens.c over to python. I'm pretty excited about this, since the blit-heavy nature of the program should result in pretty good performance, and I think that most SDL users learn by reading aliens.c (there's a lot of "aliensisms" in other peoples code :)) David Clark si...@te... Preliminary pySDL Documentation: http://www3.telus.net/futility/futility/docs/pysdl/index.html |
|
From: Mark B. <mb...@0x...> - 2000-06-03 17:40:05
|
On Sat, 03 Jun 2000, "David Clark wrote: > My understanding is that the following minimal test program should > work. Unfortunately, it doesn't. > > #! /usr/bin/env python > > import sdl > sdl.init(sdl.INIT_VIDEO) > video = sdl.video_set_mode(200,200,16,sdl.SWSURFACE) > video[100][100] = video.map_rgb((255,255,255)) > video.update_rect((0,0,0,0)) > while 1: > pass > > This should plot a white pixel at the center of the surface, but no > white pixel appears. This is strange; I remember testing this back > when it was introduced in 0.0.3, and it worked fine then. Am I doing > something wrong? This is what you would intuitively expect, I imagine, but it's never worked this way. video[100] this returns a list of of the pixels at 101 video[100][100] indexes the 101st element of the list returned from video[100] So when you do video[100][100] = value, what you're doing is assigning value to this element in the list returned by video[100]. However, this list doesn't directly map to the memory used by video. In order to get the behavior you're looking for, you'd need to do something like: y_list = video[100] y_list[100] = video.map_rgb((255, 255, 255)) video[100] = y_list Cleary for one pixel, it's advantegous to use set_at. For linear access cases, it's faster to do stuff like: y = 0 for y_list in video: for x in y_list: x = get_some_color() video[y] = y_list y = y + 1 For less linear access cases, but still in loop, it's better to do something like: s_copy = video[:] some_loop_construct: s_copy[y][x] = some_color x = some_number() y = some_number() s_copy[y][x] = another_color video[:] = s_copy Generally speaking, if you can get your code into a for x in some_range it'll be faster. If you can't, then it's a good idea to copy the buffer, and then copy it back when you're done. If you're not doing a lot of drawing, set_at is probably a good idea. |
|
From: David C. <D. C. <si...@te...> - 2000-06-03 16:51:52
|
Mark Baker writes:
> On Fri, 02 Jun 2000, Pete Shinners wrote:
> > right now in pysdl, there's no way to go mess with
> > pixels aside from the get_at and put_at. needless
> > to say this is extremely slow. even a 200x150 window
> > of the fire takes a couple seconds each frame.
>
> This is inaccurate. You can manipulate surfaces using the slice operator.
> surface[y] returns a list of pixels.
> c_x = surface[y]
> x = 0
> while x < len(c_x):
> c_x[x] = some_color
> some_color = some_other_color()
> x = x + 1
>
> Whether or not this ends up being faster, is a different story all together.
My understanding is that the following minimal test program should
work. Unfortunately, it doesn't.
#! /usr/bin/env python
import sdl
sdl.init(sdl.INIT_VIDEO)
video = sdl.video_set_mode(200,200,16,sdl.SWSURFACE)
video[100][100] = video.map_rgb((255,255,255))
video.update_rect((0,0,0,0))
while 1:
pass
This should plot a white pixel at the center of the surface, but no
white pixel appears. This is strange; I remember testing this back
when it was introduced in 0.0.3, and it worked fine then. Am I doing
something wrong?
--
David Clark
si...@te...
Preliminary pySDL Documentation:
http://www3.telus.net/futility/futility/docs/pysdl/index.html
|
|
From: Mark B. <mb...@0x...> - 2000-06-03 13:54:33
|
On Fri, 02 Jun 2000, Pete Shinners wrote: > right now in pysdl, there's no way to go mess with > pixels aside from the get_at and put_at. needless > to say this is extremely slow. even a 200x150 window > of the fire takes a couple seconds each frame. This is inaccurate. You can manipulate surfaces using the slice operator. surface[y] returns a list of pixels. c_x = surface[y] x = 0 while x < len(c_x): c_x[x] = some_color some_color = some_other_color() x = x + 1 Whether or not this ends up being faster, is a different story all together. For the future I intend to have an execute buffer based alternative "surface" object. This will allow various operations to be stored in a queue, and to be executed from C routines. Other things I've been considering, is a map_rgba. For the most part, dealing with alpha from within PySDL isn't overly friendly at this point. It's alright for blits and what not, but not friendly for per-pixel manipulation. PySDL, I'm afraid, may also never be overly good for complex per-pixel manipulation. Python simply isn't a fast language, and drawing in Python loops will never really rival a compiled language. Though I do intend to attempt to optimize things using the execute buffer, I'm not certain if it'll really help much, and I'm not sure it really matters. Most games are little more than bitmap pushers, and this should certainly be faster, due to most of this being in SDL. |
|
From: Pete S. <pe...@vi...> - 2000-06-03 01:24:50
|
Peter Nicolai wrote: > you mean integrating NumPy into SDL-specific calls or > something? It would be nice to use this for > generative-art type stuff --p well, i tried porting the SDL demo, XFlame. this just does the standard fire effect creeping up the screen. right now in pysdl, there's no way to go mess with pixels aside from the get_at and put_at. needless to say this is extremely slow. even a 200x150 window of the fire takes a couple seconds each frame. i've been spending time with Numeric, and it should be really simple to make some functions to transfer between surfaces and arrays. once this is done the fire demo should run swift under python. (i would hope) my current design is to add a few functions to the surface objects: get_array(rect) -> array set_array(rect, array) get_array_rgb(rect) -> (array, array, array) set_array_rgb(array, array, array) map_rgb_array(array, array, array) -> array they should be pretty common sense. getting the surface image data as an array of ints, and also the ability to get the array as a set of R, G, B arrays. we'll probably want something for the alpha as well? i am interested in hearing people's ideas of how best to lay this out? perhaps instead of the set_array style functions you are allowed to pass an array as a source for blit() and/or create new surfaces with an array in the constructor? numeric python has a great C-interface, so it should hook into pysdl really easily as well as be very quick. need input |
|
From: Peter N. <pn...@ya...> - 2000-06-02 23:32:06
|
hi -- First of all thank you Mark, Pete, David and whoever else for working on PySDL and the Win32 port. Everything seems to work just fine on my machine -- I see panda bears -- though with a few ideosyncracies. For example, Photoshop goes haywire while a PySDL window is running??? whee... also, when using hardware surfaces, the only way to get the fill_rect() to work is for me to NOT lock the surface like I'm supposed to. I'm using doublebuffer, could that be why? It works fine without locking but I guess it might not run on other machines. If mustlock() is true on a machine does it mean that fill_rect will then work on a locked surface? I was trying to figure out how to hide the mouse cursor. There's an SDL ShowCursor() toggle. It would be an interesting learning experience to try to add this to sdlmodule but the problem is then compiling it. Could this be put in one of your revisions, or do you have a MSVC project file yet? Finally I tried making a simple class that makes a sprite-like object so I can create and redraw a bunch of things easily. It seems to work but is slow -- is this something that shouldn't be done in python or using a class? Anyway thanks a lot, this is a lot of fun for me . -- peter __________________________________________________ Do You Yahoo!? Yahoo! Photos -- now, 100 FREE prints! http://photos.yahoo.com |
