There are a few minor issues that still exist, though they may or may not be worth addressing:


QMB Particles - All explosions are stifled when underwater. This is really not correct; explosions are not less powerful underwater, so they should not be made to appear less powerful. And I think this is the reason my splash effect is messed up; the QMB system interprets the splash as an explosion (as before, with the spark effect), and so decreases the power of the effect, but since it's not a powerful "splash" in the first place, the effect is just being stifled into nothingness pretty quickly.


The +zoom_key alias -- as a programmer, I can't see such un-optimal code and not want to fix it, heh. I did find it is better to save the values and restore them (as you do) rather than just counting on the math to take care of that, because when banging on the key really rapidly, the math can get out of order and mess things up. However, there is still no need for all the "in between" steps in the your alias. It only needs a start, and end, and an animation in between. So this would be much cleaner:

alias +zoom_key "valsave fov 1; valsave sensitivity 2; mul sensitivity 0.1; valsave r_viewmodel_fov 3; r_viewmodel_fov 0; fov 70; wait; fov 50; wait; fov 30; wait; fov 20; wait; fov 10"

alias -zoom_key "fov 20; wait; fov 30; wait; fov 50; wait; fov 70; valload fov 1; valload sensitivity 2; valload r_viewmodel_fov 3"


Pressing TAB during "Congratulations" text causes the text to disappear.


All pitch values should be .17 higher than they are. This would probably require the fullpitch adjustment to be altered down to:

cl_maxpitch 79.8269

but the minpitch value would not really need altered from -70.


With transparency in effect, teleporter surfaces always render on top of water, and water always renders on top of shadows. 

Erg. I left out a "wait" in that second alias right after the "fov 70" heh.

Should have been:


alias +zoom_key "valsave fov 1; valsave sensitivity 2; valsave r_viewmodel_fov 3; mul sensitivity 0.1; r_viewmodel_fov 0; fov 70; wait; fov 50; wait; fov 30; wait; fov 20; wait; fov 10"

alias -zoom_key "fov 20; wait; fov 30; wait; fov 50; wait; fov 70; wait; valload fov 1; valload sensitivity 2; valload r_viewmodel_fov 3" 

Oh yeah, and that old issue where your name is constantly being changed when you mess with it in Multiplayer -> Setup. It should only commit the change when you select "Accept Changes" or perhaps when you exit that screen. 

I've added 1 (one) vertex shader to it.

Now, before you start baying for my blood, there's a good and very valid reason for this. But before I give the reason, bear in mind what I said a good bit upthread about D3D being able to software-emulate vertex shaders. That means that it retains full compatibility: there's no bumping of the hardware requirements involved here.

Also - it's a single generic vertex shader that all vertices go through, so it keeps with the philosophy of "one place for everything and everything in one place".

Now for the good and valid reason. I lied: there's actually two.

First, and the biggie, is the dreaded Direct3D half-texel offset problem. If you've noticed that the 2D GUI widgets look significantly poorer quality in D3D, that's the reason why. Another symptom would be black lines around the water textures with r_oldwater 0 (you didn't see this in D3D 8 because r_oldwater 0 wasn't supported).

The thing is, the only way to cleanly and non-intrusively fix this is by tagging some lines of code onto a vertex shader. Believe me, I tried other ways, and they all had the downside of needing (in some cases significant) changes to the base engine code (FQ's GL_SetCanvas thing would have had impact throughout the codebase).

Essential reading: http://aras-p.info/blog/2016/04/08/solving-dx9-half-pixel-offset/

Second reason: texture matrix. There are API differences with how the texture matrix is applied, and the only alternative way to work around them was to software-emulate the texture matrix and apply it before copying over texcoords. That ran incredibly slow.

Potential third reason: I only mentioned two above, but this is a potential third: there are also API differences with texgen, and if in the future Mark V ever uses texgen for anything, this is the cleanest and most performant way of bypassing them.

Anyway, I am willing to back out of this if Baker (or any other key user of Mark V) considers it too objectionable, or otherwise considers the fallback modes acceptable, but I do strongly recommend it as the best and most compatible solution. In particular I consider the half-texel offset problem completely unacceptable; while the others would have viable software fallbacks (at a performance cost), fixing half-texel offset acceptably but in a different way would require re-implementing the entire transform pipeline in software (or invasively modifying the base engine code in too many places). 

It works! Thanks a lot. 

Glad you are happy. Look forward to playing your maps!

Tried to illustrate limits for func_illusionary mirrors in the video. 

@mh - Any ideas you wish to implement even if they are Direct3D only enhancements are fine.

Many of the boundaries I set for this project have been to allow it to reach completion and keep goals in areas of my knowledge set.

Your strengths and interests in the advanced/low-level rendering are far higher than mine, use them how you see fit. Is perfectly acceptable for the Direct3D build to have extra features.

@gunter - I agree with some of those. Wanted to wrap up.

@bloughsburgh - Thanks! 

Security cameras would be nice feature for base maps:

Security Cameras 2017 Demonstration Video 

Could be fun, even more so if you could have rotating cameras. Security monitors would require a "use" button, I guess. 

@mugwump - That is one of the main questions, how to expose the capability to someone making a map. On the mapping side, clearly camera entities would be involved.

And then the secondary question is should it be done through QuakeC instead. The problem I see with this is the someone couldn't make it work with stock Quake.

Most of the questions are just how to make it available in a map editor and to do it for multiple view screens - in a way that allows flexibility. 

I tried to compile this with CodeBlocks, but im getting TONS of error messages.. Is it possible to release a non broken source?? :/ 

I use Visual Studio on Windows. XCode on the Mac. Every once in a blue moon, I may check to see if the CodeBlocks compile works, but it is rarely up-to-date.

Linux isn't supported at this, if that is what you are trying to do. 

The WinQuake Debug, GL Debug, GL Release all compile fine with CodeBlocks 13.12 Full Install on Windows from freshly downloaded source.

Although I use Visual Studio and rarely update the CodeBlocks project, it isn't often that I make changes that would cause the CodeBlocks project file to break very much.

But the CodeBlocks project has unsupported builds in it too, like the Linux build. 

I fixed it myself, it was indeed caused by an older version of CodeBlocks... However, for some reason i cant assign my mousebuttons to a key..
Is it possible to add a simple MD3 loader?
I want to use a FitzQuake engine for my game (atm im using an older Mark5 version), but i dont want to use mdl. 

I tried to play warpb_sw4848 demo from quaketastic.com/?dir=files/demos (protocol 10002). It ends around 2 min 40 sec in with the message:

Host_Error: CL_ParseServerMessage: Illegible server message, previous was svc_clientdata

Not sure if it's a bug or expected behavior. 

I had issues with demos too, if you delete the demos (and keep the lines in the quake.rc) the engine hangs up.. Very unstable... 

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.