Register a SA Forums Account here!
JOINING THE SA FORUMS WILL REMOVE THIS BIG AD, THE ANNOYING UNDERLINED ADS, AND STUPID INTERSTITIAL ADS!!!

You can: log in, read the tech support FAQ, or request your lost password. This dumb message (and those ads) will appear on every screen until you register! Get rid of this crap by registering your own SA Forums Account and joining roughly 150,000 Goons, for the one-time price of $9.95! We charge money because it costs us money per month for bills, and since we don't believe in showing ads to our users, we try to make the money back through forum registrations.
 
  • Locked thread
Jabor
Jul 16, 2010

#1 Loser at SpaceChem
The thing I actually want most in this game is some real keybindings. You won't believe how many times I've inserted ddkp into the program while trying to rearrange things.

I binged through most of the levels last night, just primes and sorting to go. And my brain has wasted most of today designing a solution to the former one. Game is addictive and I haven't even started seriously thinking about optimisation yet.

Adbot
ADBOT LOVES YOU

Jabor
Jul 16, 2010

#1 Loser at SpaceChem

Wild M posted:

I haven't done that one yet, but don't you just have to shuffle numbers between the stacks and inject new numbers in their proper place after doing some subtraction and comparison? Though I don't recall the node structure there.

Game is too good for how much development went into it.

That's the basic strategy, yeah - you use your two stacks to emulate a list, and then use whatever sorting algorithm you can implement in the space constraints to sort it.

Much of the complexity comes from the fact that the node arrangement is rather pants-on-head and (I assume deliberately) designed to require lots of instructions just moving things around and leaving you squeezed for actual code space.

Jabor
Jul 16, 2010

#1 Loser at SpaceChem
In general yeah, you should be splitting things across nodes if you can. For example, if your first node zeroes out everything that isn't 1, 4 or 5, that makes signaling easier. Also remember that you have the position of the instruction being executed as effectively another piece of state.

--

Primes ended up being fairly straightforward, though of course it took forever to run. There are a bunch of optimisations I need to do on that.

Jabor
Jul 16, 2010

#1 Loser at SpaceChem

Quinton posted:

I went with a really trivial convert RLE sequences to sequence of color numbers, feed that from one edge, feed X values from another edge, feed Y values from a third edge, and fuse them into X, Y, C, -1 and spit them out. Super straight forward, skips the trickiness with needing to break the sequences at the right edge (since single draw commands cannot wrap onto the next line), but not nearly most optimal.

This is basically what I did as well. There's a really obvious optimisation that I only realised after finishing it.

Jabor
Jul 16, 2010

#1 Loser at SpaceChem
Sequence Sorter done.That's the first time I've had to use JRO shenanigans just to make the topology work, but overall I'm reasonably happy with it as a first solution.

I'll probably give things a break for now.

Jabor
Jul 16, 2010

#1 Loser at SpaceChem
Well, since we're posting solutions, here's my unoptimized prime detector, courtesy of Euclid. 97485/5/38, and there's potentially enough space to compact it to 4 nodes.

Jabor
Jul 16, 2010

#1 Loser at SpaceChem

ymgve posted:

I just saw someone else proposing a different algorithm that might be better, too:

1. Pump everything into stack A until you get a 0
2. Move everything from stack A to stack B, and detect the lowest number and output it
3. Move everything from stack B to stack A, but remove the number detected in step 2
4. If stack empty, goto 1. Else, goto 2

This is kind of how I solved it. The selection sorting itself was pretty straightforward, but recognising the end of the sequence and outputting a 0 there was a bit tricky.

One helpful insight is that you don't need to keep the sequence in order, so you can just pull out the lowest element seen so far when you're copying the sequence, and if you see a new lowest element you can just put the old one back in at that point.

Jabor
Jul 16, 2010

#1 Loser at SpaceChem

ErIog posted:

The problem is that I can't tell if my changing the code fixed the problem or my passing is still just a fluke in the random data. I wish the game was more rigorous with how it tests the solutions. Random data is fine, but passing doesn't mean anything if you pass due to the RNG giving you data that doesn't trigger holes in your algorithm. Pairing random data with some hand-constructed data meant to smoke test the algorithm would be a nice compromise solution.

This is actually what the game does do AFAIK - the first run of the program (which is the one used for scoring your solution) is on a fixed set of data, and the second run (which only happens if the first run passes) is randomised.

Really, the problem is that the fixed set doesn't always do a good job of exercising all the edge cases.

Jabor
Jul 16, 2010

#1 Loser at SpaceChem
http://steamcommunity.com/sharedfiles/filedetails/?id=481921899

So am I like, the only person who's finished Signal Exponentiator?

Jabor
Jul 16, 2010

#1 Loser at SpaceChem
I think there's one big trick you're missing: when subtracting two numbers to compare them, you only need to keep one of the original numbers around. You can reconstruct the other one via addition.

This should let you eke out a little more space.

Jabor
Jul 16, 2010

#1 Loser at SpaceChem
This is seriously my jam. Why is it not October yet.

Adbot
ADBOT LOVES YOU

Jabor
Jul 16, 2010

#1 Loser at SpaceChem

TheKnife posted:

I impulse pre-ordered the physical manual edition before even watching the video, are you supposed to get an e-mail from zachtronics or humble store after that? Because I only got a paypal receipt
I figure they will want my address eventually

Yeah, you get a humble link, and it has a link to a form where they want your address.

Shipping the physical stuff is apparently starting on ~26th.

  • Locked thread