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. 

"Quakespasm uses a software library for media playback, Mark V uses Windows hardware accelerated playback. On the computers I have tried Mark V on (probably around 20), it typically loads instantly.
...
The software library Quakespasm uses is more reliable because it isn't subject to Windows settings or Windows .dlls,
...
Mark V is a "pure client", it doesn't use 3rd libraries (that's why doesn't need .dlls"


Is there any way I can troubleshoot this? The delay I'm getting is really awful. If I go to the Start map and toggle the External Music ON in the menu, my game completely freezes for 17 seconds while the MP3 loads (track04.mp3, 3.78 meg).

If I then toggle the External Music OFF and instantly toggle it ON again, my game completely freezes for 17 seconds while the MP3 loads....

Is there any certain Windows setting or dll I should be looking at as the culprit?

I can't remember any other software having such a delay when I'm loading MP3s.... 

Sounds like you don't have enough memory. The Windows API probably precaches the whole mp3 (I'm just guessing), Quakespasm's library feeds it to the sound system in chunks.

Either way, I know almost nothing about Windows settings and such, I never change mine. People at superuser.com or Tom's Hardware might know such things. 

quakespasm includes mp3 decoders.
mp3 patents technically violate the gpl and/or patent law.
(another reason for me to not include dependancies with my quakespasm patch).
using the system's mp3 decoders is one way around that issue (avoids distributing it, and system component avoid gpl issues).

markv uses directshow, which is a system component...
but directshow is poo...
that said, even 17 seconds is excessive even for directshow. wth?

the third way is to use windows' 'acm' api, which can provide stream-based mp3 decoding, which is the method that fte uses. this doesn't do anything silly like scanning the entire file, and isn't even aware of the file. yay pk3s.
markv already uses this api! but the other way around (encoding mp3 for avis).
and with it decoding to memory, it can also be used for sound effects too! yay!..
but yeah, directshow sucks. 

According to Google;

the last MP3 decoding patent expired September 2015. (Decoding = playback)

the last MP3 encoding patent expires April, 2017. (Encoding = recording)

Mark V still can play the music from the CD, so you can always put the Quake cd in the CD drive.

Mark V's mp3 playback is plenty fast on the computers I have tried it on and I've not seen anyone else in this thread (1100+ posts) report that it is slow. But I remember Fifth having problems to get it to work on his Surface Pro, then he did a driver update or something and it worked fine. 

I might add that DirectQ always used DirectShow (AFAIK) for mp3 playblack, and I never recalled seeing a "mp3 is slow" thing in a DirectQ thread -- DirectQ got tons of usage too when MH was developing it.

But yeah, I don't know much about Windows settings and drivers and such --- I never change any settings.

You could try playing music from the CD since Mark V still supports that. 

Was it a driver update? I can't remember now, I thought you had fixed it because I moaned incessantly ;) 

I was going to ask you what you did to fix it.

You posted something like "I reinstalled <XYZ> and now my music is working!" 

try uninstalling+reinstalling windows media player. that'll probably reset whatever is screwed. that or it'll fail completely, but hey, there's always ffmpeg+vlc, right? 

I wasn't aware that the ACM library -- which Mark V already uses for other purposes -- could do mp3 playback, which sounds like unlike DirectShow isn't subject to Windows Media Player settings.

So at some point in the future, I may look through FTE and rewire Mark V to do what Spike does, which is more robust.

/But since I have no time for engine coding, that'd be sometime in 2017 

Mixing the music and quake sfx in-engine is somewhat tricky (if you want the final result to match vanilla quake running at -sndspeed 11025 + a CD playing / an external music player).

You need to duplicate what happens in the OS mixer, so running the 11025Hz output of the quake mixer through a high-quality resampler to get 44100Hz, then mixing in the music, taking care to reduce the volume of the resampled sfx a bit to avoid clipping. Resampling after sfx mixing is key to keeping it sounding like vanilla quake.

(the above doesn't apply if for those who play with -sndspeed 44100 which I find ear-grating :P) 

most modern (cheap) sound cards favour 48khz(dvd quality).
apis like wasapi (that thing that directsound is now a wrapper around) tend to favour floating-point audio too (which incidentilly makes clipping MUCH easier to deal with, also, hurrah for sse).
resampling 11khz to 44khz, crapping over it a bit, then resampling to 48khz via directsound is kinda crazy.
especially when that first resample step *STILL* uses nearest sampling...
so yes, I'm not surprised at you finding it ear-grating.

back in the dos days, the lack of os-level mixing meant that taking actual control of the hardware output rate made sense. with quake spitting out 11khz audio and the sound card outputting analog audio smoothly at the same rate, the hardware would then do linear sampling for you. obviously this varies based upon sound chips.
Or in other words, just fix ResampleSfx to use linear resampling instead of nearest, and have quake output to the OS's native mixer rate, and you'll have audio that sounds as close to vanilla quake as you can realistically get.
There is imho no point in lowpass filters etc, unless you're trying to get underwater effects or whatever... which isn't vanilla quake.

and yes, mp3s played at 11khz sound terrible. so don't do that.

side note: it was recently reported to me that the existing method to get FTE to play internet radio stations sucks.
While I was of course aware of this, I really cba to change anything. We have OSS4 now, the dude should just use a real player, they generally have hotkeys anyway. 

Hypothesis: Could the weird delay be caused by Windows Media Player searching for covers and metadata through the Internet?

Does the MP3 delay also happen in windowed mode? Does any icon activity or notification message pop up in the Windows taskbar during that time?

Maybe Windows is showing up one of those system pop-up windows asking for you to confirm something before x seconds, but since you're in fullscreen you can't see it and the game has to wait for the background pop-up window countdown to end before playing the track. 

Real Player? Is that still around?

Oh wait. The dead one is WinAmp ... the one that -- It Really Whips the Llama's Ass.