News | Forum | People | FAQ | Links | Search | Register | Log in
Fitzquake Mark V
I wasn't planning on doing this mini-project, it started as an effort to address some Fitzquake issues, fix them the right way up to Fitzquake standards (i.e. do it right, once and properly versus continual releases) and donate it back.

FitzQuake Mark V Download:

http://quake-1.com/docs/utils/fitzquake_mark_v.zip

Short version: Eliminated most issues in FitzQuake thread, most issues I can even remember hearing of ever and marked every single one clearly with a very minimal implementation.

It may be the case that only metlslime and Quakespasm and engine coders may find this engine upgrade of interest.

Features: 5 button mouse support, single pass video mode, external mdl textures, alpha textures (like RMQ), record demo at any time, rotation support, video capture (bind "capturevideo toggle"), console to clipboard, screenshot to clipboard, entities to clipboard, tool_texturepointer, tool_inspector (change weapons to see different info), clock fix, contrast support, fov does not affect gun, gun displays onscreen, Quakespasm wrong content protection, external ent support, session-to-session history and .. (see readme).
First | Previous | Next | Last
@gunter 
Very nice little camera providing illustration.

Yeah, Mark V acquired some movetype enhancements/clip links crash fixes from Quakespasm Spiked. 
The World's Most Explosive Bug Report 
your website has a typo "frequenrly" 
Damn 
 
 
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! 
@baker - Gamedirs 
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. 
Quexpo 2116 
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! 
@johnny -- Yeah I Fixed That Now ;-) 
 
We don't make typos.

Just syntax errors.... 
2116 - 1996 = 110? 
 
Never Was Good With Subtraction 
 
 
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 
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.... 
 
Gunter ... do cl_autodemo 1

If you ever have that happen again, upload the autodemo (the most recent demo living in your id1 folder or whatever gamedir you are using).

Mark V cl_autodemo only keeps 3 autodemos at any time so it isn't a burden or resource consumer. 
 
Got it.


And m_filter was probably the mouse smoothing thing I Was thinking of.... However, in Mark V:

]help m_filter
Console variable: (TODO: UNUSED -- remove)

Doh.


Also, I tested on the older WinXP laptop, and vsync did indeed work in GL Mark V. I guess my netbook just doesn't handle the GL vsync techniques correctly.


+zoom_key -- I think you are setting the sensitivity too low when this is used. 1/10th standard sensitivity seems better (10%). Looks like you're using 6.25%


There's an issue with the Winquake version if you run in a window with the vertical resolution set the same as your screen height. Like if I run in an 800 x 600 window on my 1024 x 600 netbook. The HUD is chopped off at the bottom of the screen. 
First | Previous | Next | Last
This thread has been closed by a moderator.
Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors.