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

I'm trying to save the contents of a Bitmap object to a MemoryStream object. This works fine when I run it under Visual Studio, but if I just double-click on the .exe, I get the following error: ---------------------------- System.Runtime.InteropServices.ExternalException: A generic error occurred in GDI+. at System.Drawing.Image.Save(Stream stream, ImageCodecInfo encoder, EncoderParameters encoderParams) at System.Drawing.Image.Save(Stream stream, ImageFormat format) ---------------------------- Here's my code: ---------------------------- Bitmap __tempBitmap = new Bitmap(width, height, __tempBitmapData.Stride, System.Drawing.Imaging.PixelFormat.Format8bppIndexed, __tempBitmapData.Scan0); __loadedFileBitmap.UnlockBits(__tempBitmapData); __tempBitmap.Palette=__tempPalette; Stream __tempStream = new MemoryStream(); __tempBitmap.Save(__tempStream, ImageFormat.Bmp); ---------------------------- The __tempBitmap.Save line is where it chokes. Any help would be appreciated. -Hiro_Antagonist

When you blit, you can just specify your destRect to be a different size than your srcRect, and it will "Stretch-Blit" automatically. However, on hardware-accellerated machines, it will anti-alias the image it puts in the destRect, and there's absolutely nothing you can do about it. This may be good for you, but it's very bad if you're trying to enlarge the image and use a transparency background color. (You can see on http://www.xtremedotnettalk.com/t80676.html what happens when you do this.... My enlarged archer icon on the right ended up with a purple halo because of this anti-aliasing...) -Hiro_Antagonist

Hey all. 2 seperate but related issues: 1) Is there an easy way to load a .gif onto a surface? (I have no trouble loading from a .gif embedded resource, but when loading from a file it chokes. The DD documentation seems to indicate it only natively can handle .bmp's...) 2) I want to populate the .Palette property of a surface with the palette that was defined in the image file (.bmp or .gif -- either one.) Anyone aware of an easy way to populate SurfaceInstance.Palette with the appropriate palette? (I want to load the palette for a surface so I can change a few designated colors/palette_entries in the image before blitting it to the main surface.) Any help would be greatly apprecaited -Hiro_Antagonist

Glad to be of service. =) -Hiro_Antagonist

I sincerely doubt that DirectDraw will ever stop being suported under Windows. I think that we'll see it always supported in a kind of 'emulation mode', even if/when the primary OS is built from the ground up on D3D. Microsoft has an internal design philosophy these days of retaining backwards compatibility. Given that DD is a relatively thin but valuable technology, maintaining support for DD (at least in terms of keeping it running under Windows) should be relatively easy. I think that if DD best suits your needs, then you should feel comfortable developing with it. I expect it will be supported indefinitely just like DX1 is still supported today and just how DD (not otherwise touched since DX7) was updated to run under managed mode in DX9. -Hiro_Antagonist

It looks like you've got just about everything, but when you draw your knight, try this: primary.Draw(destination1, knight, DrawFlags.Wait | DrawFlags.KeySource); My understanding is that the DrawFlags.KeySource flag tells the Draw() function to use the transparency you set up with your ColorKey. Hope that helps. -Hiro_Antagonist

well, I believe that if you're using the MS Installer for a .NET app, there's a way to get it to easily and transparently install the .NET 1.1 framwork as part of your installation experience. (I'm not sure of the specifics, but I crawled through the MSDN documentation and including .NET Framework with a .NET app install is supposedly an 'easy-to-use feature.') You can also package the DirectX 9.0b Redistributable with your product, and then manually add hooks into your installer to install the managed run-time components. Or, if you want the DirectX managed components installed more silently (and probably as a smaller distribution package), you can get the silent installer from MS by signing up as a MVLS. This has already been covered a bit in (http://www.xtremedotnettalk.com/t80725.html), but I don't think it got fully resolved there.... Hope that helps. -Hiro_Antagonist

Well, I'm not sure how to actually code it, but I do know that alpha-blending is speficially to achieve "partial transparency". By definition, the alpha value of something is hot transparent it is. Using graphic formats like PNG, I believe each pixel can be given its own alpha value. 255=opaque 127=50% transparent 0= transparent Hopefully someone else can tell you how to actually apply it in Direct3D. That's beyond my knowledge... =P -Hiro_Antagonist

You want to use alpha-blending, I believe. I'm thinking about rewriting my entire graphics engine to use Direct3D instead of DirectDraw, just for the alpha-blending. I want it that much. =( -Hiro_Antagonist.

Are you sure your users are installing the *managed* directX components, after they've definitely installed .NET 1.1? Using the process below, I have had no problems (or reports of problems) getting C#/DX apps to work on run-time (non-dev) machines. The main 'gotcha' here, as far as I can tell, is that DirectX9.0 does not automatically install the Managed components, which is a really pain, if you ask me. So you have to manually run "<location of directx files>\dxsetup /installmanageddx". (These were also included in another post recently, but I'll put them here again for completeness.) Just to be clear, THESE INSTRUCTIONS SET UP A RUN-TIME (non-dev) MACHINE TO RUN .NET 1.1/MANAGED DIRECTX 9.0b APPS. However, THIS IS NOT A PUBLIC, DEPLOYMENT-READY PROCESS. (These instructions are too clunky to expect paying customers to follow them.) If you want to distribute your app to (potentially) paying customers, you'll have to figure out how to smoothly integrate the .NET 1.1 and Managed DX9.0b installs with your own installation process. I haven't worked through that yet so I can't really help there. ----------------------------------------------------------- Basic Steps: 1. Install .NET 1.1 Framework 2. Install *managed* DirectX 9.0b 3. <Install/run your app> ----------------------------------------------------------- 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. -------------------- 3. Run <your app> -------------------- 1) have them download, extract/install, and run your app.