InsideQC Forums

If i remember correctly nehahra used some hacked together map tools (pascal based even) and they only work on win9x or older not sure why but maybe the source for qbsp etc was not opensourced at that time.

qbsp source was available in 1996.


also try selecting the text in the post where I mentioned Nehahra...

Ok Thanks leilei

Any normal Quake mods that use sprites as "models"?

I suppose the bullet holes in hipnotic might count?

Actually, s_light.spr is used in the first underwater area in E4M7.

Retroblazer

Check for corrupted lightmaps in mfxsp17 or jam2_mfx.

here is a shot of jam2_mfx in a broken engine (QuakeSpasm 0.85.9, Mac OS X) (note the diagonal stripes in the lightmap on the right side of the main archway)
http://www.quaketastic.com/files/screen ... ghtmap.jpg

and a working one (tyr-glquake):
http://www.quaketastic.com/files/screen ... ghtmap.jpg

This comes from the unfortunate way that the pixel width / height of the lightmap for a surface must be computed by a precision-sensitive floating point calc. From what I understand, originally engines would use x87 FP which uses 80-bit intermediate precision, but if you do a dot product of floats in C, the standard allows rounding each intermediate product to 32-bits, which is what happens when compiling with SSE FP (and probably non-x86 arches too). This builds up enough error to mess up the lightmap dimensions.

The fix is easy, just adding some casts to double in CalcSurfaceExtents: also see here: https://sourceforge.net/p/quakespasm/patches/15/ (ignore the first patch which is using inline asm).

I noticed that one, is a very good bug-fix. If I recall, you tried to ASM it at first.

/On another note, are there any mods that use animated skins on alias models? (alias models = Quake .mdl models)

TF uses animated skins on a few models, teleport pads come to mind. lots of flickering lights.
these models are also normally meant to be colourmapped, so should match the owning player's colours too (without showing player.mdl or other weird glitchy things). so that's another thing to support... two birds with one stone, right?

This map is particularly useful for rendering bounding box issues: https://www.quaddicted.com/reviews/veni05a.html

In GLQuake, there is an area near fancy bridges that the rails will disappear. Similar to the Shub disappearing in GLQuake if you stand just right.

And: It is likely that those fences are rendered wrong in every WinQuake variant because of something about the texture. I think the fences are an alias model (q1 .mdl model) that may have a size unfriendly to WinQuake.

Physics ...https://www.quaddicted.com/reviews/trincasp2.html

The Forgotten Tomb in the beginning of the map, you walk under a wind tunnel that you have to jump.

In a coop game in standard Quake with 100 ping connected to a dedicated server, you may never be able jump high enough to touch the trigger depending on what the sys_ticrate is.

qbism wrote:In Sock's map backstein.bsp for example, framerate-independent physics fix is required to hit a certain air tube target. (Or reduce gravity or increase fps.) In the reverse case, there could be old maps that require classic NQ physics, I don't know.

http://forums.inside3d.com/viewtopic.php?p=54274#p54274

Good thread..

Not quite on topic but I uploaded a test map I used when modifying the QuakeSpasm renderer, to check for regressions from Fitz 0.85.
http://quaketastic.com/files/misc/rende ... stmap2.zip
Requires quoth (mapobject_custom to load an external .bsp).

It's nothing special, but tests various things like:
- water textures on bmodels
- skip textures on bmodels
- frame of bmodel
- transparent external bmodel
- fullbrights on transparent bmodels

WinQuake renderers that support skyboxes seem to have issues with stuff in the sky like E4M7 and draws them.

Go to map E4M7, load a skybox.

Look up and you'll see this the box that holds a shambler in front of the sky and the shambler too.

Probably because the sky drawing code doesn't write to the WinQuake equivalent of the depth buffer and it draws the skybox first.

The skybox code does write to the Z-buffer, but its values are set infinitely away.

Regular sky surfaces are completely skipped when a skybox is used, due to the monolithic strict no-overdraw behavior of the software renderer, so there's no way to draw their depth values in the same rendering pass.

Coincidentally enough, I'm planning to figure out a proper solution for this soon.