dx8 is much bether in that way, really…
But dx8 isn’t cross platform either!!! hahahaha!
How can you complain about gl being fiddly to do pbuffers on linux, macs etc, when dx8 doesn’t do anything at all on these platforms?
Even if DX8 doesn’t run on other platforms, it’s a question of design. And the way render-to-texture works in DX8 is simply lightyears ahead of OpenGL. I have to agree with dave that the pbuffer design kinda sucks. So let’s hope that we get OGL 2.0 soon which fixes that mishap.
IT’s probably more of to do with the completely different way windows works to other operating systems. The only reason you’re exposed to the kludgyness of it all, is because OpenGL is cross platform. Therefore any setup relating to platform dependant features must go through windows code.
The fact you dont see this in dx8 means nothing. It’s not ported to any other platform, so they can just stick a nice wrapper on the top of it, and call it render to texture. It’s still doing the same stuff underneath.
Nutty
Nutty,
I do not think you can blame windows or opengl’s portability. It is simply a matter of pbuffers being a poor design. Even if you consider the environment, I do not think that pbuffers is the only solution that would have worked. If it was, then you could complain about it being because of windows or because of opengl’s design.
Originally posted by Nutty:
[b] But dx8 isn’t cross platform either!!! hahahaha!
How can you complain about gl being fiddly to do pbuffers on linux, macs etc, when dx8 doesn’t do anything at all on these platforms?
[/b]
its rather simple: in dx you don’t need to use a windowsfunction to generate your rendertarget.
think about it. is a texture dependent on the os? it isn’t. is a rendertarget? no. except it has to interfer with the os. when does it have to? if the os needs access to it. to show it. so the framebuffer has to interfer with the os, to display it in a window. there, a wgl func makes sence. but an offscreen buffer. thats just an array. it does by no means need to interfer with thet os. so there is no need for a wgl-extension at all.
GL_ARB_render_target
would be able to create buffers of arbitary size, with additional parameters to say it should be bindable as a simple 2d texture, or a cubemap, or what ever. or, it does interfer with the os… some /flags/|GL_OS_ACCESS_ARB|/other flags…/
and then you need to use some wgl
GL_WGL_render_target
HGLRC hrc = wglMountTargetToHDC(hdc);
wglUnmountTarget(hrc,hdc);
something in this way… (the os-mounting is only needed if its a visible framebuffer for the os, the “screen”)
but making simple pixelbuffers os dependend is utterly stupid.
in dx, you just set a flag at texturecreationtime… render_target…
IT’s probably more of to do with the completely different way windows works to other operating systems.
But windowing systems don’t have anything to do with render-to-texture? What I want is create a texture object, attach a buffer to it, set that buffer as active render target, and render to it. I don’t want to have a separate rendering context, nor do I want a full-featured pbuffer. That’s the way it works in DX 8. It’s also the way it’s currently proposed in the OpenGL 2.0 drafts, by the way.
Another thing that OpenGL 2.0 hopefully finally gets rid of, is the platform-dependent routines to specify depth and stencil buffer formats, which semantically has nothing to do with windowing systems. Of course the implementation to create these buffers will most likely be platform-dependent, but in the end OpenGL is only a platform-independent API. All the implementations (that is, drivers) are platform-dependent code for a large part. And I think that not defining things as wglMakeCurrent as core part of the GL API was a mistake.
The fact you dont see this in dx8 means nothing. It’s not ported to any other platform, so they can just stick a nice wrapper on the top of it, and call it render to texture. It’s still doing the same stuff underneath.
I highly doubt that it’s doing the same stuff underneath. There’s no separate rendering context in DX for render-textures so there’s no complete state change when I decide to render to a texture. The render context switching for RTT in OpenGL (caused by the use of pbuffers for doing RTT), is a big design flaw IMHO.