I reviewed your demo and peeked at some internals. Things affecting lookspring ...

1) internal game clocks (seems fine)
2) onground is non-issue
3) Although the problem went away on level change, it could be just a coincidence.
4) The server wasn't stuffcmding anything that interfered.

Can you link me up a copy of your config.cfg and autoexec.cfg so that I can review some other potential things since cvar settings combinations could be involved or divide strangely with floating point. 

I almost replied your post @ inside3d yesterday about your engine and polygon points.

But I suspect you might not like my opinion of an answer, but here goes ...

Mark V has *ALL* of mh's matrix calculation and manipulation functions. This stuff primarily is not needed for WinQuake since it doesn't use OpenGL, yet even Mark V WinQuake uses these.

I you looked at Mark V texture pointer code, you can see it drawing the polygon and doing that calculations you are seeking would be straightforward.

What stopped me from posting is that since you do the software renderer, you likely don't use OpenGL matrix transformations -- and I felt my answer would be unhelpful (*).

You'd also probably have to add some GLQuake extra fields to some structs to make life easier. So I figured you would hate my answer and didn't post it.

(* because it took me a couple of years of get good at 3D matrix math and if you aren't using it regularly, I doubt you wanted the "hey start learning it and in 6 months .." kind of answer.)

There is Carmack matrix manipulation stuff in WinQuake, but where it differs from the look and feel of OpenGL matrix manipulation it looks Greek to me, mostly because if I didn't need to understand it for a feature, why investigate. I think one of the few times I used Carmack's matrix stuff was for "fov doesn't affect gun" option.

More Concise version: If I were in your shoes, I would add all the glpoly_t to the WinQuake renderer and modify the surface structure and use those to access coordinates. Then use mh matrix functions against those points and things like Mark V project/unproject (which is basically similar to gluProject) But I don't think you'll like that idea.

Plus my thoughts are shaped by my lesser knowledge of the internal workings of the software renderer than yourself, so I don't even know if "what I would do" is optimal. 

(* because it took me a couple of years of get good at 3D matrix math and if you aren't using it regularly, I doubt you wanted the "hey start learning it and in 6 months .." kind of answer.)

Yes, that's more or less the point. I don't want to get deep into this kind of 3D math before finishing the stuff I'm working on right now. Plus, what puzzles me the most is not the math, but the fact that it seems that the on-screen vertex data is unreliable.

I you looked at Mark V texture pointer code, you can see it drawing the polygon and doing that calculations you are seeking would be straightforward.

For now I'm going to do it the brute force way and extract the coordinates from the chained spans data, iterating through the whole chain to get the max and min x & y values. I suspect there'll be a lot to rewrite in the engine to get this kind of data in a straightforward way. But I'll take a look at what you suggested, thanks.

By the way, Makaqu has support for .scale on SPR sprites, so you can copy it from there. IIRC it's pretty simple. It also has .scalev, which can be used to scale each axis individually. The only model format I didn't try figuring out how to scale is BSP. 

extract the coordinates from the chained spans data

The glpoly_t has those and generates them on map load.

BuildSurfaceDisplayList <--- in Mark V and I think the same name in FitzQuake 0.85, which might be the same code as GLQuake (never looked, but seems very likely).

Also see: DrawGLPoly where it shows code drawing iterating through a polygon.

Generates all that glpoly_t stuff. Just on map load.

For any glpoly_t named "p" ... the verts are p->verts[0] (X), verts[1] (Y), verts[2] (Z)

Anyway, the reason I recommend this is that the code for getting the verts is already written in GLQuake.

(Then create a projection matrix and a model view matrix based on current player origin/angles and fov and combined with the viewport width/height you can get convert between real world points and screen points including z near depth 0 and z far depth 1 as much as you like <--- part of answer you will hate obviously, but the nice part is that it works.). 

Here's a thought for you ... QuakeDroid has tap-fire and the very first QuakeDroid was (WinQuake) before a switched GL to be the main QuakeDroid.

1) Load up Mark V WinQuake.
2) Type vid_touchscreen 1 in the console.
3) Double click on a torch and watch what happens. It is QuakeDroid "tap fire".

Now double click on a wall.

Now think about the fact that in order for that to work, the "tap fire" has to know the targeting distance to get the angle of fire correct!

("Tap fire" has about all the calculations you want, and it does them in WinQuake! No GLQuake at all. It shows you how to do most of the things you need.) 

Hey, I've got a map incoming for the 100bjam. It is currently using many new mdls, some with alpha textures recently supported with the newest Quakespasm release. Notable, these trees here as seen in Quakespam 0.93, Quakespasm currently displays all my models correctly:

https://i.imgur.com/MYhrOkX.jpg

When in MarkV dx9 the transparency doesnot work on 1 skin, also the model itself appears to be transparent with the background bleeding through
https://i.imgur.com/AaNJD6G.jpg

In Mark V the skin is fixed but bleeding from behind the model is visible, as well as a transparent layer that seems to cover the entire model:
https://i.imgur.com/bSNiZLw.jpg

Also, geometry is bleeding through all my models in Mark V even when they don't have transparent skins:
https://i.imgur.com/z4IHTIO.jpg

Currently only QS will run this map correctly. Anything that can be done Baker? 

OMG! It's beautiful! I knew you were a talented guy but I've never seen anything like that in Quake. I'm not sure I would have ever thought it possible.

1. Do you have r_shadows off?

If r_shadows is off ...

There is an Open GL Mark V 1.99 in the following zip http://quakeone.com/markv/builds/1099_mark_v_windows_extras_revision_3.zip (It's the SDL GL .exe)

I would recommend you check and see if looks ok in OpenGL.

Let me know ... 

Disable fog. 

Running on the newest openGL MarkV fixed all the issues with the models and the display perfectly now.

But there's a new problem. My map uses a func_illusionary for the bottom skybox face, with a minlight func_group beneath it. This is in order to properly light the models. Other methods failed because there is a problem with the current version of ericWs tools. This sky works fine in QS, but the bottom is not showing in this MarkV release now. 

I guess I didn't notice that the bottom skyface wasn't showing on older MarkV version as well. I mean I could try casting sky on a func_wall (although this makes sky 'shootable') instead as this also worked in QS, but will either of these methods methods display properly in MarkV? 

So there is a func_illusionary skybrush at the bottom of the map?

Do you have a sample .bsp that illustrates the issue? Need something to look at. 

Sample map with func_illusionary as bottom sky face, beneath that func group with minlight, beneath that a regular brush. 3 layer Sandwich. Run this in Quakespam and MarkV and you will see MarkV has no support for func_illusionary sky.

Source is included
http://www.quaketastic.com/files/misc/testing/MarkVskytest.zip 

Cool! Sky brush entities are rare (so rare I can't name with a map that uses one, and I have lists of maps with uncommon features) I probably forgot to implement it for lack of a test subject. 

Yeah, otherwise it seems to run fine in the newest version which is good news. I guess this means v1.999 is on the way?:) 

Rubicon Rumble Pack, version 1.03. In map telefragged, when you approach the area with the 4 labs (the one with the platforms going up and down in a pool of slime), Mark V closes to desktop with no error.

This is on Windows 10 1803 x64, with all versions of Mark V. 

For the area you are talking about, could you type viewpos and give me the numbers.

It looks like this:

Camera: (544 288 50) 0 90 0
Viewpos: (544 288 28) 0 90 0

Rubicon Rumble is a really big map. 

Sky entities addition done. Just need to build.

(I would like to look the issue that gvakarian says occurs with Rubicon Rumble before doing another build, I've looked around some of the maps but I don't know/can't find the area he is referring to ... the maps are gigantic). 

Great stuff Baker. I'm hoping that players who are MarkV users will be able to enjoy my map. Not sure how your gonna find that Rubicon glitch, needle in a haystack. Goodluck 

The approach to the 4 labs is in telefragged.bsp at "1134 -319 -8" facing angle "0 0 0". the labs are through the doors at the end of the hall. 

Haha! Thank you!

If someone says they have an issue and I can't investigate it, it is annoying as hell!

-----

@redfield - Any chance to get something to test the outstanding issue of screenshot you first posted that had black where transparency would be in the DirectX Mark V. I've done some fence model texture skin tests in DirectX Mark V and it renders just fine.

I'm glad to see alpha masked models get some live use in actual Quake. 

It's a tricky one. Baker mentioning floating point divisions put me on the right track of what to look for.

Ok, in FvF, the Cleric and Monk can create health and armor. In Quest (coop) mode, they get XP (frags) for giving that health and armor to their teammates.

A regular health box given to a teammate earns you 0.25 frags... so after you've given 4 health boxes you've earned 1 frag/point/XP.

Quake doesn't have a problem with this for math and display purposes, as it only shows the rounded number in scoreboards and such, and when the map changes, the fraction is dropped completely from the frags value.

BUT! This seems to be the cause of the bug. When ANY player's frag value contains a fractional value, it prevents EVERYONE on the server from using centerview! Well, I mean, it usually works on a delay of like 20 seconds.... But what's up with that? Why should someone else with a fractional frag value prevent everyone's centerview from working correctly? Why would frags even be involved in centerview?

Upon tossing that 4th health box to a wounded teammate (so my frag value no longer contains a decimal value), my view will then auto-center right away (having previously pressed the centerview key).


Reproduced in Mark V, QuakeDroid, ProQuake, and Qrack... so... if you fix this bug, you'll be breaking new ground ;) 

Awesome gunter! Glad to see you solved the mystery.

I turned over every rock and was striking out. 

@NightFright

For me the big deal is that Mark V has a really hard time loading MP3 files on my WinXP netbook. I've heard another person say something similar.

When loading a decent-quality MP3 track inside Mark V, the entire game literally freezes up for over 20 seconds while a glitched menu sound (if I just activated external music in the menu) replays over and over until it unfreezes, and then the music starts playing.... I manged to find some re-encoding settings that reduced the quality of the MP3 a lot and got that freeze delay down to 5 seconds....

However, when I use OGG files (by renaming things or hacking Mark V with a hex editor to replace "MP3" with "OGG") then the song loads almost instantly, with only a 1 second delay or less.

So yeah, it's a real issue for me, and not just some weird irrational preference for certain formats! ;) 

Add: I'm not sure, but since you can reliably identified and recreated the circumstances in multiple engines, it gives me something to think about. 

Gunter, I just want to point out that it is impossible to play ogg on Android or an iPhone (without unacceptably chewing up metric shit tons of CPU -- hence the frames per second would be absolute trash --- because it is an obscure format and hence does not have hardware decoding in the processor) while because mp3 uses hardly any cpu at all because it has hardware decoding built into every phone/PC/device on the planet.

Plus the Mac version of Mark V plays mp3 via Apple API via hardware decoding using nearly 0% cpu. ogg being an obscure format that no companies ever use, there is no Apple API for that.

I care that your Quake works right, but you already found a solution that works for your computer issue with mp3 by cheating around with something that happens to work on Windows.

So your personal issue is solved.

My issue is I want things to work the same on all 5 platforms that Mark V supports.

Why the hell would I want to support an obscure music format that can never work on the 2 mobile platforms that I like with Mark V.

Why would I also want to recode the Mac version to support a shittier music format that uses more CPU? Oh -- and since I couldn't use Apple API I would have to rewrite the music code.

And the Quake .mp3 sound tracks are available everywhere, like on the Steam page. Case in point, this guy is links to it. Also Travail's soundtrack is mp3.

Also why the hell support more than 1 music format?

Shall we figure out new graphics formats like .bmp or hey let's do .gif!

The only engine that can't play mp3 is DarkPlaces, and to be blunt --- DarkPlaces is an extremely shitty engine for playing Quake because it made itself so damn incompatible with a lot of Quake mods.

I'm just communicating my point of view.

I don't care if people discuss it or what not, discussion is always a great thing -- environments where you don't find discussion or arguing are sterile and mindless. You might consider listening to my point of view, though --- I have one too! Haha