Re: [Pysdl-devel] Further development...

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

On Tue, 25 Jul 2000, David Clark wrote:
> As far as my needs go, I consider pySDL largely feature-complete right
> now. I have a couple of very minor requests as stated below, but I
> would support version 0.0.8 or 0.0.9 becoming 1.0, and future releases
> simply being bugfixes or changes required to keep up with new features
> in the C SDL libraries.

Yes, this seems likely.
 
> As far as future expansion goes, I think it's important to divide the
> issue up into two groups:
> 
> 1) Refining and improving current features: This I support. I'd still
> like to be able to manipulate video surfaces as simple 3-d arrays (as
> in fb[x][y][color], although fb[y][x][color] would be ok too) and I'd
> like a fb.get_type() function, that returns either HWSURFACE or
> SWSURFACE (although mustlock() does pretty much the same thing).

I'm not too sure I understand the color portion of that, but let me address the
other part.

In order to modify the surface we would instead need two new objects per
surface. The first would need to carry a reference to the second, and
implement the sequence methods to acquire the second, and store the index into
it first and second, plus if it's an assignment the new value. The second would
carry a reference to the surface and use the stored index values to compute the
location in the surface.

Each surface would probably want to always keep these objects around, in order
to not need to reallocate them for every access.

The first object would probably want to be expanded from my previous statement,
to include its own reference to the surface object. This would allow it quicker
access for masquerading as a list. This, of course, is optional.

We could switch to x,y based coordinates. I've forgotten my rationalization for
the y, x scheme at this point.

> 2) New, non-SDL features: These are features that the C version of SDL
> doesn't support, such as saving surfaces as files, or drawing
> primitives, such as rectangles, lines and sprite objects. I would
> prefer not to see these features in pySDL. Suppose we implement
> fb.save_png(), and Sam or Mattias release a new version of SDL_image
> with a png save function in it? Which do we choose?

I wouldn't implement saving in PySDL. I don't even much care if SDL_image grows
or not, since I can just provide adaptors for other popular image libraries.
These adapters would simply convert surfaces into whatever format the other
libraries expect, and then the user would be on their own.
Alternatively I could go through the mind numbing process of adding yet another
implementation of file savers for every format known to man to SDL_image.
This just isn't likely, unless I find a brief moment of inspiration for working
on something that should have been standardized a number of years ago.

Something I might consider is after the next major release of glib/gdk/gtk is
writing a SDL backend for gdk. While this provides little in the form of