Skip to main content
GameDev.net gamedev.net
🔒 Locked

Texture mapping. SDL + OGL under Windows XP

Started by G Morgan Sep 10, 2007 at 4:42 PM 4 replies 1.7k views
Original Post
G Morgan
G Morgan
Hi, this is my first post here. Hopefully I won't cry too often. I'm going through the nehe lessons using the Linux/SDL code base and trying it out in both Linux and XP to ensure I understand the gotchas with porting. I've modified the Linux/SDL code base from http://nehe.gamedev.net/data/lessons/lesson.asp?lesson=06 so that it is OOP based (i.e. wrapped the state and drawing functions of the drawn object into a class). The basic idea is to take a spinning cube and add a texture to it then display it. This works fine until I try to resize the window, at that point the texture disappears and the box becomes plain white. I've tried adding the Tut6::LoadGLTextures() method to the front of the draw() method but that doesn't bring the texture back. The class definition is below class Tut6 : public OGLObject { public: Tut6(); int draw(); int init(); private: GLfloat xrot; GLfloat yrot; GLfloat zrot; GLuint texture[1]; int LoadGLTextures(); }; The draw and LoadGLTextures methods are pretty much ripped directly from the original code base. draw() comes from the drawGLScene(void) method. glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT); object.draw(); // Draw it to the screen SDL_GL_SwapBuffers(); basically all the code between the top and bottom lines has been moved into draw(). Is this resize/move texture disappearing problem something that generally occurs in Windows that needs to be coded around. The code works fine under Linux. Another issue I'm having is that I can't get the program to go full screen in Windows. //edit - it seems this has something to do with the window getting larger than my monitor. I tried the original code and because it was limited to 640*480 the texture stayed in place. When I expanded the window to a size comparative to the size of my LCD it went blank. I modified my own code and found the same, at low res it stays fine but at high the same problem returns.//
DMINATOR
DMINATOR
It would be good if you could show the resize code. I can however make a guess that you are recreating window context with new screen width and height parameters. When you usually do that in windows then all the data that is stored in OpenGL is cleared (textures for example) (This may be the issue specific to only OpenGL + SDL - I am not sure, but I am getting the same results).

You just need to reload the textures. The resizing is not so widely used with openGL. Usually it is a fixed size window windowed/fullscreen.

I guess this is the reason for this. I don't know how it works in linux though.
G Morgan
G Morgan
To further my edit above. It seems it still blanks on resizing but not on movement (at full size 1280*800, it blanks on either).

My resize code

int resizeWindow(int width, int height) { // function to reset our viewport after a window resize
// Height / width ration
GLfloat ratio;

// Protect against a divide by zero
if(height == 0)
height = 1;

ratio = (GLfloat)width / (GLfloat)height;

// Setup our viewport.
glViewport(0, 0, (GLint)width, (GLint)height);

// change to the projection matrix and set our viewing volume.
glMatrixMode(GL_PROJECTION);
glLoadIdentity();

// Set our perspective
gluPerspective(45.0f, ratio, 0.1f, 100.0f);

// Make sure we're chaning the model view and not the projection
glMatrixMode(GL_MODELVIEW);

// Reset The View
glLoadIdentity();

return(TRUE);
}

I've tried sticking LoadGLTextures() at the front of the draw() method as mentioned. Didn't make a difference. Do I need to run glEnable( GL_TEXTURE_2D ); again?

This sort of issue is why I wanted to get things running in Windows though. Hard enough work getting a simple CLI app to work in both.
DMINATOR
DMINATOR
I think you should put the LoadGLTextures() in the resize function at the end and not in the Draw() . And yes try to enable GL_TEXTURE_2D because it may disable the states also.
Trenki
Trenki
AFAIK when resizing in SDL you have to call SDL_SetVideoMode again. This might cause the OpenGL rendering context to be recreated which means it will be reset to the default values it the last time you called SDL_SetVideoMode. This means texture enable state and any other state would need to be setup again. Also textues would be lost and need to be recreated.

Moving the window should not cause any problem at all.

It is very uncommon to have an OpenGL application where you can resize the window and as you see you get problems with that. You may want to read up on SDL_SetVideoMode some more (SDL ref doc and in the include files). Maybe it is specific on the case of the OpenGL context
shotgunnutter
shotgunnutter
Quote:
Original post by Trenki
AFAIK when resizing in SDL you have to call SDL_SetVideoMode again. This might cause the OpenGL rendering context to be recreated which means it will be reset to the default values it the last time you called SDL_SetVideoMode. This means texture enable state and any other state would need to be setup again. Also textues would be lost and need to be recreated.

Moving the window should not cause any problem at all.

It is very uncommon to have an OpenGL application where you can resize the window and as you see you get problems with that. You may want to read up on SDL_SetVideoMode some more (SDL ref doc and in the include files). Maybe it is specific on the case of the OpenGL context


This is correct. When you call SDL_SetVideoMode on an SDL_Surface, the Surface is reset, along with the OpenGL rendering context. All your textures, display lists, state settings, etc are reset. Lets say you loaded a texture and OpenGL gave you a texture_id of 476; all textures are reset so texture 476 now contains nothing, or possibly junk data.

So, you will need to reload everything. If you are using display lists, this will include level geometry.
I just wanted to see if he would actually do it. Also, this test will rule out any problems with system services.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.