I haven't been keeping up with Quake recently, good to see so much work still going into MarkV. Can't wait to play some split screen when it happens ;) 

Any chance for a Linux version of the 1.99 release? And actually have working external music support? Quakespasm Linux has working music I don't see why the Linux binary of MarkV can't have it.

Also what the hell does "Cache_RLU: NULL link" or whatever even mean? I've never had that happen in Quakespasm. 

Now, mh, YOU KNOW that the paragraph you quoted from yourself in the past is utter nonsense (why are you trying to make it sound overly-complicated by talking about sorting lists and comparing bitrates and acting as though it's a crazy impossible situation if there are multiple formats in the same folder?).

Do you know how I know that you know it's nonsense? Because I just fired up DirectQ, YOUR QUAKE ENGINE, and guess what? It can play both MP3 and OGG files, and if I have BOTH an MP3 and an OGG file of track04 in the same folder, it simply plays the MP3 instead of getting confused by this "crazy-assed situation" and causing the earth to explode. FTE, on the other hand, supports both formats and gives preference to the OGG in the same situation.

So, YOU'VE done this. It was simple, because apparently you did it without even knowing you did it. It just works automatically, easily, and effortlessly for the user. But now you act like it's some impossible insurmountable obstacle to programming....

Are you retarded or something?

See, I don't listen to tards, because they say retarded things that just aren't true.

Just saying! ;) 

Now the continuing report of the weird centerview behavior....

Me and another player on the FvF server experience it working and not working at the same times. I checked the clock and it seemed to be right about 15:30 when it stopped working. On the next map (it starts working again after map change), I watched again to see if it would repeat, and it seemed to stop working again right about 15:30. Then it started working again around 18:00, stopped again sometimes after 20, then stopped again after 21... and stayed that way. At each point I told the other guy and he agreed that it would start/stop working during the same periods it did for me.

I was using Quakedroid with keyboard only, and he's in Linux Mark V using mouse + keyboard.

I tried playing around some more to see if those times would aproduce the bug in single player or local multiplayer, and by restarting a map on the online server and messing with the host_framerate, but I can't really get it to repeat.....

But it's rather odd that centerview (not force_centerview) should be affected by anything the server is doing... at certain times... for multiple connected players... isn't it? We were just standing around in the game not doing anything weird. Pretty sure I don't do anything in FvF that should alter a player's view like that. And as I reported before, after tapping the centerview key, the view will center itself after like 10-30 seconds when the issue occurs.

Weird one. *shrug* 

@gunter ... get me a demo and the time within the demo the problem crops up. Use cl_autodemo 1 or have your friend use cl_autodemo 1.

There are dozens of items used in the Quake view drift calculations, some come from the server or the mod (QuakeC).

It could be so many different things like the server/QuakeC specifying "wishangles" or movetype fly/noclip or an onground flag that without live catching it, there is not a reasonable chance of isolating what is occurring.

Since a demo is the capture of all communication from a server, the information within a demo should be enough for examination to see what variable is the source of what you have experienced.

Other: I'll build the Linux in the next 24-72 hours. The "link active" thing should go away. Although I spent some time examining ffmpeg, too many irons were in the fire and I never got around to adding soundtrack support for Linux nor QuakeDroid because there was too much going on. So that'll happen next time (maybe Christmas).

@fifth - Yeah, split screen is going to happen! Haha! Almost happened this time. Next time is a lock. 

It's ironic that this may happen when I am playing the least amount of Quake for about 10 years. 

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.