Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

2048 implemented in 487 bytes of C

gist.github.com

Post reply on HN
Print view View original

41–47 of 47 posts

Re: 2048 implemented in 487 bytes of C

#41

Post by adsr »

userbinator wrote: post #39
adsr wrote: post #37

Earlier quoted context omitted.

That could be true for other embedded projects as well, but then it's the size of the executable binary that is of concern, not necessarily the size of the source code on your development box.

Exceptions like C++ templates exist (in which a small amount of source can expand to a huge binary), but usually there tends to be a general correlation between the size of the source and the binary. Trying to write as little source code as possible also leads to trying to find the simplest, most concise algorithm to do a particular task, and that also has effects on the binary size.

This isn't C++. Just adding whitespace, descriptive variable and function names and comments wouldn't add any size to the resulting binary since the code is semantically the same. Using library functions can keep your amount of lines low, but you get that back when at link time if you do static linking at least. Wouldn't you prefer maintainable code that people can easily understand. I just want this said since obfuscated minimal C code isn't the same as minified JS.

Algorithms is an interesting case since you have to ask if you are optimizing for size or speed, as an example you can implement a linear search in fewer lines of code than binary search. Does that mean that linear search is a better more optimized choice. It does if you are optimizing for small executable binary size.

Re: 2048 implemented in 487 bytes of C

#42

Post by wglb »

plg wrote: post #32

I never understood why this sort of thing is interesting. Let's say you can program 2048 in 487 bytes of C ... and then someone else comes along and they can program it in 387 bytes of C. So what? Is there a use case in the year 2014 where 100 bytes matter? How many bytes would it take to code it in C in a human readable fashion? Such that some other programmer could look at it, understand it, modify it, fix bugs, et…

Think of it as a puzzle.

Checkout the demoscene stuff and superpacking JS.

Re: 2048 implemented in 487 bytes of C

#45

Post by Almaviva »

nullc wrote: post #2

Like the small JS version this also has the bug where you can summon more tiles by pushing again in a direction where movement isn't allowed.

He shouldn't call his game "2048" if it has that bug. It's a much easier game than the original one, as you are never forced to move a big number out of a corner and you never fear the dreaded position where you have exactly one open row and you are forced to move all your big numbers away from the edge.

Re: 2048 implemented in 487 bytes of C

#46

Post by akira2501 »

userbinator wrote: post #31

I haven't tried it, but a game of this complexity looks like it could be implemented in roughly the same number of bytes of binary, meaning it fits in a bootsector... Coincidentally, a sector on optical media is typically 2048 bytes.

ISO 9660 is 2352 bytes, actually. The logical size is 2048 bytes, but the other bytes are needed for error correction and other headers.
Post reply on HN