Hi,

I am trying to create a Custom Surface Class example using GLFW as mentioned in the documentation. While declaring the

class CustomSurface : public LLGL::Surface I am getting the errors shown in the screenshot. The errors seems to be pointing to NSObjcRuntime.h and NSObject.h. I am only mildly familiar with Mac environment so any help is appreciated

I am unfamiliar with Mac environment so any help is appreciated.

• Static linking now supports multiple renderers in the same lib.
• Added empty api for shader uniforms. Note: Static linking will not not compile with current cmake setup. Each renderer api must now have one of the following defines:

• LLGL_HAS_MODULE_DX11
• LLGL_HAS_MODULE_DX12
• LLGL_HAS_MODULE_OPENGL
• LLGL_HAS_MODULE_OPENGLES3
• LLGL_HAS_MODULE_VULKAN
• LLGL_HAS_MODULE_METAL

Hi, recently I have been using LLGL to replace the ugly underlying API layer in my engine, I am a big fan of LLGL architecture as I hate opengl-like architecture "ex: bgfx", anyways I have some questions about this library.

1-Why supporting OpenGL? Vulkan is a great successor and run on almost all platforms that OpenGL run on, and can run on mobile devices plus it has DirectX-like structure and a modern API. The reason I dislike OpenGL is it has some sort of legacy function that is still used until now! for example it requires a vertex format for each vertex buffer created! correct me if I am wrong but it is the only API that does that in 2018.

2-Do I have to create a resource heap for each pair of Texture and sampler in every shader?

3-Will I need more than one CommandBuffer for my project?

4-Why is "RenderSystem" / "Renderer" named with these names? shouldn't they be named Context and the "Context" class should be named Device?

• I kinda prefer DirectX namings + naming anything with "Renderer" can cause huge confusion especially with newcomers.

Hi, I'm trying to run the examples, but I can't get it to work.

I followed the setup instructions to install everything and it all builds fine. (I'm using visual studio 2019)

When I run the develop build for the PBR example and pick the DirectX12 option in the console I get a "failed to open file: Example.hlsl" error

I then manually setup the Debugging->Working Directory to point to the project directory, and that fixed the loading issue.

After that I get a crash on D3D12CommandContext::SetPipelineState

traced it down to:

D3D12MipGenerator::CreateComputePSO if (auto blob = DXCreateBlobFromResource(resourceID)) returning null

/* Load resource from binary data (*.rc file) */
if (HRSRC resource = FindResource(moduleHandle, MAKEINTRESOURCE(resourceID), RT_RCDATA))

I don't seem to have this .rc file. Did I miss something?

Hi,

I was checking the License more carefully and I noticed that this library is using none of the well-known licenses. Therefore I was here to actually ask if there is a plan on using anyone of them like MIT, Apache or GPL?

I was planning in using this in one of my projects, but at the current state I'm a bit concerned about consequences in using your code on top of mine.

Thank you in advance for any clarification given.

Hi. I found that when write compressed texture to Cubemap texture with extension GL_ARB_direct_state_access you call glCompressedTextureSubImage3D function just like when it is not compressed you call glTextureSubImage3D function. And I checked that why you call this function in page : https://www.khronos.org/opengl/wiki/Cubemap_Texture. It says : "Uploading pixel data for cubemaps is somewhat complicated. If OpenGL 4.5 or ARB_direct_state_access is available, then glTexSubImage3D can be used to upload face data for a particular mipmap level. The third dimension values for glTexSubImage3D represents which face(s) to upload data to. The faces are indexed in the following order: ..."

But when I use the compressed type write function it seems write nothing to the texture(all is black). So I want to know whether the glCompressedTextureSubImage3D function can use for cubemap texture just as same as the glTextureSubImage3D function ?

Backstory: I was trying to build this library under Visual Studio 2019 for Win32 Arch and I found out that Vulkan was not able to be found, with the latest SDK version ( 1.1.130 ). Looking at how you did include Vulkan I found out you're using the old suggested method. Nowadays it's better to use the native FindVulkan.cmake which is provided by any Cmake version that is >= 3.7.

I doubt someone will build this code with an older CMake version.

Thank you for the awesome work you're doing. Looking forward on this project.

There is an inconsistency between this lines: DXCode.cpp: caps.features.hasLogicOp = (featureLevel >= D3D_FEATURE_LEVEL_11_1); DX11Types.cpp (function Convert): if (src.logicOp != LogicOp::Disabled) without define LLGL_D3D11_ENABLE_FEATURELEVEL added to compile.

Value of hasLogicOp can be set to true by D3D_FEATURE_LEVEL_11_1 but the code assumes it's disabled without LLGL_D3D11_ENABLE_FEATURELEVEL

I would like to point out that an identifier like "__LLGL_COMMAND_BUFFER_H__" does not fit to the expected naming convention of the C++ language standard. Would you like to adjust your selection for unique names?

I have identified bugs at https://github.com/LukasBanana/LLGL/blob/master/sources/Renderer/Vulkan/VKRenderContext.cpp#L411-L416 and https://github.com/LukasBanana/LLGL/blob/master/sources/Renderer/Vulkan/VKRenderContext.cpp#L465-L470

the outdated VKPtr and VKPtr don't get deleted, instead a new object is made every time the SwapChain is recreated; this causes it not to be deleted on the GPU.

I think it should check if one of the objects exists, if it doesn't, it should create one; then it can recreate it. Like this:

	if (!swapChainImageViews_[i]) {
		swapChainImageViews_[i] = VKPtr<VkImageView>{device_, vkDestroyImageView};
	}

	auto result = vkCreateImageView(device_, &createInfo, nullptr, wapChainImageViews_[i].ReleaseAndGetAddressOf());
	VKThrowIfFailed(result, "failed to create Vulkan swap-chain image view");

	if (!swapChainFramebuffers_[i]) {
		swapChainFramebuffers_[i] = VKPtr<VkFramebuffer>{device_, vkDestroyFramebuffer};
	}

	auto result = vkCreateFramebuffer(device_, &createInfo, nullptr, swapChainFramebuffers_[i].ReleaseAndGetAddressOf());
	VKThrowIfFailed(result, "failed to create Vulkan swap-chain framebuffer");

I’ve been working on getting Retina support into LLGL. The new code is not done and requires a lot of clean-up but the changes involve re-thinking what SetVideoMode does so I thought you should take a look sooner rather than later.

In Retina mode the size of the surface and the size of the drawables diverge. An NSWindow is sized in a space that roughly approximates 72 dpi and then the drawables are sized upward to a match the actual dpi of the screen. So I needed to alter SetVideoMode to resize the drawables independently of the surface size. I started by stubbing out Window::AdjustForVideoMode and all of the fullscreen handling (more on fullscreen later).

Then I added Surface::GetPreferredResolution() so a surface can advertise a preferred resolution that differs from GetContentSize(). Finally I updated OnSetVideoMode for both Metal and OpenGL to resize the drawables appropriately. And that was pretty much it beyond tweaking Info.plist and updating the sample code a bit.

Basically I’ve pared down SetVideoMode to only update the size of the drawables, roughly equivalent to ResizeBuffer in DirectX. This eliminates the possibility that calling SetVideoMode could generate a resize event while handling a resize event. It also eliminates the code that was trying to re-center the window on every resize event which was making live re-resizing impossible on the Mac.

(BTW, I tweaked the DirectX versions of OnSetVideoMode to allow arbitrary sizes to match the Mac. On Windows the main use would be to to reduce the size of the drawables for performance reasons.)

The next step is to get fullscreen working again. Previously SetVideoMode was called at both ends of the process, first to kick the system into fullscreen mode and then to handle the resulting resize event. I want to avoid that recursion by introducing new RenderContext routines for entering and exiting fullscreen mode. Then clean-up, including adding some capability flags.

17: Mapping - Validation errors triggered on Vulkan 11: Post-Processing - Validation errors triggered on Vulkan 6: Multi-Context - Validation errors triggered on Vulkan 5: RenderTarget - Validation errors triggered on Vulkan 4: Queries - Validation errors triggered on Vulkan

LLGL::CommandBufferFlags::MultiSubmit seems to imply, that it should be possible to record a command buffer once and resubmit it multiple times to prevent CPU cycles being wasted dispatching draw calls to the GPU while nothing has changed.

The results of testing out this theory made me wonder whether or not the results I was seeing were intended behaviour. Tested with Vulkan.

    LLGL::CommandBuffer *renderCmd;
    {
        LLGL::CommandBufferDescriptor commandBufferDescriptor{
                .flags =(LLGL::CommandBufferFlags::MultiSubmit)
        };
        renderCmd = renderSystem->CreateCommandBuffer(commandBufferDescriptor);
    }
    renderCmd->Begin();
    {
        renderCmd->SetViewport(renderContext->GetResolution());
        renderCmd->SetPipelineState(*pipeline);
        renderCmd->SetVertexBuffer(*vertexBuffer);
        renderCmd->SetClearColor(LLGL::ColorRGBAf(0.1f, 0.1f, 0.1f));

        renderCmd->BeginRenderPass(*renderContext);

        renderCmd->Clear(LLGL::ClearFlags::Color);
        renderCmd->Draw(3, 0);

        renderCmd->EndRenderPass();
    }
    renderCmd->End();
    while (window.ProcessEvents()) {
        queue->Submit(*renderCmd);
        renderContext->Present();
    }

This little example produces nothing more than the clear color flashing between black and the gray specified in the command buffer. The triangle, which renders just fine when the command buffer is re-recorded every frame in the main loop, is no where to be seen with this code.

However, some experimentation revealed even weirder behaviour: Re-recording the command buffer for the first three frames of the application and then continuing to use it works just fine. If the command buffer is altered at a later point in time, it requires only 2 repeated recordings (with a Submit call and a renderContext->Present() in between) for the changes to be displayed without flickering. Re-recording the command buffer less than 3 times for the initial frames of the loop, or less than 2 times at a later point in time will result in flickering back and forth between what seem to be the previously recorded draw calls and what actually should be displayed.

I think this might be happening because a double buffered swap chain also has two command buffers. When a new frame is forced to render, it will cycle back to the previous command buffer. If the command buffer contents have not been updated in a frame, no new image should be acquired from the swap chain.

Should it be possible to re-submit command buffers in this way? Am I using LLGL incorrectly?

I would like to offer WebGPU support for LLGL. And almost directly, straight. Every function would be remap. And it was compiled into two files: JS (WebGPU access) and WebAssembly (residual C++).

1. The library assumes all rendering in Native top-level windows there are other surfaces the - like composition visuals (IVisual), and swap panels etc.
2. the main game loop is owned by the the library this should be factored out for the library to be used as a component
3. UWP support and Core windows support - additionally IVisual, Swap panel in uwp
4. support Google/Angele/GLES under windows.

So I'm trying to generate Shader/Material/Resources using shader reflection. I already did this before and had an hlsl solution.

Looking through the code I found out you can actually use ShaderProgram::Reflect() to do exactly that, but now I have a minor problem.

I need to create and initialize a shader whenever I want to use shader reflection to create the actual shader.

From looking through the code I can see that you only need the shader byte code which is generated using the shader compiler.

Unfortunately I don't see any way to just compile the shader and use the byte code to reflect.

Am I missing something? If not could you make this possible by splitting the compiler and reflection from the shader resource?