10 ms·

KABOOM in 180 lines of bare C++

854 points by haqreu 8y ago

edoo 8y ago
Impressive effect. I didn't realize openmp was so easy to use. It isn't realtime but you could bake up some cool effects with this. AMD FX8320 3.5GHz $ time ./tinykaboom real 0m4.176s user 0m28.631 sys 0m0.012s
- maksimum 8y ago
  i7-3770: real 0m6.800s user 0m6.695s sys 0m0.034s 2x e5-2667 v2: real 0m2.217s user 0m56.088s sys 0m0.016s Seems like it's pretty inefficient with the dual CPU setup.
  - edoo 8y ago
    Weird result. I guess it makes sense that it could use twice as much CPU to finish in half the time but looking at the numbers doesn't feel intuitive. I wonder how many shaders this would keep busy. There is probably a class of GPUs and above that this could work on rather well alongside an already large workload.
- userbinator 8y ago
  Running it on the GPU would probably get to realtime speeds. This technique is used a lot in demoscene demos, which certainly do run in realtime.
- nazri1 8y ago
  I saw the openmp pragma and thought to myself "neat! should be fun to watch the cores work hard at this" and went ahead and compiled and run it and smiled at the 400% cpu usage in top. $ time ./tinykaboom ./tinykaboom 78.08s user 0.02s system 369% cpu 21.159 total Then I wondered how it would fare if I were to port it to Go and went ahead and hastily did port to Go and thought that, "hmmm this should run a bit slower than the c++ version" but surprisingly it ran more than twice faster: $ go build ./tinykaboom.go $ time ./tinykaboom ./tinykaboom 34.32s user 0.03s system 368% cpu 9.315 total https://github.com/holygeek/tinykaboom/blob/master/tinykaboom.go https://github.com/holygeek/tinykaboom/blob/master/tinykaboo... Here's the corresponding perf report: Go: Samples: 103K of event 'cycles:pp', Event count (approx.): 37252033995665 Overhead Command Shared Object Symbol 32.17% tinykaboom tinykaboom [.] math.sin 28.80% tinykaboom tinykaboom [.] main.hash 11.81% tinykaboom tinykaboom [.] main.rotate 7.76% tinykaboom tinykaboom [.] math.Min 5.18% tinykaboom tinykaboom [.] main.lerpFloat64 4.25% tinykaboom tinykaboom [.] main.noise 2.59% tinykaboom tinykaboom [.] runtime.mallocgc 2.59% tinykaboom tinykaboom [.] main.fractal_brownian_motion 2.58% tinykaboom tinykaboom [.] main.signed_distance c++: Samples: 234K of event 'cycles:pp', Event count (approx.): 86721459552303 Overhead Command Shared Object Symbol 67.93% tinykaboom libm-2.23.so [.] __sin_avx 30.80% tinykaboom tinykaboom [.] _Z5noiseRK3vecILm3EfE 1.27% tinykaboom libm-2.23.so [.] __floorf_sse41 0.00% tinykaboom tinykaboom [.] _Z23fractal_brownian_motionRK3vecILm3EfE 0.00% tinykaboom tinykaboom [.] floorf@plt If anyone can give suggestions on how to make the tinykaboom.cpp faster that would be neat!
  - haldean 8y ago
    What were your compilation flags?
    - nazri1 8y ago
      I used the default one in CmakeLists.txt (-O3). I ran the comparison again on another machine that I have and this time their performances are about the same: c++: $ time ./tinykaboom ./tinykaboom 46.72s user 0.01s system 364% cpu 12.804 total go: $ time ./tinykaboom ./tinykaboom 42.50s user 0.07s system 350% cpu 12.161 total
  - namirez 8y ago
    There are a few potential improvements here: 1) Use a look up table for 'sin' rather than using 'std::sin'. 2) Tell the compiler what instruction sets to use; for example, tell GCC to use 'skylake' instructions (https://gcc.gnu.org/onlinedocs/gcc-6.2.0/gcc/x86-Options.html https://gcc.gnu.org/onlinedocs/gcc-6.2.0/gcc/x86-Options.htm...). 3) Many of the functions could be 'inline constexpr'. 4) Although 'ofs <<' is buffered, it can still be very slow. Create the output in memory and use a lower level function like 'fwrite' to write it to file. 5) Use 'std::thread' or 'std::async'. It makes the multi-threading more portable and clear.
erikpukinskis 8y ago
SDFs are amazing.
jcoffland 8y ago
Really well written. The other articles in the series on computer graphics are excellent too. The use of GitHub to show diffs of each step is quite effective.
- mi_lk 8y ago
  > The use of GitHub to show diffs of each step is quite effective. Little off-topic, but that's one of the reasons I like to use Magit on Emacs, you can see the diff of each commit interactively and intuitively. [1]:https://magit.vc/ https://magit.vc/
  - codetrotter 8y ago
    Git can show you the diff of any commit as well, though I guess maybe the interactivity you mentioned is important. Anyhow, with just git. Diff of most recent commit: git show HEAD Diff of preceding commit: git show HEAD^ Diff of commit before that again git show HEAD^^ Of course you don’t want to type ^ 200 times. Fortunately you don’t have to. Diff of commit three steps back before most recent: git show HEAD~3 Or you can look at the log first git log And find a specific commit and then use the first few characters of the id of that commit, e.g. git show af4c And of course I would be remiss to not mention git diff And git diff --cached These two show you unstaged and staged changes before you commit. I use these commands all the time. So much that they are two of the commands I have created very short two-letter aliases for in my .bashrc alias di="git diff --cached" alias dp="git diff"
    - gigatexal 8y ago
      I’m a noob on a new team with git (well versed on TFS though) thank you for posting this.
    - viraptor 8y ago
      Alternatively, you can use `tig` which allows you to browse the commit log, diffs, and blames interactively. It's a terminal ui tool.
themodelplumber 8y ago
Wow, this is very similar to the way I use procedural 3D textures and displacement maps to draw planets and things. So much so that I don't even see the explosion, just a growing planet (really, just tweak the mapped color gradient a bit). Example: https://www.friendlyskies.net/images/266.jpg https://www.friendlyskies.net/images/266.jpg So much of 3D graphics is "hmm, this random thing I just made slightly resembles an $X". "OK, so let's say I just created a method for modeling $X." :-) Really fun stuff.
- codetrotter 8y ago
  Very interesting indeed! Off-topic: May I suggest that you switch to using imgur instead of the image host you chose? The ads on imgur are much less intrusive.
  - themodelplumber 8y ago
    Imgur doesn't work on the old iPod I was using while my phone charged. It never loads fully, but TBF I never upgrade iOS past 2 major versions. So iOS 7 and the first "plain" image host search result it is... :-) Edit: Found the image link on my own site: https://www.friendlyskies.net/images/266.jpg https://www.friendlyskies.net/images/266.jpg
    - codetrotter 8y ago
      Understandable. Unfortunate but understandable.
      - themodelplumber 8y ago
        Found a copy on my web server and linked above.
        codetrotter 8y ago
        Thanks :)
gammateam 8y ago
Impressive I was willing to criticize the line count if it had a bunch of dependencies, but 180 lines seems accurate and I'll give a pass to the obligatory core C++ include statements Way to go!
RodericDay 8y ago
I'm not sure that's Perlin noise, seems like Value Noise http://flafla2.github.io/2014/08/09/perlinnoise.html http://flafla2.github.io/2014/08/09/perlinnoise.html
etaioinshrdlu 8y ago
This technique (distance field sphere tracing) was popularized in a big way on the community https://www.shadertoy.com/ https://www.shadertoy.com/
- userbinator 8y ago
  Inigo Quilez created that site, he could be said to have been the one who really popularised it all. He has a bunch of articles on his site about distance fields: https://www.iquilezles.org/www/articles/distfunctions/distfunctions.htm https://www.iquilezles.org/www/articles/distfunctions/distfu... https://iquilezles.org/www/articles/raymarchingdf/raymarchingdf.htm https://iquilezles.org/www/articles/raymarchingdf/raymarchin... He also has videos on YouTube, some of which show the creation of a scene starting from the basics.
lbj 8y ago
As pretty as this is I recommend reading all of his tutorial. Lots of it is old stuff that most of you will have seen takes on before, but he's got some great angles and insights hidden in each post. Start here: https://github.com/ssloy/tinyrenderer/wiki/Lesson-1:-Bresenham%E2%80%99s-Line-Drawing-Algorithm https://github.com/ssloy/tinyrenderer/wiki/Lesson-1:-Bresenh...
hestefisk 8y ago
This is pretty cool. Reminds me of my old escapades on the demo scene (The Party!) in the late 90es.
acidburnNSA 8y ago
Add in some lookup-tables from experimental nuclear interaction probability tables and you've got yourself a Monte Carlo radiation transport system capable of simulating in precise geometric detail all sorts of systems. This was indeed one of the early uses of computers back in the 1950s. For example: https://en.wikipedia.org/wiki/Monte_Carlo_N-Particle_Transport_Code https://en.wikipedia.org/wiki/Monte_Carlo_N-Particle_Transpo...
wprapido 8y ago
Brings back fond memories from the demoscene days back in the 90's! Cheers!
Const-me 8y ago
Modern GPUs are just too powerful to ignore. Especially for graphics-related stuff. Yet HN community seems to ignore GPUs. When I recently published my hobby project that renders much more advanced procedurally-generated stuff, I only got a single upvote: https://news.ycombinator.com/item?id=18921046 https://news.ycombinator.com/item?id=18921046
- holga 8y ago
  You completely missed the point of why people like this..
  - Const-me 8y ago
    The OP's 180 lines of C++ could be rewritten to similar count of lines in HLSL or GLSL. The resulting code would render in realtime while also consuming less electricity. Indeed, I don't see why people like this. In modern world, doing graphics on CPU is very inefficient.
    - vidarh 8y ago
      You miss the point. The point is not doing it efficiently, but explaining the concepts without being distracted by getting it running on specific hardware and the like. Read the introduction to the overall series.
      - Const-me 8y ago
        > The point is not doing it efficiently Have you read the linked article? It says "I want to have a simple stuff applicable to video games." > without being distracted by getting it running on specific hardware Just target Windows and use Direct3D, 99% of PC game developers do just that. The last GPU that didn't support D3D feature level 11.0 was intel sandy bridge from 2011. Everything newer then that supports 11.0, and unlike OpenGL with it's extensions, the majority of features are mandatory. Very rarely I saw compatibility issues across GPUs in recent years, and when I did it was a driver bug.
mistrial9 8y ago
reminds me of a patch to MacOS WindowMgr that made an explosion when you closed the window.. didnt win MacHack i n Ann Arbor MI that year but it was fun..
Solar19 8y ago
Nice. Does Visual Studio support the level or version of OpenMP used in this code? (see the pragma)
- haqreu 8y ago
  Yes it does, however you'd need to modify CMakeLists.txt, as it is written for g++
nertzy 8y ago
I was hoping that this was a clone of the Atari game. https://en.wikipedia.org/wiki/Kaboom!_(video_game) https://en.wikipedia.org/wiki/Kaboom!_(video_game)
- deleted 8y ago
  [deleted]
- grumpyDev66 8y ago
  Me too!
cheick1 8y ago
I would learn language C C+ and C++ who can help me please
franciscop 8y ago
This is amazing, thanks for sharing! One particularity of fire is that it does not generate shadows, while smoke does (might be useful for more realistic effects): https://physics.stackexchange.com/questions/372117/shadow-of-fire-doesnt-exist https://physics.stackexchange.com/questions/372117/shadow-of...
angeal1131 8y ago
Oh. I thought it was the Atar2600 game.
- deleted 8y ago
  [deleted]
- butterisgood 8y ago
  Kaboom! was awesome... need paddle controllers to really appreciate it though.
tombert 8y ago
I suppose this shows a bit of a sickness inside me, because I have a strong aversion against reading these articles because of my pure distaste for C++, which is stupid because this article is great. Still, it's hard for me to not want to create a series of blog posts under the title "All those cool graphics tutorials in <language I like better>".
jrjarrett 8y ago
Aw, here I thought it was an implementation of the 1980's Atari 2600 Activision game :/ https://en.wikipedia.org/wiki/Kaboom!_(video_game) https://en.wikipedia.org/wiki/Kaboom!_(video_game)
tpaschalis 8y ago
I ported this [1], as well as ssloy's previous [2] article that was featured recently in HN, in Golang. I wanted to say he's an excellent introduction to graphics. As a sysadmin, I had never drawn more than simple lines and the whole thing seemed daunting. Now I see how fun it can be, and I'm waiting for next weekend to pick up some more! [1] https://github.com/tpaschalis/go-tinykaboom https://github.com/tpaschalis/go-tinykaboom [2] https://github.com/tpaschalis/go-tinyraytracer https://github.com/tpaschalis/go-tinyraytracer
deleted 8y ago
[deleted]

854 points by haqreu 8y ago

edoo 8y ago

Impressive effect. I didn't realize openmp was so easy to use. It isn't realtime but you could bake up some cool effects with this. AMD FX8320 3.5GHz $ time ./tinykaboom real 0m4.176s user 0m28.631 sys 0m0.012s

maksimum 8y ago
i7-3770: real 0m6.800s user 0m6.695s sys 0m0.034s 2x e5-2667 v2: real 0m2.217s user 0m56.088s sys 0m0.016s Seems like it's pretty inefficient with the dual CPU setup.
- edoo 8y ago
  Weird result. I guess it makes sense that it could use twice as much CPU to finish in half the time but looking at the numbers doesn't feel intuitive. I wonder how many shaders this would keep busy. There is probably a class of GPUs and above that this could work on rather well alongside an already large workload.
userbinator 8y ago
Running it on the GPU would probably get to realtime speeds. This technique is used a lot in demoscene demos, which certainly do run in realtime.
nazri1 8y ago
I saw the openmp pragma and thought to myself "neat! should be fun to watch the cores work hard at this" and went ahead and compiled and run it and smiled at the 400% cpu usage in top. $ time ./tinykaboom ./tinykaboom 78.08s user 0.02s system 369% cpu 21.159 total Then I wondered how it would fare if I were to port it to Go and went ahead and hastily did port to Go and thought that, "hmmm this should run a bit slower than the c++ version" but surprisingly it ran more than twice faster: $ go build ./tinykaboom.go $ time ./tinykaboom ./tinykaboom 34.32s user 0.03s system 368% cpu 9.315 total https://github.com/holygeek/tinykaboom/blob/master/tinykaboom.go https://github.com/holygeek/tinykaboom/blob/master/tinykaboo... Here's the corresponding perf report: Go: Samples: 103K of event 'cycles:pp', Event count (approx.): 37252033995665 Overhead Command Shared Object Symbol 32.17% tinykaboom tinykaboom [.] math.sin 28.80% tinykaboom tinykaboom [.] main.hash 11.81% tinykaboom tinykaboom [.] main.rotate 7.76% tinykaboom tinykaboom [.] math.Min 5.18% tinykaboom tinykaboom [.] main.lerpFloat64 4.25% tinykaboom tinykaboom [.] main.noise 2.59% tinykaboom tinykaboom [.] runtime.mallocgc 2.59% tinykaboom tinykaboom [.] main.fractal_brownian_motion 2.58% tinykaboom tinykaboom [.] main.signed_distance c++: Samples: 234K of event 'cycles:pp', Event count (approx.): 86721459552303 Overhead Command Shared Object Symbol 67.93% tinykaboom libm-2.23.so [.] __sin_avx 30.80% tinykaboom tinykaboom [.] _Z5noiseRK3vecILm3EfE 1.27% tinykaboom libm-2.23.so [.] __floorf_sse41 0.00% tinykaboom tinykaboom [.] _Z23fractal_brownian_motionRK3vecILm3EfE 0.00% tinykaboom tinykaboom [.] floorf@plt If anyone can give suggestions on how to make the tinykaboom.cpp faster that would be neat!
- haldean 8y ago
  What were your compilation flags?
  - nazri1 8y ago
    I used the default one in CmakeLists.txt (-O3). I ran the comparison again on another machine that I have and this time their performances are about the same: c++: $ time ./tinykaboom ./tinykaboom 46.72s user 0.01s system 364% cpu 12.804 total go: $ time ./tinykaboom ./tinykaboom 42.50s user 0.07s system 350% cpu 12.161 total
- namirez 8y ago
  There are a few potential improvements here: 1) Use a look up table for 'sin' rather than using 'std::sin'. 2) Tell the compiler what instruction sets to use; for example, tell GCC to use 'skylake' instructions (https://gcc.gnu.org/onlinedocs/gcc-6.2.0/gcc/x86-Options.html https://gcc.gnu.org/onlinedocs/gcc-6.2.0/gcc/x86-Options.htm...). 3) Many of the functions could be 'inline constexpr'. 4) Although 'ofs <<' is buffered, it can still be very slow. Create the output in memory and use a lower level function like 'fwrite' to write it to file. 5) Use 'std::thread' or 'std::async'. It makes the multi-threading more portable and clear.

erikpukinskis 8y ago

SDFs are amazing.

jcoffland 8y ago

Really well written. The other articles in the series on computer graphics are excellent too. The use of GitHub to show diffs of each step is quite effective.

mi_lk 8y ago
> The use of GitHub to show diffs of each step is quite effective. Little off-topic, but that's one of the reasons I like to use Magit on Emacs, you can see the diff of each commit interactively and intuitively. [1]:https://magit.vc/ https://magit.vc/
- codetrotter 8y ago
  Git can show you the diff of any commit as well, though I guess maybe the interactivity you mentioned is important. Anyhow, with just git. Diff of most recent commit: git show HEAD Diff of preceding commit: git show HEAD^ Diff of commit before that again git show HEAD^^ Of course you don’t want to type ^ 200 times. Fortunately you don’t have to. Diff of commit three steps back before most recent: git show HEAD~3 Or you can look at the log first git log And find a specific commit and then use the first few characters of the id of that commit, e.g. git show af4c And of course I would be remiss to not mention git diff And git diff --cached These two show you unstaged and staged changes before you commit. I use these commands all the time. So much that they are two of the commands I have created very short two-letter aliases for in my .bashrc alias di="git diff --cached" alias dp="git diff"
  - gigatexal 8y ago
    I’m a noob on a new team with git (well versed on TFS though) thank you for posting this.
  - viraptor 8y ago
    Alternatively, you can use `tig` which allows you to browse the commit log, diffs, and blames interactively. It's a terminal ui tool.

themodelplumber 8y ago

Wow, this is very similar to the way I use procedural 3D textures and displacement maps to draw planets and things. So much so that I don't even see the explosion, just a growing planet (really, just tweak the mapped color gradient a bit). Example: https://www.friendlyskies.net/images/266.jpg https://www.friendlyskies.net/images/266.jpg So much of 3D graphics is "hmm, this random thing I just made slightly resembles an $X". "OK, so let's say I just created a method for modeling $X." :-) Really fun stuff.

codetrotter 8y ago
Very interesting indeed! Off-topic: May I suggest that you switch to using imgur instead of the image host you chose? The ads on imgur are much less intrusive.
- themodelplumber 8y ago
  Imgur doesn't work on the old iPod I was using while my phone charged. It never loads fully, but TBF I never upgrade iOS past 2 major versions. So iOS 7 and the first "plain" image host search result it is... :-) Edit: Found the image link on my own site: https://www.friendlyskies.net/images/266.jpg https://www.friendlyskies.net/images/266.jpg
  - codetrotter 8y ago
    Understandable. Unfortunate but understandable.
    - themodelplumber 8y ago
      Found a copy on my web server and linked above.
      - codetrotter 8y ago
        Thanks :)

gammateam 8y ago

Impressive I was willing to criticize the line count if it had a bunch of dependencies, but 180 lines seems accurate and I'll give a pass to the obligatory core C++ include statements Way to go!

RodericDay 8y ago

I'm not sure that's Perlin noise, seems like Value Noise http://flafla2.github.io/2014/08/09/perlinnoise.html http://flafla2.github.io/2014/08/09/perlinnoise.html

etaioinshrdlu 8y ago

This technique (distance field sphere tracing) was popularized in a big way on the community https://www.shadertoy.com/ https://www.shadertoy.com/

userbinator 8y ago
Inigo Quilez created that site, he could be said to have been the one who really popularised it all. He has a bunch of articles on his site about distance fields: https://www.iquilezles.org/www/articles/distfunctions/distfunctions.htm https://www.iquilezles.org/www/articles/distfunctions/distfu... https://iquilezles.org/www/articles/raymarchingdf/raymarchingdf.htm https://iquilezles.org/www/articles/raymarchingdf/raymarchin... He also has videos on YouTube, some of which show the creation of a scene starting from the basics.

lbj 8y ago

As pretty as this is I recommend reading all of his tutorial. Lots of it is old stuff that most of you will have seen takes on before, but he's got some great angles and insights hidden in each post. Start here: https://github.com/ssloy/tinyrenderer/wiki/Lesson-1:-Bresenham%E2%80%99s-Line-Drawing-Algorithm https://github.com/ssloy/tinyrenderer/wiki/Lesson-1:-Bresenh...

hestefisk 8y ago

This is pretty cool. Reminds me of my old escapades on the demo scene (The Party!) in the late 90es.

acidburnNSA 8y ago

Add in some lookup-tables from experimental nuclear interaction probability tables and you've got yourself a Monte Carlo radiation transport system capable of simulating in precise geometric detail all sorts of systems. This was indeed one of the early uses of computers back in the 1950s. For example: https://en.wikipedia.org/wiki/Monte_Carlo_N-Particle_Transport_Code https://en.wikipedia.org/wiki/Monte_Carlo_N-Particle_Transpo...

wprapido 8y ago

Brings back fond memories from the demoscene days back in the 90's! Cheers!

Const-me 8y ago

Modern GPUs are just too powerful to ignore. Especially for graphics-related stuff. Yet HN community seems to ignore GPUs. When I recently published my hobby project that renders much more advanced procedurally-generated stuff, I only got a single upvote: https://news.ycombinator.com/item?id=18921046 https://news.ycombinator.com/item?id=18921046

holga 8y ago
You completely missed the point of why people like this..
- Const-me 8y ago
  The OP's 180 lines of C++ could be rewritten to similar count of lines in HLSL or GLSL. The resulting code would render in realtime while also consuming less electricity. Indeed, I don't see why people like this. In modern world, doing graphics on CPU is very inefficient.
  - vidarh 8y ago
    You miss the point. The point is not doing it efficiently, but explaining the concepts without being distracted by getting it running on specific hardware and the like. Read the introduction to the overall series.
    - Const-me 8y ago
      > The point is not doing it efficiently Have you read the linked article? It says "I want to have a simple stuff applicable to video games." > without being distracted by getting it running on specific hardware Just target Windows and use Direct3D, 99% of PC game developers do just that. The last GPU that didn't support D3D feature level 11.0 was intel sandy bridge from 2011. Everything newer then that supports 11.0, and unlike OpenGL with it's extensions, the majority of features are mandatory. Very rarely I saw compatibility issues across GPUs in recent years, and when I did it was a driver bug.

mistrial9 8y ago

reminds me of a patch to MacOS WindowMgr that made an explosion when you closed the window.. didnt win MacHack i n Ann Arbor MI that year but it was fun..

Solar19 8y ago

Nice. Does Visual Studio support the level or version of OpenMP used in this code? (see the pragma)

haqreu 8y ago
Yes it does, however you'd need to modify CMakeLists.txt, as it is written for g++

nertzy 8y ago

I was hoping that this was a clone of the Atari game. https://en.wikipedia.org/wiki/Kaboom!_(video_game) https://en.wikipedia.org/wiki/Kaboom!_(video_game)

deleted 8y ago
[deleted]
grumpyDev66 8y ago
Me too!

cheick1 8y ago

I would learn language C C+ and C++ who can help me please

franciscop 8y ago

This is amazing, thanks for sharing! One particularity of fire is that it does not generate shadows, while smoke does (might be useful for more realistic effects): https://physics.stackexchange.com/questions/372117/shadow-of-fire-doesnt-exist https://physics.stackexchange.com/questions/372117/shadow-of...

angeal1131 8y ago

Oh. I thought it was the Atar2600 game.

deleted 8y ago
[deleted]
butterisgood 8y ago
Kaboom! was awesome... need paddle controllers to really appreciate it though.

tombert 8y ago

I suppose this shows a bit of a sickness inside me, because I have a strong aversion against reading these articles because of my pure distaste for C++, which is stupid because this article is great. Still, it's hard for me to not want to create a series of blog posts under the title "All those cool graphics tutorials in <language I like better>".

jrjarrett 8y ago

Aw, here I thought it was an implementation of the 1980's Atari 2600 Activision game :/ https://en.wikipedia.org/wiki/Kaboom!_(video_game) https://en.wikipedia.org/wiki/Kaboom!_(video_game)

tpaschalis 8y ago

I ported this [1], as well as ssloy's previous [2] article that was featured recently in HN, in Golang. I wanted to say he's an excellent introduction to graphics. As a sysadmin, I had never drawn more than simple lines and the whole thing seemed daunting. Now I see how fun it can be, and I'm waiting for next weekend to pick up some more! [1] https://github.com/tpaschalis/go-tinykaboom https://github.com/tpaschalis/go-tinykaboom [2] https://github.com/tpaschalis/go-tinyraytracer https://github.com/tpaschalis/go-tinyraytracer

deleted 8y ago

[deleted]