Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: Nuke on March 18, 2010, 03:37:28 am
-
ive been throwing this idea around on irc a lot and thought it was time to throw it down here. the idea is to be able to set a clipping rectangle to localize and lock drawing to within the defined area. this is kinda useful for keeping hud gauges in their defined box, but where it would really shine is in dealing with render to texture.
say you want to render your screen to a texture and use it as one of the cockpit textures, then you wanted another one for a radar and another for a weapon status screen. you suddenly have to deal with 3 dynamic textures where it would be more efficient and way faster to only have one and use uv mapping to divide it between all the elements. problem with this is that if you do something like render the frame to the texture it would use up the entire texture, where some parts would want to be reserved for the other gauges. you could also have run over where things may render outside of the desired area, clipping rectangles would prevent that from happening.
while rendering the screen to the texture you want to draw some hud gauges for it, and this requires something like getScreenCoords(), it would return coords in the range of the whole texture. the clipping rectangle would effect those to, so you could set up maybe the top half of the texture as the rear view camera display (or sniper cam or turret cam or whatever) then split up the bottom of the texture among the other panel elements.
usage would be probibly something like gr.setClippingRectangle(x1y1,x2,y2), the coordinate represent a rectangle within the texture. now if you draw a pixel at 0,0, it gets drawn it the top corner of the rectangle, wherever that happens to be in the texture. you could do whatever, including rendering the frame. or getting coordinates which would be in the clipping rectangles local space. once youre done you can gr.setClippingRectangle() without any args to set to default (essentially whatever your render target was).
-
What you're asking for isn't a clipping rect it's a subsurface. Clip rects don't transform coordinates they just refuse to draw pixels outside.
The "Open GL way" to do what you want is to create several textures, but have them all pointed at different sub-rectangles of the same piece of memory, by using glTexSubImage2D. Don't know yet how that is or isn't supported in the FSO engine, but that's how you'd do it.
I'm not sure it would be any faster or more efficient though.
-
ive done this kinda thing with sdl's draw functions, my understanding of opengl on the other hand is limited, all i can do so for is render a bunch of line drawn polies. :D in sdl you lock a rectangle (i think), then anything drawn is in that rectangle's space, you blit it into the surface and unlock to get back to drawing to the surface (i think im not gonna search through all my code to find it). im sure some form of what you mention is in the engine (how else do things like tech room models and drawing of models to the hud work :D).
-
Yeah SDL is more like DirectX in that regard, with its surface-oriented philosophy and the ability to lock subsurfaces.
There's one efficient way to have multiple offscreen render targets in OpenGL, and that's to attach them all to a single framebuffer object (FBO). That way you don't pay the hit of a context switch when you change render targets, only when you switch to a new FBO.
What I don't know yet is if FSOpen does it that way, or if it creates a new FBO for each new render target. I had a quick browse of the relevant code in graphics/gropengltexture.cpp, and it's not immediately obvious how it organizes things.
I'd have to actually run the game it step through in the debugger to see what happens, but I can't do that here from work, people might notice that the game I'm debugging isn't the right one ;)
-
Just tell them you're compiling some documentation of what not to do.
-
We're using the Unreal Engine here. Therefore they are all experts already in what not to do ;)
-
My friend Dan has been trying to get me to start using that since the big release.