But the big commit on Wednesday (2348adf1), though it included some nice
things, seems to have broken things a bit for me. The game now runs really
slowly. The game rate seems to be scaling with fps, which it seemed not to be
before. I get about 12-15fps when not much is going on, which translates to a
painfully slow gamerate. If I turn off the background (thanks for that
option!) I get 30 fps and a decent gamerate.
This was a rather silly mistake on my part. I've fixed it; I'll update the repository tonight.
When any of the 'skip' options are in effect, the game runs faster as you'd
expect, but scrolling the map is paradoxically much slower then normal.
Yes, the scrolling is framerate dependent when it shouldn't be. This should be fairly easy to fix.
I wonder if it would make sense to make the build queue a bit cleverer.
Currently it waits for the builder of the job at the front of the queue to
finish recycling, even if it would be possible to start a job further down in
the queue immediately. It took me a while even to realise that recycling was
per-builder rather than global, and realising it made my operations much more
efficient - but more fiddly.
This is tricky - data is expended when a process is built, so allowing a build job to jump the queue could use up all the data the job at the front of the queue will need when its builder has finished recycling. Since one of the purposes of the queue is to help autonomous processes coordinate their build orders (before the queue was implemented they had to do this by broadcasting messages to each other), and another purpose is to let the player determine the order things are built in, I don't think this would work.
(In case you haven't noticed, the player can reposition the jobs on the queue by dragging them with the mouse - this is mentioned in the tutorial now, although it wasn't in earlier versions.)