This old version is looking good though....

I'm pleased that you decided to revert to Quake Defaults for most things, with menu options to change them.

Some of the previous minor issues I had seem to have been fixed.

Nice. 

It's always just out of reach, but so close to begin just right.... And Baker never has time to work on it, heh.

I do wish I could use the most recent Mark V, but like I said, everything past mark_v_e just crashes (with one of those Microsoft error reports, if you would like all that mass of information....).

I can use the winquake version of the newest mark v, but of course winquake looks like butt :D (Arrgh, and it's got RCON in it... I so wish the old version that I can use did too!).

It does seem a lot of the old bugs were fixed, but I'm also seeing new issues that didn't exists in my previous old old version, r15.

For example (these issues also exist in the new winquake version):

No particle trail on vore balls. What happened to them?

The FPS display is in the top right... but if you size the screen area down, it does not stay in the top-right -- it just vanishes (or is not being drawn, or is hidden behind the "brown screen border").

Why did the HUD move to the center (single-player style) instead of moving to the left edge (deathmatch/proquake style) like it used to, so you can also display some player names in the extra space....

In the winquake versions only, if I set the screen to an 800 x 600 window (my netbook screen is 1024 x 600) then the HUD gets cut off at the bottom of the screen (pushed down too far, really -- looks like the full-screen console is the same way), by about the same amount of space that the title bar takes up at the top of the screen, maybe.... You might be able to replicate this by setting a window height to the same resolution height of your screen?

Eh, there are other bugs, but it looks like they have been fixed in the newest version (judging by the winquake one).

What are the chances that the GL version will ever be fixed so that it will work on my WinXP Quake netbook again? ... I suppose that's moot, since Baker has no time to work on it anyway, heh....


I tried Quakespasm. Oh my gosh, it runs like ass. I don't know what it is, but some effect it's creating causes the frame rate to be like 10 FPS on my netbook, in the entry area of the Start map, unless I turn and face a wall. Seems like the colored lights or something; it depends on where I'm looking. I promptly deleted it, and will continue to use the old version of Mark V.

*sigh*

Well, it's still better than any other client for me, but it's always just SO CLOSE to just right! D: 

Does the Direct 3D version run?

http://quakeone.com/proquake/interims/mark_v_20160207_directx.zip

(Voreball trail is probably a mistake in a last beta build which involved a change regarding model flags, easily fixed. If the DirectX version runs for you, I'll fix bug and post an update.)

I don't normally include the Direct X version because Microsoft --- and only Microsoft out of 53 anti-virus providers --- says it is a trojan or something crazy. 

Well, Microsoft ended support for WinXP, so I had to uninstall MS Security Essentials, so I definitely won't be getting a security warning! Hey, my netbook still makes a find Quake device! :D


Yep, that DX version works, and looks nice. At first I thought it would not be usable, because I was getting only 10 FPS, but then I switched to full-screen mode and it works fine! I guess DX doesn't like running in a window. I generally prefer to run Quake in a window so I can easily switch around to other things while I'm playing, so I can look at config files and make notes about bugs I find in Fitzquake ;) but I will definitely use this, even if I gotta go full-screen now!

Excellent!
Thanks very much for that!

While you're fixing the voreball particles, here's my quick wishlist for three ProQuake-type features that you might consider adding in (because these should be pretty easy additions), listed in order of assumed simplicity:

Colors 14/15 (just a simple option that gives players more choice)

Proquake style Centerprints -- they appear near the top of the screen (just below the chat area) instead of blocking the view directly in the center of the screen. FvF does use a good amount of centerprints....

Bring back the deathmatch-style HUD... the way it used to be in Fitzquake (and ProQuake), over on the left (with extra player names on the right), instead of centered at the bottom single-player style (with no extra player info), as it is now....



I have another issue that is FvF-related (not really that important, but I will report it). FvF does not allow blank names, and will automatically assign a default name if someone tries to name themselves "". Well, during a game if I go to Multiplayer -> Setup, and try to erase my name to change it to something else, as soon as I erase the final letter of my name, that means my name is "" and FvF instantly assigns me a default name, heh, so I can never fully delete my name in order to change it to something else. I don't think the name should be "set" until the player is done editing everything and "accepts changes." (This didn't happen in old old versions of Fitzquake mark v.)


Anyway, thanks again for the DX version!
Best Quake Client so far, for my needs! 

I tried Quakespasm. Oh my gosh, it runs like ass.
Only if you're interested,... it would be nice to know why that is the case. If MarkV GL runs well, it's 99% likely just a configuration difference causing the slowdown, since QS may have different defaults(?).

I guess I should add this to an FAQ for QS, the settings to try for a low end laptop: (try each setting in sequence, checking if it increases FPS in start.bsp)
- use fullscreen
- r_oldwater 1
- gl_flashblend 1
- r_dynamic 0

Less likely to help: launch with command-line args:
-bpp 16
-novbo
-noglsl

Also what is your gfx card / and which driver is reported by "gl_info"?
Sorry for the spam, Baker 

scr_sbarcentered 0 

@ericw --- if someone says GL version low fps or problems and then says the words like Netbook or Windows XP or even hints at "old computer", it's always Open GL drivers.

I just say "DirectX version" and then they say "Works fine. 200 fps. Thanks!" It's 100% problem solver in that department. 

Agreed, I just thought he mentioned that GL markv was running reasonably while QS was giving super low fps. 

yeah, or they could scrape the internet looking for the right opengl drivers, find lots of 404s, and the resign themselves to buying something that is actually still supported!... stupid laptop manufacturers that refuse to allow the chipset manufacturers to provide generic drivers...
or yeah, they can use d3d.

FTE has a d3d renderer too... :) 

Would you be willing to try Ericw's list of settings in Quakespasm to see if it works --- I bet the -bpp 16 may make a bit difference.

And then do a review of Quakespasm from the perspective of someone who runs a standard ProQuake Quake server (GLQuake compatible, Quake protocol) and plays online? 

Another cvar to try: r_flatlightstyles 1 -- it removes styled lights without sacrificing dlights the way r_dynamic/gl_flashblend would. 

Ah, thanks, Baker. scr_sbarcentered 0 is just what I wanted.


ericw, r_oldwater was the culprit. As soon as I turned that off, the FPS smoothed out DRAMATICALLY (running in an 800x600 window, it went from 6 FPS to just over 60, standing in the Start map, looking at the 3 teleporters and lava -- all water surfaces). Oddly, running full screen seems to give me about a 10 FPS decrease....


And gl_info returns:

intel
intel 945GM
1.4.0 - Build 7.14.10.4926 

Oh, and this probably can't be helped (I skimmed over mh's post about fog, above), but the fog in DX Mark V is rather unsmooth compared to the OpenGL Mark V.

http://imgur.com/a/fNE7a

It's hard to get a good still image of the effect, but you can tell the lower image is much more "line-y" even in areas that aren't so dark on the wall. It's really noticeable when walking around, because you see the fog lines moving across the walls.... The OpenGL version had a much more subtle effect, and seemed smoother and much less noticeable on most surfaces.

I guess this is just a result of DX not doing fog as well or something? Probably not a setting to smooth that out.... Too bad; I like a little fog. Give a nice sense of depth. 

Are you interested in doing a review of Quakespasm from your perspective?

Most of the feedback Quakespasm receives is from single-player only types.

Diversity of feedback is what makes an engine better and helps developers have a broader point of view.

(re: fog --- Yeah, I have no control over Direct3D differences in fog rendering. Probably midday tomorrow, I'll try to rebuild fixing missing voreball trail. I probably stripped the flag.) 

that fog banding is interesting, because both shots have the same number of bands, but somehow on the lower shot it's more noticable.

If you look at the darkest parts of the image, like the wood pillar on the left side, it's clear that the lighting ramp is different -- top shot appears more blown out (slightly) -- i wonder if that's why the banding is more noticable in the bottom image, because the lighting is darker so the fog grey color has more higher contrast to the black walls.

Anyway both shots look bad, and this is a good example of why fog is difficult to make look good. You need to avoid solid colored patches of the scene, (such as a pitch black wall) since only the noise of textures and lighting can hide the banding that will always occur. 

ericw, r_oldwater was the culprit. As soon as I turned that off, the FPS smoothed out DRAMATICALLY (running in an 800x600 window, it went from 6 FPS to just over 60, standing in the Start map, looking at the 3 teleporters and lava -- all water surfaces).

Thanks! Glad that worked. 

I guess this is just a result of DX not doing fog as well or something?

GL or DX don't actually "do fog" at all - your GPU does. All that GL or DX do is provide your program with a means of saying "draw this polygon with fog", but your GPU does all the actual drawing.

With everything else being equal, there should be no difference whatsoever between images produced by one API versus images produced by the other, because it's the same GPU that's doing the drawing; all that the API does is send commands to the GPU.

On the other hand, DX does provide a handful of extra fog quality/performance options whereas GL hides them all behind a single glHint (GL_FASTEST/GL_NICEST), and allows the actual result to be implementation-dependent.

One possibility is that one of those extra options, if configured, would resolve it.

Another possibility is that the projection matrix isn't configured correctly in the DX version, causing loss of some depth precision, causing the extra banding. 

Baker, I'm afraid I just find Quakespasm off-putting for various reasons, but I will try to give it a test drive, since you asked....


So, it seems that now DX Mark V is running fine in a window... I'm not sure what changed (I often delete config files when testing), but most likely it was just me rebooting my netbook after testing no-telling-what last night.... In any case, the DX version is now running just as smoothly as the older OpenGL one, even in a window.

But here come some bug reports! heh

Your default lava color is incorrect!!!!!

Haha, yeah, this is a minor niggle, but your r_lavacolor is "255 80 50 150" and the Quake default should be "255 80 0 150" (search for "lava" here to see http://unix.superglobalmegacorp.com/quake1/newsrc/Quake/view.c.html )

It does alter the color a bit... Of course, the lava intensity needs to be dropped to about 100 for my tastes; in standard Quake, if you were in lava you were dead, so it didn't matter that it was blinding in there. But in Runequake and FvF, there are ways to be in lava and not be dead, so you need to be able to see a little bit... 100 looks good to me (it's still lava, after all!). Normally I'm for keeping the defaults, but in this case, it would benefit from a slight change. Though I'm afraid I don't like the "light" blends in Mark V though -- way too transparent. But as long as it defaults to the defaults, that's fine. And Mark V provides the ability to change them to tastes, so that's fine too.

All other blends look good to me at Quake default, though for some reason the Ring blend looks a bit heavy. Maybe I'm just used to all the Quake clients that made it too light, but is there a variable to adjust the Ring blend? Hm, it does look like the cshift_powerup stuff for invisibility is the highest % on that page I just linked. I guess it's supposed to be that way.


Speaking of invisibility... I really liked that "always draw weapon when invisible" option in the old OpenGL version of Mark V that I was using... It made my weapon transparent. I like little tweaks like that which enhance things without really drastically changing the default Quake feel.

However, in the new DX version, the weapon just stays completely solid, and in the Winquake version, the weapon is completely invisible again... (of course I can't test the newest OpenGL version...). I wouldn't expect the Winquake version to do good transparency, but it seems the option, in that case, should leave the weapon completely solid. Which I actually don't like (laugh)! 

Ok, so, I find this interesting too, though I am clueless as to the internal stuff.

I cranked the gamma and contrast up to max (for the sliders) and made some more screenshots.

OpenGL (older version of Mark V) is on top, and the newest Mark V DX version is on bottom....

http://imgur.com/a/pkjip

You can see the ugly square of fog over the close wall in the bottom image.... Though it turns out, in the top (OpenGL) image, the fog is actually extending farther toward the "me" in the image -- that's why the left edge of the first image looks lighter. The OpenGL fog still somehow looks better/smoother (even in this forced setup). I'm not changing any other settings -- just switching which client I run.

Here the same angle with fog off, and they are pretty much identical:

http://imgur.com/umSZFPC

You can only tell them apart because of the odd lighter shadow under the grenade launcher in the OpenGL one -- I don't notice that in game, but the screenshot seems to capture it, same as the first image I posted upthread. Uhh... for some reason, imgur may resize the view so the odd lighter shadow is not visible o_O But trust me, it's there in the original image, heh.

Ok, now the most interesting image.... I changed my position to emphasize the fog distance difference:

http://imgur.com/RhCrSig


Now look at that!

The fog does get closer to "me" in OpenGL, but also the bands on the wall are not all straight and parallel, which actually helps them not seem so ugly/uniform/bandy/unnatural.... And especially in the lit areas of the wall, the GL fog looks much better than the DX. This is what is pretty noticeable in play, under more typical lighting conditions.

There's also some difference in the interaction of the fog and the teleport texture. 

Image 3 settles it - there's a different fog range calculation being used depending on the API.

That's going to require a code change and a whole bunch of testing to fix up though. 

While testing Quakespasm, I looked at the fog (looks good - identical to the OpenGL images above), and I noticed what is causing the difference.

The fog is BEHAVING differently... and this would be hard to capture in a non-animated image, and it may be difficult to describe. But you should be able to replicate this yourself if you wanna see it in action. Just ramp up your brightness and contrast in Quake, and go to the entry room for E4M8 and look at the black wall opposite the portal while walking forward very slowly, or even looking left and right a bit. Oh, I also use a very light fog setting 0.03

The GL fog is JUMPING along the wall, in small sections at a time. That's why the bands in the GL screenshot are not perfectly straight lines -- one section of the line will jump forward, then another section. This actually makes it less noticeable on the walls when you are moving around, because you don't see any "movement" -- a line doesn't move across the wall, it just suddenly is there or isn't there, and that's really hard to notice when you're moving around, especially with the lines being not perfectly straight due to them jumping unevenly.

The DX fog is MOVING very smoothly along the wall, in perfectly straight lines. It looks bad because you easily see the movement of straight lines smoothly scrolling across the walls.... 

Ok... animated images... Keep in mind the colors will be extra ugly for being compressed to a GIF.

Just barely creeping forward you can see how the GL fog jumps in small sections, instantly. There are no missing frames in the fog's positions:

http://imgur.com/grwHCPv


In DX, moving forward a big faster, the fog evenly scrolls across the wall. There are lots of missing frames of fog position in the animation.... I'd describe it as similar to interpolated movement, if that makes sense, because it moves very smoothly across the wall.

http://imgur.com/sTbVMuU



Is there any point to doing/discussing this?
Who knows!
I just do the testing. It's up to other people to do anything about it ;) 

Windows Build

Vore trail fixed, "submersion in lava" color slight typo fixed.

/Took a quick look at the DX transparent model with invisibility ring. Oddly discovered it doesn't look like FitzQuake 0.85 ever had a pathway to use model transparency if the driver doesn't support combine (the Direct3D wrapper does not support combine) --- so may not even be possible (didn't expect that). The non-combine rendering pathway does a series of operations that already use blending but it isn't alpha blending -- so that's probably one reason FitzQuake uses combine in the first place. A bit annoying.

I don't have time to do anything of substance on the engine, but the above 2 things were 2 minute fixes.

But in the future when the day comes that I have that time, I always read all the notes. 

That's interesting, i don't remember whether i added that support or not (but i would have assumed i did.) There is this comment in the readme:

- fullbrights now use additive blending instead of alpha blending. This allows me to support external glowmaps, and entity transparency with fullbrights/glowmaps. In some cases, additive fullbrights are rendered using multitexture, but only if GL_EXT_texture_env_add is available. The command line option -nocombine will disable the use of GL_EXT_texture_env_add.

This implies that without combine, models with fullbright masks are rendered in two passes. It doesn't say that they are rendered correctly with alpha though... hmm. 

It is probably a virtually non-existent situation.

I've not seen an instance of someone using .alpha on an alias model in a single player release. And there probably aren't any Open GL drivers that don't support combine.

It's just that the Direct3D wrapper doesn't have combine ability written in the code and that Mark V offers a "gun with transparency" option when invisible, instead of Quake not drawing the gun at all.

/But the brush models don't suffer this problem in the Direct 3D + no combine scenario (I tested against back2forwards which uses .alpha for glass). So at some future date when I have time to chart out the rendering, I should be able to rewire something --- assuming I would do that instead of maybe taking a shot at adding combine to the Direct3D wrapper.