 |
|
|
|
|
|
||
|
|
||
|
|
||
|
|
|
|
|
|
||
|
|
||
|
|
||
|
|
|
|
|
|||||||||||||||||
Add Forum to Favorites | Send Topic To a Friend | View Forum FAQ | Track this topic |
Last Thread Next Thread |
| Rendering efficient 2D sprites in OpenGL using Texture Rectangles |
|
 |
coden4fun Banned Member since: 10/7/2007 From: Asheville, NC, United States |
|||
 Posted - 11/2/2007 4:37:55 PM |
||||
| This is a great article. I can now start my game in OpenGL. I was making a game engine using SDL, but I couldn't rotate sprites in real-time without using either Dx, or OpenGL, so I was undecided. Now with what I've learned in this article I am sure to make the engine with OpenGL. Great Article! My Blog |
||||
|
||||
|
Trillian Member since: 4/28/2005 From: Montreal, Canada |
|||
|
Posted - 11/2/2007 10:26:35 PM |
||||
Quote: Unless I'm mistaking, Direct3D's ID3DXSprite interface uses some kind of batching (it most likely stores vertices in a vertex buffer and sort them by texture), so I'd be very surprised if you could get a comparable performance using immediate mode opengl. Apart from this, the article is a good introduction to those who want to start using the power of opengl to build simple 2D games. I'd have loved a tutorial on 2D sprite batching though... |
||||
|
||||
|
Tojiro67445 Member since: 7/1/2007 From: Salt Lake City, UT, United States |
|||
|
Posted - 11/2/2007 11:35:58 PM |
||||
| Decent article, though a fully functional sample project would have been fitting. One issue I have, though, is that you keep mentioning efficiency throughout yet you still use immediate mode rendering (glVertex and friends)? If you really want to be efficient (and match the D3DX interface better) you would be far better of using Vertex Buffer Objects or at the very least Display Lists. In fact, that would be pretty good advice for any modern OpenGL program... Still, a nice little code blurb that serves as a decent example of how to use the the extension. |
||||
|
||||
|
ReadTFM Member since: 8/19/2007 From: Nemo, AR, United States |
|||
|
Posted - 11/3/2007 10:20:56 AM |
||||
| Your color keying doesn't work so great -- that's why you have that purple halo around your sprite. |
||||
|
||||
|
Trillian Member since: 4/28/2005 From: Montreal, Canada |
|||
|
Posted - 11/3/2007 10:48:08 AM |
||||
Quote: Color keying always causes trouble when used in combination with lossy file formats such as JPG. That is because some pixel colors are approximated, they do not remain pure RGB(255, 0, 255). |
||||
|
||||
|
Tojiro67445 Member since: 7/1/2007 From: Salt Lake City, UT, United States |
|||
|
Posted - 11/3/2007 12:18:18 PM |
||||
Quote: Even with a lossless format, though, you will still end up with a very sharp, aliased edge. Really there's no reason not to use alpha channels for these things anymore, which can easily avoid these problems. |
||||
|
||||
|
blueshogun96 Member since: 6/9/2005 From: Edgewood, WA, United States |
|||||
|
Posted - 11/5/2007 1:21:25 PM |
||||||
Quote: I decided not to use any forms of batching to keep the article more simple for beginners to use. I'm sure anyone who knows how to add static/dynamic batching can do so themselves. Just wanted to make it noob friendly. Quote: Thanks for pointing that out, but I left out such features for the reasons above :) I wanted to have the source code for the example available for the public to download, but it seems GameDev didn't post it. I need to host the file somewhere so you all can download it. Quote: Yeah, I used a cheap method of color keying with this sprite. (http://www.codesampler.com/oglsrc/oglsrc_4.htm#ogl_color_key) Quote: True, but I used a .BMP file. Thanks for your positive inputs on this article, I hope someone finds it useful and can use it to make great commercial games :) |
||||||
|
||||||
|
bitshit Member since: 9/29/2005 From: Rotterdam, Netherlands |
|||
|
Posted - 11/5/2007 5:13:04 PM |
||||
Quote: I'm kind of an opengl noob, but im interested in how this batching would be implemented. Does opengl itself facilitate batched drawing calls somehow? |
||||
|
||||
|
Koshmaar Member since: 11/21/2003 From: Cracovia, Poland |
|||
|
Posted - 11/6/2007 5:32:14 AM |
||||
| Does this approach of GL_NV_texture_rectangle has any performance (or any other) advantages over using normal textured quads? I'm talking about immediate mode in both cases. Koshmaar Magic Pencil | SDL_Config (Homepage, Download) ) |
||||
|
||||
|
blueshogun96 Member since: 6/9/2005 From: Edgewood, WA, United States |
|||
|
Posted - 11/6/2007 3:41:27 PM |
||||
Quote: If you're an OpenGL noob, I'd recommend you learn more about how to use batching in OpenGL if you don't already. When you have experience in that area, adding it won't be a problem. Here's a nice thread I found on the subject: http://www.gamedev.net/community/forums/topic.asp?topic_id=395980&whichpage=1� Quote: It depends on what you're using it for. For a power of 2 texture, the performance difference wouldn't be noticeable. But using GL_TEXTURE_2D when using a non-power of 2 texture created a noticeable impact on my framerate. When I use texture rectangles, the problem went away. It's totally up to you. For more information on how this extension works and it's limitations, read this article on nvidia.com: http://developer.download.nvidia.com/opengl/specs/nvOpenGLspecs.pdf I hope this helps :) |
||||
|
||||
|
GolfHacker Member since: 6/28/2007 From: San Diego, CA, United States |
|||
|
Posted - 11/7/2007 4:56:26 PM |
||||
Quote: My Dirk Dashing game uses essentially the same technique described in this article. My engine does lots of sorting and culling to limit the amount of data going to the card, and that works very well. The game runs fine on 1GHz or better desktops, but has some issues on laptops and older machines where OpenGL isn't well-supported in hardware. I would love to be able to speed up the game performance to better accomodate these machines. I am unclear about how to effectively use VBOs or display lists in a 2D game, where there are lots of animated sprites that are always changing (e.g., the texture changes every frame or so as the characters run, jump, etc). I've read about VBOs and display lists and looked at code samples, but I don't see how these can help when my sprites only have 4 vertices each, they don't touch other sprites (so I can't blast a whole bunch of vertices to the renderer in one shot), and the texture is always changing. |
||||
|
||||
|
apatriarca Member since: 7/3/2006 From: Torino, Italy |
|||
|
Posted - 11/7/2007 7:47:22 PM |
||||
| I’m currently designing my first 2D game in OpenGL (I have written only 3D application before...). In my design every sprite that want to be rendered must be registered to a sprite manager class. That class keep track of the positions and write them to a dynamic VBO when needed. The sprite manager class will probably also sort the sprites based on the texture used (a texture will contains more than one frame of the animation - maybe also more than one object - to be able to write the maximum number of sprites in a single API call). I don’t know if it’s the best design. |
||||
|
||||
|
DeadXorAlive Member since: 7/24/2005 From: Utrecht, Netherlands |
|||
|
Posted - 11/8/2007 7:35:19 AM |
||||
Nice article!Quote: Perhaps a texture atlas can help here? It would require some intelligent grouping and sorting but it can reduce state changes for textures. |
||||
|
||||
|
GolfHacker Member since: 6/28/2007 From: San Diego, CA, United States |
|||
|
Posted - 11/8/2007 10:05:26 AM |
||||
Quote: Thanks for the good suggestion. I'm already doing this to a certain extent, at least for static background objects that are not animated. It's not too feasible for dynamic sprites that have their own unique animations. I used gDEBugger to help me minimize state changes, so the state changes aren't really the bottleneck anymore. And applying various culling techniques has helped me minimize the amount of polygons I'm sending to the card per frame. So I think I'm about as optimized as an immediate-mode application can be. Everybody keeps telling me I shouldn't be using immediate mode, but I am unclear how to do a 2D game without using immediate mode. @apatriarca: as I understand it, VBOs should be fine for geometry that doesn't change frequently. The idea behind a VBO is to minimize data transfer per frame by storing geometry that doesn't change often directly on the card, and just passing a reference to the VBO. If the geometry does change frequently, then you have to send the VBOs to the GPU every frame, so VBOs wouldn't help you save much bus traffic (if any). This whitepaper is one of the references I've been reading that explains it well: http://www.spec.org/gwpg/Mar2_06/opc.static/vbo_whitepaper.html. |
||||
|
||||
|
DeadXorAlive Member since: 7/24/2005 From: Utrecht, Netherlands |
|||
|
Posted - 11/8/2007 11:09:08 AM |
||||
| You can use vertex arrays for a 2D game in a similar way to immediate mode. I haven't done benchmarks myself yet, but I remember a talk (can't find it, sorry) in which was said that immediate mode is very hard for the driver to optimize for and vertex arrays will provide better performance for this reaon alone. I think it's worth to try it, it's not much work, or did you already? |
||||
|
||||
|
apatriarca Member since: 7/3/2006 From: Torino, Italy |
|||
|
Posted - 11/8/2007 4:08:29 PM |
||||
Quote: When you use the immediate mode the driver knows nothing about what you want to do and can’t do any optimization. VBOs are mode driver-friendly and can also be used with dynamic scenes. In the link you gave me I have for example read the following sentence: “VBOs give applications the flexibility to be able to modify data without causing overhead in transfer due to validation.” Dynamic VBOs can also help to save memory traffic by allowing the update of subsets of the buffer. I think in OpenGL 3 VBOs will be the only way to send geometry to the GPU. I really don’t see any reason to prefer immediate mode to other methods. Instead of calling several functions you write the data in an array and then call a function. |
||||
|
||||
|
Ademan555 Member since: 11/30/2003 From: Lafayette, CA, United States |
|||
|
Posted - 11/8/2007 9:37:56 PM |
||||
| I didn't see anyone else mention this, but with the presence of GL_ARB_texture_rectangle why did you use GL_NV_texture_rectangle in the tutorial? (also isn't texture rectangle core by now?) cheers -Dan |
||||
|
||||
|
blueshogun96 Member since: 6/9/2005 From: Edgewood, WA, United States |
|||
|
Posted - 11/21/2007 11:03:26 AM |
||||
| Sorry for the slow reply, but you're right, I should have used the ARB instead of NV, but either one works fine. |
||||
|
||||
| All times are ET (US) |
Last Thread Next Thread |
|
