@johnny .. call it Mark V.

(It was supposed to be a FitzQuake patch and a engine coder bug-fix tutorial --- qbism used it for that a lot --- not a separate engine. Spike may be reliving that with Quakespasm Spiked a little. I wasn't ever looking to usurp the FitzQuake name, I was originally trying to help metlslime locate engine fixes discovered at inside3d in the hopes his unreleased FitzQuake might happen.)

@gunter -- yeah, let me know. I care. And thanks for isolating the intermission cam thing. I'll be checking it out. 

I see your angle, got it.

Originally, I thought of making it compatible with that.
hd/id1
hd/travail
hd/hipnotic

However -- since most replacement content users are Quake experts ---

I stuck with the simple method that allows a user to shoot themselves in the foot -- Over a complex method that is very precise but that could be a little annoying.

Most content replacement users know what they can and cannot do.

What are your thoughts on this? Do you think I should change it? I want this to work in a manner that other engine coders (you, metlslime, Quakespasm, etc) find acceptable. 

Very nice little camera providing illustration.

Yeah, Mark V acquired some movetype enhancements/clip links crash fixes from Quakespasm Spiked. 

your website has a typo "frequenrly" 

 

Oh, it seems I wasn't including the most recent .qc source code with that demo. I guess that might matter a little if you were trying to follow along in the code to see everything.... I updated it now:

http://www.fvfonline.com/camtest.7z


It seems to work for me without the glitch in Quakespasm Spiked, which I downloaded from the link you posted above. 

If you set the movetype it works correctly in Mark V, right?

Either way, I'm still going to look into it because it is a behavior difference (I hate those, no matter how small). 

Correct, and agreed. 

Cool bug, Gunter! You've caught something that would almost never surface.

Explicitly requires a multiplayer scenario and that reading the code, everything looks great. 

This bug could have gone uncaught for 100 years. 

Would be awesome if people still played Quake in 2116! 

What are your thoughts on this? Do you think I should change it?
My thoughts are that anything that requires setting console variables will suck. Anything that requires the user to be aware of filesystems will similarly be crap.

Make it a menu (like fte's menu_downloads [but more polished] or whatever). Then the filesystem becomes irrelevant and much easier to install high-res stuff (and also get rid of it again without breaking stuff).

Also, configs do kinda need to be part of your replacement content, if only so that you can enable/disable nearest filtering (and other equivelent settings that vary from one engine to the next). 

Well, I AM an insane code hacker. I live outside the box and push things to their limit -- which is also why I find so many bugs!

There's all kinds of crazy stuff in FvF. More people need to play FvF. The reason I do weird stuff with the intermission camera is so players can DANCE during intermission! Heh. I got that idea from Unreal, where the winner of the match would be shown during the intermission, and he could do taunts like the pelvic thrust. So I added that to FvF (we can vote into Deathmatch mode, though you can dance in Quest mode too). I gave the player 10 different dance moves to perform! Come and try it, people.

Yes, I'm self-promoting! We usually have "Sunday-night FvF" as the pre-planned time to gather and play each week.

http://fvfonline.com
connect fvf.servequake.com

;) 

@spike - I like my Quake simple which is why I like FitzQuake.

I don't even like menus, my engine has 1 more preferences menu than I like (because I would prefer zero).

I just like it to be simple.

I think users that are that serious that they need something like that -- need to be using an FTE or DarkPlaces. 

@gunter -- I was pursing a false lead, but I obsess about little behavioral differences like that. I'm going to overcome that and slap a "to be continued" on it since it's a Friday night. 

Celebrating 110 years of Quake.

Exhibits:
Latest Engine updates to Mark LVI
Arcane Dimensions 3, so big we had to upgrade Mark LVI and QSS 101.5 to support bsp4 and protocol 77777.
QmasterIII's celebrating the release of his great grandfather's mod released in 2016 by adding aupport for AD2! 

typo fixed 

We don't make typos.

Just syntax errors.... 

 

 

Hm, so vid_vsync simply does not work at all in the GL version (or Win version)?

In DX, changing the value gives a warning about it taking effect after mode change, and upon mode change (changing the resolution) the FPS will be clamped to 60 no matter what I have host_maxfps set at. And then everything looks smooth.

But in GL there is no warning and no change in FPS....

Can vsync not be made to work in GL (or Win)?

Also, since it requires a "mode change" it might be better to stick the vsync setting in the resolution menu so that it can be "applied" like any other mode change, but even without having to actually change resolution.....



Also, wasn't there a "mouse smoothing" thing in Quake at some point? I know there used to be the -dinput command line option.... My mouse movement does not seem very smooth. Er, well, I am using a touchpad on this netbook, heh, but still.. it is pretty un-smooth.

Let me plug in a usb mouse....

Oh! That's MUCH smoother with an actual mouse!

So I guess my question is: Is there any way to smooth the motion of my netbook's touchpad? heh. Shut up! I know I'm the only person on Earth who plays Quake with a netbook touchpad!

I have "mouse acceleration" disabled already. I hate that. 

Vsync in Direct3D is part of the specification. In Direct3D 8 or 9 you select it by setting PRESENT_INTERVAL_ONE (vsync on) or PRESENT_INTERVAL_IMMEDIATE (vsync off) when you create your Direct3D device. To change it you setup new present parameters with the appropriate options then Reset the device: the moral equivalent of a mode change. Direct3D 10+ is nicer: it's just a parameter on the Present call (equivalent of SwapBuffers for GL). To change it you just use a different value; no Reset or mode change needed.

Vsync is not part of the OpenGL specification because the OpenGL specification leaves that up to the OS (sometimes one wonders if the OpenGL spec authors take tips from Sir Humphrey Appleby). Typically on Windows it's implemented by the WGL_EXT_swap_control extension, although it's entirely possible for a vendor to define their own extension for it. Because it's an EXT extension, drivers aren't obliged to support it.

So if your OpenGL driver doesn't have an extension for vsync you don't get to have vsync in OpenGL - even if vsync works in Direct3D on the same hardware and OS.

In cases such as that you might find a setting for vsync in your driver's control panel. 

Hm, no vsync options in my limited OpenGL control panel.

I guess I will stick with the DX version, after all that hassle getting the GL one to work, hah.

Oh well, the mirrors look cool, but they actually cause a pretty big FPS decrease for me anyway. 

@gunter --- Like MH said ...It's your Open GL drivers. Your log says "Swap Support" found. So Mark V tries to use it. Apparently when it tries to use it, nothing happens. 

On the other hand... it seems I'm still getting the intermittent crash on level change with DX....

Dr. Watson says the crash was caused by "access violation."

I guess I'll run with -developer and wait for it to happen again to see if the qconsole log has any information....