Not sure if this has already been requested, but it'd be a real time saver I think.

Predictive text for commands. Just like on swyftkey or similar, you type a letter and behind it the engine fills in, in grey, any possible command pertaining to that letter.

If you hit enter then it completes the command in text, if not then you carry on typing as normal.

Adding custom keybinds is all very well... but if prediction was a base feature then it'd remove a lot of this piddling about for most if not all users.

Just a thought. 

it exists, start typing something then press tab 

Thanks! 

Not exactly what I meant though - I know what the commands are already. 

keep hitting tab and you won't have to type the rest 

ijed is learning about tab completion in 2016?

fte does exactly what ijed is talking about with the show the command before you type it thing.

In theory it sounds great.
In practice it is a horror.

It doesn't know what you are going to type and instead annoys the F out of you autocompleting something random you aren't looking for --- and in doing so --- ruining your train of thought. 

(Hehe, I should have softened that up a bit and wordsmithed it a little before clicking submit.

The effort to write that feature is great, but the way an advanced engine will have 1000 cvars and commands and most of them are things an average user is never looking for --- this causes the end result to be undesirable.

In my opinion ;-) ... 

I'm still requesting this feature for Quakespasm : the ability to quick load a random map from the whole list by typing a simple command in the console.

Please, I need this, built-in ! 

Open host_cmd.c in the Quakespasm source and find Host_Map_f --- there is a list called "extralevels" and you could make it pick a random one from that list if you type "map random" in the console.

So edit it to do that and then recompile Quakespasm and you are all set. 

The Swyftkey thing I mentioned is a downloadable keyboard for mobile which manages not to be annoying.

But yeah, not exactly top of my christmas list :) 

 

Why this meprisable attitude ?

As a player of Quake, I'm simply asking for a usefull feature, so what's wrong with my request ? 

I recently discovered that it actually looks pretty nice. But maybe the shadows should be one-sided? Since they're supposed to fall on the floor, I see no reason for them to be visible from below. It only contributes to the amount of situations when they look weird.

http://i.imgur.com/HDjlEze.png 

Agreed 

2 

Just saw this...

Axel Gneiting, a programmer at id Software, has ported Quakespasm to Vulkan: https://twitter.com/axelgneiting/status/755988244408381443

Code: https://github.com/Novum/vkQuake 

Whole screen grey, except for the status bar. any map, even e.g. dm4. Does not happen in fitzquake. Any idea? 

Argh.. :(

Would you mind launching with the "-condebug" flag and uploading the generated "qconsole.log" file?

You can disable some rendering code changes with "-noglsl" (alias models, gamma correction) or "-novbo" (new world renderer), one of those may help. 

emailed you the log. neither option appears to change the situation. 

So what generation of graphics cards does one have to be using to get the benefits of Vulkan - or does it not work like that? 

its not meant to work like that.
its meant to be that if vulkan works on your gpu, then your cpu can skip a whole lot of work. your gpu might take a bit longer, but it's probably going to be idle anyway, and with vulkan its supposed to be much harder to inadvertantly cause the cpu+gpu to sync up.

in practise, there's a number of overheads due to the system compositor, and nvidia (at least) is doing a terrible job at overcoming those.
this results in double the framerate at low resolutions (yay!), and half the framerate at high resolutions (oh noes!).
however, I'm also using quake as a benchmark (few other games expect to achieve 3000fps) so take what I'm saying with a pinch of salt, at least when applied to other games.
Games with a lot more 'things' moving around are the ones that will benefit most, so it really depends how dynamic your various scenes are.

personally, the nicest thing about vulkan is not having to worry about falling back to gl1.1 :) 

Thanks, nothing obvious in the log.
The only other thing that comes to mind is try both quakespasm.exe (SDL 1.2) and quakespasm-sdl2.exe. Also might be worth backing up and deleting id1/config.cfg. 

Vulkan has little to offer Quake because a typical Quake workload just isn't heavy enough to benefit from what Vulkan does offer. It looks more like it's just a fun project for the guy at id: a way for him to learn Vulkan and give something cool to the community.

While it is true that most Quake engines (those based on/similar to the original renderer) are CPU-bound, that's because of the way the API is being used, not the API being used. Lots of small draw calls with glBegin/glEnd, sync points all over the place, animating on the CPU then pushing data to the GPU every frame; it's all a combination of the worst possible things you can do on 2004+ hardware. Try to do the same under Vulkan and you'll probably end up even worse. On the other hand, fix the way the API is used and Quake is no longer CPU-bound so Vulkan is unnecessary. 

Is there a way to fix this behavior:

http://images.akamai.steamusercontent.com/ugc/490148994130320242/20D5703E20B310E84B96ABFBED8E1ACB388A846A/

http://images.akamai.steamusercontent.com/ugc/490148994130320455/C933577F2FA4D5C19AE52F368F9231A743649309/ 

That's a long standing GLQuake bug.

In summary: entity slot 0 is reserved for the world. Entity slots 1 to 16 are for players. Entity slots 17 onwards are for everything else.

When a player is killed, they move from one of the player slots to one of the "everything else" slots. Their old player slot then becomes free for them to respawn into (or for another player to join into, I guess). That way the player slots don't get filled up very quickly with dead bodies.

How GLQuake colours a player model is that it checks what entity slot number it's in. If it's in one of the player slots (1 to 16) it will apply colormapping to a copy of the player model texture, re-upload that to the GPU, then use it instead of the regular player texture.

And that's how it happens: the entity moves outside of the player slots, so GLQuake no longer colours it.

IIRC this is fixable but if an engine still uses the old colormapping code there may be some more extensive rewriting needed to make it run well.