Compatibility Benchmark Mods

[Spike]

what's wrong with just calling D_DrawZSpans after drawing your skybox, like the software renderer does for regular sky/walls/etc?

by the way, the amd64 instruction set should have enough registers to draw both colour+depth in one pass, if you enjoy asm nightmares...

[mankrip]

[Spike]

I'm not sure that I understand.
which clipping algorithm do you refer to? the software renderer clipping polys to the screen/each other to avoid overdraw, or the opengl-esque workaround for the lack of fragment programs/cubemaps? if the former then you've completely lost me, if the latter then WHY?!?!?

as I see it, its just a single cubemap lookup. these things are fully opaque, there's no need to use additional passes (assuming that colour and depth writing are conceptually different aspects of the same pass).

presumably if you splice D_DrawSkyScans8 a little, you should be able to determine the s+t+face values for the start+end pixels for each span, and subdivide until they're the same skybox face, and then just sample from that face as you would any other texture (subdiv 16 or whatever for perspective correction). there's no scrolling textures/dual layer textures to contend with either. really all you need is the screenspace coords and the worldspace-eye coords, and the cubemap/2d texture array that you're sampling from.
zero overdraw (well, unless you have shamblers, anyway).

Ages ago, before I even started FTE, I had a software renderer that would simply not draw colour for skies (still drew depth). This meant that I could draw a skyroom, then the regular room, and you'd have a portal type thing you could see the skyroom through.
fun times.
q3 has 'RT_PORTALSURFACE' entities. if you had the same you could pvs+frustum check them in advance so that you'd know whether you need to generate that skyroom first or not.
If you want to get all fancy, you can clip (viewport or whatever) that skyroom to the portal's bounding box to avoid excessive overdraw. you can then figure out the viewmatrix required to transform the far side according to the viewing angle+relative position to the portal surface. you do tend to need to generate an extra frustum plane for the far-side scene in order to avoid weird geometry entering the near side.
and if you want to get even more fancy, you can draw that view to some texture, figure out the texture coords for the view and then reuse them any other times you see that portal through another portal.
the physics is a different matter, as you need some kind of csg subtraction for collisions, such that your view is allowed to actually cross the portal plane gracefully (FTE has solid_portal for this sort of thing, which provides both the csg thing and automatic teleports for engine physics when the central point of a trace crosses the plane).
*cough*
urr, yeah, skybox = simple cubemap. yup. that's all I have to say.

[mankrip]

The software renderer has two kinds of clipping: polygon clipping, and spans clipping.

Any overlapped spans are clipped by the renderer. No exceptions. I already figured out how to deal with the polygon clipping, but understanding the spans clipping is harder.
The planes, vertices, surfaces, edges, etc are completely ignored by the spans clipping algorithm. The code gets the chained list of spans and process it raw. Spansets have no data telling which surface they belong to, so I have to learn the whole process that generates them in order to figure out how and where to change their behavior.

Reverse engineering the regular sky spans from D_DrawSkyScans8 in order to project the skybox would work, but is not a clean solution. And it would be slower, because it would effectively split the polygons of the skybox into the polygons of the regular skies.

Q3A-style portals and render-to-texture effects are a possibility, indeed.

[mankrip]

Expanding my previous reply a bit:

Quake's software BSP renderer uses two kinds of polygon clipping, plus the spans clipping.

First, polygons are clipped against the frustum.

Second, intersected polygons are clipped using an algorithm that strongly resembles . This step mainly ensures that BSP entities' polygons don't intersect with the BSP world's polygons, and is the reason why software-rendered Quake engines have no BSP overdraw problems. (However, BSP entities' polygons are only clipped against the world, not against other BSP entities, which is why BSP entities can have Z-fighting against each other.)

Since the second clipping step ensures that no polygons are intersecting each other, there's no need for per-pixel Z-buffer check. This is why Carmack introduced the per-spans clipping. All the engine needs to do is to check the beginning and the end of each surface's spans against the beginning and the end of the nearer polygons' spans, and clip them accordingly.

The combination of both methods not only eliminates the need for Z-buffer reads, but it also almost eliminates the need for Z-buffer writes.
My guess is that at the time, the spans generated from MDL models' triangles were usually too small for those clipping algorithms to be more effective than Z-buffer checks in them (however, the lack of alpha masking support in MDL models suggests that Carmack may have considered using the clipping algorithms in them instead). And SPR models can't use those clipping algorithms because of their alpha-masked texels (i.e. sprite's spans can include more pixels than the ones that will be effectively drawn).
If someone were crazy enough to make a game using only BSP models (no MDL, no SPR, no particles, no alpha masked/blended surfaces), D_DrawZSpans could be eliminated completely. It would be really fast, and maybe really ugly.

[frag.machine]

[mankrip]

Maybe something with more elaborated assets, like a racing game in an empty urban city (with no people, no trees, and so on) or a shmup with simple ships. Anything that can be made with just a low amount of big polygons.

[qbism]

[mankrip]

[ericw]

Here's a good one.. Got an email saying that progs/bolt.mdl wasn't rendering in the Scourge Done Slick mod in the latest Quakespasm release.

I downloaded http://quake.speeddemosarchive.com/quak ... dSmega.zip and launched with "-hipnotic -game sdsmega"
Press '9', '1', '4' to play the "research facility" demo. About 30 seconds into the demo there are some shamblers attacking the player, you should see the lightning bolt model.

What seems to be happening is, "progs/bolt.mdl" isn't included in the list of model precaches in the svc_serverinfo that the client receives when playing back the demo. Quakespasm's new mdl renderer uploads all of the mdl precaches sent in svc_serverinfo into a VBO, and fails when asked to draw an mdl that wasn't precached. (this architecture and a good portion of the code I borrowed from RMQEngine, but I imagine other engines that load mdl's into a VBO might have the same behaviour.)

So it seems that for strict compatibility with the original engines, a client should be able to render an mdl that wasn't mentioned in svc_serverinfo. Still thinking about what I should do to fix this.

[mankrip]

That means Quakespasm should also be incompatible with the console command "viewmodel", which can load non-precached models into a "viewthing" entity.

I actually used that functionality to implement a player model selection feature in my JoyMenu mod. All the player had to do is to set the number of available models in a cvar, and then the menu is able to cache the selected model into the viewthing entity through the viewmodel command, store its .modelindex somewhere else, remove the viewthing and use the stored index to make the player and the bots use that model.

[qbism]

What if the client automatically precaches EVERY mdl it finds in path? What's the worst-case RAM? Many large maps use almost every monster and item, anyway.

[ericw]

Mankrip, good catch, I hadn't thought of the 'viewmodel' command, and you're right it was broken.

I applied a fix which is to just to create a VBO per mdl model, which is set up in Mod_LoadModel. Specifically, the VBO is uploaded within GL_MakeAliasModelDisplayLists. I guess this is less optimal in terms of OpenGL use than having all of the models in one buffer, but it should still be a lot faster than immediate mode.

qbism - the only flaw I can see with that is it wouldn't handle the case of adding a new mdl while the engine is running, and then loading it with 'viewmodel'.

Another thing I wanted to support is using the "flush" command to reload mdl's from disk, so you can replace an mdl and see the change immediately in game. By doing the VBO upload inside GL_MakeAliasModelDisplayLists, this automatically just works.

[mh]

"progs/bolt.mdl", "progs/bolt2.mdl", "progs/bolt3.mdl" and "progs/beam.mdl" are loaded on-demand in CL_ParseTEnt. With hindsight the "single big VBO for all MDLs" approach is a bad architectural choice for the Quake engine.

[Baker]

Anyone know if there are any mods that have color pink 255 in .mdl model?

I'm sure there are, possibly even in normal Quake, but I can't think of one right now.