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? 

 

mh: It's fantastic to have something where you can go in, look at a bunch of GL code and see the Vulkan code needed.

I agree with that. I think Axel made a very awesome contribution. And I've seen similar appreciative comments about the Vulkan API port on several different web sites. 

You are right, I was partly confusing Spike's post with yours. I'm sorry about that.

Doesn't change my point though, no matter who said things. 

Also about the GPL situation: Zenimax does own the rights to the original Quake source code. I do not. I can't just go ahead and randomly change licenses because I would want to. I'm also pretty sure even asking would be pointless. 

Never heard of this before as I'm not a MacOs Quakespasm user.
This really big map of mine which uses the "-heapsize 160000" makes my map run under WindowsXp but not on a MacOs.

Just a reaction of a player that don't know where mac periphericals go with QuakeSpasm_0.92.0

What can I say? 

You know Quakespasm defaults 256 MB by default, right?

(which is more than your crusty command line example which is asking for 160 MB or so) 

wait, I'm not the one who's asking.
It is someone on this MacOs Quakespasm that asks me advice.
I tried to reconstruckt the failure and the maps runs fine for me with the "-heapsize 160000" option.
It is his quaestion from him to me how to load a map that size on MacOS.

I know nothing of macs and apples. 

I think that's normal.. QuakeSpasm on OS X is probably running as 64-bit, and more heap space is needed to load the same content when the engine is 64-bit. Anyway, just dropping the -heapsize argument should be fine since it defaults to 256MB now. 

I understand, I'm just nudging you to not use --- nor suggest --- the -heapsize commandline argument.

It's archaic at this point except in exceptionally odd circumstances.