It turns out my complicated plan was just that: complicated. Although there
are currently some bugs, the method I used to build the VBO in the first
place will work equally well for building the index lists.
Just some problems with lightmaps. There also seem to be some issues with
seams (t-junctions?) and far clip, but they're quite separate.
There's also a problem with a segfault when loading a second map.
The entire vertex set from every model is put into one list (not yet
uploaded). chains of elements arrays are build for non-instanced models
(instanced models will have their chains built each frame).
Still nothing being rendered: still in the process of building the display
lists, but I'm making good progress. Get this into git before something
goes wrong :)
Yay, Deek for finding another bug in qf :). He had an old dirconf that
didn't specify HudType and thus caused the status bar code to blow up. Set
the default to "id" if none is found.
Yay, Deek for finding another bug in qf :). He had an old dirconf that
didn't specify HudType and thus caused the status bar code to blow up. Set
the default to "id" if none is found.
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.
Calling programs shaders was a little confusing when I use shader to refer
to the sub-programs (vertex and fragment shaders). Also, print the program
number as well.
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).
textbox, crosshair, tileclear, fill and fadescreen are the remaining
functions.
There's a problem with 2d icons being drawn over the text (instead of
under), but I'll leave that for later.
Add GLSL directory to QF and use it for all gsls based code (instead of
GL). defines.h, types.h and funcs.h are derived from gl2.h from khronos.
Text drawing now uses triangles instead of quads.
This means that nq-glslx can get through demo1, demo2, demo3 and bigass1
without crashing. However, nothing is rendered, so unless you like black,
it's not very interesting.
The links are now in "instance surfaces". For non-instanced models (world,
doors, plats etc (ie, world and its sub-models)), there will be one
instance surface per model surface. However, for instanced models (ammo
boxes etc), there will be many, dynamically allocated (not yet
implemented). This commit gets the static instance surfaces working.
This has several benifits:
o The silly issue with alias model pitches being backwards is kept out
of the renderer (it's a quakec thing: entites do their pitch
backwards, but originally, only alias models were rotated. Hipnotic
did brush entity rotations in the correct direction).
o Angle to frame vector conversions are done only when the entity's
angles vector changes, rather than every frame. This avoids a lot of
unnecessary trig function calls.
o Once transformed, an entity's frame vectors are always available.
However, the vectors are left handed rather than right handed (ie,
forward/left/up instead of forward/right/up): just a matter of
watching the sign. This avoids even more trig calls (flag models in
qw).
o This paves the way for merging brush entity surface rendering with the
world model surface rendering (the actual goal of this patch).
o This also paves the way for using quaternions to represent entity
orientation, as that would be a protocol change.
The error was quite valid: setting GL_TEXTURE_MAX_ANISOTROPY_EXT to 0 is
incorrect. The problem was caused by the call to glTexParameterf being
before the gl_anisotropy cvar was initialized. Thus, move all of the setup
code in GL_Init_Common() to after all the checks and, more importantly,
after the call to GL_Common_Init_Cvars().
It turns out that due to the way we do fullbrights, nothing special needs
to be done to get the fullbright texture blended with the model even when
fog is enabled.
There are some problems with menus and the console messing up the key_dest
state (they assume console/menu or game, nothing else), but otherwise
things seem to work.
in_bind_imt is now gone. I guess mercury was right in that it was a poor
design. However, it was (and still is necessary) to support "bind" and
"unbind". Now, instead, they work only with the IMT_MOD table. IMT_MOD sits
below IMT_0 in the imt hierarchy. If the key is not bound in IMT_0+, then
IMT_MOD will be checked. This way, "bind" and "unbind" can never mess with
a user's more sophisticated binding setup.
The backquote is not always usable for toggling the console, and the new
bind system doesn't automatically bind a key to both game and console imts
(by design). Thus create a cvar that allows the "always works" console
toggle to be specified in eg $fs_globalcfg. While I'm at it, do one for the
menus, too.
If the default sound device does not support mmap access, retry with
plughw. However, assume the user knows best and do not retry if snd_device
has been set to anything, including "default".
QF alsa support now works out of the box with pulseaudio.
Due to quake's original sound engine using a push model, the actual place
to which the sound data should be written is not necessarily where the
"hardware" dma cursor is, but rather where the last write finished off.
Thus, the correct output location is indicated by snd_paintedtime rather
than snd_shm->framepos.
I've had enough of this for the moment, but I'm pretty sure the test needs
some more consideration, and I'll probably forget about it if I don't mark
it.
I found wolfram's line-line intersection page and noticed their equation
for the time of intersection was rather different to mine. After analyzing
the differences, it turns out they produce exactly the same results (when
the lines are coplanar), but their method allows me to eliminate one dot
product (4->3). Not only that, but it turns out that their method works
equally well for skew lines (ie, non-coplanar).
mine:
CxA.CxA
-------
CxA.AxB
theirs:
CxA.AxB
-------
AxB.AxB
While unit normals aren't needed, they were too big for sane math. Now
epsilon can be used for the distance tests. One of the two new tests passes
now :).
When the trace stradles a plane in the current leaf, check the other side
of the portal, too, as it is possible that leaf will restrict the movement
of the trace.
All current tests pass! However, I can think of some situations (and I
already have a solution) where things will fail, but that's next.
It turns out that the box trace CAN get out of the solid from that location
(though a similar point trace can not). This is because of my decision to
allow non-points to touch a plane from either side without crossing the
plane, whereas a point touching a plane is always considered to be on the
front side of the plane as there is no further information to disambiguate
on which side of the plane the point is.
The trace is moved as far into the leaf as possible without leaving the
other side of the leaf. This ensures that trace_contents is started from a
good location. There is currently a problem with traces that stradle a
plane getting, but this has cleared up all the current contents related
tests.
When visiting a leaf in box mode, use trace_contents() to get the highest
priority contents of any leafs touched by the box in the current location.
I'm now down to one failing test case, and it's an "allsolid" issue that
might be an incorrect assumption in my test case.
