Rendering woes
Yeesh.
Since I’m running the client itself in a single process, anything that has to go from one to the other has to be serializable, since it’s being run through pipes… well, that means I can’t really use some of the pygame types in my basic game objects.
So I’ve started a rendering ‘engine’ that’s pretty much just a set of wrapper classes; each one takes a certain game object (maps and panels right now, I think they’re generic enough that it won’t grow much beyond that), updates its internals with sprites as necessary, and provides update/draw methods (they’re extending pygame.sprite.Group for this purpose).
The problem is that these rendering objects aren’t persistent… they’re regenerated every frame. This might cause performance issues, but the thing I’m more concerned with is animation… I might have to track the position of an actor within the actor model itself rather than within a rendering object, which I didn’t particularly want to do, but if that’s what I can depend on being persistent, I might just have to settle for that little breach of my arbitrary protocol.
I’m not too sure I like the way this whole client method is going anyway… I guess we’ll see. Damn you, Unladen Swallow, hurry up and kill the GIL so I can just use threads!
Oops.
Well, turns out instead of simulating a queue with a manged list… I should have just been using a managed queue. Brilliant, huh? Yeah.
Going to apply this when I get home and hopefully I’ll end up with an execution queue that can accept and process arguments pretty much the way I’ve been attempting to for… oh, weeks now.
Frustrating. But hopefully it works and then I can move on to something new.
Multiproc woes
Well, I think I’ve figured out the infuriating problems I’ve been butting my head against with multiprocessing.
Turns out I can send and update objects and get them back with the changes intact, and I can send and update lists with the same kind of success… but I can’t send and update a list of objects, update the objects, and expect to get them back with their state updated.
So it looks like my ideal scenario of having a simple execution stack containing (among other things) a map object that tracks its tiles as a list is not going to work. I do think I can still use the stack for menus; if I’m recalling correctly (it was late last night), I can modify an object and update it by copying, modifying and replacing it in its list (which is stupid, inefficient and maddening, but works).
I’d like to see if processing or parallelpython can handle this scenario… but I’ve already burned so much time figuring it out in multiprocessing that I’m not too thrilled with the idea of trying to abandon it.
Either way… I did manage to get the input process passing commands to the top element of the execution stack, it just didn’t work as expected because of multiprocessing’s apparently-undocumented restriction on how many nested levels of data (about… one) you can depend on sharing between processes.
Multiprocess command input
Well, this multiprocessing crap ROCKS, but man does it make things… interesting.
After wrestling with a serialization issue, I realized I can’t keep a lock as an instance variable on an object I need to pass between processes; I should have figure that out sooner, but I had written it to work with threading, which doesn’t have this particular quirk.
Now I’m working on getting a sensible method of passing events out of the input thread and determining where best to process them; I knew it’d be a little hairy, but it looks like I either made some questionable decisions early on about where to implement things or just did so with the (now forgotten) intention of moving them later on, because I’m left wondering whether actor movement should really be handled by actors themselves or by the maps they are associated with, and how much graphical information the actor should keep about itself — it needs to track its own sprite sheet, but as far as rendering, I think I need to introduce a generic processor in the GUI thread to handle this.
So at this point I’m largely working on juggling code to put things in places that make sense, with the objective of successfully passing commands from the input thread to the GUI thread in a way that correctly and efficiently invokes the required functionality, and (when necessary) passes it back to the server as well.