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.
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).
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).
not all beam types are supported yet
also changes studio api init sequence, fixes missing cvars
vertex type struct is no longer names as brush-specific
uniform buffer allocation is now in vk_render
blending issues still remain
RI.drawMode affects how time is interpreted for models, so make sure it
uses the correct time
implement indexing for model rendering -- this fixes weird holes
Alibek Omarov
Andrey Akhmichin
Ivan 'provod' Avdeev
SNMetamorph
mittorn
Skyrim-police