Asking Baker for help since he has experience with both the software renderer and with things like his tool_texturepointer. 

Did I say adding ogg support was impossible? Don't seem to recall saying that. Yes, I've written it myself in the past, did I deny that? You'd think the fact that I've written it would put me in a position where I could be assumed to know what I'm talking about, but apparently not.

Yes, I know what code that supports multiple formats looks like. I know the kind of things it needs to do. I've written such code, so please don't assume that I'm BSing when I say that the MP3 code in MarkV is nothing like it. This isn't a simple modification, this is an extensive gut-and-rewrite.

Asking for the same thing over and over again when it's already been both patiently and impatiently explained that you're asking for a lot more than you realise is wearing pretty damn thin. 

I don't quite understand what's the big fuss about having to use MP3 versions of the Quake soundtrack. They are not that hard to obtain. "Other ports support OGG" is not a valid reason to insist on this IMHO.

Sure, it's maybe nice if you can use the soundtrack files in different ports if they are in OGG format, but honestly I am only using Mark V by now. As far as I am concerned, I got used to using MP3 files. 

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.