Assuming you're using Managed DirectX9 with VB.Net, I would also recommend reading through Mr. Clingerman's first 2 tutorials (page showing links to all 3 tutorials in the series here: http://geekswithblogs.net/clingermangw/category/5002.aspx ).

They helped me quite a bit in getting my 2D graphics library started (I'm using SlimDX, though, which is quite similar to Managed DirectX ... I first worked up a Managed DirectX version of what I wanted to do, then tweaked things to fit the slight changed needed for SlimDX .).

Good luck with your project,
-Matt

Quote:Original post by HolyGrail

Quote:Original post by MJP
SDL defaults to GDI, even if you specify that you want a hardware device. This is because DirectDraw no longer provides hardware acceleration.

Ok.
Is there any link or proof your statement ?
You say that DirectDraw no longer provides hardware acceleration.
If it's the case, I don't understand because ddraw.dll is still present.

Go ahead and try it yourself. Specify that you want a hardware video surface, and then use SDL_VideoDriverName to see what driver its using (Windib is their name for the GDI driver).

Presumably SDL leaves in DDraw support for platforms that still support it in hardware.

That first chunk of code you listed ("Sub Main") isn't from the DX3DEngine class ... it's from Class Main (a new class he adds at the end with just that one Sub in it).

So, his structure goes like this: Class DX3DEngine holds the guts of the creation and rendering code. Class GameEngine abstracts it and would hold the actual game code (his "Render" method is bare to start with ... all sprite drawing would occur between the "BeginRender" and "EndRender" calls). Class Main launches the game form and runs the game loop.

Now, with that said, I'll admit that I never actually went through and built the whole thing according to the tutorials. Instead, I used the tutorials to get me familiar with the concepts on (1) how to setup the Direct3D Device and (2) how to use the Sprite object to draw 2D things to the screen. So, with that, I've assembled my own approach summarized as this:

Initialize things ahead of time ...

1> Launch Game Form & Create Direct3D Device (the "CreateDevice" method in the tutorial is a big help there) ... keep a useable reference to the Device, since just about everything else used in Direct3D will need to reference it

2> Create a Direct3D.Sprite object (as shown in tutorial #2) ... you only need 1 and like the Device, you will want a useable reference to it for your main loop code ... since this is used to render all of your sprites, I like to call it a SpriteBatch (similar to what is used in XNA)

3> Load your sprite graphics into Textures ... best done as "sprite sheets" (fitting as many sprite graphics into a single file as possible), and should be in power-of-2 dimensions (256x256, 512x512, etc.)

4> Define your individual sprites as a reference to one of the Textures and a Rectangle that is the location and size of that sprite's graphic on that Texture


In the Game loop ...

1> Device.BeginScene / Clear

2> SpriteBatch.Begin

3a> Loop through all individual sprites

3b> SpriteBatch.Draw2D ... using the individual sprite's texture, rect, and location (also allows for on-the-fly rotation, if you want it)

4> SpriteBatch.End

5> Device.EndScene / Present


I realize that I covered these things at an ultra-high level ... but I'd be happy to drill down into details wherever you may need it.

Also, the graphics file handling changes a bit from the traditional GDI/DirectDraw/SDL 2D way of having each sprite's graphics in its own file and loading it into its own surface ... to having your sprite graphics gathered together in larger files, which are loaded into Textures, which are used by the sprites by using a rectangle to determine what part of the texture to use as a sprite's graphic. (At least that was a trickier-than-expected hurdle for me to get over ... but it has some benefits, especially when wanting to reuse explosion/effects graphics between projects, or when doing animations.)

I hope this is helpful.

-Matt

I want to make a slight addendum to this: if you decide not to use the D3DXSprite extension (which I highly recommend, as did some others here), and you write your own sprite renderer using T&L vertices, be sure to set the rhw property to something other than zero (one would be fine). Some older video cards do not handle a zero rhw gracefully and will render pure white triangles (i.e., without textures).

Still, I strongly recommend D3DXSprite. It has all the functionality you need wrapped up into one easy-to-use extension, and it supports blending modes, etc. And, yes, the SDK is your best friend.