pysdl-devel

[Pysdl-devel] pal_get_at() vs. get_rgb()

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

Are these two methods identical? Both take a color number / palette
index and return an RGB tuple. Am I missing something here - are color
number and palette index concepts interchangable?

Thanks for the info on get_pitch(). Your explanation is clearer than
the one in the SDL faq :)


-- 
------------------------------------------------------------------------
Nothing seems to kill me no matter how hard I try
Nothing is closing my eyes
Nothing can beat me down for your pain or delight
And nothing seems to break me

                            - Soundgarden

Re: [Pysdl-devel] video subsystem docs

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

On Wed, 12 Apr 2000, "David Clark wrote:
> I have the video subsystem documentation in what I consider a nearly
> finished state. Comments appreciated.
> 
> http://www3.telus.net/futility/futility/docs/pysdl/video.html


Great work. I removed surface_from(), though, because it seemed obsolete.

get_palette() now returns a list of rgb tuples, instead of a tuple of tuples.
There's also a new set_palette() method that takes a list of rgb tuples, as
well as pal_set_at(index, (r, g, b)) pal_get_at(index) -> (r, g, b) methods.

There should be no more compatability problems with the video subsystem.

get_pitch() has less than novelty value at this point, since all of the surface
manipulation routines work at the color and pixel level, as opposed to the
chunk of memory level. In a C application, where the programmer would be
accessing the surface memory directly, the pitch value is used to determine the
length, in bytes, of the difference between each line of video memory (if it's
in hardware). This is because not all video cards treat a video surface, in
memory, as a linearly accessible chunk of memory. So in order to determine the
offset at which to start writing the linear X component, you would do something
like y * pitch + x. As you can see from the routines I wrote, it's just
slightly more complicated than that, but you get the idea.

In PySDL, since this calculation of the location in memory is done for you, you
often times wouldn't need to even know the pitch. I just added it for
completeness, and perhaps someone might want to output the pitch of the video
display, for some perverse and obscure reason.

the blit() method does clipping (really SDL does) before the low level blit is
performed. So if the rectangle is bigger than the destination, it shouldn't
matter. If the source is smaller, the same is true.

[Pysdl-devel] video subsystem docs

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

I have the video subsystem documentation in what I consider a nearly
finished state. Comments appreciated.

http://www3.telus.net/futility/futility/docs/pysdl/video.html

-- 
-------------------------------------------------------------------------\
David "Futility [D!]" Clark  |    "Quotation confesses inferiority."     |
si...@te...            |                 - Ralph Waldo Emerson     |

[Pysdl-devel] PySDL 0.0.3 released

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

I just released PySDL 0.0.3
Here is the relevant section of the ChangeLog:

0.0.3:
   Changed the sequence functionality for the Surface object. It's much more
   usable now. Thanks go to Ben Smith for inspiration in this direction.
   Removed the load_bmp function, and added support for SDL_image.
   Images can be loaded from either a file, or a Python file object.
   The surface method save_bmp works on either a file or a Python file object.
   Some of the less sensical return codes for functions have been modified, in
   an attempt to make the module less annoying.
   The __doc__ strings have been made more consistent, and informative.
   Added some examples of using the module, but nothing too impressive.
   The palette can now be manipulated with the set_palette(), pal_get_at(), and
   pal_set_at() Surface methods. 

The next release'll add audio support, and probably SDL_mixer support.
I'm also contemplating adding SDL_ttf to the list of future dependancies.

[Pysdl-devel] get_at()

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

Noticed something about get_at() - it returns a color, as stated in
your post, but the __doc__ string states it returns a pixel struct.

Otherwise, the interface is looking really good. Will there be
separate subsystem modules, or just the sdl namespace?

(BTW, great work! Keep it coming!)

Preliminary pySDL docs:
http://www3.telus.net/futility/futility/docs/pysdl/index.html

-- 
-------------------------------------------------------------------------\
David "Futility [D!]" Clark  |    "Quotation confesses inferiority."     |
si...@te...            |                 - Ralph Waldo Emerson     |

Re: [Pysdl-devel] Introduction and patch

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

On Thu, 06 Apr 2000, Mark Baker wrote:
> surface[y] returns a list of integers for the color of each x component 
> surface[y1:y2] return a list of lists of integers from y1 to y2 (non-inclusive)

Actually, before I confuse anyone, let me just say it works like a normal slice
in that it includes y1 but stops at y2 ;-)

Here's a diff against the release pysdl-0.0.2 there are also some changes in
regards to the return value of video_list_modes

Re: [Pysdl-devel] Introduction and patch

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

On Wed, 05 Apr 2000, Ben Smith wrote:
> My name is Ben Smith, I was attempting to write a SDL module for python as
> well.  It was an uphill battle for me, I'm new to python, and I've still
> got a lot to learn about c, and trying to use the ExtensionClass for it.
> I found this module today and it rules!  I added a small patch that allows
> you to manipulate the pixel buffer of an SDL surface in a 2d python array.  

There's a bit of a problem with your patch, and how it manipulates the
surface's memory. Not all is lost, though, since I thought the idea was a
fairly good one, and replaced the current sequence based system with something
similar to what you've proposed. I'd been blindly and temporaraly treating the
sequence of a surface as a linear chunk of memory. This needed to be changed
sometime, and now is better than later, since the user base is smaller.

Still it would be bad of me to change the interface many many times, so I'm
going to go over the code and do whatever interface changes I plan on doing,
now. I intend to move some of the -1 error code functions and methods, to using
exceptions. Of course this won't be practiced everywhere, since the idea of SDL
is to get fairly good performance, even though we're using Python.

An example how the new sequence interface works:

import sdl
sdl.init(sdl.INIT_VIDEO)
s = sdl.video_set_mode(100, 100, 16, sdl.SWSURFACE)
s[0] = range(0, 100)
s[1] = range(200, 300)
s[2] = range(400, 500)
x = s[0:3]
s[3:6] = x
s.update_rect((0, 0, 0, 0))

surface[y] returns a list of integers for the color of each x component 
surface[y1:y2] return a list of lists of integers from y1 to y2 (non-inclusive)

You can also assign to these
surface[y] = [1, 3, 5]
surface[y] = range(0, 100)
...

If the list you're assigning to the element of the surface is smaller than the
width of the surface, then it just stops at the end of the list. It will always
start at element zero of the surface.

surface[y1:y2] = [[1, 2], [3, 4, 5, 6, 7]]
surface[y1:y2] = [range(0, 100)] * 100

It behaves just like a single element assignment, in that if the list of lists
is shorter than the slice, then it'll just stop at the end of the list of lists.
Also each list can be shorter than the width of the surface, with the same
behavior as if it were being assigned individually.

I've also added get_at() and set_at() methods
get_at(x, y) -> color
set_at(x, y, pixel) -> None

so surface.set_at(0, 0, surface.map_rgb(255, 255, 0))
would be ok

I'd like to hear any interface suggestions, if anyone has any.

Re: [Pysdl-devel] Some docs posted

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

Martijn Faassen writes:
 > David Clark <David Clark wrote:
 > > I've placed what documentation I have done so far online - I have the
 > > Cdrom subsystem pretty much done, and the video subsystem about half
 > > done. I'd really appreciate feedback - I'm kind of new to this sort of
 > > thing, and I'm especially unfamiliar with framebuffer operations, so
 > > I'm sure there's things I've missed.
 > 
 > I'd like to give you feedback, but I haven't been able to figure out
 > *where* you placed the docs. Where do I look?
 > 
 > Regards,
 > 
 > Martijn
 > 

LOL.

That information _would_ help, wouldn't it? :)

http://www3.telus.net/futility/futility/docs/pysdl/index.html

Re: [Pysdl-devel] Some docs posted

[Martijn F. <fa...@ve...>]

David Clark <David Clark wrote:
> I've placed what documentation I have done so far online - I have the
> Cdrom subsystem pretty much done, and the video subsystem about half
> done. I'd really appreciate feedback - I'm kind of new to this sort of
> thing, and I'm especially unfamiliar with framebuffer operations, so
> I'm sure there's things I've missed.

I'd like to give you feedback, but I haven't been able to figure out
*where* you placed the docs. Where do I look?

Regards,

Martijn

[Pysdl-devel] Some docs posted

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

I've placed what documentation I have done so far online - I have the
Cdrom subsystem pretty much done, and the video subsystem about half
done. I'd really appreciate feedback - I'm kind of new to this sort of
thing, and I'm especially unfamiliar with framebuffer operations, so
I'm sure there's things I've missed.

I expect to be updating the docs on a daily basis until I have them
done, so continue checking back - I won't be announcing every little
change here :)

-- 
/----------------------------------------------------------------\
| David "GrinderD" Clark  |  An optimist is someone who believes |
| si...@te...       |     that the future is uncertain.    |
\----------------------------------------------------------------/

[Pysdl-devel] Introduction and patch

[Ben S. <be...@ni...>]

Hello, 

My name is Ben Smith, I was attempting to write a SDL module for python as
well.  It was an uphill battle for me, I'm new to python, and I've still
got a lot to learn about c, and trying to use the ExtensionClass for it.
I found this module today and it rules!  I added a small patch that allows
you to manipulate the pixel buffer of an SDL surface in a 2d python array.  

here's a quick example:

import sdl
from whrandom import randint
sdl.init(16)
surface = sdl.video_set_mode(320,200,8,0)
pixels = surface.get_pixels()


print "generating random colors... this takes a while"
for x in range (len(pixels)):
  for y in range (len(pixels[x])):
    pixels[x][y] = surface.map_rgb((randint(0,254), randint(0,254), 
      randint(0,254)))

surface.set_pixels(pixels)
surface.update_rect((0,0,0,0))

import time
time.sleep(20)

It's not the fastest thing ever, but you get access to the pixel buffer
pseudo-directly in python.  

The list of lists containing the pixel colors(pixels) is not destroyed in
the call to set_pixels, because I thought it may be useful to keep around.
I also didn't attach it to the surface object itself, because I thought it
would move even more slowly if there were large arrays for every surface.
It's also significantly faster without so many calls to randint and
surface.map_rgb.  


=-=-=-=-=-=-=-=
Linux - This will end your Windows session.
be...@ni...

Re: [Pysdl-devel] Greetings.

[Martijn F. <fa...@ve...>]

Mark Baker wrote:
> Sorry for the somewhat superfluous message, but I just created this list, and
> I am curious if everything is functioning properly.

It works! :)

> That said, are there any pressing issues with the current release of the
> module?

Not yet. I haven't bashed it a lot yet; just the graphics part too,
so I can't say much about it yet. I'm building a higher level interface
to SDL now (in C, partially prototyped in Python), which I hopefully
can eventually contribute to PySDL. Currently my 'high level interface'
can only draw horizontal and vertical lines, though. ;)

The basic interface from Python I'm thinking about is something like this:

* In Python, have a 'Canvas' class. Using methods like hline, vline, line,
rectangle and a host of others we can come up with, you send 'commands'
to a canvas object, which are _not_ immediately executed. Instead they're
stored in a simple stack (commands and parameters..perhaps two stacks).
The commands are location insensitive; you can only use relative coordinates.

* When we're ready preparing the Canvas, we prepare the command stack
and possibly even optimize it. For instance, if we're drawing a line
two times in the same place, we might optimize one out, etc. This could
of course get very tricky, but at least we can do the analysis in Python.
Another option would be scaling up and down the entire picture.

* Then we send the list of commands out to C, and tell it where on an
SDL_Surface we want to draw all the stuff. Since the coordinates were
all relative, our picture is relocatable. C code then does things like
locking the surface if necessary, calling all the functions (highly
optimized for the particular colordepth), and updating the right area on
the surface. Poof! We can of course do this same drawing operation
multiple times.

* If we really want to speed of drawing, we can make a blittable sprite
out of our little Canvas once, and blit that to the screen direct, instead
of doing the same drawing again.
 
Of course I didn't profile before I optimized, so I don't really know
if the performance gain from this approach (when used from Python) will
be worth it. It should avoid most of Python's function call overhead, and
also repeated locking and unlocking surfaces in SDL. And repeated querying
of colordepth info, as I have a separate set of C functions for each
colordepth (which will all be untested but for 16 bit color as that's what
I'm running on, but okay :). But at least it'll be fun puzzling it out. :)

Regards,

Martijn
 

[Pysdl-devel] Greetings.

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

Sorry for the somewhat superfluous message, but I just created this list, and
I am curious if everything is functioning properly.

That said, are there any pressing issues with the current release of the module?