Freaking brilliant.

No, really, that’s not sarcastic. Freaking BRILLIANT!

Thanks to the Queue class in processing (which I’m now using instead of multiprocessing… for no particular reason, other than it’s in Portage, and I have an aversion to using anything that isn’t in my package manager), my client is now happily passing user input to a queue which will contain the map and an arbitrary number of menus.

It’s terribly embarassing now that I was attempting to simulate a queue with a list and labelling it as an ‘execution stack’ (an ugly misnomer which helped me delude myself) when I really should have been doing this from the beginning.

Anyway, the locking I was using with the ‘stack’ was a bit counterintuitive for that implementation, but works ideally for this one.

Good stuff!

Comment

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.

Comment

Trials and Tribulations

You've made your way to a brief record of the odd and intriguing events which constitute the development of my pet project, The Great Two-Dimensional Online RPG.

Tags

architecture, c++, client, crafting, ec2, git, graphics, ipc, leveling, maps, menus, movement, multiprocessing, processing, pydoc, pygame, python, queue, rendering, scaling, server, skills, stack, synchronization, textpattern


RSS Feeds

Search This Site