dspencer
|
|
« on: August 11, 2009, 05:44:55 PM » |
|
Hi,
I'm trying to use openGL to make a 2d side-scrolling game. I'm at the stage where I want to add in graphics/animations, and I'm not sure how to go about doing the latter... it seems really inefficient to use a separate texture for each frame, but the way gl uses texels rather than pixels when specifiying a texture makes me unsure of how to be accurate if trying to store multiple frames in one bigger texture. Does anyone have advice, or tutorials, or whatnot?
Thanks!
|
|
|
Logged
|
|
|
|
Aquin
|
|
« Reply #1 on: August 11, 2009, 06:00:21 PM » |
|
Damn dude, I'm writing a tutorial that's very similar for just this thing. It won't be done until next week though. In short, if you use separate files to represent each frame, you're really killing yourself. It's just because switching the enabled texture does eat up some time. If you don't have a hundred objects flying about though, it doesn't really matter. But yeah, you can put all the frames in one giant graphic and then take that part of the texture for just one frame. The texture ranges from 0..1 on both axes. So if you have two frames taking up space on your texture (say one on the left, one on the right), the first one ranges from 0-0.5 and so on. It sounds complicated, but there's a really easy way to do it and not hurt your head. It'll be in my tutorial next week.
|
|
|
Logged
|
I'd write a devlog about my current game, but I'm too busy making it.
|
|
|
Gold Cray
|
|
« Reply #2 on: August 11, 2009, 07:05:42 PM » |
|
Agree with above. To convert from pixel coordinates to texture coordinates, just do xtexture = xpixels/imageWidth(in pixels) and the same thing for y coordinates.
|
|
|
Logged
|
|
|
|
astrospoon
|
|
« Reply #3 on: August 11, 2009, 07:06:42 PM » |
|
actually, you want to offset the coordinates exactly the width of one half pixel from the actual math. So you'll end up using 0.495 instead of 0.5 or whatever. Otherwise you risk getting a slight line of part the next pixel over. It has to do with wanting texture coordinates actually being centered *through* the pixel positions and not at the edge of the pixel, which is what something like 0.5 exactly would be.
|
|
|
Logged
|
|
|
|
Aquin
|
|
« Reply #4 on: August 11, 2009, 07:09:22 PM » |
|
I haven't run into that problem myself, but I use GL_NEAREST filtering and I'm at a pretty small resolution. I guess I better keep your suggestion in mind for myself!
|
|
|
Logged
|
I'd write a devlog about my current game, but I'm too busy making it.
|
|
|
astrospoon
|
|
« Reply #5 on: August 11, 2009, 07:29:15 PM » |
|
I've had the most trouble with this with high resolution games that blow up really low res pixel art for sprites. It would probably not show up if your 3D window resolution was low enough.
|
|
|
Logged
|
|
|
|
cecilemanganaro1
Level 0
|
|
« Reply #6 on: August 13, 2009, 02:35:37 AM » |
|
The version of GL-animator(PRO) is able to create 3D text using OpenGL effects. This program GL-animator was done for creating your own animation files using OpenGL effects. You can make a texture from a string.
|
|
« Last Edit: August 13, 2009, 03:11:08 AM by cecilemanganaro1 »
|
Logged
|
|
|
|
Rock D
Level 0
I waited for an hour but this never happened.
|
|
« Reply #7 on: August 13, 2009, 06:08:50 AM » |
|
actually, you want to offset the coordinates exactly the width of one half pixel from the actual math. So you'll end up using 0.495 instead of 0.5 or whatever. Otherwise you risk getting a slight line of part the next pixel over. It has to do with wanting texture coordinates actually being centered *through* the pixel positions and not at the edge of the pixel, which is what something like 0.5 exactly would be.
You're right, this article has some screenshots of the effect. Googling around I have not found a good tutorial on spritesheet animations in OpenGL, so props to Aquin for making one.
|
|
|
Logged
|
|
|
|
Aquin
|
|
« Reply #8 on: August 13, 2009, 09:45:43 AM » |
|
Heh, I use spritesheet animations for my games all the time (except for the current one.) I'll post it up once it's done. I'll start writing it after today. If you want to see some complex tricks, let me know now. I can't think of anything off the top of my head, but I usually miss something.
|
|
|
Logged
|
I'd write a devlog about my current game, but I'm too busy making it.
|
|
|
mcc
|
|
« Reply #9 on: August 13, 2009, 06:57:16 PM » |
|
actually, you want to offset the coordinates exactly the width of one half pixel from the actual math. So you'll end up using 0.495 instead of 0.5 or whatever. Otherwise you risk getting a slight line of part the next pixel over. It has to do with wanting texture coordinates actually being centered *through* the pixel positions and not at the edge of the pixel, which is what something like 0.5 exactly would be.
Huh, interesting. I had been forcing my texture packer to insert a 1-pixel border of blank space between all the sprites in my atlas in order to avoid this problem. Do you think if I'd used the 4.95-instead-of-0.5 trick I could have avoided the 1-pixel borders?
|
|
|
Logged
|
|
|
|
mewse
|
|
« Reply #10 on: August 13, 2009, 07:15:18 PM » |
|
Huh, interesting. I had been forcing my texture packer to insert a 1-pixel border of blank space between all the sprites in my atlas in order to avoid this problem. Do you think if I'd used the 4.95-instead-of-0.5 trick I could have avoided the 1-pixel borders?
Using texture coordinates which are in the middle of a texture pixel instead of at the corner of the texture pixel will remove the need for 1-pixel borders in the texture, yes. This is, of course, assuming that your textures are not mip-mapped, or otherwise ever drawn at smaller-than-actual-size on screen. (I assume that you're not doing either of these, because the 1-pixel border won't work in these cases either)
|
|
|
Logged
|
|
|
|
mcc
|
|
« Reply #11 on: August 13, 2009, 09:11:41 PM » |
|
Huh, interesting. I had been forcing my texture packer to insert a 1-pixel border of blank space between all the sprites in my atlas in order to avoid this problem. Do you think if I'd used the 4.95-instead-of-0.5 trick I could have avoided the 1-pixel borders?
Using texture coordinates which are in the middle of a texture pixel instead of at the corner of the texture pixel will remove the need for 1-pixel borders in the texture, yes. This is, of course, assuming that your textures are not mip-mapped, or otherwise ever drawn at smaller-than-actual-size on screen. (I assume that you're not doing either of these, because the 1-pixel border won't work in these cases either) Hm. I'm not mipmapping but I do often draw at smaller-than-actual-size. Why will the 1-pixel transparent border not work in these cases?
|
|
|
Logged
|
|
|
|
Aquin
|
|
« Reply #12 on: August 13, 2009, 09:16:42 PM » |
|
Because the 1px border would be less than 1px, but the rectangle may draw over a pixel (to round to the nearest pixel, for example.)
I personally have never run into this problem though, so I'm not sure if it's a big deal or if it's even really a problem. I do use scaling with my anims in a single texture, but this has never been an issue. Could be my filtering? I dunno.
|
|
|
Logged
|
I'd write a devlog about my current game, but I'm too busy making it.
|
|
|
astrospoon
|
|
« Reply #13 on: August 14, 2009, 04:26:10 AM » |
|
There is a filtering setting called "Single Point" or something to that effect that can help with this kind of thing I think. But the simplest thing is just to offset your textures properly.
Check out the link from Rock, it is really easy to implement:
0.5/(TextureWidth) = X Offset amount 0.5/(TextureHeight) = Y Offset amount
You shouldn't just type in 0.495 instead of 0.5. You should be calculating the offset like this, and then doing 0.5 - Offset, etc..
|
|
|
Logged
|
|
|
|
Brandorf
|
|
« Reply #14 on: August 14, 2009, 06:05:24 AM » |
|
Another interesting method of 2d animations (though it has limitations) is to arrange your animation frames as a single 3d texture, with the frames of animations comprising the depth of the texture, then to animate you simply scroll along the r(z) coord.
This has the interesting effect of allowing you to linearly interpolate between frames if you so choose, which looks really nice for particle effects or explosions. However like all texture dimensions, your frame count or depth dimension must be a power of two.
|
|
|
Logged
|
|
|
|
Aquin
|
|
« Reply #15 on: August 14, 2009, 09:52:55 AM » |
|
That's actually a really cool idea! But it sounds a bit too techy for me... still I might try it out and see how it works. :D
|
|
|
Logged
|
I'd write a devlog about my current game, but I'm too busy making it.
|
|
|
Glaiel-Gamer
Guest
|
|
« Reply #16 on: August 14, 2009, 10:08:41 AM » |
|
You could also probably build animation into a vertex shader provided hardware supports it.
|
|
|
Logged
|
|
|
|
mcc
|
|
« Reply #17 on: August 14, 2009, 10:04:28 PM » |
|
Another interesting method of 2d animations (though it has limitations) is to arrange your animation frames as a single 3d texture, with the frames of animations comprising the depth of the texture, then to animate you simply scroll along the r(z) coord.
This has the interesting effect of allowing you to linearly interpolate between frames if you so choose, which looks really nice for particle effects or explosions. However like all texture dimensions, your frame count or depth dimension must be a power of two.
Oh, that is neat. How widely supported is GL_TEXTURE_3D, incidentally? Like are there computers out there that won't support it?
|
|
|
Logged
|
|
|
|
Brandorf
|
|
« Reply #18 on: August 15, 2009, 09:08:34 AM » |
|
Oh, that is neat. How widely supported is GL_TEXTURE_3D, incidentally? Like are there computers out there that won't support it?
I've yet to find a system that it won't run on, I've tested a variety of Nvidia and ATI cards, and even a few Intel ones. The extension was put out in like '96 or so, so I'd imagine computers that don't support it would be increasingly rare.
|
|
|
Logged
|
|
|
|
lansing
|
|
« Reply #19 on: June 28, 2010, 01:07:51 AM » |
|
Probably worth mentioning in this thread (currently looking at dropping the fixed function pipeline in my render): Looks like there's GL_TEXTURE_2D_ARRAY with core OpenGL 3, similar concept except there's no blending because the r coordinate is an integer. For OpenGL 2, there's an extension named GL_EXT_texture_array http://developer.download.nvidia.com/opengl/specs/GL_EXT_texture_array.txtedit: http://www.opengl.org/wiki/Array_Texturesedit: The extension appears to be supported on GeForce 8 or newer, S3 Graphics Chrome 440, ATI Radeon 2xxx, 3xxx, 4xxx.
|
|
« Last Edit: June 28, 2010, 01:26:30 AM by lansing »
|
Logged
|
|
|
|
|