to add a qqq command from S - as quit command 

http://quaketastic.com/files/misc/mark_v_0000.png 

Waking up a wall shambler in e1m7 is probably the good old Lighting Gun coding weirdness where the shaft appears way off in totally wrong places when hitting walls just right. So your shaft found its way into the wall box....

I know of one good place to demonstrate the glitch on DM3 -- shafting this position hits person standing to the left:

http://imgur.com/a/VALEJ

I remember years back when I was looking at this weird code, I made the invisible beams visible, and they are just crazy, heh. I didn't know what the heck they were trying to do with that code, but since the visible beam actually penetrates players, I thought perhaps they were trying to make the damage beam penetrate things as well, so that's how I fixed the shaft in FvF -- the shaft will penetrate up to 2 entities in a row and still damage a 3rd (with a decrease in damage each time 30-20-10).

This old post on Quakeone links to a very detailed analysis of the lighting gun glitch:

http://quakeone.com/forums/quake-talk/quake-central/2872-lightning-gun-bug.html

That's... pretty complicated stuff. The takeaway is that the lighting gun code is pretty borked, and you can end up hitting something way off somewhere else, like a shambler in a wall box. 

So your shaft found its way into the wall box....
Suddenly I pictured the image of a glory hole in my head... 

If you want a particle (or any other effect) to only last one frame, set a flag on it when spawned (you should have a "flags" member in your particle struct for this), then set it's die to cl.time + SOME_BIG_NUMBER (I like 666 for the humour). Draw it as normal. Then after drawing, check if the flag is set (and !cl.paused) and if so, set it's die to -1. Done. Works if Quake is running at 10 fps or at 10,000 fps. 

dx8_mark_v -width 750 -height 550

= borked up screenshots

Why was I running at 750 x 550?
Because you told me:

"2) Then don't use 800x600 windowed mode ;-) Not engine's responsibility to save the user from his own choices. "

;)

Heh, yeah, that issue I was having only applies to the Windows version, but my resolution had been changed when I ran that, and that resolution was applied the next time I ran the DX one, and then my screenshots ended up being borked up.

It doesn't seem to affect GL. 

Now for the issue I was trying to report before I had to stop and figure out why my screenshots were borked up:

Mage in FvF fires 4 vore ball models for his cloudkill attack. If they hit a surface not very far away from the caster (like a wall or the floor), then you fire again (even if you wait like 10 seconds), the QMB purple trails think they started at the last position of the last ones....

http://imgur.com/a/TgR72

Perhaps it's reading the position of the former temp entity which probably has the same edict number as the new temp entity....

Though the issue doesn't occur when a surface is hit farther away from the caster. I believe that's because the former position is too far away from the new position. Ah, yeah, if I shoot a surface far away, then run up next to it, I get the same effect. So the last position must be near the new position.

Aren't you glad you have me to report these weird things instead of having to wait 100 years for them to be found? heh 

Neither 750 nor 550 divide evenly by 4. This is significant for graphics hardware, and even more significant for Direct3D which has less software emulation than OpenGL.

Try 740 x 540. 

@spy - Create and alias. Like in your command line "<engine> +alias qqq quit". Then if you want to have something like "qqq" do quit, then it would.

Looks like there is a "gamemenu.lmp" in Nehahra, I'll make Mark V use that when -nehahra is used, will make the menu normal instead of the very weird one.

@mh - QMB uses tons of inlining and preprocessor macros and initially when I identified problem thought "yeah, let's do a boolean field" and then I looked at the code and thought "Uh ... yeah, how about let's not rewrite the whole thing over a bubble".

@gunter - What MH said about the multiples of 4. Mark V has coding in Open GL and the WinQuake version about that and in screenshots, but Direct3D won't cooperate. Also the Open GL with capturedemo has problems with width not multiple of 4. Not multiple 4 is real pita, but mostly gone in Mark V.

With the Open GL version of Mark V, you can actually add -resizable and resize the Window with your mouse. But I haven't tested it lately.

Haven't mentioned it -- mostly to keep you out of trouble ;-) 

You have to have the console open to do this. 

Mirror can be solid face only? It doesn't work if it's bmodel, like func_illusionary. Is it possible to implement? 

Let me think that through.

I can't have mirrors be a true entity that can moved (like door or wall), otherwise pre-calculated mirror visibility would be issue and even possible map compile tool support couldn't help.

However, func_illusionary can't move. Hmmmm.

However, is problem I think --- func_illusionary is communicated to client through QuakeC and isn't instantly available upload level load but is still rather early ... let me think about it.

Question: Scale of 1-10 ... how important is allowing func_illusionary to do this for what you are doing? Only ask because might be annoying for me to code, but if you are making something worthwhile ... might be worth the headache. 

that's just an addendum to spice up the super secret. I placed a mirror, compiled it and found that mirror almost asks me to try to pass through it. I compiled the new version with func_illusionary and found that the magic was gone. If it's really a lot of work than I don't think it's worth it. But if that is implemented, I think it could be used in many new maps, because people love to make fake window secrets, fake mirrors can be the evolution of that type. 

This is an important difference in the design philosophy of OpenGL and Direct3D.

With GL the specification is god. That means that if the specification says that something must work, then it must work, even if it's not supported by hardware. Typically this means that the driver will drop you back to some kind of software-emulated path. It's historically been a weakness of GL that you have no way of programatically determining when/if this happens. NPO2 textures were a bitch when the first GL2 drivers came out.

With D3D the hardware is god. That means that if something isn't supported by the hardware then the driver is under absolutely no obligation whatsoever to support it either. It might crash, it might give you undefined behaviour, it might give you messed-up screenshots. The downside is that historically D3D has been an unholy mess of capabilities bits and responsibility is on the program to check these and code fallbacks.

D3D does provide software emulation of parts of the per-vertex pipeline for older GPUs that don't support hardware T&L, and you can actually do crazy shit like write SM3.0 vertex shaders in D3D9 and run them on an old 3DFX. But that's the limit of what it emulates, and that emulation is provided by the common runtime rather than by the vendor-supplied driver.

That's another difference.

D3D is actually two separate components. A common runtime is provided by Microsoft, that's what you install on your PC when you install DirectX, and that's the same irrespective of what hardware you have. Then the vendor provides a lightweight hardware-specific driver. Your program talks to the runtime, which talks to the driver, which talks to the hardware. Because the runtime is common, consistent behaviour is easier to achieve. Because the driver is lightweight there's less for the vendor to screw up. There's also potentially less for the vendor to optimize, and D3D doesn't have extensions.

With GL the vendor provides everything. That means extensions and potentially better optimizations, but also means more room for driver bugs and inconsistent behaviour. The total absence of GL conformance tests for such a long time didn't help. God only knows what goes on inside some GL drivers.

None of this will help anyone fix any issues, of course, but it might help some understand why things are the way that they are. 

I'll see if I can add it. 

Good news: the new Mac build will appropriately find id1 if it is in the same folder.

Annoying news: if id1 is NOT in the folder, it will crash (after pressing the Play button to get past the args dialog).

I can send you the full diag output if you like, but here's the interesting part of the stacktrace for the Quake app:

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 libsystem_c.dylib 0x00007fff9a93809e flockfile + 4
1 libsystem_c.dylib 0x00007fff9a939a66 fputs + 72
2 com.quakeone.mark-v 0x000000010c2d9f1a Con_DebugLog + 266
3 com.quakeone.mark-v 0x000000010c2d9a71 Con_Init + 1249
4 com.quakeone.mark-v 0x000000010c2497f2 Host_Init + 98
5 com.quakeone.mark-v 0x000000010c2d7ff9 -[QController newGame:] + 2249

And for the GLQuake app:

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 libsystem_c.dylib 0x00007fff9a93809e flockfile + 4
1 libsystem_c.dylib 0x00007fff9a939a66 fputs + 72
2 com.quakeone.mark-v 0x000000010e15f40c Con_DebugLog + 266
3 com.quakeone.mark-v 0x000000010e15f018 Con_Init + 635
4 com.quakeone.mark-v 0x000000010e155525 Host_Init + 91
5 com.quakeone.mark-v 0x000000010e1a97f1 -[QController newGame:] + 1209


Maybe Con_DebugLog is unhappy that there's no folder to put the debuglog in. 

Different thing: I did a quick test of the install and uninstall commands.

For a separate game folder (tested using digs01) everything worked as expected.

For a "bare" map that got installed into id1\\maps (tested using czg03), uninstall didn't quite work. Output from qconsole.log:

uninstall: folder "/Users/jbaxter/Downloads/mark_v_mac/czg03" does not exist 

Thanks for giving the Mac version a test.

1) Mark V Mac not in Quake folder with id1 = console debug angry = will fix. I think at one point I decided the binary needed to be in a proper Quake folder, and then I changed my mind (or something to that effect).

2) Uninstall of simple map - Mark V plays it dumb and only looks at what is out there. So uninstall only works on a gamedir. It would have a way to know what maps are part of set and since Mark V doesn't know, it can't do that.

/In the future, it is a near certainty that Mark V won't unzip anything and just use single player releases from their zip file. This will allow future Mark V to peer-to-peer transfer a required .zip for a coop game, instead of each file. 

"install" is very flexible and should be able to install most single player releases or even traditional mods via URL.

Install via URL examples

1) install http://quake-1.com/files/maps/undergate.zip
2) install http://quakeone.com/proquake/frogbots-099.zip

Doesn't matter how the .zip is packed, provided it has a .bsp, .pak or something that looks playable. Mark V looks at the contents and figures out how to unpack it. Name of .zip determines gamedir. So warpspasm.zip will end up in -warpspasm

Can only do zip files (no .rar, no .7z). Must be http, no ftp or https. 

Cool lighting gun effects, I also enjoy the jerky+normal setting...fun!

Capturedemo still gives a black video with sound. Upon looking at the .avi it shows that the data rate is 28kbps and the audio rate being 1440kbps. Clearly it just isn't recording video data.

You said something about this releasing having a link straight to the codecs? I came to the same site when clicking the codec link.

Sounds at 44k is still airy but that's damn possible it is how it is. Maybe it is how QS interacts with my sound driver. The more I try to listen for it the less apparent it becomes. 

Install this (tested on 2 separate Windows 10 machines to make 2x sure)

Google WebM/vp80 (mirror):
http://quakeone.com/markv/mirror/vp8vfw-setup-1.2.0.exe

Source page: http://www.optimasc.com/products/vp8vfw/index.html

But yeah, install the VP80 codec and that issue should go away.

Make sure capturevideo_codec is auto (default value), Mark V will use VP80 as first preference when looks at installed codecs.

/Says something about 32-bit only on that site, they are so very, very wrong and apparently the creator of that page is unaware of the WOW subsystem (Windows on Windows).

/I'm still mad at that DivX site. 

I haven't had time to update the page yet --- I'm hoping to clear the queue of outstanding stuff for Release 1.1 tonight.

- QMB particle rework for Gunter.
- Alpha channel texture support for 2D replacement elements
- Pulsar mirror on func_illusionary request
- Nehahra use gamemnu.lmp instead of dumb mainmenu.lmp (spy)
- Mac startup if not Quake folder (johhny)
- IPv4 address prints strangely on Mac.
- Maybe hopefully: WinQuake via GL for killpixel 

https://youtu.be/MGyxKckTaH0

Very cool, that'd be it.

Couple of questions:

When capturing the demo, if you open the console it will speed the recording by a substantial amount. I found that whenever the console is brought down it is not recording. Intended?

Anyway to jack up the quality...bitrate? (Purple noise and general noise in video linked). Even if there is not, this is a pretty nice feature considering we have here 720p @60fps :)

Thanks for your efforts. 

I think you might have a typo in your command line or are missing -nehahra, because I already coded for this scenario.

Nehahra should be started as:
Console: game nehahra -nehahra
Cmdline: -game nehahra -nehahra
Cmdline: -game nehahra (won't work properly)
Console: game nehahra (won't work properly)

The above should fix. 

Type "find capture" in console. If you haven't discovered this, it is super-awesome.

You'll see one of the things is "capturevideo_console"

When that is 0, it won't capture when the console is open. This is to avoid ugliness if you type "capturedemo" in the console --- you don't want 1 second of console closing in your AVI ;-)

I'm very happy it is working for you.