I only added protocol 10002 to support the Warpspasm demos that come with the game and play when you start it.

But thanks for letting me know it doesn't work with user made demos, because I didn't know. 

@steve - It's unlikely that I would add md3, Mark V follows "the path of one". One format, one name, one place for all formats and types of files. md3 has no place that in that scheme, would be a 2nd model format.

Mark V also has a software renderer that can do almost everything the GL version, but it sure can't do md3. md3 isn't a Quake 1 format, but I can understand why you would want it from a make a game perspective.

You might try to convert the MD3 to mdl with the best and most awesome tool ever created .... http://richwhitehouse.com/index.php?content=inc_projects.php#prjmp91

Ultimately, Mark V is not made for total conversion purposes. But I do wish you luck with your project.

I'm glad you enjoy the engine.

/At the same time, please understand I am not an engine coding help forum. What you may not know is that I have had in the past literally dozens of people attempt to make me their personal coding help guy. I'm pretty good at saying no. ;-) 

That's what I suspected.
Ironically, the Warpspasm startup demos get overridden by the latest Quoth's startup demos anyway :D 

the Warpspasm startup demos get overridden by the latest Quoth's startup demos anyway

I know Preach didn't do that on purpose, but that's highly undesirable. I never did any testing with Quoth 2.2 back in 2014 when I added support for the Warpspasm start demos.

I like Warpspasm enough that I may cause it to load in original form so the start demos play. 

Thx for the reply, but i think i can add MD3 myself to the old base engine i use (its an older Mark5), i mostly want it for viewmodels only because i need the "details" active on it (iron sights etc..)...

I already managed to add a working sound dsp system (based on crowbars psp engine), which is awesome btw. 

https://youtu.be/UD7xKlV2yJY 

Wow, I'm not easily impressed but that is awesome. Do you have a link to the source for any engine with that modification?

Engoo has sound modifications, and I can't recall the name of the "open source Half-Life engine", but I'm sure it has sound modifications.

I think it would be awesome to somehow expose parts of a map, sound modifications. Quake .bsp doesn't support that. And at the moment, I can't recall exactly how Half-Life marked those areas ... probably a trigger.

I have not thought about sound for a while, but obviously since Mark V can do Half-Life .bsp (provided the textures are compiled into the .bsp) ... and .alpha entities and masked textures .. that I think of a more complete engine, although in the context mostly of what someone would do in a Quake map.

I think of mirrors, security camera, portals and such because they could add more complex and richer environments to, for instance, a base map.

Plus I have largely completed intermap travel-system which requires no QuakeC support (but offers QuakeC the opportunity to intervene).

/I couldn't say exactly when any of the above would happen because there are always so many items on a to-do list. One of the main challenges of moving an engine forward is that there are always choices and with limited time some things have trouble finding their way to the front of a queue. Case in point, splitscreen and Linux build may consume much time in future and integration of possible DirectX 9 version by MH or acquired Spike's optimized network compression. It's always of a sea of choices :( 

I can give you the sources if you want ;)
I plan to control the DSP with simple triggers and stuffcmd, it adds so much to the levels ;) 

Maybe there could be something like loc files for environmental sound effect locations. 

8x multitexture (which was easy, even for me)

I'm going to offer 4.

Here's the reason why: http://www.nvidia.com/object/General_FAQ.html#t6

Summary, for anyone who didn't follow the link, is that with fixed-pipeline OpenGL NVIDIA only offer 4 texture units. 

Yeah, I'd like to take a look at that source code. 

I can't think of a Quake scenario where anything more than 4 texture units would be necessary. I think even 3 may be enough to eliminate to the overbright pass as a separate pass in FitzQuake. 

is awesome... no idea how that could be implemented in quake maps... trigger volumes?

Unreal Engine used to allow "zones" to be created by sealing off entire rooms and areas, that was a good technique. 

If I were to add a modification to that certain areas of a map had special zone modifications zones like Half-Life (echo areas) I would probably be inclined to implement it in the following manner:

- A brush similar to func_illusionary indicates the sound region. Static entities are available to the client. A field of the entity indicates the sound modification.

- Although someone like Spike may correctly point that this to some degree does not follow the client/server model ... every modern engine already breaks the client/server model by indicating skybox and fog (and now several other keys like wateralpha and friends) in the worldspawn, which is client-side. The server has no opportunity to legitimately set those global values, and maybe for the best because those would have a delay of a split second.

I would mostly need to examine a way to make it backwards compatible to non-supporting engines.

This would also allow easy editing via external .ent files. And to possibly allow someone so inclined to take an existing map and add sound zones.

Also makes it so no complex new way of communicating sound zones to a client need be added to an engine and would be compatible with save games and everything else. 

The Engoo engine has some of sound modification capability. It's one of the software renderer engines like qbism super 8.

But yeah ... I'll do some thinking and figure out some way to support such a thing --- and in a way that is very friendly to mappers and easy.

/Isn't a soon thing but more likely a vague "probably some time in 2017" thing -- like security cameras security cameras concept video. So many items in the queue + limited time ... 

I can see 5 being used for diffuse+lightmap+fullbright+caustics+detailmaps maybe.
Or add 3 more if you split the lightmaps into their own textures.
Then add two extras if you want light directions and deluxemaps for bumpmapping.
And add 4 more if you want to ramp up specular to a decent exponent...

Although its kinda pointless to worry about it if the engine needs to retain a 4-tmu pathway anyway... or two... or one...
But yeah, more than 4 and you really should be using glsl/hlsl, trying to do everything with only an alpha channel for temp data is just unworkable. 

Yeah, eventually I do have something like a "surface effect texture" planned in my head for possible surface effects.

Might as well ask your thoughts on this question to you ...

Although not soon, I would like to use probably 4-8 QME 3.1 bit flag slots but and would like to avoid any possible with what FTE uses.

One example might be to indicate additive blending.

/I have not put much thought into this lately, but while discussion about future mapping enhancements ensues ... is fairly good time to bring up those thoughts. 

hexen2 defines modelflags up to and including 23.
1<<24 is the first undefined one as far as fte is concerned.
Not that fte implements all of the hexen2 ones, or that I'm even aware of any models that use them... but hey.

that said, for additive, you're probably better off sticking with EF_ADDITIVE=(1<<5). Yes, this can be used by mappers, and does not necessitate any wire change (read: protocol uses a previously-unused bit which permits backwards-compatibility on the assumption that old implementations can safely it).
maybe some of the other bits you're thinking of are similarly already implemented in another engine. 

if (!strcmp(gl_vendor, "Intel"))

I see that Mark V has inherited this from the original code too.

The D3D equivalent (which is read from the driver so I don'thave control over it) is actually "Intel(R) HD Graphics" so this test will incorrectly not identify it.

Strictly speaking this is also a bug in the GL case because Intel may change their vendor string.

Change it to:

if (strstr(gl_vendor, "Intel")) 

dx8_mark_v -width 750 -height 550

= borked up screenshots

Fixed.

This is actually a wrapper bug, so my apologies for my previous misdiagnosis.

@Baker: in the glReadPixels implementation, "case GL_RGB" should also be using "srcdata[srcpos * 4..." because the source data will be 4-byte, even if the dest is 3.

I may have mentioned a while back that there are advantages to going native, and screenshots are one such.

Baker has implemented PNG screenshots, so in the native GL code he's doing a glReadPixels, then converting the memory buffer to PNG format (presumably via a statically linked libpng or maybe stb_image) and saving it out.

A native D3D version wouldn't do half of that work. Instead it could just use D3DXSaveSurfaceToFile on the backbuffer. Give it a filename, specify the type, boom, done, three lines of code.

I'm going to add some native exports to the new wrapper for functionality such as this. 

The DX stuff mh is doing sounds really great.

I don't understand most of it, but I hear things like "improved performance." And bug fixes are always good.

And if I'm getting the gist of things regarding more rendering passes, this might allow addressing of some issues:

Fullbright textures should not be affected by contrast -- it makes them ugly.

Screen Blends should not be affected by gamma or contrast -- I have found this is the main thing that makes them far too intense. When I use vid_hardwaregamma 0 and various values for txgamma, the screen blends look perfect, though if I mess with the contrast slider, it makes the blends too intense again.

So yeah, if that's a possibility, the screen blends should be drawn last so they are not affected by gamma or contrast.

But I have no real understanding of this low-level 3D rendering stuff. Though it sounds like there will be a great benefit from mh's work. 

Mark V applies gamma and contrasts to screenshots (only) when applicable.

For instance

1) If you are using hardware gamma/contrast, it will adjust the screenshot accordingly.
2) If you are not using hardware gamma/contrast, it will not apply it to the screenshot.

So depending on situation, writing directly to file is not necessarily desirable because screenshots could be, for instance, too dark/etc. 

Hm, there's an issue that looks similar to the previous QMB lighting texture thing with txgamma, but it appears whether or not txgamma is being used, wherever there is fog.

I first noticed it at very long range when I was zooming in, because I use very light fog, but if you set the fog much denser, like .5 and then fire the lightning gun, you will see the bad effect. 

Mark V applies gamma and contrasts to screenshots (only) when applicable.

Ahhh, understood.

By the way, here's a sneak preview of something I just did: http://i64.tinypic.com/o6flm1.jpg

This was actually taken with the GL version, just to demonstrate that there's no shader trickery or suchlike going on. 

awesome! Classic water!