IOCCC Flight Simulator(blog.aerojockey.com)
blog.aerojockey.com
IOCCC Flight Simulator
http://blog.aerojockey.com/post/iocccsim
29 comments
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).
Is there a guide on how to start making one?
Is there a guide on how to start making one?
The historical path to demo making has been:
- 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.
- 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.
The IOCCC is fun, but isn't it time for C/C++ to get standard formatting for consistent readability? Like Go and Python.
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.
Honestly, most modern C/C++ software has converged to readable formatting. Before that ~C99 it was a crapshoot, but that was 18 years ago!
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.
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.
It has, it is called whatever the company design style says and validated by tools like indent.
Sure, but good luck avoiding 927. [1]
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/
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/
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.
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!
The shape of the code is just as impressive as the size!
I am reminded of this 4 kilobyte demo: https://www.youtube.com/watch?v=jB0vBmiTr6o
(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.
(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.
Downloaded, ran "make banks"... And played. [0]
Works like a charm!
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
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
This might go beyond obfuscated to the art realm!
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.
Maybe devil you know here, but I'd take Maven over NPM.
Installed one package on NPM, installer finished, 690 new packages installed.
Installed one package on NPM, installer finished, 690 new packages installed.
Majority of which composed by a single function.
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.
Most of my games are pretty small: https://github.com/serprex?utf8=%E2%9C%93&tab=repositories&q... (specifically: othello, snake, rainbeam, Viz, roadroll, vektorael, ringbeam, Through, Crumb, Jumpless, wrapfield)
Probably better to get a set of programs like this to be from a diverse set of authors
Probably better to get a set of programs like this to be from a diverse set of authors
Thank you! This looks great!
Not games, and the code is in AWK, but this comes to mind (full disclosure - I only read a chapter or two, but the TOC is impressive):
https://news.ycombinator.com/item?id=13451454
https://news.ycombinator.com/item?id=13451454
I like Awk for small things :)
Thank God for orthogonal matrices
A writeup or video explaining how the code works would be fascinating.
Is there any explanation on how this thing actually works?
https://github.com/ysangkok/sabre
Images and review at:
http://www.tldp.org/LDP/LG/issue30/ayers3.html