The basic premise behind SpaceChem is chemical engineering: in each assignment, you get some input molecules and you have to turn them into the requested output molecules via bonding and unbonding their atoms, and the occasional nuclear fusion. A simple (and decidedly sub-optimal) example:

The chemistry part is just a front, though. What the game really is, is a programming simulator. You have a tiny board (10×8) board with input and output zones and two ‘waldos’ that trace a path on which you place and execute instructions: basically a tiny dual-threaded CPU with a select instruction set. I know it sounds simple, and that’s exactly right: it sounds simple. However, working out a workable design hard, VERY hard. Especially when you try to optimize a design for least time or components.

There are in-game leaderboards, showing you how much a design that you have toiled away at for hours actually sucks sweaty donkey balls, and a more detailed scoreboard at spacechem.net. You can also upload your solutions to youtube. Here’s one of mine for “Gas Works Park”, where you turn some random carbon strings (C₃ / C₄) and water (H₂O) and turn them into methane (CH₄) and carbondioxide (CO₂). Solution details can be found in the video description.

• Publisher site (with other engineering games): Zachatronics Industries
• Game site: http://www.spacechemthegame.com/
• Review: http://www.rockpapershotgun.com/2011/01/10/wot-i-think-spacechem

If you like programming and games (which probably describes readers here pretty well), you need to give this a try.

In any case, the two versions should be identical again (with one small exception, namely that my version emits a .size directive for assembly, but that’s a minor something that should not affect anyone.)

First of all, the vector::insert should finally be fixed. And there was much rejoicing. I’ve also added an option for forcing the map palette-index (-mp <num>, which should help with NDS backgrounds that use ext-palettes.

Also – and this one is pretty big – I’ve completely replaced the tile-mapping routines for something more general. The new method should be able to handle variable-sized tiles (-tw <n> and -th <n>) and is mostly independent of bitdepth. Specifically, bitdepths over 8 bpp can be handled as well, at least in principle. It also means that the external tileset can be a metatile-set as well now, which is good if you’re using metatiles.

With this new method also comes a way to create a custom bitformat for maps (-mB flag). I’m not entirely sure how this can be used yet, but using more than 10 bits for the tile-index, or a 1bpp collision map should be possible now.

Since this is a fairly major change, I kinda expect there’s still some bugs in the system. I have tested it for a number of options, but you know how it is with multi-platform stuff. In particular, if any of you big-endian-system users have trouble now, this will probably be the cause.

And now I will leave you with a …

• link to grit

From xkcd (obviously)

T_T

I think too much. Or so people keep telling me. And they may have a
point.

Anyway, so I’m working on this assembly version of
toncset
for, well, just because I guess. A fill
routine has 3 parts: a head, a main run and a tail. The main part
fills 32-bit chunks (words) when there’s more than 4 bytes left and
when the destination is word-aligned. This part is easy, because
you can just dump words with stmia or str.
For an example of this, see my older
memset16 post.

The tail is for the remaining bytes after the main part. Under normal
circumstances you could do this byte for byte, but some sections of
GBA/NDS memory do not take kindly to byte-writes, so you’d have to
read the word, mask the appropriate bytes out/in and then write it
back. This is mostly just annoying, but still very doable.

The head part, however, is both annoying and tricky. It consist of
filling the unaligned bytes in the first word of a run so that the
main part can do its thing. This is similar to the tail part, in that
it requires bitmasks. However, it’s also possible that both the
beginning and and of a run occur in the same word, effectively
making the head the tail as well, so you’d have to apply a double mask
… somehow. In C, it looks something like this:

This bit of C translates roughly into the following ARM code:

The main thing I thought when I’d written this down was “meh”.
You will note that registers r4 and r5 are
used here, which means stack-work (omitted here for brevity). The
positioning of pushing and popping makes everything a little awkward,
so I was off looking for something else.

The essence of the problem here is that you can only use five registers
without touching the stack: r0-r3 and ip
(r12). Now, r0-r2 are taken
by the destination, fill and size, so I can’t do anything with those.
I also need one to store the left-edge (r3 in this case),
leaving us with one for the right edge, the left and right shift
intermediaries, and the left and right masks. Right! Crap -_-.

So; strategies. Well, one of the reasons I need to use so many
registers is because the lifetimes overlap. For example, I still need
left for a while because shifting the mask up comes last
here. I can’t use r2 for multiple purposes either because
I’ll need it for the size. Now, I could free up r3 by
making the left-mask first, but then I might get in trouble when creating
the right-mask. Also, right-4 is actually
what size wants to be when it grows up in the long-run
case, so I can use that there as well. I’d just have to undo that
for the short case, or perhaps even create the right-mask from
negative numbers.

At this point I figured it would be helpful to take a look at the
various ways of creating the masks I needed. The standard form for a
0x000000FF-style bitmask is (1<<x)-1, but there are
others as well. The following list holds a few examples.

All of these use +1 or −1 as their base, and all but one is
a two-instruction affair. The left-mask looks like 0xFFFFFF00, so
the most obvious one to pick here is -1<<x.
Technically, the right-mask is 0x000000FF, using
x = 8*right = 8*(left+size).
However, you can also see it as a 0x00FFFFFF-style mask if you
use 4-right. This solves two problems at once. First,
it is the negative of the new size, so the value is readily available.
Second, this mask is a right-shifted 0xFFFFFFFF, but as the lower bits
are shifted out anyway, it doesn’t actually have to be a proper
0xFFFFFFFF; it can be a 0xFFFFFF00 as well, which we have in the form
of the left-mask. In other words, we don’t require as many registers
for temps because we already have everything we need. The resulting
code is this:

See? No r4 and r5 anywhere. The
key is toying around with r2 and r3. While
r2 is reserved for the size, it needs to modified anyway
to account for the work done here. In the end, size should be
right−4, which is what points (1a) and (1b) do. Since
right-4 is a right<4 as well, we can use
its result as the condition for the special case; the result
being the negative distance from the word-edge. As explained above,
the right-mask can be constructed from the left-mask by
lmask>>(-8*size), which is done at points (2) and
(3).

It’s a little hairy, but it works. And yet, it still evoked a feeling
of “meh” like before. It’s the two instructions at point (2) that annoyed me. The reason it’s two instructions and not one is because you
can’t multiply by −8 in one go. By +8, yes: that’s a
shifted-mov; −1, yes: that’s
rsb, r2, #0; but the combination is difficult
because the shift only applies to the second operand. A
sub r2, #0, r2, lsl #3 would do it,
but the first operand needs to be a register and I don’t have a spare
one with zero in it. I could make one, that just means I have an
extra instruction somewhere else. I do, however, have either
a +1 or −1 in ip, maybe I can use that somehow.
And then it hits me: the carry flag!

There are adc, sbc and rsb
instructions that add C, C−1 and C−1
to the result, respectively. Setting or clearing the carry flag is
easy, so that’s not a problem. All I need now is to start the
flag using +1 instead of −1 to cancel out the −1 in sbc or rsc. As it turns out, I can do that
I use this format for the left-mask: -(1<<x). In the
mask overview above I listed thi as a 3-instruction gig, but as it turns
out I can use the carry-trick here to for one instruction less. The final
version (for just the head part) looks like this:

Sweeeet :). I was happy with this, until I realized what I’d
been working on: an exception of an exception. This would definitely
not be part of the 20% of the code that uses 80% of the runtime,
so it’s really not something one should worry about. Interesting, yes,
and I learned a few new tricks, but perhaps time would have been better
spent on getting 5% extra out of the main loop. The only problem there
is that that is just boring old unrolling a bit, whereas the head
presented a more ‘interesting’ problem so I went for that
instead.

So yeah; I think too much >_>

OK, perhaps a bit of backstory is in order here.

There’s this strange thing going on in the USA known as the Creation-evolution controversy. In a nutshell, on one side you have the Theory of Evolution, accepted by all but a fraction of the scientists and supported by evidence from multiple fields; and on the other you have groups (usually motivated by their religion or ignorance and frequently both) screaming “nuh-uh!”, backed up by arguments ranging from utterly insane, to fabrications, misunderstandings, red herrings, and “I dunno, Magic Man dun it”. No, I’m not embellishing here: there are long lists of creationists claims that often make no sense at all, but are still used even after being debunked decades ago. As an example how silly these can be, consider the Banana argument. And no, this is not a parody; they’re absolutely serious.

After the scientists got so fed up by the constant misrepresentations that they won’t even debate anymore and several defeats in courts, the creationists came up with a new strategy: Intelligent Design (ID).
They’ve been quite clever with this, actually. For one, they’re leaving the Bible out of
it and claiming that life’s complexity can only come about through an intelligent,
yet unnamed (wink, wink), designer. They also claim that all they want is a fair hearing; that the scientists are being mean with their insistence on evidence and
refusal to accept bogus reasoning.