Thank you so much for your hard work!

I figured out you can force Direct3D 12 using SDL_GPU_DRIVER=direct3d12, however it doesn't seem to work with the embedded SDL3, erroring with: "Failed to convert ID3D12 Device to ID3D12InfoQueue"

If I load the newest version of SDL3 though, it seems to work well on both Windows natively and Linux using VKD3D

If I load the newest version of SDL3 though, it seems to work well on both Windows natively and Linux using VKD3D

Interesting, do you know what version exactly?
We can totally update the embedded binaries (or at least sdl one), I haven't done it for a while

I was able to finish porting the rest. I'll look into separating the commits tomorrow. I was able to find another issue which I was also having with my project. sdl.GPUDevice.TextureSupportsFormat() returns true no matter what. In the SDL header files, the return value is a bool. However if I check what the gen_impl bindings return, _r0 is 4294967040 when the function should return false. The return value is 255 before the max uint32 value which is very confusing.

I was able to figure out the issue. Purego-gen should cast bool _r0 to a byte/uint8, such as: __r0 := uint8(_r0) != 0

Purego does this: https://github.com/ebitengine/purego/blob/9059adfae616e486aa4145d6f4d5fefaa1b47a61/func.go#L343

Could you update it or would you like me to make a PR?

I was able to figure out the issue. Purego-gen should cast bool _r0 to a byte/uint8, such as: __r0 := uint8(_r0) != 0

Good catch, I fixed and re-generated all functions in latest commit

I'll look into separating the commits tomorrow.

What do you want to separate? Please don't go into too much a hassle, unless you're okay haha
As this is just adding a new example folder, I think the PR doesn't need splitting anymore (since you already managed to port everything which is amazing btw)
I was suggesting to make it more sequential at first in order to make it easier for you

About the shaders, images, code and so-on I think we should refer to the original LICENSE somewhere also, right?

Ah, no worries. I updated this branch with current main and dropped my commits that you recently added. It should be merge-able. I think it's ready? I'll see if I can test it some more on different platforms and such, but this has been quite extensive in making sure SDL GPU works well.

I have a few ideas for how we could improve the API but I think it might be best if I mess around first before proposing it in a new PR sometime later. The API is already very verbose as it's just thin Vulkan, so it's not surprising unsafe.Slice() and such is necessary user-end.

The only other non-example related changes are in macros.go and methods.go. I also added the LICENSE file from the examples repo and is also mentioned in the README. Should all be okay.

Thank you, I'll take a look tomorrow!

The API is already very verbose as it's just thin Vulkan, so it's not surprising unsafe.Slice() and such is necessary user-end.

Yeah, it would be great if we could abstract away the requirements for unsafe.Slice and unsafe.Sizeof later somehow

Everything runs well for me on Windows, and both vulkan and dx12 give the same results
I can't test other platforms, but this looks good to me!

edit: Tested on linux too and worked well👌

That's good. The only thing I've noticed is that the WINDOWPOS macros I added don't seem to work with Wayland, but they work fine through wine. I think it's something SDL will end up fixing.

I also don't like placing a second go.mod in the project. At least it points go-sdl3 to the local relative path, but if purego-gen changes, it needs go mod tidy. I don't really see any other way to deal with this though. I think it's fine.

Thanks for merging and working so hard on the bindings

Thanks for merging and working so hard on the bindings

I'm happy that we have so many gpu examples, GPU is actually the part of the API that got me to create these bindings in the first place, so thanks to you 🥳
I'm excited to try and port my voxel engine from ebitengine to sdl3 now

I also don't like placing a second go.mod in the project. At least it points go-sdl3 to the local relative path, but if purego-gen changes, it needs go mod tidy. I don't really see any other way to deal with this though. I think it's fine.

Yeah, that's the only thing I wasn't sure about, I considered doing the same for the tools under /cmd which might be okay in this case actually.
I was okay because of the replace line too, was there a particular reason for the go.mod at all? Besides not polluting the root one?
In the end, I think unused dependencies (such as /examples or /cmd's) won't show in the dependencies of a user project.
I guess it makes sense not to scare people away when looking at the root go.mod (the dave/jennifer doesn't make sense for example)

For example https://github.com/hajimehoshi/ebiten/tree/main/examples doesn't have its own go.mod and has custom dependencies only imported by there ("github.com/gen2brain/mpeg", "github.com/jakecoffman/cp/v2")

We can always revert this (the independent go module part) if we feel like it, I don't have a strong opinion so let me know

The only thing I've noticed is that the WINDOWPOS macros I added don't seem to work with Wayland, but they work fine through wine. I think it's something SDL will end up fixing.

Yeah, I don't think there's anything we can do on our end about that, beside creating an issue on the official repo
I'm not running wayland so I can't really investigate