Took an active break with the challenges but happily watched this last year. Pretty cool what's happening in this space on the site and curious now about the challenge fork that has recently appeared. Lots of good things happening on gamedev.net - hope to meet more new people that share the same interest. Alas, I'm in the hobby group which tends to hop me around from technology to technology. This last weekend (and into today) was nice. Minor distractions, work is done, already queued up the next major project to take it to the end of 2019 with dignity. All set, life is good. So I sit down to the youTube and catch up with the who is who and how badly are they doing it. You know...you've been around a while, you recognize what smells right off the .bat
Now, I'm not much for wordy blog entries but this must be told. Oh jeebers yes, this was a good smell. So sweet.
A toy 3D triangle renderer in software presented in a 4 part series.
The code built is directed to the console but there is available an alternative hardware screen blit approach with the olcPixelGameEngine starter files making it an almost 1:1 follow along. The results are great and really punch home what is going on behind the scenes on our graphics hardware. Point transformations (object space through to screen space), screen clipping of triangles, perspective texture correction at triangle rasterisation. A build up of a 3D environment from his pixel engine. I'm only to part 3 but really happy with the reinforced learning so far. My experience will be different because I refused to take the simple math by function call approach and simply overloaded operators within a couple structs as we went along. The code base is small enough to grasp the majority at once with enough speed to do some interesting future experiments.
So here we are, new software technology in our hands. Is it punchy enough to take the role of gamedev challenge framework?
it's got a real good shot (screen shot on an old i5 cpu / intel 9300 intergrated graphics)
Video Clip
I like it because it takes me back to the old days of a wolfstien like raycaster clone we were learning AI with but this is way faster. It's nice because it's so pure and not bound to a particular target machine. A start code base that can be shared between different os user types. Nothing being done behind your back, it's right there with a couple sprinkles of "actually, yes you can do it", see right here...
Thanks for breezing by.
MarkK.
Making a software triangle renderer is something I intend to have a go at too (I've already done some primitive raytracing and that is well worth doing if you haven't already), there are some great tutorials out there, some links I have already bookmarked:
https://github.com/ssloy/tinyrenderer/wiki
https://fgiesen.wordpress.com/2011/07/06/a-trip-through-the-graphics-pipeline-2011-part-6/
There's also the issue of how to have fast shaders, you could have a fixed pipeline, or I recently tried a Mesa OpenGL software implementation that I believe used LLVM to compile the shaders to fast CPU code.
I believe there are actually quite a few real world use cases where a software renderer can be useful as a side path in otherwise hardware rendered games, because you avoid the whole round trip to the GPU and can query within the same frame, and the bottlenecks are different.