Rendering to a non-sqaured texture
Author
I need to make my 2D game resolutionindpeendent, but i am having some problems here.
The native resolution of the game is 1280x1024, so i need to render everything on a 1280x1024 texture, and then stretch the texture to the actual resolution size.
But my problem goes here.Seems that i cannot render to a 1280x1024 texture, or can i?
Can you guys help me on this one?
Well, there's the NPOT (non-power-of-two) extension, but I'm not sure this applies to render-to-texture as well.
A workaround would be: create a 2048 x 1024 texture and render to a 1280x1024 area, leaving the rest as is. Then render a quad with that texture using the texture coordinates that correspond to that 1280x1024 area.
Hope that helps.
A workaround would be: create a 2048 x 1024 texture and render to a 1280x1024 area, leaving the rest as is. Then render a quad with that texture using the texture coordinates that correspond to that 1280x1024 area.
Hope that helps.
Quote:Original post by xilup
But my problem goes here.Seems that i cannot render to a 1280x1024 texture, or can i?
Don't see why you shouldn't be able to. If that is an issue for whatever reason then you could render to a 1280*1280 texture (rendering only to a section of it using glViewport) and when it comes to rendering the final texture to screen you could render it with tex coords (0, 0) to (1, 0.8), 0.8 being 1024/1280.
Author
Quote:Original post by NanohaQuote:Original post by xilup
But my problem goes here.Seems that i cannot render to a 1280x1024 texture, or can i?
Don't see why you shouldn't be able to. If that is an issue for whatever reason then you could render to a 1280*1280 texture (rendering only to a section of it using glViewport) and when it comes to rendering the final texture to screen you could render it with tex coords (0, 0) to (1, 0.8), 0.8 being 1024/1280.
pOpenGL->glSetTexture ( "render" ); //this bind an empty texture that has a size of 1280x1280 i32 t_i32Viewport[4];glGetIntegerv(GL_VIEWPORT, t_i32Viewport); glViewport( 0, 0, 1280, 1024 ); if ( m_pWindow ) m_pWindow->gOnRender (); glCopyTexImage2D( GL_TEXTURE_2D, 0, GL_RGBA, 0, 0, 1280, 1280, 0 ); pOpenGL->glClearScene ( GL_COLOR_BUFFER_BIT, GL_ARGB(0,0,1,1) ); glViewport( t_i32Viewport[0],t_i32Viewport[1],t_i32Viewport[2],t_i32Viewport[3]); glBegin(GL_TRIANGLE_STRIP); glTexCoord2f(0,0); glVertex2f(0,0); glTexCoord2f(0,1); glVertex2f(0,t_i32Viewport[2]); glTexCoord2f(t_i32Viewport[3]/t_i32Viewport[2],0); glVertex2f(t_i32Viewport[3], 0); glTexCoord2f(t_i32Viewport[3]/t_i32Viewport[2],1); glVertex2f(t_i32Viewport[3], t_i32Viewport[2]); glEnd();It is very very very slow, and when it finaly shows something on screen its only my cursor which moves really slow.
Do you have an ATI card? Cursory googling returns the following:
http://www.opengl.org/discussion_boards/ubbthreads.php?ubb=showflat&Number=219159
Generally, though, I would say the approach you're taking to higher resolutions is probably not the way to go. Stretching an image, ESPECIALLY to a size that is not a direct integer multiple of its original size, is going to look REALLY bad. If anything, I would suggest starting with art designed for the highest supported resolution and scaling it down when needed; it's always better to discard extra information than to create new information by scaling.
I seem to remember a post maybe a month or two back in the "Game Design" forum on this site that had a decent discussion on the topic of the various ways of dealing with resolution-independence. You might want to look for that.
http://www.opengl.org/discussion_boards/ubbthreads.php?ubb=showflat&Number=219159
Generally, though, I would say the approach you're taking to higher resolutions is probably not the way to go. Stretching an image, ESPECIALLY to a size that is not a direct integer multiple of its original size, is going to look REALLY bad. If anything, I would suggest starting with art designed for the highest supported resolution and scaling it down when needed; it's always better to discard extra information than to create new information by scaling.
I seem to remember a post maybe a month or two back in the "Game Design" forum on this site that had a decent discussion on the topic of the various ways of dealing with resolution-independence. You might want to look for that.
You've certainly got the right idea, can't see why that alone would cause major slow down. What graphics card are you using? Might be useful to see whats inside that m_pWindow->gOnRender() method.
Also you can use glPushAttrib(GL_VIEWPORT_BIT) and glPopAttrib() to store the currect view port and pop it back afterwards
I find it neater but I think push/pop attrib might be depreciated in opengl now.
Have you tried using a frame buffer object as a render target instead of using glCopyTexImage2D? not sure how that would fit in with your other window rendering bits though (mind if your havign slow down issues and non-power of 2 texture issues chances are your card mmight not support fbo)
Also you can use glPushAttrib(GL_VIEWPORT_BIT) and glPopAttrib() to store the currect view port and pop it back afterwards
glPushAttrib(GL_VIEWPORT_BIT) glViewport( 0, 0, 1280, 1024 ); if ( m_pWindow ) m_pWindow->gOnRender (); glCopyTexImage2D( GL_TEXTURE_2D, 0, GL_RGBA, 0, 0, 1280, 1280, 0 ); pOpenGL->glClearScene ( GL_COLOR_BUFFER_BIT, GL_ARGB(0,0,1,1) ); glPopAttrib() I find it neater but I think push/pop attrib might be depreciated in opengl now.
Have you tried using a frame buffer object as a render target instead of using glCopyTexImage2D? not sure how that would fit in with your other window rendering bits though (mind if your havign slow down issues and non-power of 2 texture issues chances are your card mmight not support fbo)
Author
Quote:Original post by Nanoha
You've certainly got the right idea, can't see why that alone would cause major slow down. What graphics card are you using? Might be useful to see whats inside that m_pWindow->gOnRender() method.
Also you can use glPushAttrib(GL_VIEWPORT_BIT) and glPopAttrib() to store the currect view port and pop it back afterwards
*** Source Snippet Removed ***
I find it neater but I think push/pop attrib might be depreciated in opengl now.
Have you tried using a frame buffer object as a render target instead of using glCopyTexImage2D? not sure how that would fit in with your other window rendering bits though (mind if your havign slow down issues and non-power of 2 texture issues chances are your card mmight not support fbo)
Thank you very much!Very usefull reply.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
