although the flight sim is a little more interesting from a technical perspective, since it's interactive and also not using the GPU to do most of the computation.
Also, despite the source code being obfuscated, observe that that "external symbols" which are still visible, e.g. XDrawLine, XSetForeground, etc. already give a pretty good overview of how it does what it does --- and in general, when reverse-engineering or analysing software, inspecting where the "black box" interacts with the rest of the world is an important part of understanding it.
And yet it looks like my coworkers everyday php code. Seriously though way to go above and beyond in the competition with something so interesting on its own as a x windows flight sim with easy to modify scenery.
Wow thats really impressive. I just wrote a flight sim the other day that i thought was frugal because it's less than 10 kloc. This on is about 100 times shorter!
I have modified the Linux SABRE flight sim to compile and run on modern Linux systems. Only requires DirectFB (replaced SVGALIB) or SDL2. Build with scons.
I have been low-level systems coder for about 10 years, and have no clue how demos are made besides the fact they use the technique of procedural generation and/or shader(s).
- learn how to program a computing device with some kind of visual (and audible too, ideally) output
- make the coolest looking (and sounding) thing you can get working
- show it off to other people, look at what they made, get inspired to do better
- return to step 2.
There are more details, of course - a lot of the "classic" demo effects depend on writing to a linear framebuffer, which isn't exactly how modern video APIs work - and there's all kinds of tricks that are only relevant to the particular hardware they were invented on - it's not impressive to break the C64's sprite limit on hardware that can draw a billion triangles a second.
My recommendation: find a way to draw pixels to a linear framebuffer (an HTML Canvas element, an SDL1.x Surface, even an OpenGL or Direct3D texture that you can render to a rectangle, if you can handle the complexity of those APIs), then go watch YouTube videos of classic 2D demos like Future Crew's "Unreal" and "Second Reality", and try to replicate those effects in your own framebuffer.
You may succeed, you may invent your own effects that you think look just as good. Once you've got some things that look good, you might want to try optimizing for code-size or speed or mixing two effects together in a surprising way.
And like any creative endeavour, the most important rule is: have fun.
Pretty cool! I don't know why I expected otherwise, but the makefile works just fine despite being from 1998. It took 30 seconds to download the files, compile, and start playing the game!
I know why: we're used to software having dependencies, and those dependencies having dependencies, and using a dependency downloader (think Maven) which needs to be configured, or misses the right version of some dependency... in short, layers upon layers upon layers. The beauty of this kind of code is that it's really pure. That, in itself, is an achievement; let alone the size, obfuscation or shape.
I love using small amounts of code to write beautiful code...preferably games. I wish there was a book with 20 programs like this, just not obfuscated. I bet I would learn a lot.
There is clang-format, which comes even with clang for windows, I use it with a Visual Studio extension and it formats the code whenever I save. I even prefer that sometimes I have the whitespace messed, but just having the braces right will format it properly, where in python you would have to fix whitespaces manually.
Go gets away with it because it ships with the official compiler tooling and most projects use it. C++ has 30 years of existing code that follows whatever convention was in vogue + whatever the individual preferred.
C++ projects I work on just require you to use a current compiler, or an older one if the project is older. So seems like 927 might not be as big an issue.
(Source code and discussion at https://news.ycombinator.com/item?id=11848097 ; explanation at http://www.iquilezles.org/www/material/function2009/function... )
although the flight sim is a little more interesting from a technical perspective, since it's interactive and also not using the GPU to do most of the computation.
Also, despite the source code being obfuscated, observe that that "external symbols" which are still visible, e.g. XDrawLine, XSetForeground, etc. already give a pretty good overview of how it does what it does --- and in general, when reverse-engineering or analysing software, inspecting where the "black box" interacts with the rest of the world is an important part of understanding it.
https://github.com/ysangkok/sabre
Images and review at:
http://www.tldp.org/LDP/LG/issue30/ayers3.html
Is there a guide on how to start making one?
- learn how to program a computing device with some kind of visual (and audible too, ideally) output
- make the coolest looking (and sounding) thing you can get working
- show it off to other people, look at what they made, get inspired to do better
- return to step 2.
There are more details, of course - a lot of the "classic" demo effects depend on writing to a linear framebuffer, which isn't exactly how modern video APIs work - and there's all kinds of tricks that are only relevant to the particular hardware they were invented on - it's not impressive to break the C64's sprite limit on hardware that can draw a billion triangles a second.
My recommendation: find a way to draw pixels to a linear framebuffer (an HTML Canvas element, an SDL1.x Surface, even an OpenGL or Direct3D texture that you can render to a rectangle, if you can handle the complexity of those APIs), then go watch YouTube videos of classic 2D demos like Future Crew's "Unreal" and "Second Reality", and try to replicate those effects in your own framebuffer.
You may succeed, you may invent your own effects that you think look just as good. Once you've got some things that look good, you might want to try optimizing for code-size or speed or mixing two effects together in a surprising way.
And like any creative endeavour, the most important rule is: have fun.
Installed one package on NPM, installer finished, 690 new packages installed.
Probably better to get a set of programs like this to be from a diverse set of authors
https://news.ycombinator.com/item?id=13451454
And despite the seriously obfuscated nature, I only got three warnings on compilation.
Banks compiled down to 19kb (though dynamically linked), which is still fairly tiny (though much larger than the source code).
Now excuse me, I'm going to have some old school fun.
[0] https://imgur.com/RvEM5q2
I'm sure python fans will disagree, but the fact that whitespace errors don't effect the correctness of C/C++ code is a feature in my book.
Go gets away with it because it ships with the official compiler tooling and most projects use it. C++ has 30 years of existing code that follows whatever convention was in vogue + whatever the individual preferred.
[1]: https://xkcd.com/927/