Background.. how?
Author
I don''t know if this was covered before but I thought I''d ask.
Lets say I have my screen 640x480 and I also have a nice bitmap of the same dimentions that I use as a background.
How would I draw the background first then my opengl objects. (Like a title screen or something)
My primary question is, if I''m limited to a texture size of 256x256 how would I display my large image in OpenGL. Do I have to use that glutbuild2dmipmaps as discussed in NeHe''s tutorials?
Is there a good url somewhere to describe how to do it?
Thanks.
I think that you can use rasterizing functions to achieve this (no idea of the performances, though). I do not think that you have any size limitations when you do this.
Checkout glDrawPixel and glBitmap (from memory, names should look like these).
Eric Laberge
Checkout glDrawPixel and glBitmap (from memory, names should look like these).
Eric Laberge
You are probably going to have to split up your background picture into 256x256 textures. Normally the gl raster functions are badly implemented in drivers do not perform well at all. If you split your background up though, you will also run into seaming problems from the bilinear filtering that is applied to the polygons. There are a few ways around this, such as overlapping the polygons, but they all make the algorithm more complicated.
Basically, if you want to limit your texture sizes to 256x256, you will need to manually split up the 640x480 (at loadtime, or by hand) texture into smaller textures, then draw them.
PreManDrake
Basically, if you want to limit your texture sizes to 256x256, you will need to manually split up the 640x480 (at loadtime, or by hand) texture into smaller textures, then draw them.
PreManDrake
Well... I know in VC++ 6.0 I can load images at least as big as 1024x1024x16bit... course the file is HUGE. I haven''t tried a bigger image simply cause it''s already 6megs =)
I get the idea your thinking here, so I''ve been digging thru everything myself *OH great the guy who can''t figure out a string is trying to help =)*
So far Tut20 seems the best way of dealing with this, and thats what I''m trying to alter =)
Axehandler
I get the idea your thinking here, so I''ve been digging thru everything myself *OH great the guy who can''t figure out a string is trying to help =)*
So far Tut20 seems the best way of dealing with this, and thats what I''m trying to alter =)
Axehandler
Well bud,
I saw a gl command to resize an images width/length, (can''t find the darn thing again) so you can use a 640x480 image and resample it to say 640x640, then make a glVertex3f that fills the entire screen at -9.0f depth (or such) and texture it.
You can then use anything else as long as you don''t hit that depth, it won''t interfear.
Now before I hear that the image has to be based on a 64x64 system. Just go change your texture size once, keep it SQUARE and it should work fine! =) (well it does for me)
Axehandler
I saw a gl command to resize an images width/length, (can''t find the darn thing again) so you can use a 640x480 image and resample it to say 640x640, then make a glVertex3f that fills the entire screen at -9.0f depth (or such) and texture it.
You can then use anything else as long as you don''t hit that depth, it won''t interfear.
Now before I hear that the image has to be based on a 64x64 system. Just go change your texture size once, keep it SQUARE and it should work fine! =) (well it does for me)
Axehandler
Author
Thanks for all the hints..
the glBitmap() and glDrawPixel() seem most promising. The speed isn''t a massive issue, and I''m sure it will be slower but for a background screen, or a menu system it will probably work just fine. As for using either of those functions to draw say an interface (like a toolbar during gameplay) I suppose i''ll have to experiment.
Axehandler I think the function you''re thinking is that glut command to build 2d mipmaps, the problem with that (and your other suggestions) are that when building mipmaps of > 256 (or not a multiple of 2) they get a filter applied to them (and the image quality could seriously degrade). In all honesty I din''t try it out yet but since I was always spoiled with direct access to the surface memory in D3D I wondered if it was possible to draw odd-shaped and sized items in OGL.
Splitting the screen into 256x256 tiles would work, and might make for some interesting effects, but it''s a sh*tload of work and I''m fairly lazy so I think i''ll explore the other above calls first.
Once again, thanks again for the tips peeps
the glBitmap() and glDrawPixel() seem most promising. The speed isn''t a massive issue, and I''m sure it will be slower but for a background screen, or a menu system it will probably work just fine. As for using either of those functions to draw say an interface (like a toolbar during gameplay) I suppose i''ll have to experiment.
Axehandler I think the function you''re thinking is that glut command to build 2d mipmaps, the problem with that (and your other suggestions) are that when building mipmaps of > 256 (or not a multiple of 2) they get a filter applied to them (and the image quality could seriously degrade). In all honesty I din''t try it out yet but since I was always spoiled with direct access to the surface memory in D3D I wondered if it was possible to draw odd-shaped and sized items in OGL.
Splitting the screen into 256x256 tiles would work, and might make for some interesting effects, but it''s a sh*tload of work and I''m fairly lazy so I think i''ll explore the other above calls first.
Once again, thanks again for the tips peeps
stop the press!
no, don't use raster graphics. i swear to god, it's slower than snails. even with hardware acceleration, since hw acc is mainly for 3d graphics. you think it won't be that necessary cuz it's only a menu, etc. you can go ahead and try, but i'm just trying to save you some time. this is what i did:
in render loop, switch to ortho mode, draw a rectangle, map the background on this. use
glMatrixMode(GL_TEXTURE_2D);
glScalef(x,y,1);
to fit it to the screen.
switch to perspective view, then render you're 3d stuff.
if you make a comparison, this'll go WAY faster, even if you're screen doesn't require that much speed, you'll notice it.
a2k
Edited by - a2k on 4/15/00 1:29:12 AM
no, don't use raster graphics. i swear to god, it's slower than snails. even with hardware acceleration, since hw acc is mainly for 3d graphics. you think it won't be that necessary cuz it's only a menu, etc. you can go ahead and try, but i'm just trying to save you some time. this is what i did:
in render loop, switch to ortho mode, draw a rectangle, map the background on this. use
glMatrixMode(GL_TEXTURE_2D);
glScalef(x,y,1);
to fit it to the screen.
switch to perspective view, then render you're 3d stuff.
if you make a comparison, this'll go WAY faster, even if you're screen doesn't require that much speed, you'll notice it.
a2k
Edited by - a2k on 4/15/00 1:29:12 AM
Author
I didn''t get a chance to try the 2d image calls but your comments kind of confused me.
If my original background screen is 640x480 how am I going to display it? Your comments just say to scale it but if the image is that big then how would I read it in and set it as a texture. I don''t want to have to convert it to an image of a multiple of 2 ie:256x256. by doing so it will seriously decrease the quality of the image and then using glScale() on it will really bring out the flaws of converting it to 256x256. ie: chunky pixels
Unless glBitmap et.al. are very unoptimized then I think I can live with the acceptable fps loss. Sure in DDraw if I blitted a monster surface (640x480) I lost 20fps but for a menu screen that was fine as drawing buttons etc was unnoticable fps loss.
I wonder how in some of the OGL games (Homeworld, etc) draw the interface at the bottom. it doesn''t look filtered to 256 unless they somehow wrote it to work like how Premandrake suggested.
If my original background screen is 640x480 how am I going to display it? Your comments just say to scale it but if the image is that big then how would I read it in and set it as a texture. I don''t want to have to convert it to an image of a multiple of 2 ie:256x256. by doing so it will seriously decrease the quality of the image and then using glScale() on it will really bring out the flaws of converting it to 256x256. ie: chunky pixels
Unless glBitmap et.al. are very unoptimized then I think I can live with the acceptable fps loss. Sure in DDraw if I blitted a monster surface (640x480) I lost 20fps but for a menu screen that was fine as drawing buttons etc was unnoticable fps loss.
I wonder how in some of the OGL games (Homeworld, etc) draw the interface at the bottom. it doesn''t look filtered to 256 unless they somehow wrote it to work like how Premandrake suggested.
actually, i think i loaded up a non power of 2 image. but in order to make it match the screen, i had to scale it to fit the screen. it suffers "slight" degradation, but might be worth it if the results aren''t what you expect. see, the ortho() mode makes the rendering pretty much flat, so the map is almost as good as the raster rendering.
i''m telling you not to use raster graphics, cuz i tried it, and rendered a 3d animated object in front, and it was really slow, i''m talkin 3fps. when i changed it to texture mapping, it went up to 80 fps. i have a lousy graphics card, so yeah, you may not even see the difference, but if you do, then, you know what to do.
a2k
i''m telling you not to use raster graphics, cuz i tried it, and rendered a 3d animated object in front, and it was really slow, i''m talkin 3fps. when i changed it to texture mapping, it went up to 80 fps. i have a lousy graphics card, so yeah, you may not even see the difference, but if you do, then, you know what to do.
a2k
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
