please set DXC_SPIRV_PATH to the full path to the DXC binary. about rbdoom-3-bfg HOT 7 OPEN

I'm not sure honestly. I think I was just very tired and not paying attention to what I was doing. I probably forgot to run source ~/.bashrc or something after I exported the path. I do think maybe the build instructions could use updating though since I doubt I would have figured it out if I were not a developer myself and there are no binary releases for Linux. I haven't gotten a chance to look at the source code yet to see what's being passed to memcpy, but if I get a chance to fix it or someone else does I'm not just looking to use this engine again to run Doom 3, but possibly to create something stand alone. Been killing A LOT of time on Quake 3 code lately, but this engine is beautiful even by today's standards in my opinion.

from rbdoom-3-bfg.

Yes, the DXC_SPIRV_PATH error message is a bit misleading since this is an internal message from compileshaders.cmake

Set the DXC_CUSTOM_PATH cmake variable (i.e. -DDXC_CUSTOM_PATH=...) to your dxc path and you should be good to go. I think we need to find a way to make this a bit more transparent (e.g. docs, error message, etc). If you look inside the main CMakeLists.txt you will see it there. However if dxc is already on your path, then cmake should have found it - interesting that it didn't. I will have to look into that.

Please let me know if this fixes your issue. If so, I will try to create a PR with better error messaging and docs.

from rbdoom-3-bfg.

Thanks. I figured it out, but now have to figure this out:

In function ‘void* memcpy(void*, const void*, size_t)’,
    inlined from ‘bool idDataQueue<maxItems, maxBuffer>::Append(int, const byte*, int, const byte*, int) [with int maxItems = 64; int maxBuffer = 8000]’ at idlib/../idlib/DataQueue.h:112:8,
    inlined from ‘void idPacketProcessor::VerifyEmptyReliableQueue(byte, byte)’ at /home/kevin/GitHub/RBDOOM-3-BFG/neo/sys/PacketProcessor.cpp:660:16:
/usr/include/x86_64-linux-gnu/bits/string_fortified.h:29:33: error: argument 2 null where non-null expected [-Werror=nonnull]
   29 |   return __builtin___memcpy_chk (__dest, __src, __len,
      |          ~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~
   30 |                                  __glibc_objsize0 (__dest));
      |                                  ~~~~~~~~~~~~~~~~~~~~~~~~~~
/usr/include/x86_64-linux-gnu/bits/string_fortified.h:29:33: note: in a call to built-in function ‘void* __builtin___memcpy_chk(void*, const void*, long unsigned int, long unsigned int)’
cc1plus: some warnings being treated as errors
make[2]: *** [CMakeFiles/RBDoom3BFG.dir/build.make:7678: CMakeFiles/RBDoom3BFG.dir/sys/PacketProcessor.cpp.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:195: CMakeFiles/RBDoom3BFG.dir/all] Error 2
make: *** [Makefile:136: all] Error 2```

from rbdoom-3-bfg.

Thanks, but before we move off the original issue I would like to know what caused it. If I test without dxc installed on Manjaro Arch Linux, I get the following cmake error message which informs you about DXC_CUSTOM_PATH. Also I have verified that the cmake scripts look for dxc on your current PATH.

-- Using module to find Vulkan and components
-- Found Vulkan: /lib/libvulkan.so (found version "1.3.279") found components: glslc glslangValidator missing components: dxc
-- Using Vulkan: /lib/libvulkan.so
CMake Error at extern/ShaderMake/CMakeLists.txt:144 (message):
  Can't find DXC: Specify custom path using 'DXC_CUSTOM_PATH' parameter or
  install VulkanSDK!

Is it possible that you changed or updated your RBDoom3BFG local copy without doing the following:
git submodule update --init --recursive
If this important step was skipped, you may not have had extern/ShaderMake installed and could get compile_shaders errors like you mentioned above. It would be helpful to know the cause of the original error to rule out bugs elsewhere.

Regarding your new issue, what Linux system and compiler are you using? It appears you have a warning which is treated as an error. I have tested RBDoom3BFG on Manjaro linux using both gcc 13.2.1 and clang 16.0.6, and both compile fine without warnings or errors.

from rbdoom-3-bfg.