On Jul 15, 7:01 pm, Tristam MacDonald <[email protected]> wrote:
> On Fri, Jul 15, 2011 at 10:15 AM, greenmoss <[email protected]> wrote:
> > After reading the responses in this thread relating how to handle
> > saving pyglet game state using pickle, the general idea seems to be
> > "don't do it that way", with various implementations of how to save
> > state while avoiding pickling pyglet objects. The solution I have been
> > using, eg getstate/setstate has so far worked for me, so this is
> > probably what I will continue to use.
>
> > However, while hopefully not sounding too presumptuous, it strikes me
> > that in theory and in practice a framework such as pyglet tries to
> > make it easier for game developers by providing convenience methods
> > for common back-end chores. Gracefully handling pickle and unpickle
> > requests seems to me compatible with this goal[1]. Am I
> > misunderstanding the aims of the pyglet project?
>
> If it is indeed a common need, then yes, I think it would be desirable to
> handle it.
>
> > [1] Note that I'm making no claims or demands about implementation.
> > Instead I am opining that it is *desirable*. Rebuttals are of course
> > welcome.
>
> I am not actually clear on what the semantics of pickling OpenGL objects
> looks like. Do we:
>
> a) pickle the file name, and hope that the file is still present when we
> unpickle to reload the texture from, or
> b) readback the actual data from the graphics card, and pickle that?
>
> Also keep in mind that we need to support pickling vertex data if we support
> pickling textures.
>
> Further question: is is even legal to pickle objects that will fail to
> unpickle depending on external state (missing image files, or
> missing/incorrect OpenGL context).
>
> --
> Tristam MacDonald
> System Administrator, Suffolk University Math & CS
> Departmenthttp://swiftcoder.wordpress.com/
My suggestion would have been to write a pyglet 'pickle' method, that
actually saves the current window/context states AND the state of the
objects given to it, in a pyglet-like fashion. These objects would be
any subclass of AbstractImage, Sprite, VertexList, etc. It would,
possibly, actually PICKLE the object, but on unpickling, besides
restoring any properties they have, pyglet would recreate the windows/
contexts in their saved state (or at least try to, and fail gracefully
if it can't), then return the list of objects as it was given, with
the objects recreated, reinitialised, and linked to the new contexts/
windows.
This would, however, involve a LOT of work, and for very customised
objects, it might fail to initialise them, etc. In the case of missing
resources, a simple graceful fail would be appropriate.
Thinking about it, it doesn't seem like a lot of work for the simple
objects, and if objects would provide their own _unpyckle_ methods for
different initialisation and linking, it should work. The prototypes
would be like this:
def pyckle(self, objs):
#create anything to store the data we're about to pickle, a db,
file, whatever is best
#save any context states, flags we need, sizes, resources etc
# not save the resources themselves, but what they refer to
(filename, possibly)
for obj in objs:
#call its _pyckle_ method which will pack the stuff it needs
and return them. Then, we save that.
#it's the developer's own responsibility to make their
personal subclass pyckle and unpyckle methods work together, so that
the data from pyckle works in unpyckle.
def unpyckle(self, file):
#read everything in
#look at context data, start creating context as it was, add
flags, resize, add resources,
# any failing on this means a graceful fail
#for every object in the data, we create a base object from the
class it was of (maybe actually python pickle that class so we have an
easy copy)
# then we call unpyckle(data_of_object,new_context), which
should: set any variables in the data, anything else that needs to be
done, then link to the new_context.
It seems feasible, and useful, at the least. What other graphics
library has the ability to save to a file, then resume just as it was?
(There are probably a few, come to think of it.)
--
You received this message because you are subscribed to the Google Groups
"pyglet-users" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/pyglet-users?hl=en.
