Yeah, I can understand that. WinQuake has tons of aliasing, all over the place, and maybe that's part of its charm, but having crisp sharp unfiltered textures with zero aliasing is also very, very appealing and it's something that couldn't be achieved on the hardware back then, so it feels more like an upgrade than a step back. Just my personal preference, at any rate. 

Is merely a result of using a screen with too low a resolution at too close a viewing distance (dpi vs viewing distance). 

yeah just get a 4k display! 

thanks! GL_NEAREST_MIPMAP_LINEAR is the perfect balance i was looking for. Too long i was using gl_linear_mipmap_linear and the scene on large maps just looked blurry far away, (thought might feel like GTA-V), lol

small maps like the dm maps it looks perfect like standard true grit Quake :) 

https://www.youtube.com/watch?v=eP4gGe2Kwvc 

On the map E1M3(The Necropolis) at the end right before the fight for the exit gate, the lift has a bug. About half way up the lift I get hurt for no apparent reason(HP going from 100 to 45) and the lift goes back down.

I am running Windows XP x86, Intel E6550, 2GB RAM, Geforce GTX 550 Ti 

host_maxfps is probably set above 72 - setting it back to 72 should fix the physics glitch. 

Feature list sounds great, congrats!

Find ;-) WinQuake gun pos ;-) Alpha .mdl texture masking, not that anyone will ever use it because about no one is capable of making models these days but should someone arise, it is available which is nice. PNG shots ;-) Having actually Quake-correct always run ;-)

1. gethostbyname -- has no purpose in the engine at all.

2. Steal r_viewmodel_fov -- sheesh! It's been nearly 6 years Mark V has had that barely 8 lines of code feature -- maybe be slightly more complex in QS, but seriously. No excuses. It's rather unacceptable Quakespasm does not have that feature, in all seriousness.

3. Maybe make a Con_Print when someone changes maxfps away from 72 do a message "This may cause physics glitches, missed triggers and killer elevators". Because clearly people post the same damn thing 80 times per year.

Anyway, I quite like the change list! 

What r view model fov does 

if (sv.active) Cvar_SetValue ("host_maxfps", 72);

Obviously it would be nice to fully decouple the timers, then work over the client code and fix up all the FPS-dependent stuff properly, but in the absence of that surely we're past the point where the disadvantages far outweigh the advantages? 

Decoupling these things is a huge task if I recall which is why no one has done it yet 

recent release attempted this IIRC

Could you tweak the physics (or damage) code to behave better at those higher rates? 

Could you tweak the physics (or damage) code to behave better at those higher rates?

This isn't something that's a simple tweak otherwise it would have been done long ago, everybody would be using it now, and we wouldn't be having this conversation.

This is something that we've all been aware of for almost 20 years - at least ever since the Quake source release and early attempts at implementing maxfps. But yet people still continue to report it as though it were a new bug several times per year. 

But yet people still continue to report it as though it were a new bug several times per year.

Well that's because we're not omniscient. 

Hello. There is any plans to do the same port for Quake 2? I'd like to play it very much, cuz there is no such a port for Quake 2 like QuakeSpasm. There is only unofficial patch, but it's not enough - the mouse input is very shitty, no support for all keybuttons in controls options etc. I hope you will do it, as I know, the Q1 and Q2 engines are very similar. 

Here you have similar project for Quake2: https://www.yamagi.org/quake2/ 

Can you make QS default to gl_flashblend 0? Unless you already have... 

Yes, it's been the default for several versions (iirc since 2014-ish) 

This may have already been discussed to death, but I'm just returning from not having played Quake in a few months and saw QS got to 0.93.0. How similar is this release to QSS? I've been using QSS or the AD version for pretty much everything since Sepulcher came out. Can 0.93.0 do pretty much everything QSS does? Which should I use for normal play? 

I'm running latest SVN code on Linux. I notice that when several enemies teleport in, only one teleport effect is displayed, while the other enemies just pop in. Is this normal? 

QSS is a separate fork/experimental build and QS 0.93 doesn't include any of its features. Perhaps for the best. 

I'm running latest SVN code on Linux. I notice that when several enemies teleport in, only one teleport effect is displayed, while the other enemies just pop in. Is this normal?

You would get this result on virtually any Quake client, going back to the original engines from 1996.

The teleport splash spawns almost 900 particles, whereas the engine by default will only support up to 2048. I suggest that there's something else spawning particles, or an enemy teleporting behind you where you can't see it's particles.

Run with -particles ### where ### is some number higher than 2048 to support more particles. 

@SavageX certainly not an intentional change. Could you try 0.92.1?
https://sourceforge.net/projects/quakespasm/files/Source/quakespasm-0.92.1.tgz/download 

@mh: Thanks, that's it! Increasing the particle limit fixes this!

@ericw: Tested this in 0.92.1 as requested. It behaves the same (and according to design).

I wonder if bumping the default particle limit makes sense. Are particle emitters sorted by player distance regarding priority or is it "random" which emitters starve? 

Quake doesn't really have a concept of particle emitters as such. Particles are just moved from a free list to an active list as required, then returned to the free list when they expire, with no sorting.

Individual particles in an effect may expire at different times, and when you run out of free particles that's it, no more particles until enough expire.

So if there are, say, 5 teleport splashes spawned, the first two will get 896 particles each, the third will get 256, the last two will get none.

It's easy enough to extend the number of particles to effectively infinite engine-side: just Hunk_Alloc (and initialize) another batch when you run out. Add some tidy-up code for map changes and it's done.

It's always seemed odd to me that QS hasn't already done this, particularly given the number of effects even in stock ID1 Quake that use up so many.

By comparison, Quake II bumps MAX_PARTICLES to 4096 but IIRC even that isn't enough for stock ID1 Quake; there are some scenes in demo1 that can go over 5000.