"Quakespasm contrast not working is probably the result of one the command line options required to make Quakespasm run on your netbook. Try removing one of those command line options and see if it runs. "

I'm not using any command line switches (other than setting resolution). I can run Quakespasm just by itself and still no Contrast adjustment (same with the Quakespasm-sdl2.exe). I tried adding the -fitz switch, and that didn't help either (although then the demos play, when they normally don't in Quakespasm).


"I think ring of shadows hue is too dark. "

Yes, I agree. How about a console variable to adjust that?


I cannot get monster skins to work in Quakespasm.... They work fine in Mark V, and all other textures work in Quakespasm, such as walls, items, and weapons. Just not the monsters, no matter where I put the textures, like:

ID1/progs/ogre.mdl_0.tga
ID1/textures/ogre.mdl_0.tga
FVF/progs/ogre.mdl_0.tga
FVF/textures/ogre.mdl_0.tga

And I even tried the Qrack format ogre_0.png in various locations, just to be sure.

But the ogre stays ugly. Well, I mean... low-resolution ugly as opposed to high-resolution ugly. *shrug* I don't care enough to keep trying to make it work in Quakespasm. 

And... how do I get high-quality monster textures to work? I tried them in Qrack format (png), I tried them in Mark V format (tga), I tried them in various locations (progs folder or textures folder), but they don't show up. Documentation, please!

Some of legacy GLQuake code in Quakespasm interferes with modern operating systems, preventing users from applying external skins to MDL files. To fix this, you need to go into your C:/Windows directory and delete system32. 

Quakespasm doesn't have external texture support for models. Just maps.

In preferences there is an option to lighten the view blends, the ring of shadows falls in that category. Otherwise you have to play with gl_polyblend or r_polyblend or whatever the name is. 

The reason the contrast slider wasn't working is it requres GL2.0+, which the intel 945 doesn't support.
Thanks for all the feedback! 

I didn't adjust the translucency and soft depth levels to match Qmaster's suggestion, though.

It should look even better with translucency, because it's multi-layered. 

Ah, gl_polyblend is something I can mess with, though I really would like to be able to adjust only the ring blend, and not ALL the blends, because I think the others are ok. If I turn the ringblend down to where I think it looks good, then all the other blends look way too light. I guess I will settle for just toning it down a hair to 0.9, which doesn't lighten anything else too much....

I've also noticed that Mark V allows standard chat behavior during the "level end" scoreboard (i.e., you can still see the chat lines on the screen, and additionally if you are typing as the level transitions, it stays on screen too). Nice touch. This is an old old Quake bug that I hadn't seen anyone else deal with. And we do like to continue chatting in FvF while we dance at the end of a level ;)


On the bad side, I seem to be experiencing a few crashes on level transition both online and offline.... That's gonna be hard to debug on my end unless Mark V can generate error logs. But it seems like it possibly happens more often on certain maps. I'll keep notes on this....

Also, sometimes, when lots of stuff is flying around (especially lightning), I get "warning: 150 tempentities exceeds standard limit of 64." I don't think there's a need for users to see that warning, is there? It's fine as a debug message, but not something the end user needs to see.

And the shadows in DX Mark V are... uh... well, they look like ProQuake shadows where it's like you can see the folds inside the model casting varying intensity shadows -- the shadows don't look solid. In the older GL versions of Mark V, the shadows were a uniform color/transparency.


And just an interesting thing to note: I found out what was causing DX Mark V to run really badly in a window when I first tried it (but fine in fullscreen). I have a little program running that sits in the corner of my screen and shows the network traffic. It's called BitMeter 2. When that is on my screen and DX Mark V is running in a window, my FPS goet to like 6. As soon as I hide the little BitMeter display, my FPS smoooths out dramatically.... It doesn't effect the GL Quake clients I've used, though I have had videos get unsmooth when I try to watch them full screen if I had BitMeter displaying as well.... *shrug* 

baker: i finally got a chance to look at the fitzquake 085 code, it appears that without texture_env_combine, you still can get alpha blending but what you lose is overbright lighting. 

Retroquad doesn't support overdraw between surfaces with the same kind of liquid in the same entity, because in most cases that would be just a waste of framerate. In maps with molten mapping enabled and compiled with lit liquids, that would be a framerate killer.

But I agree that multiple layers of translucent surfaces may give a better fog impression. The lava in some AD maps (playing with QuakeSpasm, as my engine can't run it) looks more like plasma to me due to this.

(Sorry for the off-topic, Baker.) 

@gunter: By the way, in Mark V...

* You can paste text into what you type in a "say" message (messagemode2).
* You can paste text anywhere text input is accepted. In fact, if you hold down shift and select text in the console, you can press CTRL-C and copy text.
* You can also type "copy" in the console and copy the contents of the console to the clipboard.

DX wrapper doesn't have stencil, so can't do stencil shadows. Those smooth shadows are stencil shadows. But even those shadows don't clip. DarkPlaces is the only engine that renders player shadows properly on multiple surfaces that clip.

Warnings. Standard FitzQuake 0.85 printing warnings. But I've seen it confuse more than 1 person. Quakespasm made those only print with developer 1.

Its to help mappers know they are making a map that isn't standard Quake compatible (it won't be playable in Quakeworld like ezQuake, nor playable in GLQuake, etc.)

The DOPA release by Machine Games a couple of months ago is an example of a episode that is actually all-Quake compatible.

@metlslime: Didn't have enough time to check the .bsp code to see what alpha brushes rendered ok. Sounds like you are saying that I would have discovered no overbrighting on those when combine isn't available when I did look. In the future, I probably mimic that path for models with translucency to resolve lack of transparent gun rendering in DX version.

(@mk - it's not off-topic at all. Software renderers matter too!) 

Hm, so if you can't make stencil shadows in DX, how about making the shadows completely black? Perhaps the r_shadows variable could work like wateralpha, and set the transparency level of the shadow. 0.5 might be the standard setting, but a setting of 1 would be a solid black shadow, which would look better than the weird shadows of varying thickness in DX.


I found that setting "noclip 1" caused the HUD area to turn grey. It sometimes flashes back to the HID when other effects are happening.

I tried playing a demo that someone recorded (I believe in Qrack) and it was constantly spamming the console with everyone's pings. I played the same demo in Proquake and it didn't do that. I played my autodemos from Mark V, and they also did not do that in Mark V. So I tried recording a couple demos in Qrack myself (not sure what version of Qrack I have), and they wouldn't play at all in Mark V, and one of them caused Mark V to crash. I tried the same demos in ProQuake, and it also crashed, but it popped up an error message first, "sv_lightstyle > MAX_LIGHTSTYLES"



A possible suggestion: how about overlaying the standard Quake sky over the skyboxes using the skyalpha to make it mostly transparent? Then you'd still have transparent moving clouds in front of the skybox.... Maybe just the first layer of clouds, and make the second layer completely invisible or something. 

I'd be curious to see how Gunter's multi-layered sky would look. 

That would be neat! Best of both worlds. Vanilla skies lack realism and skyboxes are pretty but completely static. Both are slightly annoying in their own way, but if we could mix them... w00t! 

Update...

I reported before, the "Invisibility - Draw Weapon" option that makes your weapon model transparent did not seem to work in DX Mark V, leaving the weapon fully solid.

But I just found that if "external_textures 1" is set, it DOES work, and my weapon model is transparent! 

Qrack questions, really you should ask R00k about his engine.

mh calls shadows in a Quake a hack. Go stand on the slime bridge in E1M1 with shadows on ... where is your shadow? Try any non-DarkPlace engine, the shadows aren't there when you walk on an entity. DarkPlaces has nice shadows.

Skybox clouds. I might put that on the list of things to see what it looks like, whenever in the future I have the opportunity to work on the engine again.

Noclip + DX + HUD. Looks like you found a bug with a certain combination of settings in the DX version. 

Setting gl_clear 1 may fix your HUD drawing issue in the DirectX version.

Interesting that activating external textures would cause the alpha transparency to work --- must kick it through a slightly different rendering codepath. 

Planar shadows in Quake also poke over edges. You can stand under a bridge that a monster is walking on and see the underside of it's shadow poking over the edge of the bridge.

After 20 years of Quake, how the fuck do people still not notice this kind of stuff? Because once you do see it, you can't un-see it, and no shadows are better than that. 

Lighting made of hacks and approximations will always have its artifacts. Lightmaps included.

http://www.quaketastic.com/files/screen_shots/contract_revoked_fog.png

It's just a matter of what's easier for you to ignore. In this case - the lack of character shadows, or their unnatural properties. 

Shadows in Quake are pretty bad

quick screenshot 

Quake disappearing shadows

https://youtu.be/lbbTMq6bfn0 

*Shadows* hang over edges?
Big deal!
Look at this! :p

http://imgur.com/rIACZjv


Heh, everybody knows Quake ain't pretty!
We don't play it for it's cutting-edge, hyper-realistic graphics....
Hacky shadows look fine most of the time.


"gl_clear 1" did fix the grey HUD issue above.


I mentioned long ago that the bubble sprite doesn't load in Fitzquake when a high-quality textures is in ID1\progs\s_bubble.spr_0.tga (and the spr_1 animation frame too). If those are in place, and high-quality textures are enabled, the bubble is simply invisible in the game.

However, in Quakespasm with the same setup, it does show the original low-res bubble sprite instead of the hi-res one... Either there's some issue imported from Fitzquake, or maybe there's something wrong with my high-res bubble sprite, and Quakespasm knows that, so defaults to the original bubble ?

But the s_light.spr_0.tga in the same location works fine.... 

Replacing a bubble texture with a red one works for me. http://quakeone.com/proquake/media/bubbles.jpg

Something is likely wrong with your texture.

Quakespasm only supports replacement textures for maps surfaces (technically .bsp surfaces, like ammo boxes, healthboxes too).

I thought gl_clear would solve the issue, I'm glad it fixed it. 

Projection shadow method follows slopes and breaks over edges. quake2vr solved some of the remaining problems on sharp corners.

history per q2vr readme-
beefquake --> kmquake2 --> quake2vr

IIRC qfusion and/or warsow may have also have this. 

Ah, that's right; I forgot Quakespasm doesn't re-texture anything but maps.

Well. my bubble sprite textures are from the Quake Retexturing Project, "Item textures v.0.73" pack.

Opening them in an image editor, I do see a difference between the bubble sprites and the light sprite; the Alpha mask of the light sprite appears to have it fully opaque, but the Alpha mask of the bubble sprites look like they're trying to make it partially transparent....

So is it a similar issue with partial transparency, maybe? And it's making the bubbles completely transparent and invisible....

Ah, yep... after tinkering around with the alpha channel in the tga, it seems that with a sprite textures, Mark V makes areas fully transparent (invisible) if they are less than 50% visible, and anything over that threshold becomes fully opaque... I think. So that's why my bubbles were fully invisible -- the Quake Retextuing Project has the bubble sprites at about only 25% visibility (75% transparent) or so....

I think Mark V needs a much higher threshold before it makes things completely transparent...
It's better to have the bubbles fully visible.

Assuming Mark V won't be able to correctly make it partially transparent, anyway.... 

Lighting made of hacks and approximations will always have its artifacts

Shadows in GLQuake are *not* part of it's lighting model. 

In the real world shadows are related to light. Hence the generalization.