Background.. how?

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

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

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

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

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

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

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.

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

Hehe, ok I guess I have to spend some time and do some experimentation.

sc0rp1o .. u so crazy.

/sixb0nes

Hey Sc0rp, if you find a good way of dealin with this, let us know.. don''t just leave us hanging

Axehandler

Hiya six.. quit followin me mon.

Ok, here are my first results and comments:
glBitmap() appears to only draw 2 color images (fonts, simple bitmaps) so for what I want to do it's not very useful.

glDrawPixels() works but a2k is DEAD ON. it SUCKS!
just drawing my scene with no bitmap 49fps. drawing with the bitmap using glDrawPixels() 5.3 fps. The image was only 300x300 pixels, 24 bit color so i'd imagine 640x480 would be nasty slow.

I have an Annihilator Pro DDR so I don't thing it's a video card thing, must simply be the implementation of glDrawPixels(). My guess is that moving the bitmap from system memory to video memory is whats killing it.

a2k, if you still have your code to how you drew your 'larger' image please paste some of it so we can see what you did.

I guess I'll have to write a handler to break the image into tiles and use them as textures.


Edited by - sc0rpy on 4/16/00 1:02:21 PM

Well, I don''t really know how fast (or how slow) raster graphics are (I work mainly with software rendering, my computer does not have any 3D card), so I obviously don''t see any difference (raster graphics might actually be faster in this case).

If raster graphics are so slow, then it might explain why I only get under 10 FPS on my friend''s Athlon 700 with a GeForce when I have to draw bitmaps... I thought the bottleneck was the palette stuff, now I''ll know what to do

Damn! I can''t wait to buy a new computer!

Thanks guys!

Eric Laberge

No worries, in all honesty I hadn''t heard of either of those 2 functions you mentioned so at least having you mention them has helped be become aware of their purpose and their limitation when dealing with high framerate graphix.

I''ve found a interesting URL when dealing with oddly shaped textures:
http://www.gegi.polymtl.ca/info/granger/cours/3.430/OpenGL/UserGuide/OpenGLonWin-13.html

read the section: "Updating Textures Quickly With Subtextures"
here is a quick rip from that URL:

"When you''re working with an image that has a width and height that''s not a power of 2, you can''t directly use it as a texture. This can be a problem, for example, when you''re using video frames as textures: none of the common video formats (NTSC, PAL, SECAM, HD-TV, and so on) have a height and width of those dimensions. You can solve this problem by creating a NULL texture whose dimensions are larger than the video frame and then load the video frame as a subtexture. "

I''ll post any comments and implementation on the above if I can decypher the text.

hey, is the opengl superbible online? well, that''s where i got the code for loading up bitmaps and textures, so if you know how to make texture objects, just apply that texture to the rectangle in ortho mode, so that you''re looking at the rectangle straight on. switch the matrix mode to texture, and then use the scale transformation matrix to mess around with the x, y coordinates until the picture matches the size of the screen. then switch to perspective mode, and then you can render your 3d geometry.

A2K:

what happens if the texture is > 256 x 256 ??

My video card supports large textures but what happens if your video card doesn''t. (like 3dfx cards).

Actually, has anyone tried the 3ds loader program posted today on opengl.org:
http://home1.pacific.net.sg/~gishsh05/

he doesn''t check to see if the texture is > 256x256 so I''m curious what happens for you 3dfx people. Actually, does anyone know if the software driver (Micro$oft) has any texture limitation size?

Thanks.

i dunno. i think i even loaded up a 640x480 texture onto my surface....

a2k

Well, a texture of 640x480 won''t work since it doesn''t follow the power of 2 rule. Large textures (ie: 1024x256) work with the software driver but I''m pretty sure I read somewhere that a good percentage of 3d cards out there dont support textures > 256x256. I wonder if there is a way or a call in OpenGL, etc that will return the maximum resolution of a texture?