So I've added per triangle collision detection for entities (vs. bounding boxes) to my quakespasm project at home but I'm running into a peculiar collision detection issue.

My code works fine when the entity's baseline angles/origins remain 0, but not otherwise. I'm using the entities's v.origin and v.angles to construct an inverse transformation matrix. I perform my per-triangle traceline collision detection, find my hit point, and then transforming the hit point back into world space.

As stated, this works fine when the baseline is zero. If i need to do some more voodoo in my math to account for baseline angles/origins please let me know? 

That is odd. Assuming your collision detection is being done in server code, the baseline shouldn’t matter at all since that is merely used as part of the network protocol and client code. What types of collisions are you testing with this? Bullets against enemy models? 

Thank you for responding metlslime. I am testing bullets against enemy models. I have a modified traceline routine that iterates through all of the model's triangles looking for ray triangle intersection (terribly unoptimized, I know).

What you have helped me understand is that i don't need to worry about the baseline information. Is using the AngleVectors on the entity's v.angles call to extract the forward, right and up vectors, plus using the v.origin sufficient to build my world-to-model space matrix? Is there a better way?

The only time it does work correctly is when the model's angles are <0,0,0>, and i invert the y axis (right vector * -1) when projecting from world to model space. I don't know if this behavior pops any ideas into your head, but i thought id share.

Thanks for your help!

FYI: the collision data is built in model space during the the Mod_LoadAliasModel process. In pr_cmds.c I invoke my modified traceline routine to translate my ray origin & endpoint from world space into model space, perform my hit detection, and then transform it back from model space to world space. 

I'm really sorry it took me this long to respond.

- Try with a clean config.

With the binary downloaded from http://quakespasm.sourceforge.net/download.htm it happens with a clean config too.

- try the Linux binary from http://quakespasm.sourceforge.net/download.htm as well as the Ubuntu one you can install with apt. Does the issue happen on both?

Ok, I've installed Quakespasm via the Software Centre or whatever it's called nowadays (which I guess is the same as installing via the terminal with apt. It's called "quakespasm-beidl", though. Is that right, or did I accidentally install the wrong thing?). As far as I can tell, the problem doesn't happen with this version of Quakespasm, or at least it hasn't yet.

- Type "condump" and upload the resulting file

Should I do this for both versions of Quakespasm I now have on my computer? And where do I upload it?

- Do you get a reasonably good framerate? What does "host_maxfps 1000" then "scr_showfps 1" show?

Under both versions of Quakespasm, my framerate is initially just under 200 on the start map and then rises a little, while hovering between 200 and 300 on e1m1. Is that good? The version downloaded from http://quakespasm.sourceforge.net/download.htm seems to have a slightly higher framerate, though, for what it's worth. 

https://snapcraft.io/quakespasm-beidl 

It would be nice to be able to bind my own menu navigation keys in QS. My keyboard doesn't have regular arrow keys but can send the numpad direction keys. Is this feature already present and I just don't see it? It's not super annoying to have a second keyboard shoved in the back of my desk to do Quake menu nav, but it would be nice to use my aircraft carrier Model F for everything. 

Oooh, Model F, you say? o: Gotta love dem clicky keys! ;) I'd wager some hardcore typists would pay a hefty penny for one of those keyboards. :D 

I love my Model M keyboards. 

Condolences to anyone else in the same building as you when you're typing on that thing. 

where does one buy these? 

why does the Quakespasm still have that "skin is taller than 480 issue"? At number of other engines have took care of that, why can't Quakespasm? 

Version 0.93.2 of QuakeSpasm is released.
Changes since the previous version:
https://sf.net/p/quakespasm/news/2019/11/quakespasm-0932/
Downloads:
https://sourceforge.net/projects/quakespasm/files/
http://quakespasm.sourceforge.net/download.htm 

... please? 

what is the command to disable fullbright in the quakespasm engine? 

... in the console.

Posted in the vein of "give a man a fish" VS "teach a man to fish". 

got it. Thanks! 

After finding much success with EZQuake and 3620x2036 DSR enabled via NVIDIA settings I notice that QuakeSpasm cannot handle the DSR resolutions well: the console rendering gets all whacked. 

Define "all whacked"
I can run it in 7680x4320 and it looks just fine.
Have you tried changing scr_conscale? (also scr_menuscale, scr_sbarscale) 

Well, this is odd: I tried to take some screenshots to show exactly how it is "all whacked" only to realize that screenshots in fact show the console and the entire screen rendered correctly. It's only on my actual screen where things look wrong.

As I started paying more attention I realized that going above the screen native resolution of 2560x1440 increases the overall "zoom level" of the screen. When using DSR resolutions, I can clearly the the bottom "status bar" dissapear and the left side of the console window falls outside the viewpoint. As the DSR resolution is increased further, so increases the amount of this "zoom" leaving out borders of the screen out from view.

Are there some other cvars involved? 

Apparently QuakeSpasm was trying to used windowed mode instead of fullscreen. 

Setting cl_bobcycle to "0" makes the screen go grey.
Found this out after a long battle to get things to work again. 

Setting cl_bobcycle to "0" makes the screen go grey.
There's a division-by-zero in the original code with cl_bobcycle 0 - "cycle = cl.time - (int)(cl.time/cl_bobcycle.value)*cl_bobcycle.value;" - whether or not it makes your game go nuts probably depends on compiler options/etc and unfortunately in the original engine it was OK but in some ports it's not.

So just set it to a really low value until the QS devs fix it. 

I think the intent was "cl_bob 0", not bobcycle