31–40 of 47 posts
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?
Have PS1 triangular graphics made a retro resurgence yet? Because I'm so down for that.
Also, due to Stack Overflow conditioning: fgetc() does not return 'char', it returns 'int' else EOF won't fit.
Very cool and nostalgic! Had no idea the PS1 look was trending. 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.
I was wondering how this was done in 500 lines...then I saw the 5000+ line library file borrowed from another project. I do enjoy the look of your results though. 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.
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.
heh, I wrote an N64 one not too long ago with the exact same style: https://github.com/glouw/gel
I was wondering how this was done in 500 lines...then I saw the 5000+ line library file borrowed from another project. I do enjoy the look of your results though. How long before somebody includes your library and says they created PSX graphics in 25 lines?
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!