I was hoping that this was a clone of the Atari game.
KABOOM in 180 lines of bare C++
41–50 of 68 posts
Re: KABOOM in 180 lines of bare C++
#42Earlier quoted context omitted.
It'd work if people just simply posted the direct image, so you don't have to load their massively bloated website. Then again a direct link wouldn't support them through their monitization methods (ads), but if I'm already running an ad blocker..
While I argued for Imgur over using the hosting site the parent to mine used with regards to intrusiveness of ads I should note something important about Imgur with regards to the bloat you mentioned. The image subdomain servers of Imgur, i.imgur.com, look at the referer of your request and will conditionally redirect you to the web app. Basically, direct links to images will only give you the image directly if the p…
Ah, thank you for the informative reply! I admit that's clever of them, even though it's not to my benefit.
Re: KABOOM in 180 lines of bare C++
#43Earlier quoted context omitted.
You completely missed the point of why people like this..
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.
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.
Re: KABOOM in 180 lines of bare C++
#44Earlier quoted context omitted.
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.
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.
> 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.
Re: KABOOM in 180 lines of bare C++
#45I would learn language C C+ and C++ who can help me please
Re: KABOOM in 180 lines of bare C++
#46This 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...
Re: KABOOM in 180 lines of bare C++
#47Earlier quoted context omitted.
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.
> 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,…
The algorithm is applicable to video games. As you yourself point out it'd not be a lot of effort to rewrite. I suggest you read the very next paragraph, which ends:
> I do not pursue speed/optimization at all, my goal is to show the underlying principles.
...
> Just target Windows and use Direct3D, 99% of PC game developers do just that.
Misses the point of the series. From the introduction (linked at the top of the page):
> I do not want to show how to write applications for OpenGL. I want to show how OpenGL works. I am deeply convinced that it is impossible to write efficient applications using 3D libraries without understanding this.
The exact same could be said for Direct3D. He gives his students a class to read/write TGA images and set pixels for that article, which should make it exceedingly clear that the point is to ensure the focus is the algorithm and no irrelevant details to teach the principles without people being sidelined by worrying about libraries, and differences between platforms and the like.
And in any case, I explained to you what the appeal of this to people here is. That you think it could be done differently does not change that the appeal to people is exactly that there are no dependencies like Direct3D or Windows or anything else (I don't have Windows anywhere, so for me that would have made it relatively uninteresting; as it would for a lot of other people here). I don't care about the performance; I care about the concepts.
Re: KABOOM in 180 lines of bare C++
#48Nice. Does Visual Studio support the level or version of OpenMP used in this code? (see the pragma)
Yes it does, however you'd need to modify CMakeLists.txt, as it is written for g++
Re: KABOOM in 180 lines of bare C++
#49Earlier quoted context omitted.
> 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,…
The algorithm is applicable to video games. As you yourself point out it'd not be a lot of effort to rewrite. I suggest you read the very next paragraph, which ends: > I do not pursue speed/optimization at all, my goal is to show the underlying principles. ... > Just target Windows and use Direct3D, 99% of PC game developers do just that. Misses the point of the series. From the introduction (linked at the top of the…
> I am deeply convinced that it is impossible to write efficient applications using 3D libraries without understanding this.
What he explains is almost irrelevant for efficiency. Other things are relevant: early Z, tiled rendering, other things about architecture of GPUs: resource types, cache hierarchy, fixed-function pipeline steps, these warps, many others.
> I care about the concepts.
I've been programming C++ for living since 2000, about half of that time something relevant to 3D graphics, both games and CAD. You no longer need deep understanding of rasterizer. Vague understanding of what the hardware does, and how to control it, is enough already. Only people working in companies like nVidia or Chaos Group need that info, IMO.
Re: KABOOM in 180 lines of bare C++
#50Earlier quoted context omitted.
The image subdomain servers of Imgur, i.imgur.com, look at the referer of your request and will conditionally redirect you to the web app. Fortunately, if you send no referer it seems you get the image directly. This is easy to do with a browser setting.
> This is easy to do with a browser setting. On your desktop browser yes. On mobile devices not as easy. And even on desktop you might not want to globally disable sending referer because other sites might break. And even if you use a browser add-on to only block referers for i.imgur.com, most other people haven’t so everyone else is still being redirected.
> On your desktop browser yes. On mobile devices not as easy.
What's even worse, on mobile, imgur heavily downscales and compresses images. Which is fine for kitten photos, but completely destroys any of its utility for screenshots, as you can't read normal-sized text on the phone.