social.noyu.me

if I have to use functions from the platform API (i.e. not just gl* stuff) then the answer may as well be “no” though

hey wait what if I made a pixelbuffer and used glReadPixels and then glTexImage2D

…

hikari no, that’s just asking for terrible performance, just use framebuffer blitting at that point…

I know how this ends (it ends with me writing my own OpenGL implementation…)

232 lines of opengl code later, i’m free

hey, since I released it now, you can now see what I was complaining about: https://github.com/hikari-no-yume/touchHLE/blob/cf6b650ebb227ac588d2eb107a8cea90a5fbe97a/src/frameworks/opengles/eagl.rs#L162-L355

@hikari dare I ask, why do you want to avoid using a framebuffer?

@aeva it’s not that I want to avoid using a framebuffer, I’m just forced by, uh, the specific legacy code I am dealing with, to render everything to a renderbuffer, and it just frustrates me that I have to copy it to another thing (a texture) before I can do anything useful with it

@hikari oh no D:

@hikari I doubt it, because semantically renderbuffers allow for vendor-specific encodings that may be incompatible with the texture sampling machinery. A reencoding step would be needed. Using a texture with a framebuffer allows for that step to be made implicit on hardware where it is necessary.

@hikari I believe the answer is no you can't have them share a block of GPU memory because the point of a renderbuffer is to have a simple flat structure and the point of a texture is to have a sampling-friendly weird structure where it's broken up into tiles laid out in morton order or whatever
so the need to explicitly copy data from one to the other reflects this?

@hikari oh I see you've also got aeva elsewhere in this thread giving probably much more accurate information than I have about the fact that renderbuffers might be weird in their own (completely different) ways too ❤️