I use always run.

The QS implementation is basically like holding shift to run. You are correct, using always run is a different feeling to holding shift (even in Winquake).

Not sure if this is a bug. It would be nice to have an option to have this operate more like Winquake. 

It would be nice to have an option to have this operate more like Winquake.

Put
cl_forwardspeed 400
cl_backspeed 400
... in autoexec.cfg. 

I'm playing through on NM and my realm progress isn't saving, using latest version of Quakespasm. Is this a known bug? 

Hi Quakespasmers. I stopped by here because someone mentioned a "Beef Thread." I didn't know there was a "Beef Thread!" So I decided to go look for it, but I stopped in here too.

I see FifthElephant is asking about the "Always Run" thing being different. I actually made a post about this on my FvF forum which goes into detail describing WHY it is that way, so I thought I would post a link here for those who are interested (especially for FifthElephant, because he is my BESTEST buddy! >:D Hi FifthElephant!)

http://www.fvfonline.com/forum/viewtopic.php?f=12&t=3776 

After playing Quake for 20 years I am used to the default behaviour. Maybe it isn't in the design goal of the engine and an option wont be included.
I find strafe jumping harder in Quakespasm as the movement is too sudden and jerky. 

I think I may have suggested in the Mark V thread that "Always Run" could be made to have 3 different settings in the menu: OFF, ON, and ALL.

ON would be the standard old setting that doesn't affect side speed, for people who have just gotten used to that.

ALL would be doubling the movement in all directions, including the side speed.

Unfortunately, Mark V changed it so that "Always Run" is ON by default, using the old method that doesn't affect side speed....

I dislike that settings, but could always just ignore it -- I prefer to be able to sidestep really FAST to dodge those rockets. But changing the default so that it's ON is just awful; now I have to make extra settings just to get back to normal. (Yeah, I've complained about this in the Mark V thread already, heh.)

But perhaps Quakespasm would be interested in my idea of 3 different settings for the menu option, for people who prefer it the old way. More user control is usually a good thing, even though I really, really like the way Qspasm has implemented "Always Run," with the full speed in all directions, and having the +speed key still be useful to toggle you to a slower pace. 

What is it with Quakespasm that makes it draw certain brush models regardless of their actual visibility - always and on the other side of the map, even from the outside. Unnecessary triple digit epoly boost.

What's going on and how can I work around the system? Check detail1.jpg from my post in the Tyrutils_ericw thread as an example: the square things in the bottom right corner. Originally, there were some columns in the back of the map as well, but I had returned them to world geometry already. 

Sounds like it's just the "brush model in too many leafs" fix.

Note that because QS uses VBO drawing and draw call batching poly counts aren't as relevant. 

that's the "flicker fix" we implemented. QS's MAX_ENT_LEAFS is 32, so I think the way it works is if an entity bbox spans more than 32 leafs, the server will make it always visible rather than potentially flicker.

Workarounds would be simplifying world geometry where the bmodel is or shrinking the bmodel. 

 

When this problem really came forward in community consciousness (http://forums.insideqc.com/viewtopic.php?p=26885#p26885) I had just recently fixed it by dynamically recalculating visibility for each client, for each entity, each frame. That was effective (it wouldn't have pulled large bmodels into the PVS all the time) but caused hugely excessive CPU load.

It turns out that in this case just drawing it anyway is a more efficient approach, at least for hardware-accelerated engines (the point I made above about r_speeds counts not being so relevant to a properly-optimized renderer can't be overstated enough). 

Might be a good feature? It's really annoying to convert from tga... 

 

I recommend LodePNG. 

I am always installing GIMP or using imagemagick to convert to png, it's a pain.

@Fifth
I'll try to look into a cvar for the classic behaviour of "always run" before the next release.

@boristhesp1der (late reply!) glad you liked tfuma, Fifth built the majority of the map and I took over finishing gameplay and routes, w/ contributions from sock. I did set up that slime pit fight :) 

But for most web stuff you need JPG-compression, and for the rest TGA is mostly not a problem. 

JPG is not really "needed" for web use, it just the most common. Many times it gets used when PNG would be the better choice.

I always wondered why Quake used TGA, which is an obscure format and pretty much obsolete now.

Even if its improved capabilities aren't used, I think PNG is the best choice, but for in-game screenshots JPG is probably fine as long as the compression is low. 

The code to write TGA is pretty simple, that might be why. Or maybe it was compatible with other software they used at id at the time. 

Simple and fast. PNG with compression will take longer. It will freeze game for a second.
Of course I'm just speculating. 

I prefer to start with uncompressed images. It's easy enough to convert quickly with any number of apps. I use something similar to this: https://www.imageconverterplus.com/features/right-click-menu/

@metlslime id was most likely was using Truevision video accelerators in their Windows machines back then. TGA was originally from Truevision. 

 

Software Quake used PCX. Because that was an 8-bit renderer it was also just a simple matter of "dump the pixels".

According to Carmack's .plan file ID were using Intergraph accelerators on NT as their graphics workstation platform of choice at the time GLQuake was written.

PNG format didn't even exist when Quake was released. First release of PNG was October 1996.

TGA offers simplicity and speed, although nowadays with disk IO being the primary bottleneck for many operations a compressed format may well be the faster option, at least until SSDs go cheaper than spinning plates of rust. 

I prefer to start with uncompressed images. It's easy enough to convert quickly with any number of apps. PNG has lossless compression. It's like ZIPping TGA, but in one operation. It is easier to preview and maintain. 

Got it. Obviously PNG would be the most handy format at the moment especially for immediate sharing. I take the previewing aspect for granted as I have the aforementioned shell viewer/converter and Photoshop. 

JPG is not really "needed" for web use, it just the most common. Many times it gets used when PNG would be the better choice.

Read about how those compression algorithms work and when they're appropriate to use.