61–70 of 73 posts
Ray Tracing in a Weekend Series. Most the way through the first book and I plan on continuing it. [1][2][3]
Tiny Renderer - How OpenGL Works. A software renderer in 500 lines of code. Wiki has a full tutorial. [4]
The Book of Shaders. A step by step introduction into fragment shaders. [5]
[1] https://www.amazon.com/_/dp/B01B5AODD8
[2] https://www.amazon.com/_/dp/B01CO7PQ8C
[3] https://www.amazon.com/_/dp/B01DN58P8C
Earlier quoted context omitted.
http://portal.aauj.edu/portal_resources/downloads/programmin...
Seems to be the same author, but an earlier book?
Earlier quoted context omitted.
Fixed point is a good approach for line drawing but doing a sqrt for circles with integer arithmetics does not work really that well even if you don't know how to convert floats to ints fast (like author of the article you linked :)).
This one shows the branchy and branchless variations of bresenham being nearly equal in speed, within 5% on the older 32 bit CPU, with the branchy old school way being 1% faster on a more recent 64 bit CPU. Both are significantly faster than the naive floating point version. That is in line with my experience that floating point can still be quite slow on the CPU; the advantage from using fixed point isn't necessaril…
If you have a "brancheless bresenham" then go for it, I've never heard of such a thing so I'd be curious to see that link. But from the description it sounds like a contradiction to the Bresenham's idea.
Earlier quoted context omitted.
This one shows the branchy and branchless variations of bresenham being nearly equal in speed, within 5% on the older 32 bit CPU, with the branchy old school way being 1% faster on a more recent 64 bit CPU. Both are significantly faster than the naive floating point version. That is in line with my experience that floating point can still be quite slow on the CPU; the advantage from using fixed point isn't necessaril…
Did you forget to add a link to your post or something? I repeat this for the final time: floating point can be quite slow but flow control is much slower. Also, fixed point square root is very slow compared to the FP one. If you have a "brancheless bresenham" then go for it, I've never heard of such a thing so I'd be curious to see that link. But from the description it sounds like a contradiction to the Bresenham's…
Earlier quoted context omitted.
Did you forget to add a link to your post or something? I repeat this for the final time: floating point can be quite slow but flow control is much slower. Also, fixed point square root is very slow compared to the FP one. If you have a "brancheless bresenham" then go for it, I've never heard of such a thing so I'd be curious to see that link. But from the description it sounds like a contradiction to the Bresenham's…
See userbinator's link for a little performance comparison of the naive floating point code vs. bresenham vs. fixed point.
Maybe I missed it, but I didn't see any discussion of the Bresenham family of algorithms. I realize this is always done for you nowadays, but if you're really teaching pixels from scratch, it seems like drawing lines and circles from raw pixels needs to be covered.
Sadly if you're actually implementing Bresenham's algorithm today you're doing something very wrong (or don't care about performance). Drawing lines and shapes is all a matter of pumping the desired geometry and shaders into your GPU today and letting it take care of the rasterization--running Bresenham's algorithm on your CPU will be many orders of magnitude slower.
Earlier quoted context omitted.
Ignoring matrix transformations is easy, as long as the eye point is at the origin. Then yes, the algebra is almost trivial: projection is just divide-by-z. But the moment you move the camera, or stretch and turn objects, or worry about clipping, you need the full machinery that matrices provide. They're not that mysterious. I wish they were taught in high school, because they would motivate kids to learn graphics an…
> I wish they were taught in high school, because they would motivate kids to learn graphics and programming. Learned Linear Algebra (matrix calculations and some analytical geometry) + Calculus in eleventh grade, around 1995. I think it was the standard curriculum in all Eastern Europe and the countries from the ex Soviet Union.
Earlier quoted context omitted.
We learned basic vector arithmetic back in highschool doing our own gamedev stuff, and it's pretty straightforward. The use of matrices as "mapping" one space to another likewise so. Any approach that ignores the relevant parts of linear algebra, though, is probably going to collapse under its own weight as things get more complicated--experiencing that collapse may be interesting from a learning perspective, but I s…
This. You went to the right high school. Matrices and vectors are just a subset of linear algebra, and can definitely be taught to teenagers. When I teach graphics to 3rd-year college undergraduates, I tell them "this is what all that point-and-vector stuff you learnt in high school was really meant for". They've usually forgotten it all, but it comes back to them quickly, and the matrix stuff on top of that isn't ve…
Earlier quoted context omitted.
> I wish they were taught in high school, because they would motivate kids to learn graphics and programming. Learned Linear Algebra (matrix calculations and some analytical geometry) + Calculus in eleventh grade, around 1995. I think it was the standard curriculum in all Eastern Europe and the countries from the ex Soviet Union.
I learned some degree of linear algebra sometime during high school (in optional math classes that a lot of my schoolmates never reached), but mostly as a set of rote-learned operations without a connection to anything useful. As a consequence, I ended up re-learning a lot of it in university, and then catching up on it again on my own while learning about 3D graphics. (American, in high school during early 00's)
Earlier quoted context omitted.
What you are wanting is this book: "Tricks of the 3D Game Programming Gurus" by Andre LaMothe. The book teaches you how to write a 3D software rasterizer from first principles. The first part of the book is nothing but a well written linear algebra primer. The book then assumes you have nothing but a C++ compiler and a pointer to the frame buffer like you might get using SDL. Unfortunately the book appears to be out…
Thanks for the recommendation, I'll see if I can find a copy somewhere. But I think the 12-yo-me wouldn't have bought a book and certainly wouldn't have appreciated one that starts with a linear algebra primer (no matter how well written). Really, what I would've needed back then would've been a relatively short tutorial somewhere online, preferrably one that doesn't require me to start with linear algebra. Just the…
Linear algebra was the new and easy part. You don't need matrix inversions, eigenvectors or triangular decompositions or any of the complex Linear Algebra stuff. It's just vector math. And you probably already know arrays. It's merely a notational convenience when you recognize that you're doing the exact same operations on three x,y,z-variables all the time.
When I saw it first as a teenager I was like "hey that's clever, lots less to write!" (when working out formulas on pen and paper, not having to write everything thrice, yay!).