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. 

Also you are not allowed to change the license. The original Quake was released under GPL, so QuakeSpasm *HAS* to be GPL and also vkQuake *HAS* to be GPL.

If I used BSD I would be in direct violation with that.

I'm not going to argue with you about the other stuff. 

Unless... You somehow managed to do a full engine rewrite with not one single line copied from the original one.

And I'm not convinced it wouldn't be possible... Except for the most trivial examples, there are many many many ways to write similar software... 

It's obviously not the scope of vkQuake to rewrite Quake. 

I have to admit that when I first looked over the code what I saw led me to think that it was being used for learning. Since that's evidently not the case that was clearly my own misunderstanding.

That aside, and squabbles about API aside (which are interesting to discuss nonetheless), I still think this is cool. It's fantastic to have something where you can go in, look at a bunch of GL code and see the Vulkan code needed for the very same thing side-by-side.

I'm not sure if that's the intention, but intended or not it's cool that it exists.

Learning from code is obviously different to copy/pasting it. I've no objections to GPL on that count, but would note that since id own the original Quake code a new release of the original code under a different license should have been possible. Of course such a release would have missed out on the years of bugfixing and features added...

It's also fair to say that the state of Quake's renderer is such that any attempt to properly use an API is effectively going to be a rewrite. At which stage being able to do a direct comparison between GL and Vulkan code becomes rather more difficult. 

For a limited time only - enjoy 100% more condescending sneering, with extra egotistical squabbling thrown in for free!

Find out who's code is the best code! Fight! Fight! Fight!... 

my code is the worst.... miiiine.

wait, we were fighting over whose was the best... fuck. 

I think the fight was supposed to be over who's code. Or something. 

I think the discussion is interesting.

Much of the discussion in this thread does relate to engine coding. Always has.

If seeing engine coders argue/explain/hyperbole technical details --- you haven't read any of the rest of this thread.

It's uncommon to see the kind of technical discussion of a recent technology (Vulkcan) by people who actually can code in it. 

Well, here's one non technical question about the engine code...

Given the current state of things, who's the actual owner of the Quake copyrights? id? Zenimax? Bethesda? How should one write a copyright notice for it? 

you want to make a commercial game using the engine? 

You don't need a permission to make a commercial game. What you need a permission for is a closed-source game. 

Who owns Quake today? 

Quakespasm thread. Not "ask anything you like thread". 

Stop being condescending. This is a perfectly fine design for something as simple as Quake.

The command buffers and swap chains are double buffered to get minimal latency, which is probably the most important thing for Quake instead of getting 6000+ FPS in a meaningless benchmark. Btw. this is also recommended by AMD.

I use multiple descriptor sets because otherwise I would have to dynamically create them on the lightmap/texture permutations. In a real engine the descriptor sets would be bigger, but you probably would still want to bind multiple ones to avoid thousands of permutations.

If you want to tell me I should index into a big descriptor set: I have been specifically told not to do this, because it's slower on their hardware. On DX12 they even *always* pay this cost. Yes you read that right. Texture arrays have problems with different texture sizes and formats.

You are wrong about DirectX 12 in general. E.g. on AMD this goes through almost the same driver, there is some thin abstraction layer on top of it for DX12/Vulkan. Additionally there is no render passes which can actually also speed up desktop chips. The swap chain is fucked up on NVIDIA right now. This will be fixed very soon.

On top of that this was code for a 0.20 release. I already fixed the memory pooling for textures.

I'm really annoyed by behavior like this. You get something to free and all you can talk about how much better you are than everybody else. Meanwhile I actually try to do something for a community.

Have a nice day, maybe you learn to have some manners some day. 

Yup this will happen. 

What's weird is that I'm not the one who actually said those things. I guess that Axel just made an honest mistake there.

But I reckon OTP is just so full of hate and spite that that wouldn't matter much anyway, eh?