After getting in contact with serplord, I now know that the sw alias
loading was correct. Turns out the gl loaders was mostly correct, just a
mistaken subtract rather than add. And with that, I can implement alias-16
support in glsl. better yet, since all the work is done in the loader, the
renderer doesn't know anything about it :) However, I need to create some
16-bit models for testing.
Not all hardware can access a texture sampler from the vertex shader, and I
don't want multiple paths this early in the game. Now, vertex normals are
uploaded as shorts. Should be 14 bytes per vertex (was 10, could have been
8 if I had put the normal index with the vertex rather than st).
This uses the same calculations as the software renderer. However, as the
lightmap calculations are not done yet, if there is no dlight in the
vicinity, there will be no light. demo1 is pretty cool to watch :)
While the first frame was fine, any subsequent ones were not. I had
forgotten that hdr->poseverts held the edited vertex count rather than
hdr->mdl.numverts.
GL Quake was weird, culling front faces. Partly understandable, since
Quake's front order is clockwise and GL's default order is
counter-clockwise. However, since the order can be specified, that should
be done instead. Thus, specify the winding order as clockwise (for quake's
data), set culling for back-face removal, and then mess with the winding
direction in the mirror and fish-eye code.
Vertex locations need to be unsigned byte rather than byte (GL is funy
with that). s and t need to be at least short, and since the normal index
is embedded in the st vector, it needs to be the same type. With this, my
test tetrahedrons seem to be working.
The plan is to do interpolated sprites based on a discussion I had with
LordHavoc about them: blending between the two sprite frames. He didn't
mention it, but it looks like blending between the sprite frames' verts is
necessary too.
Since I'm not specifying the api when creating my context, mesa is giving
me GL2. This is fair enough, but in GL2, vertex attribute 0 is the vertex
position. This too, is fair enough. The problem is, mesa is assigning 0 to
my vcolor attribute and thus I can't set it. The work around is simply to
swap the declaration order of vcolor and vertex (this really shouldn't work
eiter, I suspect).