TIS-100

TIS-100

View Stats:
Shinken Nov 27, 2015 @ 7:43pm
Do things like this happen in real programming as well?
I just just crafted a program for hours. ( the one for the "no memory" achievement)
Draft after draft I came up with incredibly elegant and beautiful nodes which would have worked if they had one or two more lines of space.

In the end I kinda tilted and my last version looked stupid, inefficient and inconsistend because I was mentally drained. That was the version that actually worked.
Last edited by Shinken; Nov 27, 2015 @ 7:44pm
< >
Showing 1-15 of 21 comments
Razguul Nov 27, 2015 @ 7:51pm 
No such thing as real programming.
Belisama Nov 27, 2015 @ 8:03pm 
Yes, it happens.
Granite Nov 28, 2015 @ 12:11am 
Yes
Simple as that. Sometimes an elegant solution gets broken into a rough beast by things outside of one's control or by preceding or subsequent code requirements.
Shinken Nov 28, 2015 @ 1:44am 
Here's the program if someone is interested:

http://steamcommunity.com/sharedfiles/filedetails/?id=564013680

Highlights:

The last node deletes half of the information it receives, then recreates part that information itself. I wrote the last node last and realized it's easier this way. Sucks to be you, earlier nodes.

There are three different implementations of basically the same loop mechanism in the first, second and last node. Like a diorama of how to do the same thing differently. Values for the loop cycles where aquired by failing and then incrementing them instead of thinking beforehand.

In the next-to-last node the same command is written five times in succession instead of doing a loop (that's just the worst offender of many more). It worked, so I didn't bother to optimize it.
__m__Yn_F_onY__d Nov 28, 2015 @ 9:28am 
Originally posted by Shinken:
In the next-to-last node the same command is written five times in succession instead of doing a loop (that's just the worst offender of many more). It worked, so I didn't bother to optimize it.

That's called 'unrolling a loop' and is usually more optimal for cycle count than using a loop. I didn't read your code entirely, but that looks to be the case for you. If you're optimizing for instruction count instead, that's a different issue.
Granite Nov 29, 2015 @ 10:26pm 
http://s10.postimg.org/lcg46ww3t/prog.png
I had to fudge an initialization loop's required zero output as it was without two operands to test. I did this rather than incorporate a, "zero" input value handler as it would have added a processing overhead I didn't want to have to pay.
Last edited by Granite; Nov 29, 2015 @ 10:28pm
DarthRaptor Dec 4, 2015 @ 11:42am 
Real programming (in a business environment) works like this:
Dev: I need two days to implement a beautiful and extensible solution
Manager: You have until this evening, just make it work
Dev. Giant hack it is then

Last edited by DarthRaptor; Dec 4, 2015 @ 11:42am
ent|ty Dec 26, 2015 @ 2:57pm 
Originally posted by Razguul:
No such thing as real programming.
Programming is problem solving.
Programming is "I have a goal" and coding something to do it for you.
prefixcactus Jan 22, 2016 @ 3:29pm 
Not exactly like this, but coding for microcontrollers, especially smaller ones with tens of bytes of RAM and a comparably small amount of program memory, sure feels this way.
[EED]Pod Jan 27, 2016 @ 1:24am 
I've had similar. 64k on the pebble watch isnt much to work with when you remember it is used both for code and any loaded data. I was so close to the limit that I had to rewrite sections of code that caused them to become much harder to read and follow but in turn meant it used less instructions (in some cases saving me 50 whole bytes at a time!).
Seedling Mar 18, 2017 @ 2:00pm 
I managed to solve this for the NO_MEMORY achievement with elegant code :D
It's essentially the same program for each node, with some optimizations for the first and last node, and it can reverse sequences of length n with n nodes.

My first attempt was 400/8/95, and it can reverse 8 long sequences. Data analysis showed that no sequence is longer then 5, so I could cut back to 373/6/60, with one single MOV node because there's no 5 long path between IN and OUT.

http://steamcommunity.com/sharedfiles/filedetails/?id=886366818
Last edited by Seedling; Mar 18, 2017 @ 2:01pm
wrOngplanet Apr 5, 2017 @ 9:55am 
@ seedling:

Heh, I came up with a very similar solution!

I have to admit tho I managed to optimize it slightly just now on the intermediary nodes. Shortened them by 1 line (I had a JEZ ST as the 2nd last line, which ofc could be replaced by a JNZ label, as the loop restarts at the end anyway).

http://steamcommunity.com/sharedfiles/filedetails/?id=898986100

EDIT: Not as efficient tho, I got 582/6/68.
Last edited by wrOngplanet; Apr 5, 2017 @ 9:59am
lisamariefan Apr 15, 2017 @ 1:45am 
My solution is fairly lean on instructions and relies on sequences not having negative values to create a buffer.

http://steamcommunity.com/sharedfiles/filedetails/?id=875605777
Last edited by lisamariefan; Apr 15, 2017 @ 1:46am
Pehrgryn Apr 21, 2017 @ 8:11pm 
I'm amazed by some of the things you all have come up with.

Here is my solution where I'm doing one way communication by index. It was not working, and then I went to change it back to the previous non-working state. I must have done something "wrong" in the reversion because it worked after that.

I'll take it. I've been at this thing for hours. Time to play some X-COM instead.

http://steamcommunity.com/sharedfiles/filedetails/?id=910499831

Shinken Apr 22, 2017 @ 2:36am 
Those are the best :D

Like someone said in a review:
Evening: It should be working, why isn't this working?
Early Morning: It shouldn't be working, why is this working?
< >
Showing 1-15 of 21 comments
Per page: 1530 50