For a depth buffer in D3D12 that is also going to be used in a texture sampler, the creation (on an Intel HD 5500 igpu) fails. e.g. SDL_GPUTextureCreateInfo type = TEXTURE_2D, format = D32_FLOAT, usage = DEPTH_STENCIL_TARGET | SAMPLER
The error messages are:
D32_FLOAT
D3D12 ERROR: ID3D12Device::CreateShaderResourceView: The Format (0x29, R32_FLOAT) is invalid when creating a View; the
Resource was already created with a fully qualified Format, which is not castable (0x28, D32_FLOAT).
D24_UNORM
D3D12 ERROR: ID3D12Device::CreateShaderResourceView: For the resource format D24_UNORM_S8_UINT, when making a D3D view, the format name for the view can't be R24_UNORM_X8_TYPELESS.
I found this is because the texture format needs to be created as _TYPELESS, then the views (depth stencil view, shader resource view) should then be created as their respective types - e.g. texture = R32_TYPELESS, dsv = D32_FLOAT, srv = R32_FLOAT
Tested and working on:
NVidia RTX 3050 (D3D12 feature set 12_2)
Intel HD 5500 (D3D12 feature set 11_1)
We may want to extend this with additional properties in the future.
Also removed SDL_PROP_GPU_DEVICE_DEBUG_VULKAN_CONFORMANCE_STRING. If we need feature level queries we can add them in the future.
this was causing problems when i was specifying non-zero buffer slots in
`SDL_BindGPUVertexBuffers`, `SDL_GPUVertexAttribute` and
`SDL_GPUVertexBufferDescription`.
`firstSlot + 1` is simply copied over from metal and d3d12 backends.
The GPU API doesn't currently support transparent windows (transparent swapchain effects doesn't seem possible on D3D12) so we should explicitly fail so users don't expect transparency and then not get it.
Fixes https://github.com/libsdl-org/SDL/issues/12410
If the window is flagged with SDL_WINDOW_TRANSPARENT, create the associated swapchain with a composite alpha value that supports blending, if available.
Fixes transparent windows on the Vulkan backend, and prevents possible validation errors by ensuring that the composite alpha value is always a valid bit in VkSurfaceCapabilitiesKHR::supportedCompositeAlpha.
Since there is no option to change it this seems like a much better default value. The stretching behaviour is really off-putting.
The new behavior shows a small black border when resizing the windows. This makes it more in line with the other backends and it's what you would expect to happen as a user.
I changed it so that the OS does the orientation change itself with a potential performance penalty.
This makes it automatically do the right thing, just like on iOS which would make the orientation change behaviour more consistent across different platforms.
But without adding an option to the user, this would disallow the user solving the problem in his in the app/shaders and saving some performance.
It's up to you to decide what to do. But I changed this in my local copy of the source for my use case.
But this also
This was intended to make the API public, so SDL_hashtable.h got an extreme
documentation makeover, but for now this remains a private header.
This makes several significant interface changes to SDL_HashTable, and
improves code that makes use of it in various ways.
- The ability to make "stackable" tables is removed. Apparently this still
worked with the current implementation, but I could see a future
implementation struggle mightily to support this. It'll be better for
something external to build on top of the table if it needs it, inserting a
linked list of stacked items as the hash values and managing them separately.
There was only one place in SDL using this, unnecessarily, and that has also
been cleaned up to not need it.
- You no longer specify "buckets" when creating a table, but rather an
estimated number of items the table is meant to hold. The bucket count was
crucial to our classic hashtable implementation, but meant less once we
moved to an Open Addressing implementation anyhow, since the bucket count
isn't static (and they aren't really "buckets" anymore either). Now you
can just report how many items you think the hash will hold and SDL will
allocate a reasonable default for you...or 0 to not guess, and SDL will
start small and grow as necessary, which is often the correct thing to do.
- There's no more SDL_IterateHashTableKey because there's no more "stackable"
hash tables.
- SDL_IterateHashTable() now uses a callback, which matches other parts of SDL,
and also lets us hold the read-lock for the entire iteration and get rid of
the goofy iterator state variable.
- SDL_InsertIntoHashTable() now lets you specify whether to replace existing
keys or fail if the key already exists.
- Callbacks now use SDL conventions (userdata as the first param).
- Other naming convention fixes.
I discovered we use a lot of hash tables in SDL3 internally. :) So the bulk
of this work is fixing up that code to use the new interfaces, and simplifying
things (like checking for an item to remove it if it already exists before
inserting a replacement...just do the insert atomically, it'll do all that
for you!).
