Small nitpick though, there seems to be an issue with the source code views, the file names and the first line of the code are on the same line with no spacing. looks like it might be a static site generation issue since there aren't any nodes to separate the name and the code in the raw html.
Edit: turns out the issue I'm seeing is somehow due to Firefox, seems to work correctly in edge.
But in the version of the HTML that Firefox receives, all that is missing and the filename is just some text that ends up immediately in front of the first line of code.
[1] https://en.wikipedia.org/wiki/Bresenham%27s_line_algorithm
There are some pathological cases, like a thin long almost diagonal triangles. But those (rare) cases can be handled too by some subdivision clipping.
You have also less branches which helps a lot.
Doing a candidate loop over a bounding box with edge equations can be much faster than ye old scanline algorithm because it lends itself more easily to simd and parallel approches - you can divide things up into tiles and process multiple pixels at a time with wide instructions and schedule tiles on multiple threads.
For the time being one may consult Ryg's amazing blog series: https://fgiesen.wordpress.com/2013/02/10/optimizing-the-basi...
Easier to implement with proper fill conventions and multisampling, and much easier to parallelize in hardware and software.
* Hardware even back in the 90s used this type of approach :)
I came up with my own approach using bresenham and storing spans, but it was slow and sucked.
Then my buddy found fatmap2.txt on a BBS and gave it to me, as I didn't have a modem at the time. It was a revelation.
Programming in Turbo Pascal I was hampered by it being 16bit, but discovered I could prepend the assembly opcodes with 66h to turn them into 32bit instructions.
Later I tried converting the code to C, being only 300 lines and at that point well understood I figured it was a good task to get started with C. I was self-taught at programming but had read enough C to feel confident enough to try.
Converted it all line by line to C before compiling... and got literally over 3000 errors and warnings, and none of them made any sense.
Discouraged I left it, but a week later I was determined to get it working. After a few hours staring and bashing my head against the wall, I saw that the constant for the texture width which I had converted to a #define in C, had a semi-colon at the end...
So I removed it, and voila it complied flawlessly...
Only later did I realize my C compiler, djgpp, was actually a C++ compiler and that's probably why I got so many seemingly weird errors.
Anyway, good times...
[1]: https://github.com/rcoscali/ftke/blob/master/ogles/doc/fatma...
Took a quick look at fatmap2 and surprisingly it doesn't do perspective-correct texture mapping (although it points to some other document in the introduction).
This one[1], code being here[2]?
> surprisingly it doesn't do perspective-correct texture mapping
Yeah it was covered in some other document, can't recall which. I have some memory of fatmap3, but I can't find any references to it, and any files I had were on my IBM Deathstar[3]...
[1]: https://www.gamers.org/dEngine/rsc/
[2]: https://www.gamers.org/dEngine/rsc/3dgpl/code/
[3]: https://en.wikipedia.org/wiki/Deskstar#IBM_Deskstar_75GXP_fa...
Edit: it was actually possible at the time.
This worked well enough if the triangle was seen fairly straight on and was not too large.
Quake popularized the per-8 pixels technique, which is close enough in most cases.
Later, somebody gave me the source code for some graphics libraries together with some drivers and I could use 800x600 resolution with millions of colors.
After that I went to Windows and Linux and graphics APIs quit being an issue.
Filling the triangle and spinning the cube are the perfect level of difficulty if you want to get your hands a bit dirty and achieve that sense of accomplishment. Anything beyond this starts to feel like a very risky time-reward tradeoff.
It's based on ranges (similiar to the ones added to C++) and the concept works very well imo. Could be a good exercise to translate it to C++23 (using coroutines with the range "generator").
Yes, but it won't necessarily register so unless we're talking about insanely bright distant object that should be visible through fog from any distance and which also is not a part of the skybox, this particular problem practically never arises. The flat far plane, on the other hand, is glaringly obvious in e.g. Minecraft, or any Unity game with first-person view and fog.
Now, I've googled a bit on my own, trying all kinds of search phraes, and apparently it is a known problem that the perspective projection, when wide (about 75 degrees and up) FOV is used, will distort objects at the side of the screen. One of the solutions appears to be a post-processing pass called "Panini Projection" which undoes that damage at the sides of the screen. From what I understand, it uses cylinder (but not a sphere) as the projection surface instead of a plane.
The issue you are describing now is called perspective distortion (https://en.wikipedia.org/wiki/Perspective_distortion), and it is something that also happens with physical cameras when using a wide-angle lens. There is no single correct answer for dealing with this: similarly to the situation with map projections, every projection is a compromise between different types of distortion.
Anyway, if you're writing a ray tracer it's possible to use whatever projection you want, but if you're using the rasterizer in the GPU you're stuck with rectilinear projection and any alternate projection has to be approximated some other way (such as via post-processing, like you mention).
2. clipping is a GPU fixed function done on x,y,z axes separately, so it will always be a planar cut
3. the effect you're talking about can be entirely removed by setting the frustum's near plane to fit within your collision hull, e.g. for a spherical collider
function near_plane_meters(collider_radius_meters, width_px, height_px, focal_length_px)
return collider_radius_meters * focal_length_px / sqrt(0.25*width_px*width_px + 0.25*height_px*height_px + focal_length_px*focal_length_px)
endOffering this as constructive criticism - the tutorials could be more engaging if the student could follow along and cause things to happen directly on the screen. It'd be awesome to organize the 1st unit as more than just confirming one has a compiler, to take it all the way to a kind of "hello, pixels".
[1] https://pikuma.com/courses/learn-3d-computer-graphics-progra...
https://github.com/toolslive/NFJE
You used to be able to run it in a browser until they kicked Java out.