I have a .dds file and I want a .png file. Although I already found out about the DevIL.NET library, the API design there of one static class does not parallelize, so I am hoping to find another method. This led me to XNA.
But, here's how far I got with that idea...
OK, it looks like I want this Texture2D class; then I can call myTexture2D.SaveAsPng.
But how do I get one of those from my .dds file? Well the documentation seems to indicate I want to use myContentManager.Load<Texture2D>.
Oh crap, that wasn't it, that's some kind of game content management system. Well, my searching seems to have turned up a lot of uses of myTexture2D.LoadFile; I'll go for that.
Uh am I missing an assembly reference or something? Oh no, I get it, they removed that method between 3.1 and 4.0, awesome. OK, well, it's a bit more annoying, but myTexture2D.LoadStream isn't really a problem.
Wait what's this now? It wants a GraphicsDevice? Hmm it looks like one usually gets one of those via a GraphicsDeviceManager... oh wait, I'm not going down that path again, no more Managers for me.
I guess I'm supposed to instantiate this thing manually. OK well this isn't too hard... var myGraphicsDevice = new GraphicsDevice(GraphicsAdapter.DefaultAdapter, GraphicsProfile.HiDef, (uh oh what is this PresentationParameters thing well OK I'll just try new PresentationParameters());.
Well that threw an exception. They want... a DeviceWindowHandle in my PresentationParameters? BUT I'M RUNNING A CONSOLE APP!!
So I'm really hoping there's a less convoluted way of doing this; perhaps some kind of default GraphicsDevice I could use. It feels pretty silly to create a whole window just to convert .dds to .png.
Alternative suggestions for my conversion problem welcome, I guess, although it would probably be worthwhile to understand how to use XNA from non-XNA code in general.
If you have a command line app that needs to create an XNA graphics device, the code in this answer should be of some assistance.
In a nutshell, you need some of the classes from the WinForms sample to avoid having to mess around creating a graphics device services and so on (specifically the classes ServiceContainer and GraphicsDeviceService).
Then you can do this:
Form form = new Form(); // Dummy form for creating a graphics device
GraphicsDeviceService gds = GraphicsDeviceService.AddRef(form.Handle,
form.ClientSize.Width, form.ClientSize.Height);
ServiceContainer services = new ServiceContainer();
services.AddService<IGraphicsDeviceService>(gds);
content = new ContentManager(services, "Content");
Tada - now you have a working ContentManager that you can use to load stuff. I believe you should be able to get the actual GraphicsDevice from the GraphicsDeviceService, too.
The form you create is never displayed. Remember to reference System.Windows.Forms.dll in your project.
Disclaimer: This was written for XNA 3.1. I haven't tested it in 4.0, but I suspect it will work with little or no modification.
From the top of my head (haven't used XNA for a while):
Conversion of datatypes is not a common scenario for XNA. It expects to get all assets preprocessed by the content pipeline.
XNA expects the graphics device quite often, windowless applications are out of XNAs scope.
It seems to me that you are using the wrong tool for the job, although I couldn't tell another one except DevIL, which you already dismissed.
Related
I haven't found a clear-cut answer for if I can do this nor how to go about it. I'd like to allow my game to load additional MGCB into content managers, thus allowing additional content to be made after I release my game.
I've seen talk of building them on the fly, but nothing about loading them nor using them. If I missed this question being asked and answered elsewhere, please feel free to correct me.
My initial solution was to just not use the MGCB content pipeline at all, and replacing it with an uncompressed zip structure similar to the classic "pak" concept games have used in the past. I fear inefficiency with that. I'd like to use the "native" content pipeline system if I can.
I'm going to go ahead and post my own answer to this, in case anyone else ever finds themselves pulling out their hair trying to resolve this. Everything will hint that you can do this, but there's no real, practical way to.
If you want to allow mods or additional content to be dropped into your game after the fact, you have to design your own content management system. It's easy with something like DotNetZip and a little out-of-the-box thinking, and despite my initial fears, if it's not faster than the MonoGame content system, it's certainly no slower.
I am trying to write a VST Host which basically should provide a better interface to control to Plugins at the same time. For that i looked searched for the best way to do it and stumbeld over VST.NET. Now i made this code to just simply open a plugin:
HostCmdStub cmdstub = new HostCmdStub();
VstPluginContext cont = VstPluginContext.Create("C:\\Program Files\\..\\Turnado.dll", cmdstub);
Logger(cont.PluginCommandStub.GetProductString());
cont.PluginCommandStub.Open();
(Code for the HostCmdStub taken from https://github.com/perivar/AudioVSTToolbox/blob/master/ProcessVSTPlugin/HostCommandStub.cs)
The Looger correctly logs Turnado so the dll seems to be loaded but nothing opens.
I don't really have any experience with VST.NET and my C# knowledge is also not that fresh. (If I could i would write the host in something like Java but there seems to be no good way to do so...also it seems not a good idea performance-wise).
Is there an obvious problem with my code or even a better way to create a host...I might even switch Programming language as i'm not that invested in the c#/VST.NET project yet.
I'm BRAND NEW to the whole C#/WPF thing. I have a decent understanding of the concept of the WPF layering and it is a very nice tool. What I am running into, however, is that VS and the like try to make things very hands-off as far as the underlying code.
When firing up a brand new WPF application in VS C# Express 2008, there are two immediately visible source files: App.xaml and Window1.xaml. This is all fine and dandy, but the only place I see any significance of where things start is the line in App.xaml that says
<Application x:Class="SomeName.App"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
StartupUri="Window1.xaml">
Looking into the class name of SomeName.App, I'm guessing that extending Application signifies that as where to start, but how does the application actually know that?
I am quite familiar with Java, so if it makes things easier to explain that way, please do. I like to understand things at the lowest level possible (without getting into machine code), so please help me get a bit deeper into the inner workings of C# and the WPF.
As always, thanks to the StackOverflow community for any help. :)
The concept you probably need to understand is that the tool-chain generates code from XAML files, which gives 'code-like' behaviour to the declarative XAML.
But WPF is pretty complicated and not much like anything else, and a book might be useful - personally I think the Adam Nathan WPF book is excellent, and will cover this "general understanding of the concepts" stuff much better than the Internet, IMO.
The generated app file will probably be called app.g.cs, and will be in one of the intermediate file directories - have a look in there to see the actual startup code - among other things, you'll find something like:
public static void Main() {
MyAppName.App app = new MyAppName.App();
app.InitializeComponent();
app.Run();
}
at which point it may start to make more sense.
In fact, you can write all that startup code yourself if you don't like the declarative route.
Creating a call stack diagram
We have just recently been thrown into a big project that requires us to get into the code (duh).
We are using different methods to get acquainted with it, breakpoints etc. However we found that one method is to make a call tree of the application, what is the easiest /fastest way to do this?
By code? Plugins? Manually?
The project is a C# Windows application.
With the static analyzer NDepend, you can obtain a static method call graph, like the one below. Disclaimer: I am one of the developers of the tool
For that you just need to export to the graph the result of a CQLinq code query:
Such a code query, can be generated actually for any method, thanks to the right-click menu illustrated below.
Whenever I start a new job (which is frequently as I am a contractor) I spend two to three days reading through every single source file in the repository, and keep notes against each class in a simple text file. It is quite laborious but it means that you get a really good idea how the project fits together and you have a trusty map when you need to find the class that does somethnig.
Altought I love UML/diagramming when starting a project I, personally, do not find them at all useful when examining existing code.
Not a direct answer to your question, but NDepend is a good tool to get a 100ft view of a codebase, and it enables you to drill down into the relationships between classes (and many other features)
Edit: I believe the Microsoft's CLR Profiler is capable of displaying a call tree for a running application. If that is not sufficient I have left the link I posted below in case you would like to start on a custom solution.
Here is a CodeProject article that might point you in the right direction:
The download offered here is a Visual
Studio 2008 C# project for a simple
utility to list user function call
trees in C# code.
This call tree lister seems to work OK
for my style of coding, but will
likely be unreliable for some other
styles of coding. It is offered here
with two thoughts: first, some
programmers may find it useful as is;
second, I would be appreciative if
someone who is up-to-speed on C#
parsing would upgrade it by
incorporating an accurate C# parser
and turn out an improved utility that
is reliable regardless of coding style
The source code is available for download - perhaps you can use this as a starting point for a custom solution.
You mean something like this: http://erik.doernenburg.com/2008/09/call-graph-visualisation-with-aspectj-and-dot/
Not to be a stuck record, but if I get it running and pause it a few times, and each time capture the call stack, that gives me a real good picture of the call structure that accounts for the most time. It doesn't give me the call structure for things that happen real fast, however.
We use the DesignSurface and all that good IDesignerHost goodness in our own designer. The designed forms are then persisted in our own bespoke format and all that works great. WE also want to export the forms to a text-based format (which we've done as it isn't that difficult).
However, we also want to import that text back into a document for the designer which involves getting the designer code back into a CodeCompileUnit. Unfortunately, the Parse method is not implemented (for, no doubt, good reasons). Is there an alternative? We don't want to use anything that wouldn't exist on a standard .NET installation (like .NET libraries installed with Visual Studio).
My current idea is to compile the imported text and then instantiate the form and copy its properties and controls over to the design surface object, and just capture the new CodeCompileUnit, but I was hoping there was a better way. Thanks.
UPDATE: I though some might be interested in our progress. So far, not so good. A brief overview of what I've discovered is that the Parse method was not implemented because it was deemed too difficult, open source parsers exist that do the work but they're not complete and therefore aren't guaranteed to work in all cases (NRefactory is one of those from the SharpDevelop project, I believe), and the copying of controls across from an instance to the designer isn't working as yet. I believe this is because although the controls are getting added to the form instance that the designer surface wraps, the designer surface is not aware of their inclusion. Our next attempt is to mimic cut/paste to see if that solves it. Obviously, this is a huge nasty workaround, but we need it working so we'll take the hit and keep an eye out for alternatives.
You could always write your own C# parser. That way you can be sure of it's completeness.
In your case, because you don't need anything like intellisense, you could probably get away with just using a parser generator.
Even if you wrote one by hand, however, it probably wouldn't take you more than about a month.
It's not exactly what you asked for, but you could try to use the CodeDomComponentSerializationService class to generate the CodeDom graph based on the current state of the design surface.
We use that class to handle copy/paste functionality in our built-in designer.