heres the demo of two bots dueling each other on zed2 - the vondurs property

i'm using mark_v to record the demo, and my fov is something like 135/145

but when i try to replay the demo something's strange has happened to me, using mark_v 0/99

the latest ad_1/60 engine(quakespasm-admod) has been playing the demo ok 

zed2 map

http://quaketastic.com/files/demos/fbots20.rar 

you cannot change the fov value while watching the demos in mark_v 

Downloaded zed2.bsp map and played your fbots20.dem.

Changed fov several times ok, didn't experience any problems.

I believe you, but I can't reproduce what you are experiencing but maybe something will come to mind eventually. 

take a look at these screenies
http://quaketastic.com/files/screen_shots/fov.rar
yeah i can change the fov value, but the viewing perspective is a very weird in mark_v 

My initial guess works like this:

Mark V has angle smoothing, which is not obvious in single player. An online player can immediately tell.

It looks like Frogbots use some sort of QuakeC evil to move the camera around (jerky style) that isn't compatible with camera smoothing.

I didn't invent camera smoothing and in fact several engines have it, Quakespasm isn't one of the engines that have it.

It is possible you found a special case no one noticed before. 

I get a consistent "Mark V has stopped working when trying to play a demo. Doesn't seem to matter what, but specifically now I am trying to play jam 9 demos.

Windows 10, 64-bit using latest MarkV release.

Happens in any version (DX9, 8, markv.exe)

Let me know what else I can provide! 

Ugh annoying when the solution comes to you moments after finally giving in to ask for assistance.

I attempted to switch to jam 9 using the game command in markv. But running a shortcut with the -quoth -jam9 is what worked. 

Happens. Glad you figured it out. 

there's this Admer guy at QuakeOne having trouble running Mark V. I told him I'd drop you a line, so for troubleshooting purposes you might wanna check posts #55-58 here.

Also, a few posts above those, Dutch states that he's experiencing a notable performance drop with the latest DX9 exe. 

I look at issues posted in this thread by the individual having the issue. There is a link to this thread on the Mark V page.

Keeps everything organized. 

Dutch probably made some setting that harms his FPS. Like r_shadows 3

He should try a clean install.
Same with the other guy who it won't run for -- completely new install in a new, clean Quake folder. 

Looks like an experimental map (an awesome looking one at that).

If that map gets released I'll see what is going on.

It could be one of a million things (vis, a texture, a skybox, external textures, a lit file, entity error, parsing issue, a texture name, a setting in Mark V even.). 

Hello, Baker. I'm the guy who can't run Mark V.

I tried what Gunter said, but the same problem still happens:

- I open the .exe
- RAM usage is at 9628KB
- After 15 seconds, the RAM usage jumps to around 46MB (I'm assuming it loads some game files)
- The .exe simply exits without a warning

In short, it won't run at all.
Sometimes, this happens:

https://i.imgur.com/JhSK4qI.png 

Yeah, it was a clean install, straight outta the box. New directory and everything. No old cfg files, lifted it all off my quake CDrom from '96. It's probably the r_shadows cvar. 

There should be a qconsole.log file in your Quake folder after you start Mark V.

Can you paste the text of that? 

That Microsoft crash report, could you post the text of that as well. Often the crash report text can indicate where something crashed.

What version of Windows are you using?

And I assume you are using current version of Mark V? 

Dutch, if you happen to be testing in the Start map, make sure to set r_mirroralpha 1 to disable mirrors. Mirrors are enabled by default (really shouldn't be). They are bad for my FPS.

I don't think any other FPS killing settings are defaulted on. r_oldwater 0 is another one that harms my FPS, but that isn't set by default. Assuming the secret hidden cfg file isn't retaining any non-default settings when you do c clean install....

You couldn't possibly be using a slower/older computer than I am (XP Netbook!).... I get between 40-75 FPS on the Start map, depending on what the lava balls are doing, as long as I don't have too many extra features enabled.

Hm, and if you happen to be running in a window, and you have some other program on screen that is drawing stuff, that could cause a problem too. I have a program called BitMeter, and it will destroy my FPS if I have it showing while running DX Mark V in a window.... 

I'll see about the crash report later today, because I'm currently using my phone. I remember it was referencing 3 files located in Appdata/Local/Temp.

My OS is Windows 7 (32-bit) and yes, I'm using the current version of Mark V, or at least that's what I think.
I've downloaded it here: http://quakeone.com/markv/ 

Slight correction: Windows 7 SP1.

I copied the 3 files in another folder:

https://i.imgur.com/33g4ZtZ.png

WERD147.tmp.WERInternalMetadata.xml
WERECF3.tmp.appcompat.txt

Should I send the .mdmp file? I'm a noob at debugging. 

I am on Windows 7, although not 32-bit.

The quake\id1\qconsole.log would be helpful. It is the log file Mark V writes out. 

Here are its contents:

Command line: [ ]
Log file: C:/Games/Quake/id1/qconsole.log
Sat Sep 09 18:17:08 2017
Mark V Windows (Build: 1036)
Exe: mark_v.exe (1327 kb)
Exe: 22:32:27 Jan 19 2017
Caches: C:/Users/kliker/AppData/Roaming/Mark V/caches
UDP4 Initialized: INADDR_ANY, 192.168.x.xxx
IPv6 Initialized: [fe80:0:0:0:a59f:53f6:4528:9fe7%41]
Exe: 22:32:00 Jan 19 2017
256.0 megabyte heap 

1) Do the WinQuake or Direct3D versions run?
2) Is there an opengl32.dll in your Quake folder?

I know Quakespasm runs on your machine, so it shouldn't be an Open GL issue although Mark V uses some Open GL capabilities that Quakespasm doesn't.

If there is an opengl32.dll in your Quake folder, you should delete that. But since DarkPlaces seems to run for you, I can't see how you could have a (toxic) opengl32.dll in your Quake folder. 

Baker, compile a debug build for him, keep hold of the exact pdb file that msvc generates when compiling said debug build.
Send him the debug exe, get him to send you the resulting .mdmp file.
Open the mdmp in msvc.
Then you can see the stack etc, and inspect many of the variables that might be relevant etc.

That or rip the stack trace code out of FTE's win32 port. That would allow him to simply paste you a whole list of function names which is usually enough to figure out where it crashed (although not always what actually went wrong).
This of course requires no pdb files, so hurrah for that, but it won't show line numbers etc.
Still, if you expect your code is going to crash then its quite handy... 

Ywah, the strangeness/uniqueness of Admer's problem is has been making me think about improved crash data.

Can't do anything tonight, but I'll ask you questions tomorrow or Monday about what you are referring to in FTE.