SDL_GPU.h

SDL Development
41

thank you. That’s what I think I did, but for some reasons I don’t get what I’m expecting, even though the metal gpu trace suggest that some results are ok, but not displayed correctly, it’s very strange.
The buffers are the same across pipelines… I will test it, but I don’t need to rebind buffers after having bound a new pipeline, do I? In other words, the bindings are not supposed to be order-dependent?

(I guess that like a gazillions time before in my experience of graphics programming, my code has a silly error that once fixed, makes everything render correctly :-/)

42

The buffers are the same across pipelines… I will test it, but I don’t need to rebind buffers after having bound a new pipeline, do I? In other words, the bindings are not supposed to be order-dependent?

no they aren’t…

(I guess that like a gazillions time before in my experience of graphics programming, my code has a silly error that once fixed, makes everything render correctly :-/)

…turned out the culprit was not that silly, but now it works as expected, thanks again for your help!

1 Like
43

I played around a bit with the GPU renderer and modified the test example testgpu_spinning_cube.c a little.

Now to the question, why does my square look like a sawblade?

I took a photo of it, but you can’t see this effect on a print screen.

gpu_renderer
gpu_renderer720×1280 125 KB

44

Does the unmodified program do this too, or just your version?

45

Yes, the error also occurs in the original, but I had to make a small change so that you can see it.

With rotate_matrix, I assume that it is a bug that Y and Z have been swapped.

// old:
rotate_matrix((float)winstate->angle_z, 0.0f, 1.0f, 0.0f, matrix_rotate);
// new:
rotate_matrix((float)winstate->angle_z, 0.0f, 0.0f, 1.0f, matrix_rotate);

Further down, I only rotate the Z axis, then you can see the error clearly,

winstate->angle_x += 0;
winstate->angle_y += 0;
winstate->angle_z += 8;

Or was it done deliberately, how 3 textures are used here.

SDL_GPUTexture *tex_depth, *tex_msaa, *tex_resolve;
46

I think that’s just ghosting on your monitor. My monitor has a little bit of ghosting too, but nowhere near as bad.

The 3 textures have nothing to do with it (the depth texture is the z buffer, the other two are for MSAA)

47

I think that’s just ghosting on your monitor. My monitor has a little bit of ghosting too, but nowhere near as bad.

This is hardly due to the monitor, otherwise I would have the same effect with normal OpenGL animations.

48

This is a picture I took of testgl.c running. Plain old OpenGL.

It looks worse when you take a picture because the camera isn’t synced to your monitor, so the result has multiple frames from your monitor combined into one photo.

testgl
testgl1024×806 190 KB

49

This is hardly due to my monitor. As said above, OpenGL is OK.
With SDL_gpu it really stands out.

50

The picture I posted is OpenGL.

51

Only if the shutter speed is too slow. Use a proper camera (not a phone!) and set the exposure time to the closest you can get to one frame period.

52

But I don’t necessarily need a camera, because the effect is visible to the naked eye.
I don’t see anything with OpenGL and with SDL_gpu like in my first photo.