strange output to console on Windows

[tigrazone]

---

←[0mVulkan Version: ←[0m - available: 1.3.268 ←[0m - requesting: 1.3.0 ←[0m__ ←[0mUsed Instance Layers : ←[0m ←[0mUsed Instance Extensions : ←[0mVK_KHR_surface ←[0mVK_KHR_win32_surface ←[0mVK_EXT_debug_utils ←[0m____ ←[0mDevices : 2 ←[0m0: NVIDIA GeForce RTX 3060 Laptop GPU ←[0m - Compatible ←[0m1: Intel(R) UHD Graphics ←[0m - Missing extensions: ←[0mVK_KHR_acceleration_structure ←[0mVK_KHR_ray_tracing_pipeline ←[0mVK_KHR_deferred_host_operations ←[0m ←[0mCompatible physical devices found : ←[0m1 ←[0mUsing Device: ←[0m - Device Name : NVIDIA GeForce RTX 3060 Laptop GPU ←[0m - Vendor : NVIDIA ←[0m - Driver Version : 551.92.0 ←[0m - API Version : 1.3.271 ←[0m - Device Type : Discrete GPU ←[0m____ ←[0mUsed Device Extensions : ←[0mVK_KHR_swapchain ←[0mVK_KHR_shader_clock ←[0mVK_KHR_acceleration_structure ←[0mVK_KHR_ray_tracing_pipeline ←[0mVK_KHR_ray_query ←[0mVK_KHR_deferred_host_operations ←[0mVK_KHR_buffer_device_address ←[0m ←[0mCreate Offscreen←[0m --> (5.602 ms) ←[0mLoading HDR and converting C:/msys64/home/user/from-git/nv-feb24/bin_x64/Release/../../downloaded_resources//std_env.hdr ←[0m --> (57.192 ms) ←[0mLoading scene: C:/msys64/home/user/from-git/nv-feb24/bin_x64/Release/../../downloaded_resources//robot_toon/robot-toon.gltf←[0m --> (99.653 ms) ←[0m←[33m←[0mConvert to internal GLTF←[0m --> (61.516 ms) ←[0mCreate Buffers ←[0m - Create 18 Material Buffer←[0m --> (0.020 ms) ←[0m - Create 2 Textures, 2 Images←[0m --> (0.734 ms) ←[0m - Create 50 Vertex Buffers←[0m --> (94.095 ms) ←[0m ←[0m --> (6.171 ms) ←[0mCreate acceleration structure ←[0m BLAS(50)←[0mRT BLAS: reducing from: 64887040 to: 25686016 = 39201024 (60.41% smaller) ←[0m TLAS(52)←[0m --> (35.301 ms) ←[0mSwitching renderer, from 2 to 0 ←[0mCreate RtxPipeline←[0m --> (17.305 ms) ←[0m

[mklefrancois]

This is strange indeed and I don't see this locally. Is this under Linux? What is the OS and compiler used?

[tigrazone]

Windows 10. I try vs 2019 and mingw. Output is same

[tigrazone]

seems console properties determines wrong about support ANSI escape codes for colored output

[NBickford-NV]

Hi @tigrazone ! Yes, these are ANSI escape codes; it turns out cmd.exe doesn't format these by default! (Windows Terminal and Visual Studio's Debugger Command Prompt do.) It sounds like you may have figured this out: if you create a registry key in Computer\HKEY_CURRENT_USER\Console with name VirtualTerminalLevel, type DWORD, and value 1, it should enable ANSI color codes in cmd.exe.

Here's the content of a .reg file for it:

[HKEY_CURRENT_USER\Console]
"VirtualTerminalLevel"=dword:00000001

It looks like we can also improve this on the nvpro_core side by enabling ENABLE_VIRTUAL_TERMINAL_PROCESSING using SetConsoleMode(); I'm going to look more into this.

Thanks!

[tigrazone]

why If on users computer there is no described record in registry is showed ←[0m like in my issue record? Is it real to determine if ANSI escape codes is off and dont show text with escapes? Looks like issue in determine routine

[NBickford-NV]

That would relate to the ENABLE_VIRTUAL_TERMINAL_PROCESSING approach; I'm currently looking into that.

[tigrazone]

I tested fix: add after https://github.com/nvpro-samples/nvpro_core/blob/500dea27f7043bfca3e82b5e246fe5f8c946cc54/nvh/nvprint.cpp#L242

#ifdef _WIN32
    HANDLE handleOut = GetStdHandle(((1 << level) & LOGBITS_ERRORS) ? STD_ERROR_HANDLE : STD_OUTPUT_HANDLE);
    DWORD consoleMode;
    GetConsoleMode( handleOut , &consoleMode);
    consoleMode |= ENABLE_VIRTUAL_TERMINAL_PROCESSING;
    consoleMode |= DISABLE_NEWLINE_AUTO_RETURN;            
    SetConsoleMode( handleOut , consoleMode );
#endif