Jump to content
  • Advertisement
Sign in to follow this  
claestw

SDL and OpenGL: Lost in texture mapping and learning direction

This topic is 4041 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I'm new to game programming (in fact, haven't programmed seriously for more than ten years) and wanted to pick it up again. I worked through some SDL and some OpenGL tutorials, and sort of set on a simple first goal. But I see a split in front of me and I'm a little lost as to which way to go: go SDL for 2D stuff and leave OpenGL to the 3D projects? Or carry on using OpenGL for 2D. My goal is a basically 2D interactive novel kind of project. For each "scene" of the story, there will be one fixed background image, numerous character images that will get moved around and scaled and perhaps animated as the story unfolds, and one layer of UI right at the front for things like bookmarking (save/load) and choosing which way to go when the story comes to a branching point etc. From around the web I read that OpenGL can be used to accelerate and simplify a lot of the 2D operations, such as depth testing, overlaying UI stuff on a scene, accelerated scaling and rotation of my character images (each of which may take up say a third of the screen space), and also I'll be able to use particle effects and other 3D polygon-based special effects. I prepared a few images (704x396) that I captured off a video just for testing, and created an OpenGL window of the same size. I loaded the images first using glTexImage2D() outside my main loop, and have only the following in the loop: 1. Event polling 2. On release of spacebar, bind the next image to a QUAD and draw QUAD 3. SwapBuffers Using orthogonal projection and binding the image to a GL_QUAD, the images are displayed perfectly but each image takes more than half a second to display. Someone suggested to me that I should scale my images up to 1024x1024 first, then send to glTexImage2D(), and after that, bind the texture to a 704x396 QUAD so that it displays in its original form. This works very fast, but the loading and scaling part is very slow, and the resulting image has visible distortions, sort of like some lines in certain angles are a little fuzzy here and there. To cut a long story short, what went through my head after that was: 1. There's still the tiling method, first cutting it up as 4 square textures 2. This is going to happen to every image I use, not just the background 3. There must be something I'm doing wrong So I suppose my question is... 1. Is texture mapping really the right way to go for something like this? 2. What exactly are people referring to when they say using OpenGL for 2D? 3. Are there examples of using OpenGL to build a such a layered 2D game? 4. And...what am I doing wrong? Thanks in advance

Share this post


Link to post
Share on other sites
Advertisement
1) Texture mapping is how you tell opengl how to display the images, so yes, as long as you use opengl it is.

2) Pretty much what you described: rendering in an orthographic projection on one plane facing the viewer.

4) Judging from the long delay in displaying the textures, I'd say that either a) opengl is running in software mode, and you need to either install drivers or get a new video card. Or b) you're loading the image every time it's displayed. Instead, load it once and store it. The distortions may be due to your texture filtering mode.

Share this post


Link to post
Share on other sites
Thanks for the reply. As to 4:

OpenGL is running in hardware mode, because using the exact same code, if I swap in 256x256 textures then it displays in an instant. This also goes to show that I'm not reloading the texture everytime. (The code to load textures is outside of the main loop anyway, so that I'm sure of.)

I have also tested the usual texture-mapped cube spinning in space, and there's nothing wrong with the speed there, too.

The problem arises as soon as I put in a non-square texture. :(

Share this post


Link to post
Share on other sites
I see the problem. It's not a matter of non-square textures, it's actually textures with non power of two dimensions. For example, a non-square texture that's 1024*512 would work fine, as those numbers are both power of two. Some graphics cards are fine with non power of two, while others aren't. So it's best to make sure they're power of two. Unfortunately that's an unavoidable limitation.

[Edited by - gharen2 on June 26, 2007 3:31:43 AM]

Share this post


Link to post
Share on other sites
Well, you can sort-of avoid it by loading in the image, then blitting it (with SDL) onto a surface which is the smallest Power of Two (POT) greater than your surface (if you're surface isn't a POT). Bind the new POT surface to a texture. Now, when you draw the quad, use widthOfImage/widthOfPOTImage and heightOfImage/heightOfPOTImage instead of the 1s for texture coordinates. (or use the texture matrix to scale it down, so that you can keep on using the easy-to-visualize [0,1] texture coordinates.)

Share this post


Link to post
Share on other sites
Hmmm. Thanks for the tips.

So texture size is something all 3D programmers have to deal with? Never thought it was that serious a problem.

Ezbez: so what I'll have is a POT texture where in one corner will be my real image, and the rest not relevant. Then I bind the POT texture to a quad that is the same size as my real image, and specify to map only the real image part of my POT texture?

Ah, I think I actually understand this now. I've been overlooking the fact that one doesn't always have to use the full texture image when doing texture mapping.

In other words, I can actually simply expand all of my "texture" image canvas to be POT resolution in the beginning to save me an extra blitting step, and then just make sure I specify the glTexCoord* to grab only the actual image part of the texture data. The fact that my .bmp files themselves have extra blanks, is completely irrelevant.

Would that be right? =D

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!