Question to all C/C++ programmers out there. Why are your variables so terse? I have no idea what td and dt mean and why they are both in the same function. I'm genuinely trying to read your code and have no idea what is happening because there is seemingly a desire by the author to keep variables as short as possible. Why?
The N64 had two things which made things smoother. It had sub-pixel precision for geometry after projection, and it had perspective-correct interpolation. This meant that moving objects looked smooth and didn’t “pop”. Games on the PS1 addressed the interpolation problem by subdividing, but you could sometimes see geometry suddenly move when you got closer and saw more subdivisions.
The N64 also had texture interpolation (kind of like bilinear) and antialiasing, but those don’t make as big an impact.
The N64 got all these things right, more or less, but had problems with memory bandwidth and small texture memory.
The Truth About PS1 Graphics
https://www.youtube.com/watch?v=ESXAxtdEkzY
Why PlayStation 1 Graphics Warped and Wobbled so much
Edit: It looks like all of your C is actually very well written. What a pleasure to read!
If anyone is interested in learning how graphics rendering works under the hood without too much scaffolding, there's a great course at https://pikuma.com/courses/learn-3d-computer-graphics-progra... (I'm no way associated with that website, just loved the course). That course starts from absolute basics: creating a colour buffer as in memory array and gradually covers lot of ground on 3D rendering: drawing pixels, lines, triangle fill rasterisation, texturing. The course uses minimal help: SDL is used for rendering on window and dynamic arrays are provided as a small C library. But everything else is coded from scratch in C by the instructor in the lecture, word by word.
Vertex coordinates were rounded to whole integers, giving that hallmark polygon jiggle effect from the rounding that 'snapped' them in place. The complete lack of a z-buffer also lead to lots of z fighting, as the system rendered polygons strictly in the order they were calculated.
I couldn't help noticing that it tests every pixel on the "screen" to see whether it's inside a face. Back in the software renderer days we'd run the inner loop just for the pixels that fell inside a triangle. But then you'd need to explicitly handle polygon clipping and it would greatly complicate the code. I guess 320*240 tests is nothing these days.
Anyway, great job!
For lot of us, our childhood was defined by this console. N64 as well but just something about the PS1 graphic that really speaks to me. Anybody else feel the same?
Interestingly enough the renderer was up and running. It was a lot more limited in triangle count than the PC version, hence a lot of fiddling with models.
In any case, the project fell apart for the usual disorganized management reasons.
Also, due to Stack Overflow conditioning: fgetc() does not return 'char', it returns 'int' else EOF won't fit.
Or more precisely: don't store the return value in a 'char' and check if it is EOF. On some platforms (e.g. gcc ARM eabi), regular 'char' is unsigned and the check fails.
https://www.nme.com/features/gaming-features/the-resurgence-...
https://old.reddit.com/r/ps1graphics/
There's also some people on YouTube doing PS1 and N64 style graphics.
How long before somebody includes your library and says they created PSX graphics in 25 lines?
And what about any of the operating system calls that might get used? It's also a library (despite the source code not being in the project).
The actual code to compute the logic of the graphics PS1 style, is indeed around 500 lines.
