On, Sun Feb 14, 2010, Bo Jangeborg wrote:
> Marcus von Appen skrev 2010-02-12 23:49:
> > On, Wed Feb 10, 2010, Bo Jangeborg wrote:
> >
> >
> >> I have a need for memory compression so I figured that rwops might be
> >> used to preload pictures and sounds without unpacking them. Am I
> >> barking up the wrong tree ? If not are there any documentation on how
> >> to use it ?
> >>
> > You can use the RWops C API or stream wrapper C API to implement a
> > preloading system. Both offer no pythonic interfaces though, so you
> > have to implement your own C extension module. The APIs themselves are
> > documented (type 'make doc' to build the html documentation under
> > doc/html), but do not provide any indepth examples.
> >
> >
> Is that SDL source or pygame2 ?
SDL source, if you want to use the RWops directly, otherwise, pygame2 :-).
> > Doing a quick search through the sources, you can find different
> > examples for how to use them (CPyStreamWrapper is used within
> > pygame2.freetype, the SDL RWops can be found in the rwops.c code and in
> > various parts of pygame2.sdl).
> >
> > Do not hesitate to ask, if you're stuck with anything :-).
> >
> > Regards
> > Marcus
> >
> Ah , I suppose I have to get started with C. Was hoping to avoid that.
> Any recommendations for a compiler to get started with ? I am targeting
> Windows, Apple and Linux.
GCC (Msys on Win32) - it is well supported by the pygame2 build system
on all three platforms, lowers the ground work to do (especially since
the Windows prebuilt packages are built using GCC).
You can avoid C and implement an own stream-like python object class,
which does the job for you. This will need more implementation work on
the python side, though and will cause more thread locks in the
interpreter instance, if you have a threaded python. As both, the stream
wrapper and RWops API are using thread locks, your stream classes have
- to be thread safe
- not to be accessed from another parallel thread while the pygame2
APIs operate on them
- to avoid thread locks on their own (otherwise a dead lock will occur).
The stream wrapper and RWops APIs look for the following methods on a
passed object:
- object.read (long_byte_count)
- object.write (byte_buf)
- object.seek (long_offset, SEEK_SET|SEEK_END|SEEK_CUR)
- object.tell ()
- object.close ()
For read-only access, you just need to implement read(), seek(), tell()
and close().
Both APIs do not reset the stream offsets upon performing any of those
operations. If you are using the pygame2 methods to e.g. load a SDL
video surface using pygame2.sdlimage, etc., pass the stream adjusted
stream object to it:
# Simple example
# Skip header bytes of the stream and get straight to the first
# image offset, relative to the start (SEEK_SET)
compressedstream.seek (100, 0)
# We are passing a stream, so we have to give sdlimage a hint about
# what type of image to load
surface = pygame2.sdlimage.load (compressedstream, "BMP")
# The stream is now advanced to the end of the BMP stream data. We
# use compression and have a 4 byte gap to the next image start
# (SEEK_CUR).
compressedstream.seek (4, 1)
surface2 = pygame2.sdlimage.load (compressedstream, "BMP")
...
There might be some glitches with the wrapper APIs not foreseen, so if
something goes wrong (although your code is absolutely correct), it
might be a bug within the pygame2 APIs. In that case, post an example
snippet to recreate the behaviour along with the data that fails for
you.
Regards
Marcus
Attachment:
pgp77XCFv739N.pgp
Description: PGP signature