well you could save the buildup to the instruction file of a kind, where you would save how to reconstruct the screen later, and then just do it. Also, do not use pickle, its insecure.
2011/7/14 greenmoss <[email protected]>: > On Jul 14, 11:53 am, Tristam MacDonald <[email protected]> wrote: >> On Thu, Jul 14, 2011 at 10:43 AM, greenmoss <[email protected]> wrote: >> > Are there any plans to make pyglet objects amenable to >> > pickling? >> >> I am not sure I see a strong case for needing to pickle sprite objects. The >> OpenGL data/state that would need to be reconstructed on unpickling is >> significant enough to be troublesome (i.e. can't unpickle without a valid >> OpenGL context). >> >> I would generally recommend that you separate game data from graphics data, >> and design your engine such that you can reload the graphics data based on >> the game data. > > Let me preface my response by saying that I'm inexperienced, so I > could well be taking a suboptimal approach. That being the case, the > most logical way to handle game and graphics data for an in-game > object would IMHO be to attach it to a single python object. This in > turn leads to manual getstate/setstate overrides, extra code, etc. > > Is there some other way that people handle this type of situation? > > -- > 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. > > -- 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.
