C# and Managed DirectX Invalid Rectangle
-
Hello, I am an utter newbie with C# and DirectX. None the less, I'm determined to learn C# using Managed DirectX. I'm developing a stupid game to increase my nearly non-existant knowledge and I've hit a snag. Okay, two snags. I create a surface for a plane image, my background, back, and front. Since this is a windowed program, I can't just use normal coordinates for drawing and have to create a rectangle at the window's location (the picturebox I'm drawing to). So I create a rectangle for my plane and background and draw them to the back surface then finally to the front surface which is displayed. This works pretty well, except, when I move the window part-way off my monitor's screen, I get an Invalid Rectangle exception. I figure when my rectangles I'm drawing to extend off screen it throws that exception. Unfortunately, I have no idea what to do about it. I can catch the exception, but then what do I do with it? Surely windowed games don't all throw Invalid Rectangle exceptions when they're moved off the screen. There has to be something I'm doing wrong. My next problem is totally baffling to me. I decided I wanted to use System.Drawing.Bitmap's along side with DirectX since DirectX's Surface class supports that object. In my non-DirectX program I can simply load the image with myBitmap = Bitmap(GetType(), "bitmap.png"). No worries. But in my DirectX program, using the EXACT same settings, files, and resources it says it can't find "bitmap.png" resource in that class. This is driving me up the wall. The resouce is there! It works in my other program! There is -nothing- different. In my DirectX program I have to load the file with a different constructor: myBitmap = Bitmap("c:\bitmap.png") works. But... why?! Why won't it work the other way? Anyone out there that can help me? Especially evil today, EvilDingo
-
Hello, I am an utter newbie with C# and DirectX. None the less, I'm determined to learn C# using Managed DirectX. I'm developing a stupid game to increase my nearly non-existant knowledge and I've hit a snag. Okay, two snags. I create a surface for a plane image, my background, back, and front. Since this is a windowed program, I can't just use normal coordinates for drawing and have to create a rectangle at the window's location (the picturebox I'm drawing to). So I create a rectangle for my plane and background and draw them to the back surface then finally to the front surface which is displayed. This works pretty well, except, when I move the window part-way off my monitor's screen, I get an Invalid Rectangle exception. I figure when my rectangles I'm drawing to extend off screen it throws that exception. Unfortunately, I have no idea what to do about it. I can catch the exception, but then what do I do with it? Surely windowed games don't all throw Invalid Rectangle exceptions when they're moved off the screen. There has to be something I'm doing wrong. My next problem is totally baffling to me. I decided I wanted to use System.Drawing.Bitmap's along side with DirectX since DirectX's Surface class supports that object. In my non-DirectX program I can simply load the image with myBitmap = Bitmap(GetType(), "bitmap.png"). No worries. But in my DirectX program, using the EXACT same settings, files, and resources it says it can't find "bitmap.png" resource in that class. This is driving me up the wall. The resouce is there! It works in my other program! There is -nothing- different. In my DirectX program I have to load the file with a different constructor: myBitmap = Bitmap("c:\bitmap.png") works. But... why?! Why won't it work the other way? Anyone out there that can help me? Especially evil today, EvilDingo
Having only a little knowledge of DirectX I can only offer somethings I remember from long ago. In unmanaged DX there was a Clipper object that you had to attach to your window to ensure you didn't draw off the window (I assume the screen as well). Maybe that will help. Now the real reason I replied: EvilDingo wrote: in my DirectX program, using the EXACT same settings, files, and resources it says it can't find "bitmap.png" resource in that class. Refer to my Embedded Resources[^] article for more indepth information but I have a couple ideas off-hand. 1) Make sure you set the Build Action on your .png to 'Embedded Resource'. 2) Rather than using
GetType, usetypeof(MyType). When you later decide to derive a class from that one (maybe in another assembly or a different namespace) you'll eliminate any problems arising fromGetTypenow returning a differentTypeobject. James "I despise the city and much prefer being where a traffic jam means a line-up at McDonald's" Me when telling a friend why I wouldn't want to live with him -
Having only a little knowledge of DirectX I can only offer somethings I remember from long ago. In unmanaged DX there was a Clipper object that you had to attach to your window to ensure you didn't draw off the window (I assume the screen as well). Maybe that will help. Now the real reason I replied: EvilDingo wrote: in my DirectX program, using the EXACT same settings, files, and resources it says it can't find "bitmap.png" resource in that class. Refer to my Embedded Resources[^] article for more indepth information but I have a couple ideas off-hand. 1) Make sure you set the Build Action on your .png to 'Embedded Resource'. 2) Rather than using
GetType, usetypeof(MyType). When you later decide to derive a class from that one (maybe in another assembly or a different namespace) you'll eliminate any problems arising fromGetTypenow returning a differentTypeobject. James "I despise the city and much prefer being where a traffic jam means a line-up at McDonald's" Me when telling a friend why I wouldn't want to live with himJames, I really appreciate you repling to me because you tipped me off to my Rectangle Exception. There was no clipper associated with the back surface and that is what ended up causing all the trouble. I had been working on this problem longer than any programming problem I've had in many moons. I guess that's to be expected when learning a new language... :~ I read your excellent resource article and I have one question. When using embedded resources, does that actually include the image file in the executable? Or does there still need to be an external file distributed? Since I just worked out the drawing problem, I haven't tried loading a resource yet, but to answer your question, I did have it marked as an Embedded Resource in VS.net. Is there any benefit to using it as an embedded resource as opposed to just loading the image file with the filename string constructor? Thanks, EvilDingo
-
James, I really appreciate you repling to me because you tipped me off to my Rectangle Exception. There was no clipper associated with the back surface and that is what ended up causing all the trouble. I had been working on this problem longer than any programming problem I've had in many moons. I guess that's to be expected when learning a new language... :~ I read your excellent resource article and I have one question. When using embedded resources, does that actually include the image file in the executable? Or does there still need to be an external file distributed? Since I just worked out the drawing problem, I haven't tried loading a resource yet, but to answer your question, I did have it marked as an Embedded Resource in VS.net. Is there any benefit to using it as an embedded resource as opposed to just loading the image file with the filename string constructor? Thanks, EvilDingo
EvilDingo wrote: using embedded resources, does that actually include the image file in the executable? Yes, the file will be embedded in the assembly. You still need to keep the file around for building purposes, but you don't need it in order to run the application once built. EvilDingo wrote: Is there any benefit to using it as an embedded resource as opposed to just loading the image file with the filename string constructor? You don't have the extra file lying around so the user can't modify or delete it :) Aside from that I can't think of any technical reason for using an embedded resource, but usually not having the extra file lying around is enough for me to make it one. Sorry if some of this in incoherent, I was just on my way to get some sleep :zzz:
-
EvilDingo wrote: using embedded resources, does that actually include the image file in the executable? Yes, the file will be embedded in the assembly. You still need to keep the file around for building purposes, but you don't need it in order to run the application once built. EvilDingo wrote: Is there any benefit to using it as an embedded resource as opposed to just loading the image file with the filename string constructor? You don't have the extra file lying around so the user can't modify or delete it :) Aside from that I can't think of any technical reason for using an embedded resource, but usually not having the extra file lying around is enough for me to make it one. Sorry if some of this in incoherent, I was just on my way to get some sleep :zzz:
The CP Anonymous bug bites again ;P James "I despise the city and much prefer being where a traffic jam means a line-up at McDonald's" Me when telling a friend why I wouldn't want to live with him
-
EvilDingo wrote: using embedded resources, does that actually include the image file in the executable? Yes, the file will be embedded in the assembly. You still need to keep the file around for building purposes, but you don't need it in order to run the application once built. EvilDingo wrote: Is there any benefit to using it as an embedded resource as opposed to just loading the image file with the filename string constructor? You don't have the extra file lying around so the user can't modify or delete it :) Aside from that I can't think of any technical reason for using an embedded resource, but usually not having the extra file lying around is enough for me to make it one. Sorry if some of this in incoherent, I was just on my way to get some sleep :zzz: