Currently, the engine only supports 4-channel textures. This is not always needed or wanted. Add support for the following texture configurations:

• 1-channel (R8)
• 2-channel (R8B8)
• 3-channel (R8B8G8)

While at it, change default textures (default, default diffuse, default specular and default normal) to use 3-channel textures.

Describe the bug
The unit tests on windows always report 0.0 time elapsed. This is because the clock_frequency in platform_windows.c is never initialised.

To Reproduce
Run unit tests on windows.

Expected behavior
time measurements on unit tests in windows must report actual times.

Desktop (please complete the following information):

• OS: WINDOWS 10

Description
I have notices that vulkan_context.images_in_flight is declared as: vulkan_fence**
but

• initialized as: vulkan_fence*
  

  kohi/engine/src/renderer/vulkan/vulkan_backend.c

  Line 225 in 202ac72

  context.images_in_flight = darray_reserve(vulkan_fence, context.swapchain.image_count);

• used here as vulkan_fense*
  

  kohi/engine/src/renderer/vulkan/vulkan_backend.c

  Line 490 in 202ac72

  if (context.images_in_flight[context.image_index] != VK_NULL_HANDLE) { // was frame

• and used as: vulkan_fense** here:
  

  kohi/engine/src/renderer/vulkan/vulkan_backend.c

  Line 493 in 202ac72

  context.images_in_flight[context.image_index],

  
  

  kohi/engine/src/renderer/vulkan/vulkan_backend.c

  Line 498 in 202ac72

  context.images_in_flight[context.image_index] = &context.in_flight_fences[context.current_frame];

Effect
Currently, there is no side effects as (void*) and VkFence are the same size. but as the code expands, this could end in invalid usage of this variable.

Mitigation

L225: context.images_in_flight = darray_reserve(vulkan_fence*, context.swapchain.image_count);
L490: if (context.images_in_flight[context.image_index] != 0) { // was frame

Is your feature request related to a problem? Please describe.
currently the macrodarray_push doent allow to reassign the modified array pointer after the push. like so.
array = darray_push(array, value)
because of the way it resizes internally, it may return a different pointer when resized.

Describe the solution you'd like
making the macro a direct passthrough would solve it, but inserting temprary/constant values would need an extra line of code.

Describe alternatives you've considered
NA

Additional context
NA

Describe the bug
line 230 in system_font_loader.c
CLOSE_IF_FAILED(filesystem_read(file, read_size, &data->font_binary, &bytes_read), file);
"&data->font_binary" should be "data->font_binary".
It's easy to overlook that kind of error.

Describe the bug
If the user presses both left and right shift keys, releases one, then the other, an event is only fired when the second key is released. Note that this seems to be a limitation in the Windows API layer not firing events until the last key is pressed.

To Reproduce
Steps to reproduce the behavior:

1. Open the engine
2. Press the left shift key and hold
3. Press the right shift key and hold
4. Release the left shift key while still holding the right - note no event is fired
5. Release the right shift key, note the event is fired.
6. Try this with any combination/order of left/right shift key presses.

Expected behavior
An event should fire every time a key is released.

Screenshots
N/A

Desktop (please complete the following information):

• OS: Windows 10

Additional context
Add any other context about the problem here.

Describe the bug
I just finish implementing the code from the video 21, and when I try to resize the window, it is super laggy and take a while to recreate all the necessary for the rendering.

To Reproduce
Steps to reproduce the behavior:

1. Clone the repos on a linux system using the X server
2. Build everything and run the testbed
3. Try to resize the window
4. See the lag

Expected behavior
The resize process should be smoother

Screenshots
https://user-images.githubusercontent.com/15181236/187048255-eb9baed8-08fe-492e-80da-0fbc0bcea1c5.mp4

Desktop (please complete the following information):

• OS: Archlinux
• Version 5.19.3

For some graphics cards, the current queue selection process will lead to the transfer and present queues being the same queue. The code then assumes these two are separate.

The relevant section of the vulkaninfo extract for the AMD Radeon RX 5700 XT is included below, as well as suggested code changes.

VkQueueFamilyProperties:

queueProperties[0]:
-------------------
	minImageTransferGranularity = (1,1,1)
	queueCount                  = 1
	queueFlags                  = QUEUE_GRAPHICS | QUEUE_COMPUTE | QUEUE_TRANSFER | QUEUE_SPARSE_BINDING
	timestampValidBits          = 64
	present support             = true

queueProperties[1]:
-------------------
	minImageTransferGranularity = (1,1,1)
	queueCount                  = 2
	queueFlags                  = QUEUE_COMPUTE | QUEUE_TRANSFER | QUEUE_SPARSE_BINDING
	timestampValidBits          = 64
	present support             = true

queueProperties[2]:
-------------------
	minImageTransferGranularity = (16,16,8)
	queueCount                  = 2
	queueFlags                  = QUEUE_TRANSFER | QUEUE_SPARSE_BINDING
	timestampValidBits          = 64
	present support             = true

vulkan_device.c

// GM: added this to cater for overlap of transfer and present queues
b8 transfer_shares_present_queue = context->device.transfer_queue_index == context->device.present_queue_index;
u32 index_count = 1;
if (!present_shares_graphics_queue) {
    index_count++;
}
if (!transfer_shares_graphics_queue) {
    index_count++;
}
// GM: added this if statement to cater for overlap of transfer and present queues
if (transfer_shares_present_queue) {
    index_count--;
}
u32 indices[32];
u8 index = 0;
indices[index++] = context->device.graphics_queue_index;
if (!present_shares_graphics_queue) {
    indices[index++] = context->device.present_queue_index;
}
// GM: altered this if statement to cater for overlap of transfer and present queues
if (!transfer_shares_graphics_queue && !transfer_shares_present_queue) {
    indices[index++] = context->device.transfer_queue_index;
}

See the following line:

Describe the bug
Changing the max_entries from

u64 max_entries = total_size / sizeof(void*);

to

u64 max_entries = total_size / (sizeof(void*) * sizeof(freelist_node));

makes the unit tests fail.

Screenshots

Desktop

• OS: Windows 10

Is your feature request related to a problem? Please describe.
In the current VS Code Version 1.63.2 a "bug" can occur which causes an widely spaced font setting in the Terminal window.
See: microsoft/vscode#120004

On a fresh installation of VSCode the Terminal (Windows 10, Powershell 7) looks like this (spaced out letters):

Describe the solution you'd like

In ".vscode/settings.json" the entry "terminal.integrated.fontFamily": "Consolas", could be added which resolves to a proper spacing:

Describe alternatives you've considered

The "letterSpacing" property mentioned in "microsoft/vscode#120004" did not work in my case.

event_register does not look at the callback when checking for uniqueness. This should be taken into account as it is in event_unregister.

When the image count is only 2, vulkan fails critically.
I'm still to figure out why my particular system does not end up with an image_count of 3, but the code below is a bug.

vulkan_material_shader.c
vulkan_material_shader_create(...)

// GM: removed this line - alloc_info.descriptorSetCount = 3; and replaced as below.
alloc_info.descriptorSetCount = context->swapchain.image_count;

Describe the bug

I get this validation error whenever I resize the screen:

[ERROR]: Validation Error: [ VUID-VkRenderPassBeginInfo-pNext-02852 ] Object 0: handle = 0xe7e6d0000000000f, type = 
VK_OBJECT_TYPE_RENDER_PASS; | MessageID = 0xdb2c5767 | vkCmdBeginRenderPass: Cannot execute a render pass with 
renderArea not within the bound of the framebuffer and pNext of VkRenderPassBeginInfo does not contain 
VkDeviceGroupRenderPassBeginInfo or its deviceRenderAreaCount is 0, renderArea.offset.x (0) + renderArea.extent.width (1280) is 
greater than framebuffer width (766). The Vulkan spec states: If the pNext chain does not contain 
VkDeviceGroupRenderPassBeginInfo or its deviceRenderAreaCount member is equal to 0, renderArea.offset.x + 
renderArea.extent.width must be less than or equal to VkFramebufferCreateInfo::width the framebuffer was created with 
(https://vulkan.lunarg.com/doc/view/1.2.198.0/windows/1.2-extensions/vkspec.html#VUID-VkRenderPassBeginInfo-pNext-02852)

Two locations:
vulkan_renderer_backend_begin_frame():
recreate_swapchain()

Improper usage of the __gcc__ Macro
I noticed that you're using the macro __gcc__ on the defines.h file which is not defined on Mac.

Screenshot of the defines.h file in Kohi:

I believe the proper macro should be __GNUC__ which tests for GCC as per the documentations on the GNU Fortran compiler.

SOLUTION:
Therefor the 'proper way' at least of checking for the GCC compiler should thus be:

which is the solution which I use in my engine and it works perfectly fine 👍 💯

Here's a screenshot of the docs for more reference:

and the link: https://gcc.gnu.org/onlinedocs/cpp/Common-Predefined-Macros.html

Desktop:

• OS: MacOS
• Architecture: arm64
• OS Version: 13.0.1

Hello Travis,

Thank you for the kohi series on youtube.
Since, I don't have a youtube account. I will post this here.
I believe there is a potential bug in the platform_win32.c
In the function 'platform_console_write_error'

LPDWORD number_written = 0;

WriteConsoleA(GetStdHandle(STD_ERROR_HANDLE), message, (DWORD)length, number_written, 0);

If I am not mistaken then I believe that the 'number_written' variable is not used properly.
My gut feeling about the Windows API tells me that it probably would need to be something like this:

DWORD number_written = 0;

WriteConsoleA(GetStdHandle(STD_ERROR_HANDLE), message, (DWORD)length, &number_written, 0);

I don't think it is too big of an issue here, because the LPDWORD is technically a null pointer.
If it had not been initialized to 0. the WriteConsoleA function could have probably thrashed some memory.

Kind regards,
theoldnewb

Hi, memset doesn't work with i32 correctly,
if you want to fill an array of integers with 1 using the platform_set_memory, then you will get an array filled with 16843009 instead,

see this sample code to regenerate the bug, https://ideone.com/nf3EYB

please use for loop instead.

Hello. I've been following your tutorial and sadly has encountered a problem. On my system the uninitialized event variable has a exactly a nullptr value and message handling was not working correct.

See:

Also, it seems like your loop through screens is actually pointless, since it starts from zero and condition s > 0 fails instantly.

See:

Sorry if I'm incorrect and thanks in advance for any replies.

Using the Intel(R) Iris(TM) Graphics 550 iGPU on macOS, the following error shows up repeatedly:
[ERROR]: Validation Error: [ VUID-VkViewport-height-01772 ] Object 0: handle = 0x7fa450cd8a88, type = VK_OBJECT_TYPE_COMMAND_BUFFER; | MessageID = 0xa0dbe64d | vkCmdSetViewport: pViewports[0].height (=-600.000000) is not greater 0.0. The Vulkan spec states: height must be greater than 0.0 (https://vulkan.lunarg.com/doc/view/1.2.148.0/mac/1.2-extensions/vkspec.html#VUID-VkViewport-height-01772)

Making the viewport height positive in vulkan_backend.c solves the issue.

This doesn't happen with my AMD Radeon Pro 5500M dGPU on macOS, so this could be Intel specific.

Are we missing a few assets?

[ERROR]: Image resource loader failed to load file '../assets/textures/orange_lines_512.tga'.
[ERROR]: Failed to load image resource for texture 'orange_lines_512'
[ERROR]: Failed to load texture 'orange_lines_512'.
[WARN]: Unable to load texture 'orange_lines_512' for material 'test_material', using default.
[ERROR]: Image resource loader failed to load file '../assets/textures/orange_lines_512_SPEC.tga'.

[ERROR]: Error opening file: '../assets/models/falcon.ksm'
[ERROR]: Unable to find mesh of supported type called 'falcon'.
[ERROR]: Failed to load car test mesh!
Did a clone and a clean build and also ran post build.

Describe the bug
vulkan_backend.c:
required_validation_layer_names is nullptr whenever in release version.
so when you call darray_destroy(required_validation_layer_names), program will throw a nullptr exception.

This function is using a pointer to a locally-declared VkDescriptorBufferInfo buffer_info later in the function after the scope for buffer_info has ended, which is, of course, undefined behavior.

Describe the bug
basically freeing u_text->text using incorrect size every frame;
solution: use string_free or add 1;

I've been following along with the series and after the screen clearing episode get the following error:

[ERROR]: Validation Error: [ VUID-vkBeginCommandBuffer-commandBuffer-00049 ] Object 0: handle = 0x7fdc5087b0e8, type = VK_OBJECT_TYPE_COMMAND_BUFFER; | MessageID = 0x84029a9f | Calling vkBeginCommandBuffer() on active VkCommandBuffer 0x7fdc5087b0e8[] before it has completed. You must check command buffer fence before this call. The Vulkan spec states: commandBuffer must not be in the recording or pending state (https://vulkan.lunarg.com/doc/view/1.2.182.0/mac/1.2-extensions/vkspec.html#VUID-vkBeginCommandBuffer-commandBuffer-00049)

I wondered whether this is because I'm implementing from scratch rather than copy/pasting your implementation. However, I get this same error when running a fork of this repo. I don't know what's going on here and whether it is a general error or related to macOS and MoltenVK.

Describe the bug
This function never caused an issue until now because it doesn't check against 0, basically returned the opposite of what is expected. solution: return _stat(path, &buffer) == 0;

Desktop (please complete the following information):

• OS: Windows 11

It was suggested to look into using CLOCK_MONOTONIC_RAW because it might be a better choice than CLOCK_MONOTONIC since it is not affected by NTP or adjtime.

The handedness that is currently placed into the w component of the tangent could instead be pre-multiplied against the final computed tangent. The tangent could then be converted to a 3-component vector and the extra calculation in the fragment shader could be removed.

Describe the bug
i have no idea ... but this is what the terminal prints, when i run testbed out of the bin directory

[ERROR]: Validation Error: [ VUID-VkFramebufferCreateInfo-renderPass-parameter ] Object 0: handle = 0x1714ab0, type = VK_OBJECT_TYPE_INSTANCE; | MessageID = 0x98a2a472 | Invalid VkRenderPass Object 0xcb1c7c000000001b. The Vulkan spec states: renderPass must be a valid VkRenderPass handle (https://vulkan.lunarg.com/doc/view/1.3.204.0/linux/1.3-extensions/vkspec.html#VUID-VkFramebufferCreateInfo-renderPass-parameter)
[DEBUG]: Vulkan command buffers created.
[ERROR]: Error opening file: '../assets//shaders/Builtin.MaterialShader.vert.spv'
[ERROR]: binary_loader_load - unable to open file for binary reading: '../assets//shaders/Builtin.MaterialShader.vert.spv'.
[ERROR]: Unable to read shader module: shaders/Builtin.MaterialShader.vert.spv.
[ERROR]: Unable to create vert shader module for 'Builtin.MaterialShader'.
[ERROR]: Error loading built-in basic_lighting shader.
[FATAL]: Renderer backend failed to initialize. Shutting down.
[FATAL]: Failed to initialize renderer. Aborting application.
[FATAL]: Application failed to create!.

the compilations finished without errors

To Reproduce
Steps to reproduce the behavior:

sudo apt install vulkan-sdk clang libx11-dev libxkbcommon-x11-dev libx11-xcb-dev
./build-all.sh
cd testbed/
./build.sh
cd ..
cd bin
./testbed

Expected behavior
i have a too new version of the VULKAN_SDK ?
i have the version 1.3.204.0 installed with the "debian package"-methode

Screenshots
a window show up a fragtoin of a secound ... but nothing to take a screenshot of ^^

Desktop (please complete the following information):

• OS: Ubuntu 21.10
• GPU: Radeon RX 6600 XT
• neofetch:

OS: Kubuntu 21.04 x86_64 
Kernel: 5.11.0-44-generic 
Uptime: 10 days, 4 hours, 19 mins 
Packages: 4050 (dpkg), 22 (snap) 
Shell: bash 5.1.4 
Resolution: 3840x2160, 3840x2160, 3840x2160, 3840x2160 
DE: Plasma 
WM: KWin 
Theme: Breeze Light [Plasma], Breeze [GTK2/3] 
Icons: breeze [Plasma], breeze [GTK2/3] 
Terminal: konsole 
CPU: AMD Ryzen 9 5950X (32) @ 3.400GHz 
GPU: AMD ATI 0b:00.0 Navi 23 
Memory: 14418MiB / 128731MiB

complete log:

build kohi:

Building everything...
Scaffolding folder structure...
Done.
Compiling...
engine/src/platform/platform_linux.c...
engine/src/platform/platform_win32.c...
Linking engine...
Scaffolding folder structure...
Done.
Compiling...
testbed/src/entry.c...
testbed/src/game.c...
Linking testbed...
clang obj/testbed/src/entry.c.o obj/testbed/src/game.c.o                 -o bin/testbed -L./bin/ -lengine -Wl,-rpath,.
Scaffolding folder structure...
Done.
Compiling...
tests/src/memory/linear_allocator_tests.c...
tests/src/memory/dynamic_allocator_tests.c...
tests/src/test_manager.c...
tests/src/main.c...
tests/src/containers/freelist_tests.c...
tests/src/containers/hashtable_tests.c...
Linking tests...
clang obj/tests/src/memory/linear_allocator_tests.c.o obj/tests/src/memory/dynamic_allocator_tests.c.o obj/tests/src/test_manager.c.o obj/tests/src/main.c.o obj/tests/src/containers/freelist_tests.c.o obj/tests/src/containers/hashtable_tests.c.o            -o bin/tests -L./bin/ -lengine -Wl,-rpath,.
All assemblies built successfully.

build testbed:

Building testbed...
clang ./src/entry.c ./src/game.c -g -fdeclspec -fPIC -o ../bin/testbed -D_DEBUG -DKIMPORT -Isrc -I../engine/src/ -L../bin/ -lengine -Wl,-rpath,.

running testbed:

[FATAL]: A test message: 3.140000
[ERROR]: A test message: 3.140000
[WARN]:  A test message: 3.140000
[INFO]:  A test message: 3.140000
[DEBUG]: A test message: 3.140000
[TRACE]: A test message: 3.140000
[INFO]:  Input subsystem initialized.
[TRACE]: Loader registered.
[TRACE]: Loader registered.
[TRACE]: Loader registered.
[TRACE]: Loader registered.
[INFO]:  Resource system initialized with base path '../assets'.
[DEBUG]: Required extensions:
[DEBUG]: VK_KHR_surface
[DEBUG]: VK_KHR_xcb_surface
[DEBUG]: VK_EXT_debug_utils
[INFO]:  Validation layers enabled. Enumerating...
[INFO]:  Searching for layer: VK_LAYER_KHRONOS_validation...
[INFO]:  Found.
[INFO]:  All required validation layers are present.
WARNING: radv is not a conformant vulkan implementation, testing use only.
[INFO]:  Vulkan Instance created.
[DEBUG]: Creating Vulkan debugger...
[DEBUG]: Vulkan debugger created.
[DEBUG]: Creating Vulkan surface...
[DEBUG]: Vulkan surface created.
[INFO]:  Evaluating device: 'AMD RADV DIMGREY_CAVEFISH (ACO)', index 0.
[INFO]:  Graphics | Present | Compute | Transfer | Name
[INFO]:         1 |       1 |       1 |        1 | AMD RADV DIMGREY_CAVEFISH (ACO)
[INFO]:  Device meets queue requirements.
[TRACE]: Graphics Family Index: 0
[TRACE]: Present Family Index:  0
[TRACE]: Transfer Family Index: 1
[TRACE]: Compute Family Index:  1
[INFO]:  Selected device: 'AMD RADV DIMGREY_CAVEFISH (ACO)'.
[INFO]:  GPU type is Descrete.
[INFO]:  GPU Driver version: 21.0.3
[INFO]:  Vulkan API version: 1.2.145
[INFO]:  Local GPU memory: 7.75 GiB
[INFO]:  Shared System memory: 7.98 GiB
[INFO]:  Local GPU memory: 0.25 GiB
[INFO]:  Physical device selected.
[INFO]:  Creating logical device...
[INFO]:  Loading layer library libVkLayer_khronos_validation.so
[INFO]:  Inserted device layer VK_LAYER_KHRONOS_validation (libVkLayer_khronos_validation.so)
[INFO]:  Loading layer library libVkLayer_MESA_device_select.so
[INFO]:  Failed to find vkGetDeviceProcAddr in layer libVkLayer_MESA_device_select.so
[INFO]:  Validation Information: [ UNASSIGNED-cache-file-error ] Object 0: handle = 0x1fbf620, type = VK_OBJECT_TYPE_DEVICE; | MessageID = 0xf0bb3995 | Cannot open shader validation cache at //tmp//shader_validation_cache-1000.bin for reading (it may not exist yet)
[INFO]:  Logical device created.
[INFO]:  Queues obtained.
[INFO]:  Graphics command pool created.
[INFO]:  Swapchain created successfully.
[ERROR]: Validation Error: [ VUID-VkFramebufferCreateInfo-renderPass-parameter ] Object 0: handle = 0x1714ab0, type = VK_OBJECT_TYPE_INSTANCE; | MessageID = 0x98a2a472 | Invalid VkRenderPass Object 0xcb1c7c000000001b. The Vulkan spec states: renderPass must be a valid VkRenderPass handle (https://vulkan.lunarg.com/doc/view/1.3.204.0/linux/1.3-extensions/vkspec.html#VUID-VkFramebufferCreateInfo-renderPass-parameter)
[DEBUG]: Vulkan command buffers created.
[ERROR]: Error opening file: '../assets//shaders/Builtin.MaterialShader.vert.spv'
[ERROR]: binary_loader_load - unable to open file for binary reading: '../assets//shaders/Builtin.MaterialShader.vert.spv'.
[ERROR]: Unable to read shader module: shaders/Builtin.MaterialShader.vert.spv.
[ERROR]: Unable to create vert shader module for 'Builtin.MaterialShader'.
[ERROR]: Error loading built-in basic_lighting shader.
[FATAL]: Renderer backend failed to initialize. Shutting down.
[FATAL]: Failed to initialize renderer. Aborting application.
[FATAL]: Application failed to create!.

Describe the bug
While building i'am getting error:

Building everything...
Scaffolding folder structure...
Done.
Compiling...
engine/src/renderer/renderer_frontend.c...
engine/src/renderer/renderer_frontend.c:170:15: error: variable length array used [-Werror,-Wvla]
    u8 pixels[pixel_count * channels];
              ^~~~~~~~~~~~~~~~~~~~~~
1 error generated.
make: *** [Makefile.engine.linux.mak:43: obj/engine/src/renderer/renderer_frontend.c.o] Error 1
Error:2

• OS: Linux / Manjaro

All required libs are installed
clang version: clang-12

Describe the bug
Not really a bug per-se:
As the title suggests, event_system_initialize and shutdown for some reason doesn't have parameters in the .h file in the diff

These need to be added to the key definitions and mapped on all platforms.

• mouse_state.buttons is a u8 instead of a b8. Minor issue that won't ever break anything, but should be fixed.
• input_process_mouse_wheel fires the event using a u8 instead of a i8. Won't be able to tell direction with it being unsigned.

freelist.c
u64 max_entries = (total_size / sizeof(void*)); //NOTE: This might have a remainder, but that's ok.

When running the application, the memory usage from the OS indicates 4GB usage, when you're managing only 1GB.
This calculation will need to make an assumption that not every request will be as small as a void* to be efficient.

Maybe...
u64 max_entries = (total_size / (16 * sizeof(void*))); //NOTE: This might have a remainder, but that's ok.

Note that this would have more of an impact in OpenGL than Vulkan, but the request was originally made for Vulkan.

Describe the bug
In vulkan_backend.c, within the function vulkan_alloc_reallocation, the new size is being used in the copy operation (around line 155) from the old memory block to the new. This should be the old size so as to not copy over data from elsewhere that would be invalid.

Change the size parameter from size to alloc_size.

Reported by "Happy Rhino" via YT video comment.

Describe the bug
I've tried cleaning and rebuilding. Redownloaded into another folder. .dll and .lib are built successfully. Not sure why I'm getting linking errors:

game.c.o : error LNK2019: unresolved external symbol camera_system_get_default referenced in function game_initialize
game.c.o : error LNK2019: unresolved external symbol camera_position_set referenced in function game_initialize
game.c.o : error LNK2019: unresolved external symbol camera_yaw referenced in function game_update
game.c.o : error LNK2019: unresolved external symbol camera_pitch referenced in function game_update
game.c.o : error LNK2019: unresolved external symbol camera_move_forward referenced in function game_update
game.c.o : error LNK2019: unresolved external symbol camera_move_backward referenced in function game_update
game.c.o : error LNK2019: unresolved external symbol camera_move_left referenced in function game_update
game.c.o : error LNK2019: unresolved external symbol camera_move_right referenced in function game_update
game.c.o : error LNK2019: unresolved external symbol camera_move_up referenced in function game_update
game.c.o : error LNK2019: unresolved external symbol camera_move_down referenced in function game_update
bin\testbed.exe : fatal error LNK1120: 11 unresolved externals
clang: error: linker command failed with exit code 1120 (use -v to see invocation)

Describe the bug
On Windows, when enabling the frame limit at application.c:645, it will limit the framerate to approximately 60 FPS even when target_frame_seconds is smaller than 1.0f / 60. For example, when setting target_frame_seconds to 1.0f / 144, printing out 1.0f / delta, which should give the framerate (inverse of period), it will still yield approximately 60 FPS. Interestingly this does not occur for target_frame_seconds greather than 1.0f / 60 (i.e. 1.0f / 30), although the yielded FPS seems to be rather unstable. To be honest I'm having trouble figuring out exactly why this is occurring. The clock logic at least seems correct to me. I wonder if it's due to a technical detail with the Windows Sleep function.

To Reproduce
Steps to reproduce the behavior:

1. In application.c, switch limit_frames on line 645 to true.
2. Change target_frame_seconds to a different value (i.e. 1.0f / 144).
3. Log the frequency each frame (1.0f / delta).
4. Build and run the program and observe the logged frequency.

Expected behavior
When changing target_frame_seconds to 1.0f / X, then the FPS should attempt to maintain 'X' FPS while the limiter is enabled.

Desktop (please complete the following information):

• OS: Windows

Describe the bug
Reported in YT comments. In vulkan_device.c, around line 322 the requirements.device_exctension_names darray is created, but not destroyed after the call to physical_device_meets_requirements.

Instead of just adding this though, that whole block should be moved outside the loop, and the darray finally destroyed once the loop completes, before the check to see if a device was selected.

Edit: Also includes required_validation_layer_names and available_layers in vulkan_backend.c around line 242.

change swapchain->max_frames_in_flight to be based on swapchain_support.capabilities.maxImageCount - 1

Per a comment from Bradley Stach on YT:

for the keycodes that come through in NSEvent, use #import <Carbon/Carbon.h> The defines for the key codes then follow the form kVK_Space, kVK_ANSI_A, kVK_ANSI_B, etc.

This may simplify the input section of logic (or at least make it more clear).

Copied from a comment on YT:

During testing I encountered case where allocated space at the end did not get freed.
Steps I used:

• make freelist for 3-4 elements and allocate all of them
• free last one (this will hit the case you described in the next video)
• free something else
  last operation should return false (at least for me it does). Offset is less than the only free block in the free list.

To fix that I did add some logic after while loop to fix that, but it seemed a bit hacky.

Describe the bug
I called get_memory_useage_str() just before shutdown, and I noticed some memory still being allocated in certain areas
I first started digging in with the swapchain.
swapchain.c
-1: each individual element in the render_textures array still needs to be freed.
-2: the depth texture still needs to be freed
-3 the vulkan_image* allocated just before vulkan_image_create() takes sizeof(texture) instead of sizeof(vulkan_image), don't know if that was intended.

That's what I've debugged so far

Describe the bug
Changes with episode 78 - pixel perfect object selection produce odd results, sometime the right value, sometimes zero, sometimes seemingly random high values. The issue is created when copying from the image to a buffer. While RenderDoc shows perfect image creation, the results from the copy are not.

To Reproduce
I am using a AMD Radeon RX 5700 XT - I am guessing any AMD card would do.
Try the hover functionality - see occasionally weird "object ids" appear, and mostly 0s, very rarely, the right object id

Expected behavior
return the correct object id

Screenshots

Desktop (please complete the following information):

• OS: Windows 11
• Card: AMD Radeon RX 5700 XT, latest drivers etc.
• Version [e.g. 22]

Additional context
The solution to the problem is to change the image tiling on the colour attachment image from VK_IMAGE_TILING_OPTIMAL to VK_IMAGE_TILING_LINEAR. Note this cannot be a global change for depth attachments require image tiling to be set to VK_IMAGE_TILING_OPTIMAL.

This will fix design issues as well as a few reported bugs that need attention.

Some design highlights:

• Will be implemented alongside darray, and darray will be marked as deprecated. This will allow a phased transition from one to the other.
• Will be covered by tests in the testing framework.
• Any functions that modify the array (push, pop, insert, etc.) should return a pointer to it as well to allow for function chaining.
• Remove the concept of trying to macro the type and instead pass sizeof for the stride like all the other containers.
• Should be a typesafe struct that contains data, stride, length, etc. instead of trying to hide it. This also eases testability.
• Make a new macro to convert from an rvalue to a void* for use in push/insert when using rvalues instead of always doing it (e.g. push).

Bugs to be resolved:

• _darray_pop_at, line 74, error string has %index instead of %i.
• No similar check for _darray_pop.
• _darray_remove_at, last argument to kcopy_memory should be 1 less (stride * (length - index - 1)).
• _darray_insert_at, the last element test should be removed and always done. Should insert new value at index and push last element out.

Describe the bug
In create_command_buffers within vulkan_backend.c, there are calls to zero the memory out in multiple places. In addition, there is also a call to zero the memory within vulkan_command_buffer_allocate, and the size there is wrong. Remove the extra calls and only clear the memory once.

I have a integrated GPU and I would really like you to add support for such GPUs

Bug:

In certain graphics cards, the current queue selection process will pick the same queueFamilyIndex more than once if there are not enough individual queueFamilyIndex's for each (graphics, transfer and present) queue. This triggers a validation error within vulkan that goes as follows:

Output:

Validation Error: [ VUID-VkDeviceCreateInfo-queueFamilyIndex-02802 ] Object 0: handle = 0x1088d50, type = VK_OBJECT_TYPE_PHYSICAL_DEVICE; | MessageID = 0x29498778 | CreateDevice(): pCreateInfo->pQueueCreateInfos[2].queueFamilyIndex (=1) is not unique and was also used in pCreateInfo->pQueueCreateInfos[1]. The Vulkan spec states: The queueFamilyIndex member of each element of pQueueCreateInfos must be unique within pQueueCreateInfos, except that two members can share the same queueFamilyIndex if one describes protected-capable queues and one describes queues that are not protected-capable (https://vulkan.lunarg.com/doc/view/1.3.224.0/linux/1.3-extensions/vkspec.html#VUID-VkDeviceCreateInfo-queueFamilyIndex-02802)

neofetch --stdout

shadoww@xddz 
------------ 
OS: Debian GNU/Linux 11 (bullseye) x86_64 
Host: Aspire A315-21G V1.12 
Kernel: 5.10.0-18-amd64 
Uptime: 1 day, 13 hours, 37 mins 
Packages: 2926 (dpkg) 
Shell: zsh 5.8 
Resolution: 1366x768 
WM: bspwm 
Theme: Adwaita-One-Dark [GTK2/3] 
Icons: hicolor [GTK2/3] 
Terminal: alacritty 
Terminal Font: Iosevka 
CPU: AMD A9-9420 RADEON R5 2C+3G (2) @ 3.000GHz 
GPU: AMD ATI Radeon R5 M230 / R7 M260DX / Radeon 520 Mobile 
GPU: AMD ATI Radeon R2/R3/R4/R5 Graphics 
Memory: 5397MiB / 7410MiB 

VkQueueFamilyProperties (vulkaninfo):

VkQueueFamilyProperties:
========================
	queueProperties[0]:
	-------------------
		minImageTransferGranularity = (1,1,1)
		queueCount                  = 1
		queueFlags                  = QUEUE_GRAPHICS | QUEUE_COMPUTE | QUEUE_TRANSFER | QUEUE_SPARSE_BINDING
		timestampValidBits          = 64
		present support             = true

	queueProperties[1]:
	-------------------
		minImageTransferGranularity = (1,1,1)
		queueCount                  = 4
		queueFlags                  = QUEUE_COMPUTE | QUEUE_TRANSFER | QUEUE_SPARSE_BINDING
		timestampValidBits          = 64
		present support             = true

./engine/src/renderer/vulkan/vulkan_device.c

    if (!transfer_shares_graphics_queue) {
        indices[index++] = context->device.transfer_queue_index;
    }

    VkDeviceQueueCreateInfo queue_create_infos[index_count];
    for (u32 i = 0; i < index_count; ++i) {
        queue_create_infos[i].sType = VK_STRUCTURE_TYPE_DEVICE_QUEUE_CREATE_INFO;
        queue_create_infos[i].queueFamilyIndex = indices[i];
        queue_create_infos[i].queueCount = 1;

        // TODO: Enable this for a future enhancement.
        // if (indices[i] == context->device.graphics_queue_index) {
        //     queue_create_infos[i].queueCount = 2;
        // }
        queue_create_infos[i].flags = 0;
        queue_create_infos[i].pNext = 0;
        f32 queue_priority = 1.0f;
        queue_create_infos[i].pQueuePriorities = &queue_priority;
    }

    // Request device features.
    // TODO: should be config driven
    VkPhysicalDeviceFeatures device_features = {};

As you can see above, I've only got 2 "queue families", yet, the current code requires at least one queue family for each mode (graphics, present, transfer).

Currently on Linux the intellisense is annoyed by the clock_gettime(CLOCK_MONOTONIC, &now); situation.

This fix is simple actually and requires a simple change to cStandard to be set to gnu17 instead of c17

Per a comment on YT from April E, can eliminate the need to globally turn off key repeats by doing the following:

• Solve the key repeating problem without needing to change it globally on the server by using the xkb extension to set the XCB_XKB_PER_CLIENT_FLAG_DETECTABLE_AUTO_REPEAT flag on.

Also from April E:

"I found the reason for the & ~0x80 being done on X11 events. Every event has an 8bit code. And the most significant bit in the code is set if the event was generated from a SendEvent request (like from a window manager vs the X server itself.) & ~0x80 = 0111 1111 so by anding it to the event you are clearing that top bit ensuring that you will always match your event code regardless of the event's origin. Arguably just anding by 0x7F would be better. Anyway...that's the reason behind it. So in your cases where you check for the pressed state you should do the same. You also want to free the replies you get when retrieving the WM_PROTOCOLS & WM_DELETE_WINDOW atoms."

Finally, add a static lookup table of key codes->keys and eliminate switch in translate function.