Uh. I'm not talking about serialisation. I used the word 'pickle' since that's what it all started with, but at one point, the talk diverged to a way to save the current windows and objects and restore them. Serialising or not. You aren't 'serialising' unless you choose to in this. This is probably my fault for still saying pickle, etc.
Let me try and re-explain with different words, so that I can possibly get the point across. For every object, like a Sprite, you'd have a method like such: def save(self,file): #to the file, do the following: # save self.x # save self.y # ... # save self.image_path This is pseudo-code. You don't need to save to a file, you don't need to serialise everything. There are lots of ways to save these things, the only important thing is that the 'saved' things need to persist until load is called. For ease of example, I'll assume this somehow saves everything to a file. def load(self,file): #from the file, load the following: # load x into tmpx # load y into tmpy # ... # load path into tmppath #create a NEW sprite, with the init options we have saved, tmpx, tmpy, etc. #set any other things we've saved but can't set while we initialise, like special tex coords, blending, depends what you set. #replace the current object or return the new object. These two methods are defined for every object you want to be able to save. This includes a window. A window would do this: def save(self,file): #into file: # save enabled bits # save disabled bits # save current size # ... # save whatever else we need def load(self, file): #from file: # load everything into temporary vars #create a NEW window/context #set the enabled bits in that new window to those we used to have. #disabled bits, resize it, etc. #replace the current instance or return the new one. If you have a way of getting what screen the window's on, and you WANT it to remember what screen it was on, it's a matter of also saving/ loading that. If you don't want to, you just omit saving/loading that. The global pyglet.save() method would take a list of objects that it'll call obj.save() on, then store (in this example) which file they're in into a 'manager' file. The global pyglet.load() method would read the manager file, and one-by-one load each file and load() the object into creation. Last, it'll create the saved window/context, then go through each object, and make sure it's pointing at the new context where it needs to. If at ANY point, it gives an error, everything stops and the error is reported. Just to be clear, this is NOT a way of saving/loading your game, nor is it a good way to theoretically. This is where the discussion started, but I kind of went off on a tangent. This is meant to be a way to be able to close and restore the actual graphics themselves (generally on the same machine, but similar ones will do fine). Literally, you'd be able to close, then when you start it again, EVERYTHING would be as you left it (provided you make sure you save every thing you need and load them back properly). It's a way of 'pickling' the actual graphics objects. If you serialise the objects and store them, you could say you're actually pickling them. That in mind, if you make sure you overwrite the default save/load functions, and only use sprite/window/etc subclasses for your game logic, it would work just fine as saving/loading your game, up until the point where you try it on a machine where restoring the settings wouldn't work. (At that point, it's a matter of handling it sanely, by making sure the load() function looks where it failed and ignores loading that specific bit. This would crash horrendously on resources missing, but would work for, say, some type of antialiasing not working). Hope this clears up some things, thanks for the replies. On Jul 20, 12:30 am, Jonathan Hartley <tart...@tartley.com> wrote: > Hey. Thanks for explaining further. > > I don't think it helps to do your serialisation by hand, instead of using > pickle - the same objections hold. > > The things I infer that you are talking about serialising - sprite content > and opengl state - these are not part of your application's model state. To > save them and then restore them along with your game state is conflating two > very different things, and all the objections I stated above, together with > plenty of others, will cause no end of problems. > > Suppose the opengl state contains information about the open window, such as > it's size, or screen resolution, or the display it is on. When the user > changes this state, by moving the window to another display, they do not > want this change to be reset when they reload their game! > > Suppose the user saves game on one computer, but then reloads it on another > computer. The saved opengl state might not even be valid. > > Suppose they update the application, which includes a nice graphical > makeover which improves the appearance of the sprites. Then they load their > old save game, and this reloads the old ugly sprites again. > > I don't want to be patronising, but I think you might benefit from reading > about the model-view-controller pattern. I'm not usually a big 'patterns' > kind of person, but this one seems especially pertinent here. > > Sorry to be so negative! But those are my thoughts. Obviously I wish you > nothing but success with whatever strategy you choose to go forward with. > Cheers! -- You received this message because you are subscribed to the Google Groups "pyglet-users" group. To post to this group, send email to pyglet-users@googlegroups.com. To unsubscribe from this group, send email to pyglet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pyglet-users?hl=en.
