This doesn't really answer your question but is there a reason why each individual pin is ~180 faces? That's a lot for something so primitive! You should be able to get something like that down quite substantially while retaining a decent amount of quality and that would reduce the load by an a large sum.
Why are you so desperate to hide your videos that you'd consider paying for internet video streaming to keep your users away from it? No matter what you do, users will figure it out. Even the encryption system you're using for your textures is very easily defeated.
If you're so concerned, just rename the file extension of the .wmv file to something nonsensical, perhaps changing a few bytes in the file to make it unplayable. Then restore it to its original form when you want to load the video in your game.
If you're not using the pipeline, is there actually a compelling reason to use XNA over other game APIs?
And to reiterate, I haven't used XNA since 3.0, and I don't remember the support for non-pipelined files being particularly good /at that time/.
Short answer: Certainly! Long answer: But it depends ultimately from person to person.
If you've been using unmanaged DirectX, the reasons might not be as compelling, but XNA conforms to the design of C#. The components like vertex buffers are designed a little more sensically (as of XNA4), things like render targets are easier to use, all of the boilerplate is already written for you, you already have access to good model and sprite rendering right out of the box, the effect framework is a bit easier to use. You don't need to worry about all the silliness like lost device handling, etc.
All that said, I have, myself, started moving towards SlimDX. Use the right tool for the job, everyone. XNA is a fantastic framework for DX9. But if you want to support 10 or 11, your only choice is SlimDX and that will likely never change until the next XBOX console is released and they intend on having an XBLIG on it as well (lets all hope!).
I didn't like XNA because of the content pipeline thing. Last time I used XNA -- which was awhile ago and not very extensively -- I felt like I was basically forced to compile all of my assets into the executable itself, which made user modification sort of impossible, which undercut what I was trying to do. Also rebuilding because I changed some sprite got annoying.
The content pipeline doesn't build content into the executable. It merely compiles the various files you put in it into an intermediate format readable by all platforms. All files are accessible to user modification if you write tools for them, and the 3D model format is actually FBX, which is heavily supported by various modeling tools. If you change any files inside the content project, you don't rebuild the whole application application. All it does is convert the single file you added to it, and nothing more.
You also don't need to use the content pipeline at all for the most part. The only time you actually need to use them is for effect files and sprite fonts.
Many people use XNA to write strictly Windows games to no ill effect. While XNA is designed to support WP7 and the 360, Windows is also a primary platform and functions just fine. The only difference are platform specific features of both WP7 and the 360 which are obviously unavailable on Windows (For example, xbox avatars on the 360 and touch input on WP7)
It's also worth noting that XNA is easier to learn and designed for your chosen language (C#). SlimDX is pretty much a verbatim wrapper for the native C++ libraries which carries with it some of the nuances and design choices that aren't typically dealt with in a managed environment.
SlimDX is an fantastic library, but if you are learning C# at the same time, I would recommend something higher level like XNA which takes care of most of the low level details. Once you get the hang of things and if you feel like you'd like more control over everything, you could certainly migrate to SlimDX.
Considering you mention an on-board chip on a laptop, I'm going to suggest that your hardware probably cannot load an image that large into video memory. You're looking at ~256 megs of memory just for that one picture, assuming a 4 byte RGBA texture format and no generated mipmaps. It would be entirely impossible to load ten of them, let alone one.
You'll either need to scale the images down to something far more manageable, or chop the image up into smaller fragments and only upload the ones to video memory that you can see on screen.
Don't quote me on this, but I think setting something redundantly may very well be optimized out when ran.
But honestly though, unless you're running this in a really tight high-performance loop or something (and really even if you are...), the difference is insignificant. I would likely go with the latter just as a stylistic choice.
The best solution is to include the redistributable that came with the version of DirectX you're using. You can also instruct your users to install using the Web Installer version (http://www.microsoft...&displaylang=en) and that seems to install all the D3DX libraries that are missing. Whenever I end up with a missing D3DX library for something I'm using, the web installer has fixed it for me.
Also make sure you're distributing the Visual C++ runtime for your version of Visual C++ if you're using Visual Studio.
Anyways, this is just for the new Reflector. Older versions still work just fine (assuming they didn't program a "self destruct" into the program, in which case that would be very questionable practices).
This is exactly what they've done. There has been 6 month timeouts on all versions since before Redgate purchased it. Once it times out in May, you must pay to continue using the program at all. This is also why people are not very happy with this turn of events, because people consider the new fee alongside the time bomb in older versions questionable. It was never about $35 because that is not a lot of money. It is the principle of what they are doing.
I haven't worked with D3D10 before but I assume it's similar to D3D9 in that rendering text will mess with the renderstates and not set them back after it's done with them. Make sure you're resetting the renderstates and all that before you draw your polygons.