Jump to content
  • Advertisement
Sign in to follow this  
smek2

Texture Quads + Z-Buffer = Headache

This topic is 4888 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I have written a small 2D engine based upon Direct3D using texture quads. First i would have set up a single quad, later i would use "SetTexture" and "DrawPrimitive" to draw the sprites. Then i decided to start optimizing the render process and i build a singleton texture- and spritemanager using index-buffer and batching. The spritemanager would take all the sprites added to his renderqueue and render them grouped by texture (so SetTexture will only be called once per texture), also the vertexbuffer will be locked once per texture, adding quads and then drawing with "DrawIndexedPrimitive". So far, so good, everything looked nice and smooth (i am using 24bit PNG's with alpha channel for partial transparency) like this: However, i realized that i had lost the control over the sorting, means which sprite will be in front and which will be overwritten. All of my sprites seemed to be overdrawn by each other in an arbitrary order. I then activated Z-Buffering and altered my spritemanager to give each sprite a differetn z-value, depending on its position in the renderqueue (sprites who added last to it, will be drawn last, thus beeing in front). It worked, except that i had lost my texture alpha, each sprite would become a solid retrangle, partially hiding the sprites behind. Searching the forum and googling up until 5 o'clock in the morning i came up with the "SetRenderState(D3DRS_ALPHATESTENABLE, TRUE)" solution. Now my sprites are sorted based upon their z-value. ALmost perfect, except i lost the "semi-transparency" of texture alpha. Every sprite has this jagged edges now, like this: Again i were searching the internet, but so far i did not find anything. From what i'd understand i am basically stuck with that kind of transparency. Which makes no sense to me, since the big advantage of using Direct3D is "fully hardware-supported alpha blending", right? Any suggestions?

Share this post


Link to post
Share on other sites
Advertisement
This is a common error.
Sort the polys and draw them back-to-front.
Imagine two polys, p1 and p2. p1 is in front of p2, both are semi-transparent. If you draw p1 first, it will fill the z-buffer with some values, even where the semi-transparent pixels were. Then when you draw p2 it won't pass the z-test in those transparent pixels of p1 and they will stay almost white. There is no way of fighting it except as I said sorting them and drawing in back-to-front order. This will kill the need of z-buffer but you either won't be able to control their order, or you won't be able to optimize the rendering process.

!EDIT! you can optimize it without any texture sorting, just push all of your textures into one big texture and play with texture coordinates of your polys. Then you can stuff them all into your vertex buffer, set the big texture and render. Texture is like that:

0-----------1-----------2
| | |
| | |
| image 1 | image 2 |
| | |
1-----------+-----------+

poly1.tex = { {0,0}, {0,1}, {1,0}, {1,1} }
poly2.tex = { {1,0}, {1,1}, {2,0}, {2,1} }


This way you can have as many textures as you like (if your card supports such huge textures).

Share this post


Link to post
Share on other sites
I already did that. Thats what i meant with the "SetRenderState(D3DRS_ALPHATESTENABLE, TRUE) solution."
However, i did not set renderstates for "D3DRS_ALPHAREF,0x1".
I just tried it now, but the results are the same. Transparency yes, but "jagged lines", e.g. no "semi-transparency".
Sure i could use 8-Bit PNG's with simple color-keying.
But thats not the only problem. before i used Z-Buffer and "D3DRS_ALPHATESTENABLE, TRUE" i culd alter each sprites color and overall alpha with via its vertices.
Now, i can modify the color, but chaning the alpha to a semi-transparent value
(like setting a sprites vertices clor value to 0x66FFFFFF), the sprite will simply fade to white.
I wonder, i sure missing something here, because in modern 3D games, you can see polygons using semi-transparent textures like glass or water.
Well, thanks anyway.

Share this post


Link to post
Share on other sites
Quote:
Original post by ReaVeR-Andrey
This will kill the need of z-buffer but you either won't be able to control their order, or you won't be able to optimize the rendering process.


Thanks, i were afraid to hear that. Well, too bad then.

Share this post


Link to post
Share on other sites
Quote:
Original post by ReaVeR-Andrey
!EDIT! you can optimize it without any texture sorting, just push all of your textures into one big texture and play with texture coordinates of your polys. Then you can stuff them all into your vertex buffer, set the big texture and render. ...
This way you can have as many textures as you like (if your card supports such huge textures).


I thought about that too, it's tempting. But merging all of my textures into one big texture, would'nt that make one huge memory hog? Also what about graphic cards with a texture size limit of, let's say, 512x512 pixels? That seems a bit small for covering all of the possible sprites used in a game. Consider that animated sprites use up at least a couple of frames etc.

edit: btw, i got rid of the z-buffer now, sorting my sprites based upon their entry into render queue (sprites added first, will be drawed first).
Consider the screen might be filled up with hordes of sprites, all of them using the same texture (like spaceships for example), i shudder thinking about setting this texture everytime i draw a sprite. So i simply check if the current sprite in the render-queue has a different texture than its predecessor. If so, i set the new texture, otherwise not. Thats the best i could come up with, by now.
Still i keep my rendersystems indexbuffer and functions for batching quads, for rendering tile-based maps.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!