vanilla glquake likes to crash when a gl driver reports over 1024 bytes of extensions. many gl drivers (or at least nvidia) limit the number of extensions reported to anything 'glquake.exe', which means renaming old third-party engines is one way to get them working again...
vanilla also likes to misbehave without the -no8bit arg.

GOG includes 3dfx's opengl->glide wrapper, as well as nglide and its glide->direct3d wrapper. I guess markv just doesn't like it when various opengl functions are missing.
one way to avoid this issue (including the issue with the gl->glide wrapper with no glide support) is to just directly+dynamically load the opengl32.dll from the windows system32 directory.

/me starts to wonder which other engines fail to cope with it.
/me wonders what the steam version does to avoid the glquake/winquake crashes.

but yeah, if you're not going to run vanilla glquake, one option is to just remove that opengl32.dll minidriver/wrapper. 

I might be able evade the GOG opengl32.dll by checking for the existence of the .dll and if it exists changing directory to id1 when I first call an Open GL function to cause /DELAYLOAD to kick in, so it is not found and then changing back. A bit of hassle.

/Mark V hooks up all Open GL functions at startup, so while another might wait to crash until one of them is called, Mark V will crash immediately. 

Nothing ever gets to be easy does it?

Arcane Dimensions doesn't support static entities.

That being said, I'll make it work anyway. I'll have to do a test map, but the way I redesigned it really does not require use of static entities it is just highly preferred. 

you can just load the current test map in ad 

Trying winquake build 1018 with a clean install of Arcane Dimensions, I noticed a couple of oddities... not sure if this is to be expected, especially the transparency part since that discussion got a little involved. So FWIW, FYI, etc.:

Main menu graphic has the AD logo missing: https://dl.dropboxusercontent.com/u/11690738/temp/winquake_mark_v_0000.png

"Vine" transparencies (not): https://dl.dropboxusercontent.com/u/11690738/temp/winquake_mark_v_0001.png 

(That's AD 1.5 to be clear.) 

Loaded it in original id1 Software's WinQuake and it doesn't look right either.

Something about one of the Arcane Dimensions gfx.lmp files isn't WinQuake compatible.

id Software's WinQuake screenshot - Arcane Dimensions pink menu item

vines - Mark V WinQuake doesn't support alpha masked textures on brush models just yet. It will eventually, it's on the todo list. 

Have you tried the Mac versions? Are they ok for you? 

Clarification: Asking about the startup dialog on the Mac. It should work ok now whether or not binary is in the Quake folder or elsewhere. 

Nope not yet! Will have my macbook returned later tonight. 

@pulsar ...

http://quakeone.com/markv/media/hall_of_mirrors_test_map.zip

The above test map will be a good example to explain

- mirrors
- func_illusionary mirrors
- list of things to avoid

func_illusionary mirrors cause hard to avoid issues, but a good mapper can map around their limitations. 

He is quickly done "video" explaining how to use mirrors ... walking through a map and describing limits.

Mirrors Tutorial "Video" 

Download at usual location:

http://quakeone.com/markv

Main Features

Compared to version 1.1
- Mac version Open GL w/effect | WinQuake
- Support for func_illusionary mirrors (pulsar)
- Support for same in Arcane Dimensions (pulsar)
- QMB particle effects option
- Resizable window at any time with mouse
- Several other small features
- 100.00% resolution of all issues

Thanks to the beta testers! Gunter really went overboard and identified several things that could be improved about QMB; dwere caught a few hard-to-notice issues, in particular an obscure rendering glitch.

Thanks to Pritchard, NightFright, johnny law, Bloughburgh, c0burn, spy and several others.

Upcoming DirectX 9 Version by MH?

Probable Direct X 9 version is in the works by MH (with no obligation on his part), from brief descriptions of enhancements it is very likely to be significantly superior to the Open GL and DX8 builds and will likely replace them as default Windows build.

Func_Illusionary Mirrors - "mirror_" textures

Tutorial video Test map

Requested by pulsar. There are limitations to func_illusionary mirrors, the video tutorial shows how to work within the limits.

Arcane Dimensions does entities differently than normal for func_illusionary; those are now supported.

/Final build of 2016 

gonna try it when I get home 

 

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.