glDrawPixels speed or 3d?

Started by
6 comments, last by chedburgh 20 years, 5 months ago
Hi, I’ve a quick question I’d like to ask. I’m making a turn based strategy game and I’ve been implementing my iso map in opengl, in 2d using ortho projection. I was going to use glDrawPixels to draw multiply images over each tile to build a landscape. I’ve read its not recommended to use glDrawPixels for to much work, as its very slow (cant remember where now). I’m curious to what people think of this. Is it worth sticking with for a TBS or should I be thinking of going to full 3d? Textures are not an option for all tile objects, i.e. things like sprites, terrain like hills etc. Cheers ched
Advertisement
If you''re using only glDrawPixels, why even bother with OpenGL at all? Just stick with a regular 2d blitting API like SDL or DirectDraw, it''ll be faster.

glDrawPixels will be horribly slow, just use textured quads instead if you want to stick with OpenGL. Just why can''t you use textured quads for sprites, terrain etc.? If its the power-of-two texture size limitation then theres numerous ways around that (extensions or packing multiple images into larger pow-2 textures).
Hi, thanks for the swift reply

I want to stick with opengl, as I’m enjoying learning the API, and have plans to do something else in full 3d later on. So anything I do now gives me a small grounding for later on.

For the texturing. Its not a power of 2 issue, I decided to make my tiles 128x64 for this reason. My sprites (and some terrain) can be taller than the tile there in, so I figured I could not map them to the quad (iso tile) that represents there location. Now I think about it, I could just render a square quad on top of the tile with the sprite as its texture, doh!!!! I’m assuming this would work fine?

cheers
ched
quote:Original post by chedburgh I could just render a square quad on top of the tile with the sprite as its texture, doh!!!! I’m assuming this would work fine?


Yup. With or without a depth buffer depending on whether you want to manually sort objects yourself or not.

there is no reason why you would have to store only the texture for a single object in one texture. it doesnt matter if you need power of two images, all that matters is that the whole thing has power of two dimensions. for example: why have a lot of tiny 128x64 textures if you could store 32 of them in a single 512x512 texture or 8 in 256x256? thats not just about having less files fly around but also about limiting texture switching. for animations you wouldnt have a whole texture for every single frame but store all frames in one texture and use the right texture coordinates.

if your graphics arent power of two, so what? just make the image a little bigger and use the next ^2 size. and to waste less memory with empty space collect more of them in one texture.
f@dzhttp://festini.device-zero.de
Hi Trienco, I like the idea of keeping them all in the same file. My previous plan had been to load all my tiles in a single file and them clip them out into small tile size bitmaps for binding.

Now, this may sound a dumb question (I am still a novice with ogl), but how do I keep them all in the same bitmap for texture mapping? Do I need to use the glList stuff? I’ve checked the redbook and some other docs, but I’m not sure I’m looking for the right things. If you could point me towards the relevant commands so I could research it it would be much appreciated

cheers
ched
quote:Original post by chedburgh
but how do I keep them all in the same bitmap for texture mapping? Do I need to use the glList stuff?


You''d use the texture coords to pick the correct sections of your texture to display on each quad. Start by looking into glTexCoord2f() (and its variations) and glTexCoordPointer.

Ah! I think I get it! I can clip the correct parts of the image by giving glTexCoord() fractions, i.e. a 256x256 image of 128x128 tiles, I can pass something like (128/256) to have it map only up to pixel 128. I thought tex coords had to be 1 or 0 previously, oops.

I’m at work, so cant test any of this till later…

This topic is closed to new replies.

Advertisement