• Advertisement

Archived

This topic is now archived and is closed to further replies.

Blitting using SDL

This topic is 5150 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

hi ppl, i was writing an AVI player (for playing AVI in cutscenes etc) ...... i have done alomost all the basic stuff .... now what i do is i read the bitmap(BITMAPHEADERINFO thingy) data and blit it on my screen (SDL Surface) .... but the problem i am facing is that the video is playing upside down ..... i dunno wat is the problem ..... but i think that i am not using SDL_BlitSurface properly ..... has ne1 else faced this problem ..... can anyone help me with this one ..... is it because of SDL blitting or sumthin else .... thanx in advance, enygmyx.

Share this post


Link to post
Share on other sites
Advertisement
Another thing to note, is that direct3D surfaces are also upside down as compared with OpenGL textures.

So if you end up writing your BMP loader code to display images on Direct3D surfaces, you will need to bare that in mind.

www.wreckedgames.com

Share this post


Link to post
Share on other sites
thanx for the quick response but i don't quite know how to do that in my case ...... since i am not actually creating a BMP .... this is how i do it ......
first get the frame data header .....
(LPBITMAPINFOHEADER)AVIStreamGetFrame(pgf, frame);

get the actual raw data ....
pdata=(char *)lpbi+lpbi->biSize;

create a SDL surface using the data just read:
SDL_CreateRGBSurfaceFrom(pdata, info.dwWidth, info.dwHeight, sampleSize, info.dwWidth* (sampleSize/8),R_mask, G_mask, B_mask, A_mask);

finally blit the surface:
SDL_BlitSurface(frame, NULL, S, &dest);

now since i am not creating a texture and then mapping it on some surface hence cannot invert texture coords like it was said in the post pjcast reffered to ..... how can i inverse the bitmap data in my case (i do not want to use any brute force thing like reversing the data using a loop etc.)
thanx in advance,
enygmyx.

[edited by - enygmyx on January 12, 2004 2:33:53 AM]

Share this post


Link to post
Share on other sites
I am not familiar with SDL, but if you don't want the brute force method, is it possible to map the texture to your quad so that it's upside down?

Or, possibly, just rotate your quad so that it's upside down, which would have no per frame speed penalty (like manually flipping the bitmap)

EDIT - Ahwww, I just saw that you are not mapping...

What are you doing with the bmp data?

[edited by - pjcast on January 12, 2004 2:58:32 AM]

Share this post


Link to post
Share on other sites
Maybe someone with more specific knowledge of SDL fuctons can be of more help...

But, I suggest that you write the data to a texture, instead of using SDL_BlitSurface.

You can check out a NeHe tutorial here on AVIs

Share this post


Link to post
Share on other sites
as pjcast said someone with good SDL knowledge cud help here .... someway that wud allow me to make the SDL surface correctly or blit the surfce inverted ....

well apart from the main question .... i wud also like to know if it is better the way in which i am doing it or is it better that i make texture from the data and map it on some quad?? .....

thanx in advance,
enygmyx.

Share this post


Link to post
Share on other sites
Hi.

I''m using SDL in my OpenGL projects for a variety of things and up ''til now I''ve had the same problem, that is that anything I load into an SDL_Surface is turned upside/down. I was too lazy too try and isolate the problem and correct it but your question fired up my curiosity so I did some coding. Here''s what I did :
- tried to load a BMP into an SDL_Surface using the SDL_LoadBMP function. Result : texture turned upside/down
- tried to a BMP into an SDL_Surface using my own loading routine. Result : texture turned upside/down
- tried to load a BMP into my own ... err.. let''s call it a "texture structure" (though it is only an unsigned char array...). Result : texture correctly applied

So I guess that SDL_Surface displays it upside/down when the data is accessed, though I don''t understand why...

Hope this helped a bit.

Share this post


Link to post
Share on other sites
thanx Trexmaster ..... ur post was helpful in a way that it kinda confirmed that the problem is with SDL_Surfce/SDL bliting
.... but the problem still remains ..... how to rectify this problem .... are there any SDL gurus who can help us poor souls with this ... i just joined the SDL mailing list i will also post this question there and lets see wat happens .....
Trexmaster u said that u have had problems SDL_LoadBMP function ..... but i never had any problems using that ..... also i wud like to know whether u were blitting the surface after loading it or sumthin else ..... especially in the third case where u didn''t use a SDL surface .... did u use SDL_BlitSurface after that ..... cus maybe the problem occurs with SDL_BlitSurface .....
i loaded a BMP using SDL_LoadBMP ..... and then Blitted it on my main surface(window) .... and the texture turned up ok.
kinda confusing and frustating ....
enygmyx.

Share this post


Link to post
Share on other sites
enygmyx here''s my best guess at your problem,

Since using SDL_LoadBMP worked correctly and since using your own data flipped the image, I suspect the problem lies with the image''s pixel line data order. As pjcast stated, a bitmap stores line data in bottom to top order (bottom most line comes first in the data). Assuming SDL_Surface has its pixel lines in top to bottom order (I don''t know this for certain, just a guess) and when you try:

SDL_CreateRGBSurfaceFrom(pdata, info.dwWidth, info.dwHeight, sampleSize, info.dwWidth* (sampleSize/8),R_mask, G_mask, B_mask, A_mask);

that this SDL function assumes pdata is in top to bottom order. Therefore the resulting image would be upside down and assuming this is what SDL is doing, it is not exactly a problem with SDL but a mixup between two formats. SDL_LoadBMP works correctly because it expects this issue and therefore resolves it by swapping the line order before creating the surface.

The obvious solution is swap the lines before calling SDL_CreateRGBSurfaceFrom but there may be a supported function in SDL for this. I tried looking briefly but did not find any.

Gnork

Share this post


Link to post
Share on other sites
Okay the thing is that, as I stated earlier, I use SDL in OpeGL projects. So in fact, the SDL_Surface was just used as a temporary stocking space for the bitmap data before I generate a texture with the glTexImage2D() function. So nope, no blitting at all.

I was originally using SDL_LoadBMP and SDL_Surface because I''m doing multiplatform projects ()Windows/Linux) and I knew these ones were portable, but now I guess I''ll juste use my own function and see if it works under Linux as it does under Windows (really hope it does ).

Btw I could also have just inverted the texture coordinates'' up and down sides to get it correctly mapped.

Share this post


Link to post
Share on other sites
I don't remember where I snagged this little code snippet, but it may help your problem


//This function returns a OpenGl compaitble texture from an SDL Surface

GLuint loadTexture(const char *path)
{
SDL_Surface *surface = SDL_LoadBMP(path);
if( !surface ) return 0;
if((surface->format->BytesPerPixel != 3) &&
(surface->format->BytesPerPixel != 4)) return 0;
GLuint texture = 0;
glGenTextures(1, &texture);
glBindTexture(GL_TEXTURE_2D, texture);
int retVal = gluBuild2DMipmaps(GL_TEXTURE_2D,
surface->format->BytesPerPixel,
surface->w,
surface->h,
surface->format->BytesPerPixel == 4 ? GL_RGBA : GL_RGB,
GL_UNSIGNED_BYTE,
surface->pixels);

glTexParameteri(GL_TEXTURE_2D,GL_TEXTURE_MAG_FILTER,GL_LINEAR);
glTexParameteri(GL_TEXTURE_2D,GL_TEXTURE_MIN_FILTER,GL_LINEAR);
glTexEnvf( GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_MODULATE );

return texture;
}


[edited by - yspotua on January 13, 2004 5:46:33 PM]

Share this post


Link to post
Share on other sites
It sounds to me like you need to use SDL_Flip(surface);

If you can''t do that then make it so you can All data that you load into memory is stored upside down (for optimization reasons) and when you just blit it straight to the screen that is how it shows it.

Share this post


Link to post
Share on other sites
first of all i wud like to ask if it is better to make a texture or do it the way i am doing it (performance wise)......i did it using SDL_BlitSurface cus i personally thought that it wud be faster than making a texture and mapping it on a quad .......

anyways thanx for the tips ppl .... really appreciate that but i was looking if there was some way to invert the screen in SDL .... i have looked around documentation, mail list archives etc but can''t seem to find that ...... maybe someone cud help ....

Sir_Brizz:
SDL_Flip doesn''t Flip/Invert the screen .... it is like GL SwapBuffers .... to be used with double buffering .... so basically it swaps the front and back buffer .......

enygmyx.

Share this post


Link to post
Share on other sites
This creates a new SDL_Surface which is a flipped version of the one passed in:
SDL_Surface *FlipSurfaceV(SDL_Surface *bitmap){
if(!bitmap)return NULL;
SDL_Surface *temp=SDL_CreateRGBSurface(0,bitmap->w,bitmap->h,
bitmap->format->BitsPerPixel,bitmap->format->Rmask,bitmap->format->Gmask,
bitmap->format->Bmask,bitmap->format->Amask);
if(!temp)return NULL;
SDL_Rect src,dest;
src.w=bitmap->w;
src.h=1;
src.x=0;
dest.x=0;
int origh=bitmap->h;
for(int i=0;i<origh;i++){
src.y=i;
dest.y=(origh-1)-i;
SDL_BlitSurface(bitmap,&src,temp,&dest);
}
return temp;
}

Hope it formats right.
EDIT: Close enough.

[edited by - TravisWells on January 14, 2004 8:52:33 PM]

Share this post


Link to post
Share on other sites
Okay, the reason SDL reads from top down is because the coordinate system starts in the upper-left corner of your screen; positive-y is downward so when the image is blitted, it is blitting correctly; all you have to do is redefine how your image rects are defined: top-left of your image is (x,y) and bottom right is (x+width, y+height).

HTH

Share this post


Link to post
Share on other sites

  • Advertisement