You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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)
The text was updated successfully, but these errors were encountered:
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?
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
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.
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 wholeRenderer
. 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 intermediateMesh
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 topygame.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 exportSDL_RenderGeometry
+Mesh
, or should we correctly portpygame.gpu
and let the user make that possible there? (more flexible with shaders)The text was updated successfully, but these errors were encountered: