slantz

The full and literal directions at http://www.xtremedotnettalk.com/showthread.php?t=84989 have never failed me. Every time someone has reported a problem afterwards, it always turns out it's because they didn't install *managed* DirectX with the proper /installmanageddx flag. (This produces the exception you're probably seeing when they start up the app.) -Hiro_Antagonist

Well, I had an engine that showed 255 terrain tiles, tons of units and other misc stuff, plus a complicated sidebar and I was getting about 180-220FPS on a 1.8GHz P4. If you're only getting 50 FPS, you're probably not doing any optimization/caching. I assume you're currently drawing each terrain tile on each frame? If so, try drawing each of them to another surface once when you start your game, and then drawing *that* surface to the backbuffer each frame. On my game, I was able to condense 255 (15x15) draw operations each frame down to one by doing that sort of trick. It's then just a matter of going through your game and figuring out what can be 'flattened' into cache surfaces, and then using those cached surfaces to draw to the backbuffer each frame. As for performance in D3D vs DD, it's hard to tell. We actually converted our entire DD game to D3D so that we would have alpha blending and dynamic coloring. D3D seems to max out the framerate at the screen's refresh rate, which for me is 60 FPS. So I'm not sure how many FPS I could get in theory, but making an intelligent guess (based on CPU usage and other factors) it seems like D3D can 'draw' individual sprites/tiles faster, but it doesn't seem like we can do as much optimization in D3D as we could in DD. (Or maybe we're just not as good at D3D yet.) If you definitely won't need alpha blending or dynamic coloring, I would personally advise trying to stick with DD, and just learning to optimize it as much as you can. Hope that helps. -Hiro_Antagonist

I think Kavan's right. Here is what I send to my early alpha testers. Hope it helps. -Hiro_Antagonist --------------------------------------------------------------- ----------------------------------------------------------- Basic Steps: 1. Install .NET 1.1 Framework 2. Install *managed* DirectX 9.0b 3. Run <the appliction> ----------------------------------------------------------- Detailed Steps: ------------------------------ 1. Install .NET 1.1 Framework ------------------------------ 1) Download the .NET Framework from http://www.microsoft.com/downloads/details.aspx?FamilyID=262d25e3-f589-4842-8157-034d1e7cf3a3&displaylang=en 2) Run it. ---------------------------------- 2. Install *managed* DirectX 9.0b ---------------------------------- 1) Download the DirectX 9.0b redistributable from http://www.microsoft.com/downloads/details.aspx?FamilyId=A6DEE0DB-DCCE-43EA-87BB-7C7E1FD1EAA2&displaylang=en 2) Save the DirectX 9.0b redistributable to your hard drive. 3) Run the executable. When you run the setup, it will ask you where to unpack the DirectX files. 4) Choose an easy-to-remember location, like C:\DirectX. 5) After the files are done unpacking, run the managed DirectX install. To do this, click on your Start menu select "Run..." 6) In the Run textbox, type in "<location of directx files>\dxsetup /installmanageddx". For example, if you installed the files to C:\DirectX, you would type in: C:\DirectX\dxsetup /installmanageddx This will install the Managed DirectX components to your machine.

There definitely is *no* alpha-blending in DD. I spent a loooong time investigating the matter. The closest I came was this, which is pretty darned similar to what you're doing. It does, in fact, sidestep to GDI+ rather than doing it in DirectDraw: http://www.xtremedotnettalk.com/showthread.php?t=80726 The big downside of that approach is that it resulted in a ~93% performance degridation when run once on every frame. Unless you can cache the resulting blended image for multiple uses, you will not want to do that. In order to get alpha blending working, we had to rewrite our graphics engine in Direct3D (from DirectDraw), and this has set us back weeks. Hope that helps. -Hiro_Antagonist

No, I hadn't, but I think the problem was tied to a very strange application architecture I was using. I found a way to do the strange thing I needed with a much less strange architecture, and the problem seems to have disappeared as a result. -Hiro_Antagonist

I'm having a problem where my application is locking up sometimes when I call Client.Dispose() for my DirectPlay app. I haven't been able to figure out a specific repro case, but it definitely happens once in a while. I can step through the code in the debugger, and it calls Client.Dispose() and then just stays there and never moves to the next line of code. Does anyone have any ideas of why this could be happening? Any help would be very much appreciated. -Hiro_Antagonist

I'm making a rather large-scale 2-D game myself, and had coded my entire engine in DirectDraw. However, you don't get really any frills with DirectDraw -- certainly not colored lighting or alpha blending. So... I'm actually in the process right now of recoding my entire game w/ using Direct3D instead of DirectDraw. I thought I could get by without alpha blending, or at least figure something out within DD, but believe me, I have spent a huge amount of time researching th eproblem, and i do need alpha-blending for a half-way decent look for my game, and that's not going to happen w/o D3D. There's a lot of literature out there for making 2D games in D3D. My undersatnding is that the right way to do it is to use Sprites. I really can't offer too much D3D-specific advice yet becuase I'm just starting to go down that road myself, but I can say that you'll probably be better off if you just suck it up now and learn to use Sprites through D3D instead of using DirectDraw for any sort of intense 2D project. Hope that helps. -Hiro_Antagonist

This is what I use: key.ColorSpaceHighValue = int.Parse("FF00FF", NumberStyles.HexNumber); key.ColorSpaceLowValue = int.Parse("FF00FF", NumberStyles.HexNumber); This particular examples uses Magenta, which is FF00FF, which is also (255,0,255) for transparency. I've also used other colors under this method, and it works just like you'd expect. I'm not completely sure how to define your value in three seperate 0-255 numbers, but if you know (or can learn) how to convert them to hex, those lines should work for you. I'm not sure exactly what the high and low values are for -- I've always set them to the same thing and it works perfectly for me. -Hiro_Antagonist

Can anyone tell me if there is a managed version if Direct3D7, and if so, what the "using" line would be for the top of a c# file? I'd really like to be able to use Direct3D7 for its compatability with DirectDraw.... Any help would be very greatly appreciated. -Hiro_Antagonist

I don't think you do. I'm using VS.NET 2002, and although it is a pain sometimes, it does work. Make absolutely sure you've updated your .NET Framework (to at least 1.1) and Managed DX 9.0b Summer Update.

I'm using DirectDraw and I'm working on a series of pop-up "windows" that have some blobs of text in them. The text will usually need to wrap, but I haven't been able to find an easy way of determining the width of a given character and/or string. I managed to find Graphics.MeasureString, but that seems to be very GDI+ specific. Does anyone know how to do this in a DirectDraw app? Help would be much appreciated -Hiro_Antagonist

Heh, yeah, that's the exact same response I had. However, I've talked through the problem with some really good developers at a fairly big 2D development house, and they currently use Direct3D (7) for all their 2D games. If you're willing to invest a while in creating your own wrapper functions, you can basically write your own blit function that will break up the rectangle you want to blit into 2 triangles, and then apply them individually. But once you write a robust enough set of wrapper functions, you shouldnt' have to worry about that logic again. You can then still fall back on thinking about things in rectangular blits. Another option I haven't investigated much is the use of the Sprite object. I don't know much about it, but it's a commonly used object in D3D that's used to let you wield 2D images. In fact, the Sprite object might serve as the 'wrapper class' I mentioned above. Anyway, the only reason I'm being so verbose about this is that I really wish I would have started my project in Direct3D, even though it would have set me back a couple of weeks. Now, I'm deeply reliant on DirectDraw and it'll be even more expensive for me to do whatever I have to do to make alpha-blending work. -Hiro_Antagonist

I would probably approach it differently. I would have the crosshair on its own surface/graphcis object, and then blit that over to the desired X/Y location each frame. No matter how you do it, you'll probably have to rebuild your primary surface from its component layers each frame, otherwise you'll have residue from previous frames sitting around. -Hiro_Antagonist

thnx for posting this. The font stuff isn't as straightforward as I expected, and you saved me the time of having to look it up myself. =) -Hiro_Antagonist

Well, you can't do alpha-blending w/ DirectDraw. It's a fact, and it's unfortunately true. However, there are some alternatives using other technologies. Here's a really really really slow method, but it'll work if you just need to alpha-blend something that you can cache and use the result over and over again: http://www.xtremedotnettalk.com/showthread.php?s=&threadid=80726 I've also heard that D3D7 surfaces are fundamentally the same as DirectDraw 7 surfaces, which supposedly means that you can use D3D7 to apply alpha-blending to your DD surface. (BTW -- You're using DirectDraw 7, not DirectDraw 9 -- they haven't updated DD since version 7.) I haven't personally verified this yet, but my development partner is right now looking into this for our own use. I'll post if/when it's possible, but it'll probably be a couple of weeks at least before I know. What most people say to do is to just learn to use Direct3D, even if you're using a 2D app. From my understanding, your performance will be better and you'll have more 'tricks' (like alpha blending) at your disposal. There are ways to use D3D so it's not too awkward doing 2D, especially if you write your own custom wrappers that only do what you want. I kind of wish I'd gone that route, but alas I've got a pretty big codebase now all relying on DD. So, I'm hoping that D3D7 surface thing works out -- otherwise, well, I might just have to rewrite my entire graphics engine in D3D9. =P -Hiro_Antagonist