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. 

I am the person trying to run LXSU4 on MacOS with QuakeSpasm.

It is telling me couldn't spawn map. I'm using the supplied command line:
-heapsize 160000 -game lxsu4 +map lxsu4

I also tried every other combination and method I know.

LXSU4 is created by MadFox and featured on the Quake Expo 2016 site:
https://qexpo2016.com/sins-gorge-for-quake1/ 

The zip file is LSXU4, not LXSU4, so try -game lsxu4 +map lxsu4. 

You can type "game lsxu4; map lsxu4" in the console.

Both gamedirs and map names autocomplete in the console if you press tab.

No more typos 

Ok, it works. Thanks! The zip file / game folder was supposed to be named LXSU4, but it isn't. 

for elexis ufour! 

The original game displayed the view weapons slightly differently depending on the view pitch. I don't know if it was a feature or an oddity (it also strangely depended on the screen size), but I know enough games that do similar things deliberately (so it wouldn't look like the weapon is glued to the player's chin).

Looks like this effect was lost somewhere along the way. What I'd like to ask is why. 

Oh, and apparently I misremembered Fitzquake exhibiting the old behavior - I just checked and it doesn't. So it's not a Quakespasm change. 

There's a car to display weapons like winquake at least in markv 

Just saw it now, I packed it with the wrong name. 

There's a car to display weapons like winquake

Yeah, it looks really cool! Rocket launcher example. 

Hey guys, I think I've read about it somewhere but I can't seem to remember or find the page again, so please clear something up for me: there's no RTlights support in QS, is there? And while we're at it, I'm looking for something similar to DP Pretty Water for QS. Do I have any chance of getting lucky? 

As I understand it, QS is more about improving the engine within an acceptably Quakey aesthetic - stuff like RT lights and hi-res fresnel FX on water don't really mesh with the grungy pixel art look that was established in the original game. 

No more http://quakespasm.ericwa.com/job/quakespasm-sdl2/ builds?