Texture Mapping & Polygon Rasterizing Tutorial (1/2) [C++20]

The editor used in this video is Joe, and it is being run in That Terminal. DOSBox was not used, neither was That Editor. The compiler used is GCC 10.0.1, and run in Debian GNU/Linux. The source code is now up at bisqwit.iki.fi/jkp/polytut/ . You will need GCC 10, but with small changes it can be compiled with as early as GCC 7. ERRATA: The compile-time for-loop is not C++11, but C++20. It depends on fold expressions (c++17), std::index_sequence (c++14), and lambda templates (c++20). A reminder: Do not reply to this post if you want me to see your comment. Post your words as a new comment, not as a reply, unless you are addressing the contents of this comment specifically. YouTube does not show creators new replies, it only shows new comments. If you reply here I will not see it unless I manually check for it. If you are addressing a comment someone wrote, then you should reply it, though.

20 years of knowledge condensed into 20 minutes of video.

I really appreciate that you are up-to-date with current C++.

Bisqwit made me rethink my entire life in two minutes when he said circles do not exist and are merely cylinders.

when you think you know a bit of c++ comes this guy and teach you 20 new things that completly blow your mind

The way you reduced the interpolation formula down to a constant increment is just genius.

14:41 my heart literally stopped beating for those 3 seconds

“Ultramarine blue”, 10/10

21:07 - "Note: A comma is not permitted here. It is a curious inconsistency, but the actual reason is: What I explained previously was a fold expression, while this is a pack expansion. These are two different features with slightly different rules. C++ is great, but it is not perfect..." What's also not perfect is when communities gloss over the strange syntax and kludges in modern languages, hoping not to scare away newcomers. This usually just causes novices to tear their hair out in frustration when they DO encounter such strangeness. I wish I had known at the start of my career that almost all language features are not the "right" way of doing things, but just clever hacks to force compilers to do things they were never designed to do, using a minimum of syntax changes and code rewrites. A forewarning (and apology) every now and then is a good thing. Thank goodness I don't do web development anymore. Modern Javascript makes my eyes bleed.

I remember making a 3d software rasterizer a good while ago. I found the projection matrix to be the hardest part to figure out. Can't wait to see your solution.

This brings back lots of late night memories writing my own software engines. Except it was usually in C and inline assembly. No one talks about this stuff anymore since 3d hardware took over. I look forward to the rest of this series.

Man, I can't tell you how much I love these kinds of videos. I have tried to make a basic 3D engine just for fun, but could never figure it out, so I love stuff like this. Please make more of them. You have knowledge many of us don't.

Bisquit explained 10 books and my entire course of computer graphics with that intro and I understood better thia video than the other ones I mentioned. Thank you so much! Please take your time for explaining some SDL functions!

18:29 Years later and this still my go-to source for compile-time for loop. I still remember 2 years ago when it was all just symbols to me :D

Great to see a new series start. I'm excited for part 2.

That surely looks interesting! Looking forward to seeing more.

Great video. Thanks for the idea of the compiletime for loop. Good work and kinda easy to follow.

Just skipping drawing eg. the rightmost pixels of the triangle is an easy way to avoid overlapping pixels of adjacent triangles. However, it doesn't give the nicest result for the right edge of the triangle when there's no adjacent triangle drawn there (eg. this is the visible right edge of an object). There's like an entire line of pixels missing there. In many cases (and with very high resolutions) it might not matter visually at all. In other cases it might (especially with certain textures with thin edge colors). The more "correct" way of deciding which edge pixels to draw is to see if the center of the pixel is inside the mathematical triangle or not (which can be done with a dot product). This is slightly more complicated and requires a few more operations (some multiplications and additions), but in principle gives a nicer result. Of course in this case there's still the problem of what happens if the pixel is exactly on the edge of the mathematical triangle (which may well happen). In this case we need to decide whether to draw it or not, and change this decision for the other adjacent triangle. In this case we can use your simpler method: If it's on the right or the bottom, we don't draw it, else we do. But yeah, with a simpler renderer where it isn't crucial to draw triangles to the very edge, the simpler approach is viable. (I do not know what GPUs do, but I have the understanding that they use the better method I described.)

I loved the "inefficient way" section of the video haha. I was doing the same thing when I was learning to program a software renderer until I heard about scanline rendering. Then everything was so much easier hehe.

As someone who knew most of the things in this video already and has developed simple rendering engines himself, I still very much enjoyed your video. This would've been tremendously helpful back when I first learned all of this, and still today it is a very nice presentation of the core aspects of computer graphics. Also, I like the way you casually use C++20 in your projects, few people really do that.