Which way to render 2D graphics is faster in d3d? Using sprites or texturing quads/other polys?
By using sprites do you mean D3DXCreateSprite etc? This almost certainly uses textured quads under the hood, and batches up the draw calls to make things fast. I'd suggest using this and only investigate manually creating quads if this isn't sufficiently fast.
Related
For context, I was mulling over a design where static UI elements can be rendered to a texture and drawn, instead of drawing each separate UI element every frame. And then I thought, "Wait, couldn't you do this for everything?" Instead of drawing each tile in a tile map, couldn't you just draw it once on a big texture and use that?
Although this would seem like a good idea, I don't really know what the best practices are for this type of texture use.
Some possible questions/topics:
Why is binding a texture so slow? Does glBindTexture() push the texture to a higher memory cache for access?
In the case of the tile map example, does drawing large textures pose performance issues? Is it better to draw multiple smaller textures?
I have to render large quantities of particles. These particles are simple non-textured quads (squares actually). Oh, and they're moving all the time since they're particles.
I have considered 2 options but as I'm not an OpenGL expert I don't know what's best.
Use VBOs to render them all.
Pros: faster than immediate mode.
Cons: (I don't know much about VBOs but) from what I gather the quads' coordinates need to be stored in some buffer in RAM... and all of these coordinates need to be computed by the CPU. So for particle P1(x,y) I would have to compute 4 other coordinates (P2(x-1,y-1), P3(x-1,y+1), P4(x+1,y+1), P5(x+1,y-1)) - that's a lot of work for the CPU!
Use a display list: First create a tiny display list for a single square quad. Then, to render each particle do some pushMatrix, glTranslate, callList, popMatrix.
Pros: I don't have to compute 4 coordinates manually - glTranlate does that.
Supposedly display lists are faster than VBOs.
Cons: Are they faster than VBOs when they contain just one quad?
Mind you: I'm calling OpenGL stuff from Java so there's no smooth way of transforming Java arrays to GPU arrays (everything has to be stored in intermediary FloatBuffers before transfers).
Display Lists are for static geometry. Rendering just one single quad, then changing the transformation, rinse and repeat is horribly inefficient.
Updating VBOs is better but still not optimal.
You should look into instanced rendering. Here's a tutorial:
http://ogldev.atspace.co.uk/www/tutorial33/tutorial33.html
In the case of simple quads using a geometry shader turning simple GL_POINTS into two GL_TRIANGLES would do the trick as well.
To do particle simulations i think what you are looking for is transform feedback, here is a nice demonstration with some code on how to do it http://prideout.net/blog/?tag=opengl-transform-feedback
I'm writing a simple 2d game using SDL and I was wondering, what if I just apply a bitmap texture to rectangles with OpenGL and use them instead of sprites, eliminating any calls to SDL_BlitSurface? Will my application become faster as a result of OpenGL hardware acceleration?
P.S.: My application will be running in windowed mode (not fullscreen), if that's important.
Yes, in general, that should be faster and more scalable (you can draw more sprites before you start getting a performance hit).
Is it a good or bad idea to use display lists for drawing textured rectangles?
The display list would be re-compiled only if the texture the sprite is using changes.
For drawing a single sprite, there's no real problem in doing it that way, but there's no advantage to it either, assuming you're using glRotate/glTranslate to position the sprite. Plenty of games have been written that way.
In my games, I use a vertex buffer object with GL_DYNAMIC_DRAW to store all the sprites which share each texture atlas. I update the vert positions on the CPU and send the whole batch in one draw call. I can draw many more sprites using this approach. I could do the positions in a vertex shader if I needed to draw even more.
Also, keep in mind that OpenGL ES2 doesn't support display lists, so if you're thinking of porting to an ES2 device you'd have to re-do it. (iPhone/iPad support ES1 but you can't mix and match with ES2, you can use display lists OR shaders but not both).
I would like to draw voxels by using opengl but it doesn't seem like it is supported. I made a cube drawing function that had 24 vertices (4 vertices per face) but it drops the frame rate when you draw 2500 cubes. I was hoping there was a better way. Ideally I would just like to send a position, edge size, and color to the graphics card. I'm not sure if I can do this by using GLSL to compile instructions as part of the fragment shader or vertex shader.
I searched google and found out about point sprites and billboard sprites (same thing?). Could those be used as an alternative to drawing a cube quicker? If I use 6, one for each face, it seems like that would be sending much less information to the graphics card and hopefully gain me a better frame rate.
Another thought is maybe I can draw multiple cubes using one drawelements call?
Maybe there is a better method altogether that I don't know about? Any help is appreciated.
Drawing voxels with cubes is almost always the wrong way to go (the exceptional case is ray-tracing). What you usually want to do is put the data into a 3D texture and render slices depending on camera position. See this page: https://developer.nvidia.com/gpugems/GPUGems/gpugems_ch39.html and you can find other techniques by searching for "volume rendering gpu".
EDIT: When writing the above answer I didn't realize that the OP was, most likely, interested in how Minecraft does that. For techniques to speed-up Minecraft-style rasterization check out Culling techniques for rendering lots of cubes. Though with recent advances in graphics hardware, rendering Minecraft through raytracing may become the reality.
What you're looking for is called instancing. You could take a look at glDrawElementsInstanced and glDrawArraysInstanced for a couple of possibilities. Note that these were only added as core operations relatively recently (OGL 3.1), but have been available as extensions quite a while longer.
nVidia's OpenGL SDK has an example of instanced drawing in OpenGL.
First you really should be looking at OpenGL 3+ using GLSL. This has been the standard for quite some time. Second, most Minecraft-esque implementations use mesh creation on the CPU side. This technique involves looking at all of the block positions and creating a vertex buffer object that renders the triangles of all of the exposed faces. The VBO is only generated when the voxels change and is persisted between frames. An ideal implementation would combine coplanar faces of the same texture into larger faces.