Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

What to do with SDL_RenderGeometry #3346

Open
damusss opened this issue Feb 23, 2025 · 3 comments
Open

What to do with SDL_RenderGeometry #3346

damusss opened this issue Feb 23, 2025 · 3 comments
Labels
discussion enhancement render/_sdl2 pygame._render or former pygame._sdl2

Comments

@damusss
Copy link
Member

damusss commented Feb 23, 2025

A lot of methods of Renderer use SDL_RenderGeometry (and the unfilled counterpart), but they only use it for triangles and quads. The thing is, sdl_rendergeometry has the potential of being one of the most performance-saving functions of them all, this is because if you combine it with a texture, properly set out texture coordinates and vertex positions you can literally render thousands (probably even millions) of tiles with a single draw call, removing the current bottleneck of the whole Renderer. The thing is, if it was that simple to add it, I wouldn't be making this issue.
The issue is the layer from python to C. To use sdl_rendergeometry raw, we would need to convert the user's vertex data from python sequences to a c array, effectively iterating the very big sequence every frame, and all the speedup would be lost. The (pretty much) only solution would be an intermediate Mesh class, that stores the c array once (or when the mesh changes) so that the function is actually performant.
So, then, the thing that needs to be discussed is: is it worth adding a Mesh class to pygame.render, explain the complexity of vertex data, texture coordinates and stuff in the docs, in a module that is supposed to offer a ready-to-replace gpu alternative to surface rendering?
Summary: at this point, it would just be easier to use pygame.gpu. So, what do you think? Should we export SDL_RenderGeometry + Mesh, or should we correctly port pygame.gpu and let the user make that possible there? (more flexible with shaders)

@damusss damusss added enhancement discussion render/_sdl2 pygame._render or former pygame._sdl2 labels Feb 23, 2025
@Starbuck5
Copy link
Member

Summary: at this point, it would just be easier to use pygame.gpu. So, what do you think? Should we export SDL_RenderGeometry + Mesh, or should we correctly port pygame.gpu and let the user make that possible there? (more flexible with shaders)

I don't see how that would be easier. Plus, our goal is to allow our users to exploit the full power of SDL, so I don't see it as a port one thing or the other thing, I see it as port both. Perhaps there's something I'm missing?

@damusss
Copy link
Member Author

damusss commented Feb 23, 2025

so I don't see it as a port one thing or the other thing, I see it as port both. Perhaps there's something I'm missing?

No no, that makes sense. Do you agree that it would be slower without Mesh (I might be missing something)? Do you like the idea of the Mesh class? Do you have a better solution? How would a vertex look in python? another class (Vertex), a dictionary, a sequence? sorry for the question wall xD

@Starbuck5
Copy link
Member

I don't want to leave you hanging, but I haven't done any of the requisite research to answer those questions. I think your idea of keeping some state in C so it can be repeatedly re-applied sounds right. One thought is that Mesh is a meaningful term in computer graphics, we'd want to be sure that it's appropriate for how we would use it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discussion enhancement render/_sdl2 pygame._render or former pygame._sdl2
Projects
None yet
Development

No branches or pull requests

2 participants