Sign in to follow this  
xilup

Rendering to a non-sqaured texture

Recommended Posts

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?

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Quote:
Original post by Nanoha
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.



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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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


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)

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this