#### Archived

This topic is now archived and is closed to further replies.

# Real 2D game prog. in D3D8

## Recommended Posts

MatuX    122
In DirectDraw7 you just blitted rects and it was ultra fast, in D3D8, you have to send vertex buffer batches of 2 triangles (a quad) to DrawPrimitive and it is obviously ultra slow since you have to repeat the operation NTiles*NLayers and batching only 2 triangles just makes things worse. So, is there a way of doing real 2D game programming in Direct3D8 or we f*cked up? --------- Non viable "solutions" 1. Rendering a full 3D terrain.. This is simply stupid, you obviously don't know the main feature of DD7 is the ability to deliver high quality and very artistic images, you certainly cannot do: http://matux.hypermart.net/diablo2_screen009.jpg or http://matux.hypermart.net/diablo2_screen001.jpg using this technique. 2. Another "solution" was to add all the textures I could into a macro-texture, ie. all 64x32 tiles into a big 256x256 tile. Then you render in batches of multiple polygons and you just change the tu,tv coordinates to point to the desired tile. But now, this ends up being either a map art eater or not being faster at all since you wont have all the textures you will use to render a single scene in the macro-texture so this mean that you will have to use as few textures as possible because it will still batch very few polys if you design high detailed scenes like: http://matux.hypermart.net/007.jpg or http://matux.hypermart.net/009.jpg, and using very very detailed scenes with high-quality pre-render images like those are the real point of doing 2D. And no, more than 256x256 is not an option since there're still lots of Voodoos and TNT cards out there. Edited by - MatuX on January 15, 2002 1:54:03 PM

##### Share on other sites
Guest Anonymous Poster
whats wrong about directx7 interfaces for 2d games?
hm...

if you REALLY want to use directx8,
use CopyRects() to build a (self maintained) "texture cache",
and then fire all rects with the same texture in one batch.
sorting will probably not work because the draw order would
change.

another thing:
is "one-rect" batch rendering really SO slow?
the textures remain on the card, so there shouldn be a problem.

ofcourse you will never get the performance of 2D blits when using 3D, so - as above - why not use d3d7+dd7?

btw. if you start game-dev NOW t&l hw will be standard when you are done.

##### Share on other sites
CrazedGenius    156
have you actually tried 2D quads?

Yes, you may not be doing batching, but I have found that you can render thousands of quads in a given frame before the framerate drops to unacceptable levels (if you do it right). I'd argue with the "obviously ultra slow" part based on my own test results on a gf2Go laptop.

If you really want to, you could batch up several transformed quads on the CPU and send them all to the card at one time. You'll get slight performance gains (on the order of +1 fps in my tests). The gains may be better on lesser hardware. For my apps, I've never had to get fancier than the inefficient single quad technique.

Keep in mind, you are probably more fill limited than geometry limited.

I'm not even sure about the "ofcourse you will never get the performance of 2D blits when using 3D" part. Real 2D blits might beat 2D quads in very simple tests, but I have never seen anyone test them side by side on the same hardware. When you start to do more complex operations (blending, etc.) the 3D technique should outperform DD7.

Try it - create a simple DD7 app and the equivalent DX8 app. (This should only take an hour or so). Compare the results. If you would like, post the code here so that people can try it on multiple machines and make sure that one app is not more optimized than the other.

Edited by - CrazedGenius on January 15, 2002 2:44:06 PM

##### Share on other sites
MatuX    122
I''m surely will end up doing that if no one can justify why everyone insists so much on using 3D apis to do 2D.

##### Share on other sites
Poisler    151
I know your frustration. I''ve been away from game programming for about a year and when I came back I took one look at Directx 8 and said WTF is this?? I read a whole bunch of articles and all of them said different things. I think the best solution however is to use the D3DXSPRITE interface. There''s not a lot of documentation on it but it''s pretty easy to use once you understand it. This is the basic way to get something on the screen;
  //set up DXGraphics and windows the normal way//get a texture from a file//The render routine would look something like thisvoid Render(){ //Clear the backbuffer to a black color dx8.pd3dDevice->Clear( 0, NULL, D3DCLEAR_TARGET, D3DCOLOR_XRGB(0,0,255), 1.0f, 0 ); // Begin the scene dx8.pd3dDevice->BeginScene(); //This is where D3DXSprite comes in dx8.pd3dxSprite->Begin(); dx8.pd3dxSprite->Draw(pSrcTexture, pSrcRect, NULL, NULL, 0, &trans, 0xFFFFFFFF ); dx8.pd3dxSprite->End (); // End the scene dx8.pd3dDevice->EndScene(); // Present the backbuffer contents to the display dx8.pd3dDevice->Present( NULL, NULL, NULL, NULL );}

pSrcTexture is similar to a surface. It holds the bitmap.
pSrcRect is a RECT that tells DX which area of the source surface you want to display.
trans is the location that you want to draw to on the screen.

So, if you wanted to move the image around the screen, you would change the values in the tans struct. If you wanted to do animation you would change the values in the pSrcRect.

Hope that helps.

##### Share on other sites
CrazedGenius    156
I think it was S1CA who pointed out that some drivers have been using the "3D way" to do DD under the hood for awhile now.

I''m not sure I can justify it to you. Many of the points that seem obvious to you are not actually true (at least not on newer hardware). You may have to try it for yourself.

You and I are on opposite sides of the spectrum. Based on what I''ve seen, I can''t see how anyone can justify using DirectDraw (on newer hardware). I think you might be surprised with the results when you actually get things going...

##### Share on other sites
MatuX    122
I can reach 80fps performing just 350 DrawPrimitives using batches of 2 polys (which is actually more or less what the billboarding example delivers when rendering 350 trees). I''m on a Duron 800@950 with a GF2MX. You may think, but that is perfectly fine! But the minimum specs we''re trying to reach is a TNT1, worst is that I can''t even test the engine on a TNT2...

CrazedGenius, you said you could deliver several *thousands* of quads on a frame without losing too many fps. Did you use some kind of batching or you actually made thousands of calls to DrawPrimitive?

The problem isn''t CPU, I''ve even tried underclock my Duron from 950 to 600Mhz and I just lost 5fps, which certainly is nothing and can be gained with enough code optimization (non DX API-related code optimization).

Removing Alphablending will give me a boost of 10fps, removing SetTexture (which is actually being done every frame) will give me a boost of 20fps. Those numbers are nothing compared when I remove the actual DrawPrimitive line (everything else is processed) where I get a boost of 400fps

We think the game will be finished in a year or less, so maybe we can tweak our minimum specs... I have been trying stuff like abusing alphablending (all the drawn quads are blended), even performing unuseful render states changes and the fps won''t change that much...

The bad thing here is that 350 DrawPrimitives is ~30% of what we plan to deliver on in-game graphics.

D3DXSprite??! I started with that, it''s the slowest SLOWEST thing in the world

##### Share on other sites
CrazedGenius    156
The TNT is going to be slower for this because it doesn't support 3D as well as later cards. Perhaps DD would be better in that specific case...

Removing DrawPrimitive should cause a huge increase, but not because you are saving geometry processing. It's because nothing is drawn. No drawing, depth testing, texturing, blending, etc. the vertex procesing is the least of your worries.

Here are some specs and caveats:

I am rendering 1000 blended quads on the screen at 30 fps using code that is not at all optimized (see below) on a GF2Go (the same chip as your MX). Yes, 30 fps is not fast, but you would probably also never need to draw 1000 quads. The quads don't kill you, the pixels do. (I'm using the typical RTS as a benchmark - if you have 1000 units on the screen, you can't really hope for great frame rates)
The performance increases greatly with lower quad counts, no blending, and smaller textures. This is the importent bit. If I use very small textures, my framrate increases. If I use very large textures, the framerate will die. Keep this in mind...

About the code. The testing code is based on the "2D in DX8" article on this site. It is not at all optimized in any way. In fact, it's quite bad (the test code, not the article). I have a panel class that contains 4 vertices and it's own texture. I create 1000 panels, meaning that I create 1000 little vertex buffers and 1000 copies of the same texture (obviously, I must be crazy). Each frame sets a random translation matrix (within the bounds of the screen), changes the vertex buffer, changes the texture, sets the transform, and renders the panels with blending. 1000 quads = ~30 fps. 500 quads = ~40 fps. 500 unblended quads = ~60 fps.

Some comparison numbers to DD - I use a 64x64 texture in this case. This means there are 4096x1000x30 = 123Mpixels/s or ~500MB/s (check my math...). Compare those numbers to the pixel throughput of your DD apps (I don't know, but I *think* it should be much better - also, remember that these are blended)

I don't use D3DXSprite - I prefer to reinvent the wheel for more control and optimization (although obviously not in this case!)

Edited by - CrazedGenius on January 15, 2002 4:19:52 PM

##### Share on other sites
BitBlt    386
2d tiles may be a tad faster than 3d tiles (on some cards) when rendered normally. But there''s so much you can do with 3d tiles that won''t cause a performance hit that would cripple 2d tiles: lighting, fades, transparency, etc.

Besides, DirectX 8 still has all the objects for DX7.

Make games, it''s fun

##### Share on other sites
MatuX    122
Hmm.. It seems you, Crazed, was right It''s a fill rates issue. I was able to deliver 140fps with +550 quads and I reached that because I used 64x32 textures. Bigger textures makes the difference, rendering hundred of them will just kill your 2D app.
I tried some 128x128 and 256x256 quads and I got 84fps rendering only 56 quads.

So, doing some calculations I ended up having ~154,000 triangles per second which isn''t bad as I''m not using TnL... At least, that is what I think

I ran a nVidia benchmark that told me my GF2MX was able to handle 500,000 textured triangles without using TnL, so, this means I could deliver, at least, some thousands more triangles on my engine, so, I came up with 2 solutions I would like to share with you guys and tell me what do you think:
1. Will cropping the texture into small pieces, say, the 64x32 texture into 4 textures of 32x16, and render four times more triangles make things speed up? The problem here is "balance", I need to find the balance between texture size and amount of triangles to render per frame.
2. I can''t remember!!!! While writting the first solution I forgot the second one lol..

PD: Using TnL completely screws up the app making all the quads constantly flash (normal/black/normal/black/etc.) and it won''t even display all of the quads on the screen, just some of them, plus it''s much slower, I haven''t worked on this bug, yet.
PD2: Thanks for all your help guys, it is really worth

##### Share on other sites
CrazedGenius    156
I''m glad to hear things are working.

As for your question. I don''t think splitting the textures up will solve anything if your goal to to render the complete texture each time. For instance, don''t split up a house and then draw four chunks of the house. Just don''t draw more than you have to. If you have little units that can fit in a 32x32 texture, use that size. What matters is the final number of pixels.

Oh - another way to answer your question. Square textures are generally faster than rectangular, although you should try it to see if the difference is substantial.

Also, this *might* be of help... If you have large amounts of the scene that are static, you *might* see gains if you render several, tiles to a larger texture and then use that texture for as long as you can. If you have a house on a hill, this saves all the overdraw of the pixels that are under the house and never seen. Again, you''ll have to see if it''s worthwhile.

##### Share on other sites
DrunkenHyena    805
G''day!

If you''re drawing a lot of layers, you might get a nice speed boost by using a Z-buffer and drawing from front to back (top layer first). If you''re fill-limited, it could help quite a bit.

If you don''t have much overdraw, then it''d be a waste of memory.

##### Share on other sites
Anarchi    122
DirectDraw is kinda getting on a bit, D3D8 is the way to go if u want to create a "good" 2D game since D3D supports scaling, rotation and alpha blending without loss of performance.

Ive been using D3DXSprite for my platform game and people have reported it running at 150FPS (GeForce) with full effects and parallax backgrounds.

If u like, come to my site and download the D3DXSprite wrapper at:

##### Share on other sites
a person    118
first off, using 3d pre rendered graphics does not classify a game as "real" 2d in my book. its more like "i want detailed 3d that cant be done on the hardware so i am pre rendering everything first". while nothing wrong with that, as art is art, you should not consider your game "real" 2d. the point of using 2d methods is NOT to use highly detailed 3d models. the point of using 2d is to convey imagary that cannot be done in realtime 3d. this includes hand drawn 2d art which is my preference when doing 2d games since ussually the prefection of 3d renders are not in the art. but that is a whole another topic.

you are missing some key elements to why your framerate is poorer in dx8 vs dd7. some dos and donts:

DONT use drawprimitiveup(), its slow.
DO use drawprimitive().
DO use DYNAMIC_MEMORY flag (i think thats the one), as well as WRITEONLY and there is a writeonce flag as well. this will ensure dx places the vertex buffers in the correct place.
NEVER read from a vertex buffer.
NEVER write to a vertex buffer more then once.
NEVER lock() the vertex buffer more then needed. you should be creating a vertex buffer of about 100 vertics or so which represent your quads (as strips). then when you call drawprimitive you only pass the indexs that will be drawn. this allows better batching of send the vertices to the card at least.
DO use XYZRHW vertices, since you know where everything goes on screen, you dont need to transform ANY vertices using matrices. maybe for particles systems but thats another story.

fillrate is a big problem, but not as much as you think. especially if you are just drawing the screen once or twice over then spriknling a few sprites on the screen (even if you sprinkle many sprites). as said before you draw front to back with zbuffer on. dont forget to set the proper z values for the vertices. if you truly believe that dd7 is a better solution then by all means use it.

also no one says you HAVE to draw the entire screen over each time. in fact you dont have to clear it either. just draw the background and use dirty rects. so you only redraw where sprites are or if your screen scrolls. this of course is NOT rendering to a texture. also who says you cant use a 256x256 tile? you can store a multitude of your smaller tiles there. and its one less call. why would you still need to draw individual tiles? granted there are times where it saves memory, but anytime you have a "highly detailed scenes" you most likly dont have many repeating tiles. thus you can batch the tiles into a larger texture and draw with one call. you can also believe it or not, have the hardware repeat the textures for you. so you can draw mulitple "tiles" using a single quad. just use uv coordinates greater then 1. though i suggest not making the number too high since some cards dont like it (though when i say to high i mean some thing higher then 256). this further batches large areas of the same texture easily with a single call without even having to deal with multiple quads. this of course means you have to work a bit harder to organize the data.

please define "map art eater". are you saying that it reduces the overall number of tiles you are allowed to use? if so then you are mistaken since you can have multiple texture sets, which by defination should be similar in some fashion. best bet would be to oraganize due to locality. thus keeping tiles in the same area of the map together for easy caching. you may also consider a texture set that contains most frequently used tiles used in the map so you dont have to worry about them being paged out. i also dont understand why you need more then 100,000 polygons to draw the map. at 64x32 texture size you fill the screen (at 640x480) with only about 150 quads. even at higher resolutions you still dont get anywhere near a 100,000 limitaion unless your are drawing things that are not on the screen like a ignorent fool.

one last thing, dont trust what a benchmark says your polygon throughput is. this number does not reflect at all with what you are doing. ussually when they do high polygon tests it results in VERY FEW state changes (which includes changing the texture). and a few last questions:
what resolution are you runnign at?
Are you keeping your quads the same size or are you strecting/shrinking them when drawn on screen so the texture size is not the actual screen size.

##### Share on other sites
CrazedGenius    156
quote:
Original post by a person
NEVER write to a vertex buffer more then once.
NEVER lock() the vertex buffer more then needed.
DO use XYZRHW vertices

This raises the interesting question - how do you move XYZRHW vertices without locking? I''ve found that (at least in my code), I break about even between the cost of a lock and the cost of transforming with matrices.

I agree with most of your optimization hints, but someone who''s new to this can go very far without worrying about many of these things.

##### Share on other sites
MatuX    122
Hey guys, thanks a lot for you suggestion, you''re helping me a lot on my quest for the best frame rate

CrazedGenius:
About squared textures... Well.. I tried using 32x32 textures and guess what? I got a boost from 140fps to 390fps. I got very excited when I saw this, then I thought that splitting my tiles in two and rendering two 32x32 quads will solve everything up... Wrong, I got 140fps rendering two 32x32 quads, just the same than rendering one single 64x32. So, splitting is not a solution as I thought.

Drunken: That is very interesting, I''ll surely try that out.

Anarchi: You''re crazy, I bet you will have a +400fps boost if you stop using that d3dxsprite bullshit. Don''t remember where I readed it, but it said D3DXSprite was meant as an easy way to render sprites for debugging purposes, and it IS slow.

a person: Ok, you''re right, I missed that one. I will point that out as a "really good" advantage of using 2D, since pre-rendered 3D images aren''t the only way of delivering good art
I already took care of all the key elements you mention (just when I started the topic I was already doing that )..
I will be working on not drawing all the screen each frame, the problem is, when scrolling, do I have to constantly render the screen again? In DD I used framebuffers to accelerate that, but I can''t have a 1024x1024 texture to hold the frame buffer, I guess I can think something out to speed up scrolling.

The problem with batching textures in sets is that I''m not just rendering 64x32 tiles. I have trees, houses, buildings, characters, walls, ladders, etc. Not even a single one of those will be 64x32, most, and most times the terrain will be hidden by those higher layers (that is why zbuffer can come very handy here).

I just draw 1000 triangles for the terrain map, 100000 are the amount of tris per sec I''m able to deliver.
I''m at 800x600, and no, I''m not modifying in any aspect my textures.

##### Share on other sites
grasshopa55    128
D3DXSprite is a viable option and is not just for debugging. If so, Microsoft would not be touting the D3DX library so much. It all depends on what you want to use it for. For my current project, a simple fighter, I have at max, 30 textures on screen all of varing sizes and the frame rate if acceptable ( ~100fps ) on a Pentium Celeron 400 with a TNT2.

MatuX, for your system, the D3DXSprite objects may not be what you need. Are you creating a tiled game? if so, then the other suggestions here may prove more useful. Also, the D3DXSprite object is not designed to be used to blt a large number of textures ( namely tile-maps ). It's primary function is wrap up some simple 2D operations ( for HUD's, etc ) in a 3D enviornment.

Edited by - grasshopa55 on January 16, 2002 10:10:57 AM

##### Share on other sites
AndyM    122
Firstly, some people forget to use indexed polys - this is much better and faster than trying to clump everything into triangle strips or fans.
Put all sprites into 256x256 textures - fill up a vertex buffer of quads for each texture, (one lock,unlock,drawprimitive per texture).
But this can only improve fps by 50% or so over d3dxsprite.
Drawing an isometric landscape is still faster in software on many cards (e.g TnT2), as their alpha blits are kinda slow.
A

##### Share on other sites
Forcas    181
Sure... you can use a bunch of accelerated effects with D3D8, but then your target audience NEEDS 3D CARDS. You can do scaling, and a few other tricks with DDraw7... That''s why I''m opting for DDraw 7 in my new 2d game.

##### Share on other sites
Guest Anonymous Poster
quote:
Original post by a person
first off, using 3d pre rendered graphics does not classify a game as "real" 2d in my book. its more like "i want detailed 3d that cant be done on the hardware so i am pre rendering everything first". while nothing wrong with that, as art is art, you should not consider your game "real" 2d. the point of using 2d methods is NOT to use highly detailed 3d models. the point of using 2d is to convey imagary that cannot be done in realtime 3d. this includes hand drawn 2d art which is my preference when doing 2d games since ussually the prefection of 3d renders are not in the art. but that is a whole another topic.

you are missing some key elements to why your framerate is poorer in dx8 vs dd7. some dos and donts:

DONT use drawprimitiveup(), its slow.
DO use drawprimitive().
DO use DYNAMIC_MEMORY flag (i think thats the one), as well as WRITEONLY and there is a writeonce flag as well. this will ensure dx places the vertex buffers in the correct place.
NEVER read from a vertex buffer.
NEVER write to a vertex buffer more then once.
NEVER lock() the vertex buffer more then needed. you should be creating a vertex buffer of about 100 vertics or so which represent your quads (as strips). then when you call drawprimitive you only pass the indexs that will be drawn. this allows better batching of send the vertices to the card at least.
DO use XYZRHW vertices, since you know where everything goes on screen, you dont need to transform ANY vertices using matrices. maybe for particles systems but thats another story.

fillrate is a big problem, but not as much as you think. especially if you are just drawing the screen once or twice over then spriknling a few sprites on the screen (even if you sprinkle many sprites). as said before you draw front to back with zbuffer on. dont forget to set the proper z values for the vertices. if you truly believe that dd7 is a better solution then by all means use it.

also no one says you HAVE to draw the entire screen over each time. in fact you dont have to clear it either. just draw the background and use dirty rects. so you only redraw where sprites are or if your screen scrolls. this of course is NOT rendering to a texture. also who says you cant use a 256x256 tile? you can store a multitude of your smaller tiles there. and its one less call. why would you still need to draw individual tiles? granted there are times where it saves memory, but anytime you have a "highly detailed scenes" you most likly dont have many repeating tiles. thus you can batch the tiles into a larger texture and draw with one call. you can also believe it or not, have the hardware repeat the textures for you. so you can draw mulitple "tiles" using a single quad. just use uv coordinates greater then 1. though i suggest not making the number too high since some cards dont like it (though when i say to high i mean some thing higher then 256). this further batches large areas of the same texture easily with a single call without even having to deal with multiple quads. this of course means you have to work a bit harder to organize the data.

please define "map art eater". are you saying that it reduces the overall number of tiles you are allowed to use? if so then you are mistaken since you can have multiple texture sets, which by defination should be similar in some fashion. best bet would be to oraganize due to locality. thus keeping tiles in the same area of the map together for easy caching. you may also consider a texture set that contains most frequently used tiles used in the map so you dont have to worry about them being paged out. i also dont understand why you need more then 100,000 polygons to draw the map. at 64x32 texture size you fill the screen (at 640x480) with only about 150 quads. even at higher resolutions you still dont get anywhere near a 100,000 limitaion unless your are drawing things that are not on the screen like a ignorent fool.

one last thing, dont trust what a benchmark says your polygon throughput is. this number does not reflect at all with what you are doing. ussually when they do high polygon tests it results in VERY FEW state changes (which includes changing the texture). and a few last questions:
what resolution are you runnign at?
Are you keeping your quads the same size or are you strecting/shrinking them when drawn on screen so the texture size is not the actual screen size.

A message for "a person" :

I want your opinion. Imagine you have a class named CTextureBank for example and it contains an array of CTexture wich represent LPDIRECT3DTEXTURE8 interfaces. In each CTexture objects there would be a set of coordinates (a vertex buffer or a index buffer) or pointer to another class containing the coordinates like a CSprite or CTile class. Do you think it would be accelerated? Also, if the camera is in orthographic view, does it speeds up the thing?

##### Share on other sites
a person    118
oops, i guess i was unclear about the "NEVER lock() a vertex buffer more then once". let me rephrase and explain it better. you should never lock() the vertex buffer more then once per frame. if you do, you should not lock the same vertices over (like when doing particle systems) and should still lock at least 20-100 vertices at a time. ussually its easier to handle translations via custom software routines and faster then using matrics unless you go the hardware TnL route, even in that case you probally get better speed using custom translations. though this is specific to 2d sprite/tile stuff.

AnonPoster: of course it would be accelerated if using a 3d video card. it however may not be the best solution. camera view only will affect non transformed vertices. though since dx requires a perspective transformation anyway, you will have all the calculations done regardless of view type.

Mautaux:
even more advice. being a naive person i thought you were trying to do a traditional 2d game and not an isometric game (the pics should have clued me in, heh). i ussually consider isometric games 2.5d since they try to fake a 3d look moreso then traditional 2d games.

you say using square art will be taboo due to isometric style of your game and it would hinder the art creation. i hate to say, but using alpha blending on all those polys is bad and killing your fillrate, it will be even worse on older cards. you have two options:

1. alpha testing which should be faster since no blending is performed at all. not sure if older cards support that though.
2. square tiles that are skewed to fit how you want them to look. though this is probally a difficulty when creating the tiles. though you could just post process your tiles to be square then later when rendering skew them. there should not be too much quality loss.

even if you dont use 64x32 tiles with some bigger or smaller, you can still place them on a single texture for groups. i dont understand why you are so against doing this. if you really dont want to change your artwork at all, then dont use dx8. dx8 will require some compromises since 3d video cards were not designed with this sort of thing in mind.

also as another little remark, ff tatics which used an isometric view, used square artwork which was skewed to give the isometric look. while certain things will require more layers of art to accomplish the same look you seem to be going for, it may be faster in the long run.

do you have artwork already or are you using tradtional iso artwork form another game?
must you support voodoo and old tnt 1 cards? seems to be a little silly in this respect since many pcs nowadays have at least a tnt2/intel/better then voodoo2 video card. not usre if voodoo3 has 256x256 limitation though.
and the most important question, does your old engine with dx7 run as fast as the current dx8 engine at the SAME resolution and color depth?

also running in 16bit instead of 32bit will help with fillrate issues.

##### Share on other sites
Anarchi    122
quote:

Anarchi: You''re crazy, I bet you will have a +400fps boost if you stop using that d3dxsprite bullshit. Don''t remember where I readed it, but it said D3DXSprite was meant as an easy way to render sprites for debugging purposes, and it IS slow.

I dont understand why so many people dislike using D3DXSprite, all it does is set up the vertices, textures, and matrix for you, if u did it yourself it would be the same code anyway, why re-invent the wheel?
Ive seen a comparison and they both perform the same. The only time D3DXSprite is slower is when the programmer does not know how to use the interface properly, which is probably because the SDK Docs dont explain the usage well.

Oh, as for the "real 2D" thing, DirectDraw and D3DXSprite both display the same output on the screen, the only difference is the blitting system, and since 3D is getting faster all the time, DirectDraw will be a thing of the past when games are concerned, its primary purpose was/is to accelerate WinGDI drawing functions and video acceleration.

##### Share on other sites
OutAxDx    100
I was able to blit 192 25x25 surfaces onto the screen at 400x300 at 32 bit, with DirectDraw7, and get over a thousand frames per second on my TNT1. Incase some people dont realize, DirectDraw ALSO uses hardware acceleration, just like Direct3D. If your card supports hardware acceleration, DirectDraw for 2d can be a lot faster.

##### Share on other sites
DrunkenHyena    805
quote:
Anarchi: You''re crazy, I bet you will have a +400fps boost if you stop using that d3dxsprite bullshit. Don''t remember where I readed it, but it said D3DXSprite was meant as an easy way to render sprites for debugging purposes, and it IS slow.

This is just plain wrong. It is meant as an easy way to render sprites, that doesn''t mean it''s for debugging only, or that it sucks.
quote:
I dont understand why so many people dislike using D3DXSprite, all it does is set up the vertices, textures, and matrix for you, if u did it yourself it would be the same code anyway, why re-invent the wheel?
Ive seen a comparison and they both perform the same. The only time D3DXSprite is slower is when the programmer does not know how to use the interface properly

Well, that''s not quite true either. You can do it much faster than D3DX, the question is, do you need to? If your game is already hitting the refresh rate, why would you need to speed it up?

Anarchi''s game proves that D3DXSprite is a viable option for 2D. Unless you already have a better implementation handy (or you''re doing it for educational purposes) I''d recommend that people use D3DXSprite until it shows that it''s not sufficient, then look into an alternative. In a console-style 2D game on decent hardware, D3DXSprite will do just fine.

I could write something significantly faster than D3DXSprite, but I haven''t needed to. I may do it now for "research" purposes so I can publish something showing that D3DXSprite is fast, but if you need it, you can do it faster. Hell, I''d do it tonight but I have to get on a plane in a few hours and I haven''t finished packing.

Maybe I''ll write it when I get back from Tennessee (as long a bear doesn''t eat me).

Stay Casual,

Ken
Drunken Hyena

##### Share on other sites
KellyMiller    122
quote:
Original post by Anarchi
DirectDraw is kinda getting on a bit, D3D8 is the way to go if u want to create a "good" 2D game since D3D supports scaling, rotation and alpha blending without loss of performance.

Ive been using D3DXSprite for my platform game and people have reported it running at 150FPS (GeForce) with full effects and parallax backgrounds.

If u like, come to my site and download the D3DXSprite wrapper at: