
N64 object software renderer in 512 lines - _cwolf
https://github.com/yellingintothefan/gel
======
devwastaken
On the note of N64, N64 emulation, especially its GPU portions, are still
incredibly hard to get right and has been fraught with problems for a long
time. On modern systems the performance still can be less than desirable. One
of the saving graces to this has been GlideN64,
[https://github.com/gonetz/GLideN64/releases](https://github.com/gonetz/GLideN64/releases)

But even that is still in a lot of development. There's a lot of magic the N64
hardware uses apparently.

~~~
digi_owl
Reading up on the N64 hardware a bit gives the impression that it was ahead of
its time, more akin to the shader based pipelines of today than the kinds of
hardware that was starting to show up on PCs at the time.

[https://en.wikipedia.org/wiki/Reality_Coprocessor](https://en.wikipedia.org/wiki/Reality_Coprocessor)

~~~
jchw
This is the impression that most people end up with, but it's not really like
shaders at all. My understanding is limited, but it seems the microcode serves
a somewhat limited role in the graphics pipeline, something along the lines of
decoding data and controlling hardware registers.

~~~
monocasa
In most contexts, the RSP handles all T&L, making it analogous to modern
vertex shaders.

~~~
pandaman
This was pretty standard at the time - everything had a programmable DMA
controller, which was capable of extensive data transforms, and often there
had been some vector ALU stuffed in. The difference with modern arcs is that
it was sitting in front of fixed function hardware. After you did whatever you
wanted with the data it still went into the fixed function hardware and came
out as pixels on the screen. You could have the same data pre-computed and fed
to the GPU for the same result.

In modern architecture, there are programmable ALUs _inside_ the fixed
function hardware and its fixed functions are very limited, it's just triangle
setup and color/depth buffer, usually. The GPU input is just a list of
indices, which is transformed by the programmable processors inside.

------
Hydraulix989
Looks like it is just using OBJ files (nothing specific to N64 data formats at
all).

~~~
sehugg
From what I can gather N64 uses a binarized OpenGL display list format for
models: [http://ultra64.ca/files/documentation/online-
manuals/man-v5-...](http://ultra64.ca/files/documentation/online-
manuals/man-v5-1/pro-man/pro04/04-05.htm)

But I'd bet most titles had their own formats to support vertex deformation
and animation. (Anybody know any details?)

It looks like it'd be pretty fun to program the N64 GPU, with its "high-
quality, Silicon Graphics style pixels" :)
[https://level42.ca/projects/ultra64/Documentation/man/pro-
ma...](https://level42.ca/projects/ultra64/Documentation/man/pro-
man/pro12/index.html)

~~~
Jasper_
Most titles use one of the standard Nintendo-provided microcodes for the RSP
(Reality Signal Processor, the programmable part of the graphics chip).

F3DEX2 ("Fast 3D, Extended, Version 2") is one of the well-documented ones and
one of the ones used by most games. You can find a breakdown of the command
stream here:
[https://wiki.cloudmodding.com/oot/F3DZEX](https://wiki.cloudmodding.com/oot/F3DZEX)

This viewer is actually an .obj model viewer, and has nothing to do with that.
For something that's actually an F3DEX viewer online, I wrote
[https://magcius.github.io/model-
viewer/#zelview/data/zelview...](https://magcius.github.io/model-
viewer/#zelview/data/zelview/HAKAdan_scene.zelview0)

------
westoque
I never understood the importance of lines of code for projects such as this
one.

Couldn't you technically just concatenate everything into 1 line and call in
"X software in 1 line of code"?

Isn't it a better benchmark to have better code structure even if the project
is composed of more lines of code or more files for that matter.

~~~
oxide
Yes.

That said, it's novelty and working within set restrictions that makes it
impressive.

Not the line count of the code, but the fact that it works within the set
restrictions of making an n64 software renderer (novelty) with that line count
of code. (also a novelty)

It's not important at all, it's novel. We have had hacky, and even gimped for
quick hacks n64 emulation (compare Project 64 to say, Dolphin) since the late
90's-early 00's, but we haven't had a 512 line object software renderer. A
novelty for those who like novel programming exercises!

~~~
westoque
I completely agree. You make a good point! It's definitely a novely.

In my programs, I never took lines of code as a restriction. Since if you have
a compiled program, the binary size tends to depend mostly on the compiler.
I'm more focused on other restrictions, such as memory usage, etc.

------
jcoffland
This is very well written code. There are not a lot of comments yet it's
designed in a way that it is still quite readable. I believe this is due to
good partitioning of concerns, which also leads to an economy of code. It goes
without saying, perfect formatting is a must.

"Elegance is not optional.

There is no tension between writing a beautiful program and writing an
efficient program. If your code is ugly, the chances are that you either don’t
understand your problem or you don’t understand your programming language, and
in neither case does your code stand much chance of being efficient. In order
to ensure that your program is efficient, you need to know what it is doing,
and if your code is ugly, you will find it hard to analyse.” -- Richard
O’Keefe, The Craft of Prolog (MIT Press)

~~~
ci5er
Some problem spaces have boundaries and exceptions. These can be somewhat
ameliorated by better representations ... but sometimes (e.g. device driver
apis, or context switching code that works on multiple processor families, or
(heaven forfend) business logic) ugly is ugly and you can't do much about it.
It can't all be elegant global illumination solutions...

~~~
jcoffland
All code can be elegant if the language allows it.

------
twerkguru
Has nothing to do with N64. It's just basic software renderer and a .obj/.bmp
loader. I made one of these when I was 12 after reading "The black art of 3d
game programming" which was designed for dos games.

------
ethagnawl
As someone who knows nothing about graphics programming, I'd be interested in
seeing a walkthrough or "literate" version of main.c.

~~~
g00gler
Same here. It’d also be great if the variables were a bit easier to interpret.

~~~
_cwolf
I'll see what I can do.

~~~
rocky1138
Is there any reason why most of these 3d engines use one-letter variable
names?

~~~
ramses0
Because 'x' is easier to type than
"getHorizontalScreenSpacePixelPositionRelativeToBottomLeftCorner()" ?

~~~
jjjensen90
While true, you end up reading code with your variables more often than you
write your variables so I tend to optimize for readability over ease of
typing.

~~~
dagss
In a setting with much arithmetic "x" is also vastly easier to read. See
pretty much any mathematics or physics paper or textbook -- made for
reading...

------
jcalabro
Why are they called "scrots"?

~~~
grzm
_SCR_ een sh _OT_

~~~
colanderman
That's a really unfortunate abbreviation. That word is also common slang for
male anatomy in the States.

~~~
dzmien
'scrot' is the name of a popular linux screenshot utility. I have never heard
of anyone using it in any other context. Well, until now anyway :P

------
amelius
(deleted)

~~~
paraboul
And this is the case

------
luminarious
How many lines of WebGL would it be?

~~~
khedoros1
How many lines does it take you to build a pixel buffer in WebGL? SDL2 here is
being used to handle input, open a window, and update a texture stretched over
the full window using a software-rendered buffer of pixel data.

