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. 

Quakespasm could be modified to do so borrowing Mark V code which has had the dead bodies colored for nearly 4 years.

The changes to do this are located in this source code and marked "#ifdef SUPPORTS_COLORMAPPING_EVERYTHING" the source. Mostly touches cl_parse.c, cl_main.c and gl_model.c are where the main changes are.

Would be a pretty straightforward code grab and the code has essentially remained unchanged for a very long time (one change since was a simple 1-liner if I recall for mods that set an invalid skin #, which I think ericw pointed out).

The remedy to fix the GLQuake "bug" is to watch for any model or colormap change in cl_parse.c for all entities.

If one happens, color up a skin for the model + color combo and store it off. On new level or gamedir change, clear the skins queue. 

sometimes I think the cure isn't any better, with spies in TF changing their appearance mid-game, having one of their dead bodies in your base makes it trivial to figure out what they now look like. 

sometimes I think the cure isn't any better, with spies in TF changing their appearance mid-game, having one of their dead bodies in your base makes it trivial to figure out what they now look like.

I can't remember if the same would happen in software Quake or not.

Either way, this is one of those issues where gameplay in a mod depends on what is clearly an engine bug. Should a fix to an engine bug be allowed to break (or otherwise have a lesser impact on) a mod? Or should it be fixed in the mod code instead? And given that the engine code change is client-side, is it even appropriate for the mod to have been depending on the bug in the first place?

Questions, questions. 

disconnect, change team, etc, all those corpses change colours too, which is weeeeird.
That said, its also weeeeird for corpses to change simply because the player respawned then.

if .colormap carried the top+bottom colours explicitly then that would solve the issue for nq.
You can work around that using DP_SV_CLIENTCOLORS and DP_ENT_CUSTOMCOLORMAP, eg:
self.colormap=1024|self.clientcolors;
That said, this won't help with qw skins or richer colours (unless you wanted to send a whole lot of extra data).
Of course, because mods use .colormap, and its part of every single quake protocol, there'll always be somewhere that is still b0rked - even if you did network the skin names for every single entity. 

Aren't legacy data formats exciting? 

First of all, I did not do vkQuake because I wanted to "learn Vulkan". I already did the Doom port before, which of course was much more involved.

Also you are wrong about the CPU overhead. This is exactly the kind of stuff that is much faster with Vulkan - not that it matters for Quake.

vkQuake serves as an example of how to properly write Vulkan applications. Even with something as simple as Quake there are basics which are not trivial. 

vkQuake serves as an example of how to properly write Vulkan applications
you're not using texture arrays at all nor descriptor arrays, you've no tripplebuffering, you're using an entire descriptor set for each texture of each material, you still have each texture in its own allocation.
its that last one especially that makes it look like an engine that someone's learning from (or they're just lazy, like me).
either way, I'd suggest fixing those before claiming that its 'properly written'.
Sorry, but that irked me enough that I felt I had to say something.
additionally, if you really want to make something that is useful for other people to learn from, then use a friggin license that they *CAN* use. The GPL sucks. Keeping your code separate from quakespasm's code and under a different license should do it.

Also you are wrong about the CPU overhead. This is exactly the kind of stuff that is much faster with Vulkan - not that it matters for Quake.
when running fullscreen at 1920*1080, quakespasm is about 10% faster than vkquake for me.
FTEQW's vk renderer gets about 1200 fps vs gl's 1800 vs d3d9's 3000 fps, when running at that same resolution and a single preset that doesn't have stuff that one of those renderers doesn't support (I'm not going to give numbers for vkquake here because I don't really want to start a pissing contest over engines, yet...).
(small note, this is fullscreen rather than at 640*480, so its subject to whatever excessive buffer copying nvidia are doing behind the scenes. hopefully this will be less of an issue when nvidia actually get their act together)
So yes, switching API will indeed increase your framerate!... but not by switching to vulkan for most users right now. At the same time, rewriting how the API is used will increase the framerate significantly.
I knocked up some crappy opengl renderer a while back when I was trying to familiarise myself with more recent opengl extensions without having to care about older gpus: http://triptohell.info/moodles/junk/youredoingitwrong.png (jam6_daya)
obviously that specific example has no entities nor server logic etc, a pure renderer. trying to match settings I can push fte's gl2 renderer to 2200fps, fte's vulkan renderer can reach 2600fps (this doesn't conflict with the gl vs vk comparison thanks to 640*480 not suffering so much from nvidia's deficiencies). comparitively vkquake does indeed get a noticably higher framerate than quakespasm but its still severely CPU limited because neither are actually making the most of their rendering API.
Imho, mh's comment about the CPU overhead is perfectly valid. Just switching APIs *can* help, but actually properly using the API you already have will still be a bigger and more reliable boost (unless you do both, but then you have the above issues with nvidia's tripple-copy inefficiencies).
Who cares when you're already pulling more than 200fps, right?


put simply, if you want high framerates, go with d3d. even on nvidia. you can call that the microsoft tax if you want, but for me linux wasn't actually any different - even just enabling bloom in linux+vulkan dropped the framerate into the hundreds (which is barely felt on windows).
vulkan might be the future, but its certainly not the present - yet.
here's hoping the drivers stop being shit some time soon.

(I'd have started on a d3d12 renderer already if it had not meant opening myself up to all the win10 malware, iiuc the drivers are more mature so shouldn't have the defects I've been talking about). 

Obviously this is not done yet.