This was an attempt to add map lighting w/o lightmaps. Unfortunately
there are just not enought of them to explain all light in maps. We're
missing something else. A lot of it.
we were mixing up row vs column major matrices
now RTX ray generation is fixes, and traditional rasterizer rendering
should also be projecting similar to gl render
this basically checks that acceleration structurs are building without
any vulkan errors (we still don't know whether they are bulding with
correct geometry though).
we also have compute shader pipeline ready for ray tracing (yay)
but it doesn't do any raytracing yet
This makes it possible to just pass `-8` to ./waf configure on Windows
and it will build 64-bit binaries. Yay I guess.
However, it's completely broken conceptually -- it ends up just brute
rewriting `conf.env.DEST_CPU` from `amd64` to `x86_64` at one particular
point in wscript. Why? Because many places in build system expect
`x86_64` as 64-bit DEST_CPU, especially breaking SDL2 lib detection.
Some of these are in waifu and patching that is beyond what I can hold
in my head right now.
Why that particular point? Because it DEST_CPU gets rewritten a few
times before that and no times after it seems.
This does not address `./waf msvs` VS project generation yet -- it will
still produce only Win32 platform that needs to be manually rewritten.
There's a mechanism for msvs extras to be passed a set of platforms, but
I've yet to make it work.
Quality of this commit is questionable. I have no idea whether what I did
here makes sense or not.
But it compiles and runs (provided with hlsdk-xash3d amd64 build, which
is another story).
This omits necessary waf changes that are necessary to make a valid
64-bit build. Apparently it's not enough to just pass `-8` on Windows,
you also need to hack wscript to add `x64` target to MSVC. I'll do that
later when I figure out how.
This change is a precursor for RTX Vulkan effort --
VK_KHR_ray_tracing_pipeline and friends are only available on 64-bit
nvidia drivers (no idea about AMD, pls send GPUs onegai).
Now each geometry is first allocated a slot with VK_RenderBufferAlloc,
and then VK_RenderBufferLock/Unlock are used to upload buffer contents.
This allow for two things:
1. Uploading buffer data to GPU memory on/after Unlock.
2. (Re)building BLAS for RTX on/after Unlock.
These buffers are now directly referenced by render_draw_t, which also
will be helpful in the future for both renderers.
This makes it possible to just pass `-8` to ./waf configure on Windows
and it will build 64-bit binaries. Yay I guess.
However, it's completely broken conceptually -- it ends up just brute
rewriting `conf.env.DEST_CPU` from `amd64` to `x86_64` at one particular
point in wscript. Why? Because many places in build system expect
`x86_64` as 64-bit DEST_CPU, especially breaking SDL2 lib detection.
Some of these are in waifu and patching that is beyond what I can hold
in my head right now.
Why that particular point? Because it DEST_CPU gets rewritten a few
times before that and no times after it seems.
This does not address `./waf msvs` VS project generation yet -- it will
still produce only Win32 platform that needs to be manually rewritten.
There's a mechanism for msvs extras to be passed a set of platforms, but
I've yet to make it work.
Disable depth test and set dst blend factor to 1 for kRenderGlow mode.
Sprites are occluded in software.
(does this break any other code depending on Glow mode? who knows)
Now rendering submodules specify their colors and matrices using
VK_RenderState global stat api. This is a trade-off between making all
submodules track their state on their own, or managing that state
centrally.
