Why Refactor? Let’s Refactor the 3D Polygon Renderer. [c++20]
42,351
Published 2020-05-02
Become a member: youtube.com/Bisqwit/join
My links:
Twitter: twitter.com/RealBisqwit
Liberapay: liberapay.com/Bisqwit
Steady: steadyhq.com/en/bisqwit
Patreon: patreon.com/Bisqwit (Other options at bisqwit.iki.fi/donate.html)
Twitch: twitch.tv/RealBisqwit
Homepage: iki.fi/bisqwit/
You can contribute subtitles: youtube.com/timedtext_video?ref=share&v=GnKh8Eb1zU…
Downloads:
bisqwit.iki.fi/jkp/polytut/
Music list (s = SPC-OPL conversion):
— Famicom Tantei Club 2 — Interviews (s)
— Final Fantasy Mystic Quest — Shrine (s)
All Comments (21)
-
As always, the source code is available here: iki.fi/bisqwit/jkp/polytut/ 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.
-
Eventually you won't have technical debt, but rather debtnical tech.
-
Not sure if it was mentioned in the video but the book “Refactoring: Improving the Design of Existing Code” has a solid definition of refactoring — what it is, why it’s beneficial and what’s good design as the aim of refactoring. Another important (and perhaps more approachable) book is “The Pragmatic Programmer” (20th Anniversary Edition) which also handles refactoring as part of more general discussion on design and programming as a craft. Both books are highly recommended.
-
First
-
The only time that manager understands what Tech Debt is, is when they hire someone and that someone quits after spending one week looking at the codebase. When that happens, it's too late and the product fails.
-
Modern C++ template programming is hideous and hard IMO. Hats off to you.
-
Doing work < refactoring the code I swear I refactor it more that I code up new one...
-
It's funny. Everything you're doing right now is by and large the opposite of what I aim for when writing this kind of code. You've made the functionality increasingly generic and capable of more and more things in a small number of functions, where generally I would aim to break up anything complex into smaller and smaller chunks that do the simplest possible things that it's reasonable to do. Compare and contrast: Function that can render arbitrary convex polygons. vs. Function that splits an arbitrary convex polygon into triangles. Function that splits a triangle into flat top and flat bottom sections. Function that can draw flat top or flat bottom polygons. Ultimately I suppose this comes down to intention. I learnt coding in an era and context where performance was at such a premium (and compilers were not always that great) that you do anything you can to ensure that the code is fast, and this includes things which force more assumptions onto the programmer. If a particular vertex ordering improves performance, the code would demand the use of that format, and so on. To a certain extent this is a tradeoff, but again, it depends on your goals. 'clean' code is often written under the assumption that performance is free, or that computer performance improves quickly enough that you can justify the slower but more elegant code because it'll be fine in future, over the messier but faster code. Sometimes you can get both, but at some point, frequently you have to pick one. And you might say writing 'correct' code is better, but with that attitude we never would have had realtime 3d in the 90's... And you could also ask yourself why something like Microsoft office now uses 1000 times as much memory to do mostly the same tasks it used to do with considerably less memory... Part of it is just because absent those harsh hardware constraints, people are free to do bad things (from a performance perspective) if it makes the code easier to understand, faster to write, or so on... Optimisation is a tricky subject though. There are many ways to approach optimisation, and it's usually not wise to optimise too soon. (though of course, creating things which make optimisation more difficult is not helpful if you know performance is going to be a major consideration in the future.) One of the obvious problems with optimising too early is that you may waste a lot of time using really aggressive optimisation on stuff that doesn't need it because it hardly ever runs...
-
it's really nice that you've explained about readability and maintainability of the codes, separate them into multiple header files, and using less dependencies while ensuring that it can be platform independent
-
Selamat pagi, Tuan. Good morning, Sir.
-
When I watch your videos I feel so dump xD
-
Much love for this series <3
-
I am watching the video alone at 4 in the morning, and that demon voice at 4:06 scared the shit out of me.
-
"In that sit st ss the lt s tht thss tht si" 12:42
-
Thanks to Bisqwit, I'll always wonder if my coach driver is secretly a software engineering genius.
-
Nothing else on the internet releases as much dopamine as a new bisqwit video notification.
-
Great stuff, looking forward to upcoming videos!
-
The intro surprised me 😂
-
Awesome content as usual 👏 Would be very insightful to share how you think of design patterns before/during developing a project
-
Yay new video!