pysdl-devel

Re: [Pysdl-devel] pysdl & numpy decision

[Peter N. <pn...@ya...>]

> so anyways, a decision has to be made. i personally
> still
> like the X,Y notation, it just 'clicks' for my
> brain. but
> i could easily adapt to the other style. it's really
> simple to do on the "C" side either way we just need
> to
> make a choice.
> 
> i definitely leave this one open for discussion, i
> might
> have missed a good argument for/against either
> method.

just my 2c:

my instinct is that if surface.pixels[] 'directly'
operates on a numpy array, then it should be in the
regular format of a numpy array ([y,x]) even if that
feels wierd.  That way, once you figure out how numpy
arrays work, you won't be confused further (like I was
by your example :) .  

that said I think it might be great to define
functions that would operate on the array 'indirectly'
and that would offer the familiar
surf.some_method(info, (INT x, INT y, INT w, INT h))
format, or surf.setpixel((x,y),color) or whatever. 
There are all kinds of possibilities for that... But
the 'real' array I think should be unreversed and if
possible contiguous, also then it would be as close as
possible to the way (i think?) SDL surfaces are
stored, even a few % speedup is worth it and the
transfer is more elegant.  Also I actually think it's
easier to think about because it's the same as the
regular PySDL surface access.
 --P






__________________________________________________
Do You Yahoo!?
Send instant messages & get email alerts with Yahoo! Messenger.
http://im.yahoo.com/

[Pysdl-devel] pysdl & numpy decision

[Pete S. <pe...@sh...>]

> It's not that bad now that I figured out the
> funky-looking slice notation and found out I don't
> have to know matrix math.  It looks like most of what
> I'd use it for would just require the easier stuff.

yeah, all it comes down to is their flexible slicing and
using the ufuncs. i'm pretty sure the pyopengl module
also uses numpy for arrays of point attributes. i think
this is an incredible mix and do want to try playing
with it.



> I tried your gradient function with just the normal
> slice operator.  It is still fast but takes .160 sec
> just on the one slice command to transfer to the
> surface. So the surf.pixels thing will be great.  Also
> I had to fix a couple things:
> --These should be [2]'s for blue ^ not alpha
> --The first shape parameter is the # of rows, not the

doh, you caught me. i whipped the routine up at work.
and was unable to try the final version of the code,
i only knew the 'meat' of it created the gradient :]



> > so now surface.pixels[20,20] lets you access pixel
> > at 20,20
> Won't this be the same problem with w and h?  I guess
> it depends on which way your conversion goes as far as

ok yes, this is the __BIG__ decision that needs to be
made. which order the pixel array is accessed: X,Y or Y,X


X,Y: this is the most intuitive order for me, that's about
the only argument for it (heh), when printing the array
it is actually transposed from the way it is viewed, kinda
strange, but usually you don't print arrays of images,
that's really slow and only for debugging

Y,X: aside from me finding this a little odd, it does offer
some encouraging benefits. first, it keeps the interface more
consistent with the currently available index operators
(mysurface[50][10] = mysurface.pixels[50,10] = row 50, column 10).
of coarse, if you print the array it's WYSIWYG. the other
potential benefit is a slight speed boost. if we access the
surface with Y,X and it has no odd pitch settings the pixel
data is 'continuous' and numpy has some optimizations here
and there for these continuous blocks of data. (don't get too
excited about this, it's just a couple %'s faster)


so anyways, a decision has to be made. i personally still
like the X,Y notation, it just 'clicks' for my brain. but
i could easily adapt to the other style. it's really
simple to do on the "C" side either way we just need to
make a choice.

i definitely leave this one open for discussion, i might
have missed a good argument for/against either method.

here's my crude examples;

surf.pixels[:,100]  ==  row 100 _or_ column 100
surf.pixels[50,10]  ==  row 50 & col 10 _or_ row 10 & col 50



> would it be possible to keep an extra position in the
> 3rd dimension in addition to the RGBA, to use
> optionally as an additional mask or a terrain
> identifier (ie passable/impassable) for tiles in a
> map, or possibly for bump maps?  Maybe that's overkill
> though. 

yeah, this would be possible, but your right it might be
a little overkill. probably better as a separate array,
but who knows? especially since arrays must contain all
the same data type, so unless your mask/terrain/map data
is the same format as the pixels you really don't want
to mix them.



> Thank you for doing this.  I'm going to try to turn my
> own more convoluted gradient function into array
> functions.  I think in my case the math was the real
> bottleneck so it should help a lot.  I was doing a
> radial blend between two colors with an adjustable
> curve.  It would be nice if it could work in real
> time.

whew, if/when you get this working mind posting it?
it'd probably make a good example of something pretty
complex being done with the arrays.


> Also, are there any plans to support SMPEG?  I've been
> surprised to find that there are almost no Python
> multimedia extensions, but it would be fun to mess
> with that. I'm glad to see SDL_mixer supporting Ogg
> Vorbis. 

yeah, in fact all the new SDL "support" libraries seem
to have gotten neat new features (as david noted in
his mail)




note, just so you can play with this at home.. here are
the quick changes you need to make to use the "pixels"
member

/* this goes near the top (fix path)*/
#include "../Numerical-15.3/Include/arrayobject.h"


/* this goes in initsdl after Py_InitModule3 line*/
    import_array();


/* and here is the main code, this goes in
   sdl_surface_getattr, put this block at the top
   of the function */
 
if(!strcmp(attrname, "pixels"))
 {
     Surface_Object* surface_ref = (Surface_Object*)self;
     SDL_Surface* surf = surface_ref->surf;
     PyObject* array;
     int dim[2],  type;
     switch(surf->format->BytesPerPixel)
     {
  case 1: type = PyArray_UBYTE;  break;
  case 2: type = PyArray_SHORT;  break;
  case 4: type = PyArray_INT; break;
  default:
      PyErr_SetString(PyExc_RuntimeError, "no support for 24bit surfaces yet");
      return NULL;
     }
     dim[0] = surf->w;
     dim[1] = surf->h;
     array = PyArray_FromDimsAndData(2, dim, type, (char*)surf->pixels);

     /*swap x and y, and account for stride*/
     ((PyArrayObject*)array)->strides[0] = surf->format->BytesPerPixel;
     ((PyArrayObject*)array)->strides[1] = surf->pitch;
     ((PyArrayObject*)array)->flags &= ~CONTIGUOUS;
     return array;
 }


/*tada, the formatting is likely destroyed by email
  but its a small piece of code. note, no support for
  24bit surfaces with this. still a little uncertain
  of how to best handle them*/

whew, these pysdl mails are getting longer and longer :]

Re: [Pysdl-devel] To do?

[Peter N. <pn...@ya...>]

> On that note, something I've noticed (on Win98) -- 
> the PySDL window acts funny

I have to modify this because it only happens in
certain cases when the hourglass icon appears -- in
this case during a loop when I'm setting surface
pixels before updating.  When I update, I can get the
window again. No big deal...

I still wonder about the console window thing although
I did find that running a script with 'pythonw.exe'
gets rid of the console.  I've been trying out
'Freeze' though and it doesn't work there.

__________________________________________________
Do You Yahoo!?
Kick off your party with Yahoo! Invites.
http://invites.yahoo.com/

Re: [Pysdl-devel] To do?

[Peter N. <pn...@ya...>]

> SDL - I think the big change is re-sizable window
> support - we need to
> implement a SDL_RESIZABLE constant and
> SDL_VIDEORESIZE events. 

On that note, something I've noticed (on Win98) -- 
the PySDL window acts funny.  If you change windows on
your desktop, it stays hidden under them even if you
select it on the taskbar, so you have to close all
your windows to see it.  Also, if you click on an
exposed part of a partially hidden window, it doesn't
come to the top.  If you right-click on it on the
taskbar, though, the pop-up menu comes up and the
window surfaces again.  This doesn't happen with
regular SDL apps like defendguin.  

Also this is a minor thing but can python run a
program without displaying the console window?  I
looked through the docs but only found something
mac-specific.  It would be nice to have only one
window and one button on the taskbar for a program.
--P



__________________________________________________
Do You Yahoo!?
Kick off your party with Yahoo! Invites.
http://invites.yahoo.com/

[Pysdl-devel] To do?

[David C. <D. C. <si...@te...>]

Here's a little update as to where pySDL stands relative to the
software it depends on:

 Library          Supported             Current
-----------------------------------------------------------
 SDL               1.1.2                 1.1.3
 SDL_image         1.0.8                 1.0.9
 SDL_mixer         1.0.5                 1.0.6
 SDL_ttf           1.0.1                 1.2.1

SDL - I think the big change is re-sizable window support - we need to
implement a SDL_RESIZABLE constant and SDL_VIDEORESIZE events. There
are new bitmask joystick hat constants for the event subsystem, and
support for YUV video overlay and asynchronous blitting.

SDL_image - Mark kindly implemented TIFF file format loading, and it
seems to work great. Version 1.0.9 added TGA format loading, which
will be pretty nice, since it supports RLE encoding for extra file
size reductions.

SDL_mixer - SDL now supports the very exciting Ogg Vorbis compression
format, a free alternative to mp3.

SDL_ttf - Many functions have been added, the most important of which
is alpha blended dithering. Speed and memory usage have also improved.

SMPEG - Will now build on win32 and beOS.

As far as I can tell, the latest versions don't break anything; I'm
currently using the most recent versions of everything ok. My
documentation is currently on the back burner as I write my game and
play Diablo II, but I'll get back to it when 0.0.7 is released :)

-- 
David Clark
si...@te...
Preliminary pySDL Documentation:
http://www3.telus.net/futility/futility/docs/pysdl/index.html

Re: [Pysdl-devel] numpy testing

[Peter N. <pn...@ya...>]

--- Pete J Shinners <pe...@fo...> wrote:
> anyways, i know it comes off a little 'intimidating'
> at
> first glance, but with numpy you can do amazingly
> complex
> operations with needing loops in python. 

It's not that bad now that I figured out the
funky-looking slice notation and found out I don't
have to know matrix math.  It looks like most of what
I'd use it for would just require the easier stuff.

I tried your gradient function with just the normal
slice operator.  It is still fast but takes .160 sec
just on the one slice command to transfer to the
surface. So the surf.pixels thing will be great.  Also
I had to fix a couple things:

> def fill_blue_gradient(surf):
>     w = surf.get_width()
>     h = surf.get_height()
>     bloss = surf.get_losses()[3]
>     bshift = surf.get_shifts()[3]
                                 ^
--These should be [2]'s for blue ^ not alpha

>     ramp = arange(0, 255, 255.0/h, Int)
>     #convert to surface colorspace
>     ramp = ramp >> bloss << bshift
>     #make 2 dimensional
>     ramp = resize(ramp, (h, w))

--The first shape parameter is the # of rows, not the
length of a row -- should be: 
     ramp = resize(ramp, (w, h)) 
-because we're going to transpose it, and also
otherwise the gradient is all screwed up because it
doesn't fit the row length.


>     #assign to surface
>     #with my private unofficial pysdl&numpy bind
>     surf.pixels[:] = transpose(ramp)

I put:
      surf[:] = transpose(ramp).tolist()

That worked fine.  The rest of the function took .01
sec.  

> so now surface.pixels[20,20] lets you access pixel
> at 20,20

but then is surface.pixels[30,20] x=30 or y=30? Numpy
reverses things. Seems like it should be y=30? 

> def double_image(src, dst):
>     "dst must be at least big enough for 2xsrc"
>     w = src.get_width()*2
>     h = src.get_height()*2
>     dst.pixels[0:w:2,0:h:2] =
> dst.pixels[1:w:2,0:h:2] = src.pixels[:]
>     dst.pixels[:,1:h:2] = dst.pixels[:,0:h:2]

Won't this be the same problem with w and h?  I guess
it depends on which way your conversion goes as far as
x and y being rows or columns.  Maybe I'm confused.
Seems like it should go [y,x], maybe I just think that
way because of how it prints the arrays in the
console. But I think that would keep it consistent
with the regular slice operator.  


> the other feature i want before i "submit" is the
> ability to create a 3D array of the surface, with
> width and height
> being 2 of them, and each color plane (and alpha)
> being the 3rd
> dimension. 

would it be possible to keep an extra position in the
3rd dimension in addition to the RGBA, to use
optionally as an additional mask or a terrain
identifier (ie passable/impassable) for tiles in a
map, or possibly for bump maps?  Maybe that's overkill
though. 

Thank you for doing this.  I'm going to try to turn my
own more convoluted gradient function into array
functions.  I think in my case the math was the real
bottleneck so it should help a lot.  I was doing a
radial blend between two colors with an adjustable
curve.  It would be nice if it could work in real
time.

Also, are there any plans to support SMPEG?  I've been
surprised to find that there are almost no Python
multimedia extensions, but it would be fun to mess
with that. I'm glad to see SDL_mixer supporting Ogg
Vorbis. 

Just to make this email go on forever, I also have
been looking for info on Python browser plugins --
seems there were two projects for this that bit the
dust some time ago.  I did contact the Alice people
and they said if you run Python in restricted mode and
don't allow fullscreen it is ok for security.  Then
again they've dropped Python and are switching to
Java... ok bye

--P

__________________________________________________
Do You Yahoo!?
Kick off your party with Yahoo! Invites.
http://invites.yahoo.com/

[Pysdl-devel] numpy testing

[<pe...@fo...>]

we'll i did write up a simple numpy and pysdl binding and
it worked out to be turbo-fast. my flame tests ran at
twice the speed from the version using numpy, but with no
quick way to xfer that to the surface data.
while not fully featured, my little binding simply adds a
new member to all the surface objects, named "pixels"

so now surface.pixels[20,20] lets you access pixel at 20,20
this was an incredibly simple addition (just a couple lines
of code)

anyways, like i mentioned the flame demo ran at twice the
speed. there was also this mentioned...


>But I tried drawing simple gradients in a Python loop..
>I can make a beautiful Wise Installer/Power Point cheesy
>blue blend in about... 20-30 seconds.

here is a simple numpy example of creating a blue
gradient and putting it into a surface. this example
fills a 640x480 surface in about .05 seconds (1/17th)


def fill_blue_gradient(surf):
    w = surf.get_width()
    h = surf.get_height()
    bloss = surf.get_losses()[3]
    bshift = surf.get_shifts()[3]
    #create vertical stripe
    ramp = arange(0, 255, 255.0/h, Int)
    #convert to surface colorspace
    ramp = ramp >> bloss << bshift
    #make 2 dimensional
    ramp = resize(ramp, (h, w))
    #assign to surface
    #with my private unofficial pysdl&numpy bind
    surf.pixels[:] = transpose(ramp)


anyways, i think with the numpy extensions pythin --CAN--
be used for pixel manipulating type routines we were 
expecting to be "C" side only. (stuff like transparant
sprite collision detection is a snap)


as far as scaling images go, SDL does have some
"SoftStretch" scaling routines, but i was told not to
use them as they will be removed once a real version
of "scaling" is implemented (one that allows for
hardware acceleration)

fortunately, numpy again offers a quick enough way
to do 2X image scaling for now. (until SDL does it
"right")

def double_image(src, dst):
    "dst must be at least big enough for 2xsrc"
    w = src.get_width()*2
    h = src.get_height()*2
    dst.pixels[0:w:2,0:h:2] = dst.pixels[1:w:2,0:h:2] = src.pixels[:]
    dst.pixels[:,1:h:2] = dst.pixels[:,0:h:2]


the other feature i want before i "submit" is the
ability to create a 3D array of the surface, with width and height
being 2 of them, and each color plane (and alpha) being the 3rd
dimension. essentially this wouldn't be too different than now
but it will handle the "map_rgb" type stuff much more efficiently
in the "C" loops. the transfer would also be "free" (as in no
speed hit) on 24 and 32 bit surfaces

anyways, i know it comes off a little 'intimidating' at
first glance, but with numpy you can do amazingly complex
operations with needing loops in python. (thus, all the speed)
i'm looking for last suggestions/ideas as i wrap this thing up

i'm also planning on writing a couple examples (like cleaning
up the flame) as well as a small tutorial. let me know if
there's any ideas you'd like to see !   :]


..argh Diablo2 is leeching all my time, heh

Re: [Pysdl-devel] pflame test

[Peter N. <pn...@ya...>]

--- Pete Shinners <pe...@sh...> wrote:
> ok, i've finished my first decent version of python
> flame!
> 
> i've left enough comments in the actual source, but
> to help
> discussion... the program runs at about 15fps on my
> celeron
> 400 with a TNT2. currently, about 60% of the running
> time
> involves transferring the image the numeric python
> array
> to the sdl surface.
> 

it runs around 29-30 on a PIII 700 in Win98.  I
haven't tried it on the dual-CPU NT machines yet, but
it would be interesting to see because I've noticed
some things run unusually fast on them, like pyaliens.
 Does Python/SDL benefit from SMP somehow without
special thread programming? 

Incidentally has anyone tried compiling pySDL on a Mac
or BeOS?  There is a guy at school with CodeWarrior
who I could probably get to try it but I have no idea
what this would really entail.


> this transfer has to be done with an expensive
> python
> loop, but it will be simple to create a C extension
> to
> do it, at which point my little pflame should get
> above
> 24fps

I'll be interested in playing with that when I
actually take the trouble to figure it out...  I've
been wondering about using numpy for simple
transparency-aware collision detection.  I guess this
could still work without a fast transfer, though. But
I tried drawing simple gradients in a Python loop...I
can make a beautiful Wise Installer/Power Point cheesy
blue blend in about... 20-30 seconds.


> 
> the other thing i want to do is pixel-doubling.
> first
> i'll see if using SDL's scaled BLT is fast enough,
> i'll
> also compare that to doubling the image in numerical
> python.
> 


SDL has scaled blitting?

By the way I was looking at the alienlib thing from a
while back -- the generic entity-classes -- I've been
toying with a few different simple object classes and
am a little confused as to the best way to divide up
responsibilities (for performing movement, storing
data etc.) among the various base and derived classes.
 Any good info on the subject?  --P

__________________________________________________
Do You Yahoo!?
Get Yahoo! Mail - Free email you can access from anywhere!
http://mail.yahoo.com/

[Pysdl-devel] pflame test

[Pete S. <pe...@sh...>]

ok, i've finished my first decent version of python flame!

i've left enough comments in the actual source, but to help
discussion... the program runs at about 15fps on my celeron
400 with a TNT2. currently, about 60% of the running time
involves transferring the image the numeric python array
to the sdl surface.

this transfer has to be done with an expensive python
loop, but it will be simple to create a C extension to
do it, at which point my little pflame should get above
24fps

the other thing i want to do is pixel-doubling. first
i'll see if using SDL's scaled BLT is fast enough, i'll
also compare that to doubling the image in numerical
python.

anyways, here's the code. you'll need both .PY files in
the same location. this is running with pysdl 0.0.5, so
no need to worry if your not up to the latest release.

i'm curious to see how (un)quickly this runs on different
equipment and os's. if anyone can prune some more speed
onto this thing, let me know!

Re: [Pysdl-devel] alienslib

[Peter N. <pn...@ya...>]

--- "David Clark <David Clark" <si...@te...>
wrote:
> 
> This sort of thing is hugely appreciated (by me,
> anyway) as I think
> the best way to learn is to read the code of real
> programmers :)
> Thanks Mark.

thanks from me too


> I don't think I'll be contributing to this project,
> though - the
> Aliens style of game doesn't appeal to me at all.
> 

I don't know -- seems like aliens.lib would be good
for a lot of things.  the Entity class especially,
it's like a sprite object where the word 'sprite' is
more loosely defined; an entity could be a multi-frame
sprite or just a sound even and still keep track of
states and update itself... it seems like an intersect
or collision function would be useful although maybe
that sort of thing doesn't belong in the base class? 
It seems like it would be nice to allow for
'behaviors' in some way like:

     def addBehavior(self, state, behavior)
         self.behaviors[state]=behavior

where 'behavior' could be made up of any of the
function members of that class instance.  Is this
possible? It seems like if it was it would require
some kind of funky namespace manipulation or parsing.
Is this a valid concept though? --P

  







__________________________________________________
Do You Yahoo!?
Yahoo! Photos -- now, 100 FREE prints!
http://photos.yahoo.com

[Pysdl-devel] alienslib

[David C. <D. C. <si...@te...>]

This sort of thing is hugely appreciated (by me, anyway) as I think
the best way to learn is to read the code of real programmers :)
Thanks Mark.

I don't think I'll be contributing to this project, though - the
Aliens style of game doesn't appeal to me at all.

As another contribution to the framerate discussion, I've benchmarked
pyAliens 1.0 running on the platforms I have available to me. My
computer is a Celeron 466 o/c to 525, a Voodoo3 card, XFree 3.3.6,
Windows 95. Frames per second:

                 Software        Hardware
XWindow  :         42.58           n/a
Windows95:        117.63          453.31

A few observations: it's obvious that pySDL is up to the task of
rendering graphics fast enough for arcade - style games on Windows,
especially in fullscreen. It's just as clear that XFree just isn't
cutting it performance-wise. Hopefully when XFree 4.0 becomes stable
and DGA kicks in, this gap can be addressed. This is a pretty solid
benchmark of real-world performance, as it includes some collision
detection and event-handling code, not just raw blit speed.

David Clark
si...@te...
Preliminary pySDL Documentation:
http://www3.telus.net/futility/futility/docs/pysdl/index.html

[Pysdl-devel] got pysdl 0.0.6 working

[Preston L. <pla...@pb...>]

Just wanted to say that Pysdl 0.0.6 fixed whatever problem I was
having being able to do "import sdl".  So I'm happy it's working now,
sadly though I don't have much time to hack on python/sdl stuff the
next two weeks... :-(  Oh well.  thanks for the libraries guys, and
the interesting ongoing traffic on the list.

yours,
Preston

[Pysdl-devel] alienslib

[Mark B. <mb...@0x...>]

I was playing around with PyAliens the other day, and I thought that there were
a few things that needed changing. Namely the requirement of the audio device,
and the requirement of using a full screen mode, but also some other stuff.

So I was perusing the code, and started to make some modifications. Then it
came to me to attempt to make the game as fast as possible, because the list
was buzzing about framerates for PyAliens. So I started to rewrite everything,
starting with the building blocks I would need to make the game.
The more I played with it, the more I thought that putting this sort of effort
into a game with only one level, and no easy way of ever really extending it,
was probably wasteful.
So I decided that it might be interesting to work on a library that would allow
for the development of an easily extensible 'aliens' type game. With the birth
of this goal, I decided a proper OO style was needed for development.
So was born alienslib.

Since I've only spent a nomimal amount of time developing it, it's extremely
tiny at this point. It's almost good for nothing, but I think you can see my
ideas clearly enough. If nothing else, I'm seeking input as to whether the API
isn't too retched, and whether or not the map file format I've proposed is good
or bad.

I've also included the work I started on experimenting with rewriting PyAliens,
since I think some of it might be useful to some of you.

If there's any interest, I'll go into the design ideas more. If there's anyone
interested in contributing, I'm sure development will go much faster. As it
stands now, I'm stretched across too many things, but I never could resist one
more project. ;-)

Re: [Pysdl-devel] Announce: pyAliens 1.1

[Peter N. <pn...@ya...>]

> The only change with this version is the inclusion
> of the frame-rate
> limiting made possible by Mark's changes in pySDL
> 0.0.6 (which
> pyaliens now requires). This should now be playable
> on Windows with
> hardware acceleration.
> 
> Could someone who has compiled pySDL 0.0.6 for win32
> test this please?
> 
It may be my imagination but the software version
seems a little smoother than before.  Since you're
running fullscreen why not use the nice new
cursor-hiding feature?  

It runs at a playable speed now with hardware
acceleration, although it is still a little faster,
probably I'm not quite getting 50fps in software (thus
I guess the point about speed-limiting vs
fps-limiting).  There is some flickering though
because of the fact that the screen is updated
immediately (update_rect does nothing on a hw surface
apparently, though it doesn't really hurt anything --
I removed them to prove this). 

Incidentally what's the best way to structure a game
that has to either run in software or hardware
depending on what's available? It seems like page
flipping would be out of the question (b/c of how you
have to erase where the sprite was 2 frames ago, etc).
 maybe a second hw surface that uses
dirty-rectangle-style blits to the visible one in
place of update_rects? --P 





__________________________________________________
Do You Yahoo!?
Yahoo! Photos -- now, 100 FREE prints!
http://photos.yahoo.com

[Pysdl-devel] Announce: pyAliens 1.1

[David C. <D. C. <si...@te...>]

Grab pyAliens 1.1 here:

http://www3.telus.net/futility/futility/warez/pyaliens-1.0.tar.gz

The only change with this version is the inclusion of the frame-rate
limiting made possible by Mark's changes in pySDL 0.0.6 (which
pyaliens now requires). This should now be playable on Windows with
hardware acceleration.

Could someone who has compiled pySDL 0.0.6 for win32 test this please?

David Clark
si...@te...
Preliminary pySDL Documentation:
http://www3.telus.net/futility/futility/docs/pysdl/index.html

[Pysdl-devel] RFC: pySDL Test Suite

[David C. <D. C. <si...@te...>]

Now that pyAliens is mostly finished, I'm projectless. I've been
thinking about what to do next, and I've come up with the following
two possibilities:

1) Enhance the documentation. It would be nice if each function in the
pysdl documentation had a paragraph or two of commentary, to add
context. Things like a general discussion of clipping techniques for
set_clip(), or "is this function relatively expensive in terms
of time?" for set_at(), etc. IE make the documentation an educational
rather than reference resource.

2) A comprehensive test suite for pysdl. With so many dependencies on
outside code (SDL, SDL_image, SDL_mixer, SDL_ttf, smpeg), ensuring
that pysdl continues to function properly when someone upgrades one of
these external libraries could be pretty difficult. For example, Mark
is currently using SDL_image 1.0.4, while the latest version is
1.0.6. I'm running SDL 1.1.2, while the latest version is 1.1.3. Will
the new versions work the same way as the old, or will upgrading break
something?

I had in mind a script that would run through each pysdl function,
testing it for speed and reliability. This would be an interactive
script, explaining the function about to be run, then asking whether
or not it was successful. At the end, a report would be printed which
could be regression tested to monitor the overall performance of
pysdl. This might also be useful for cross-platform development, since
it would reveal any other time.time() - style weaknesses in the
underlying code.

What do you think, sirs? Which of these projects would be more useful
to us? Or do you have another idea you'd like me to spend my time on?

David Clark
si...@te...
Preliminary pySDL Documentation:
http://www3.telus.net/futility/futility/docs/pysdl/index.html

Re: [Pysdl-devel] Timing issues...

[Mark B. <mb...@0x...>]

On Fri, 09 Jun 2000, Michal Wallace wrote:
> On Fri, 9 Jun 2000, Mark Baker wrote:
>  
> > It's definitely better than placing the cross-platform nonsense onto
> > the user of PySDL. It's not so much a big technical deal, so much as
> > a philisophical one.  I believe that we shouldn't *need* to have
> > multiple functions, but if SDL will offer us platform consistancy
> > where Python won't, then we'll just have to go that way ;-) It's
> > only two functions, so it's not exactly the end of the world.
> 
> 
> Maybe pySDL ought to be submitted to the python distribution?
> Then time could just wrap the SDL functions.. ?

SDL_GetTicks(), while having more or less the same use for a game as
time.time() would, doesn't actually do the same thing. This would make it an
inappropriate replacement, as-is. Of course using similar techniques to achieve
relatively similar multiplatform accuracy in the time module, as SDL uses,
might not be entirely out of the question.

Re: [Pysdl-devel] Timing issues...

[Michal W. <sa...@ma...>]

On Fri, 9 Jun 2000, Mark Baker wrote:
 
> It's definitely better than placing the cross-platform nonsense onto
> the user of PySDL. It's not so much a big technical deal, so much as
> a philisophical one.  I believe that we shouldn't *need* to have
> multiple functions, but if SDL will offer us platform consistancy
> where Python won't, then we'll just have to go that way ;-) It's
> only two functions, so it's not exactly the end of the world.


Maybe pySDL ought to be submitted to the python distribution?
Then time could just wrap the SDL functions.. ?

Cheers,

- Michal
------------------------------------------------------------------------
Zike Interactive    http://www.zike.net/    http://zike.sourceforge.net/
------------------------------------------------------------------------

[Pysdl-devel] PySDL 0.0.6

[Mark B. <mb...@0x...>]

I released 0.0.6 a little while ago. Before I bother making the Win32 binaries,
perhaps a few people can give it a once over.

Re: [Pysdl-devel] Timing issues...

[Mark B. <mb...@0x...>]

On Fri, 09 Jun 2000, "David Clark wrote:
> Is including the timer subsystem ugly from a technical standpoint? Is
> it worth doing to avoid the above hack?

It's definitely better than placing the cross-platform nonsense onto the user
of PySDL. It's not so much a big technical deal, so much as a philisophical one.
I believe that we shouldn't *need* to have multiple functions, but if SDL will
offer us platform consistancy where Python won't, then we'll just have to go
that way ;-)
It's only two functions, so it's not exactly the end of the world.

[Pysdl-devel] Timing issues...

[David C. <D. C. <si...@te...>]

Mark Baker writes:
<snip>
 > 
 > I will add the SDL_GetTicks and (reluctantly) the SDL_Delay wrappers that
 > Daniel Heck provided. This should put this topic to the grave once and for all.
 > 

Back from the dead! Actually, Mark, if you really feel that pySDL
would be contaminated by this stuff, a workaround is fairly simple.

We do something like:

1. check if os.name == 'mac', if not, use time.time(). if so:
2. find out how many clock() ticks are in a second.
3. Divide this number by the framerate we want.
4. Use clock() as our timer, adding a heartbeat every time we reach
the number of clock() ticks we got in step 3.

This solution relies on the theory that the number of clock() ticks
per second doesn't change during program operation: ie that it is
unaffected by cpu load or process priority. It's also ugly, since it
implies an #IFDEF in supposedly cross-platform code.

Is including the timer subsystem ugly from a technical standpoint? Is
it worth doing to avoid the above hack?

David Clark
si...@te...
Preliminary pySDL Documentation:
http://www3.telus.net/futility/futility/docs/pysdl/index.html

[Pysdl-devel] Timing issues...

[Mark B. <mb...@0x...>]

It was my original hope to keep from reimplementing services that were already
available to Python programmers, even if there was a way already within the SDL
framework. The reasoning was really that PySDL is meant to be for Python
programmers, and a Python programmer should be occustomed to programming with
various modules already. If these modules already provide functionality, then
it's superfluous to then add another method. This is the heart of object
oriented programming; reuse. The thread and timing subsystems'
functions fell into this, and that is why I refrained from wrapping these
sections. I must admit that I was under the naive assumption that the various
time routines would have a relatively consistent amount of accuracy across
platforms, since you can hardly consider your code cross platform if it behaves
differently in different environments. This sort of thing is why Java's
threading mechanism is irritating, and apparently, Python's time module.
Of course had I bothered to read the documentation, I would've known that it
warns against this. Mistakes, though, can be corrected. ;-)

I will add the SDL_GetTicks and (reluctantly) the SDL_Delay wrappers that
Daniel Heck provided. This should put this topic to the grave once and for all.

Re: [Pysdl-devel] time() vs. clock()

[Peter N. <pn...@ya...>]

Here's a post I found in the mail archives -- the last
part by Guido Van Rossum is relevant to this:


> Test Case:
> import time
> for i in range(100000): time.sleep(1) ; print
time.clock()
> 
> Expected Behaviour:
> clock() should increment by 1 after each call to
sleep()
> 
> Actual Behaviour:
> clock() does not seem to increment at all!

This is either a bug, or a documentation error.  The
library manual does
> not seem to say or imply that time.sleep() should
interfere with time.clock().

It's not a bug.  On Unix, clock() counts "CPU time",
and a sleep
doesn't increment the CPU time (the CPU is given to
another process).
On Windows, clock() *does* count real time -- there's
no sufficiently
accurate CPU time available on that platform.

The documentation
(http://www.python.org/doc/current/lib/module-time.html)
does mention CPU-time -- so I'm not sure what you want
changed?

--Guido van Rossum (home page: http://www.python.org/~guido/)

__________________________________________________
Do You Yahoo!?
Yahoo! Photos -- now, 100 FREE prints!
http://photos.yahoo.com

Re: [Pysdl-devel] time() vs. clock()

[Peter N. <pn...@ya...>]

> Thinking some more about this, I've realized that
> time.clock() isn't
> going to be helpful equalizing timing across
> machines, since it is
> itself dependent on machine speed. clock() ticks
> every time the CPU
> cycles, which means faster CPUs will have faster
> clock()s, which means
> we're back where we started. 

Hmm.. how does it convert it into seconds then, or is
it just a bogus approximation?  

I'm still interested in
> seeing the
> results from testing time() on the Mac though, in
> case the "1-second
> precision" isn't actually as bad as it sounds.
>
 
Well... ironically it seems to have rock-solid
1.0-second precision every time:

(G3 @450mHz):
avg smallest difference between two calls to time():  
1.0  seconds.
avg smallest difference between two calls to clock(): 
 0.0166666666667  seconds.

(PPC 601 @110mHz:)
avg smallest difference between two calls to time():  
1.0  seconds.
avg smallest difference between two calls to clock(): 
 0.0166666666667  seconds.

So it looks like the Mac version of Python has a
different idea of what the time() and clock()
functions should do: time() measures seconds, and
clock() measures 'ticks' (i.e. 1/60 second like in
Director).  I suppose it's hard to know the exact
accuracy there but they did seem to take the same
amount of time to run.  Maybe this is actually good
news for the Mac in terms of keeping consistent frame
rates or whatever, but it's too bad that there's
apparently no consistency between platforms.  Would
this be something to bring up with python.org?


> I've taken a look at the Vaults and throught Deja,
> and haven't found a
> more precise timer module for the Mac. In the worst
> case scenario,
> Mark would have to implement the timer subsystem in
> order to get
> reasonable cross-platform timing support.
> 

This of course would be great but people seem to say
it would be a pain to do and it doesn't seem high up
on his list.  --P  
 




__________________________________________________
Do You Yahoo!?
Yahoo! Photos -- now, 100 FREE prints!
http://photos.yahoo.com

Re: [Pysdl-devel] time() vs. clock()

[Peter N. <pn...@ya...>]

> The issue, of course, is whether or not it works on
> the Mac. 

BTW does PySDL work on the Mac?  If not, what would
need to be done to get it going?

__________________________________________________
Do You Yahoo!?
Yahoo! Photos -- now, 100 FREE prints!
http://photos.yahoo.com