   Tool Creation
  I'm working on a game engine which has been going quite well, but now I'm wanting to write a tool to create a material file that defines what shaders a model should use, which textures to load for it and what shader parameters those textures map to. Simple enough I've got all the code done to write out the data from my material class and read it back in and it all works well. But now to my problem, how the hell do I create a front end to it all?!I've used "Windows Forms Application" before but it uses managed code which doesn't play nice with unmanged code like the code in my C++ game libraries which I need to use.I also just had a look into MFC but I can't seem figure out how to get even a simple button to work in that, and all the MFC tutorials I've found so far have been hopeless (and in several cases just links to virus infested websites :( ). It also looks as if the form designer is completely useless for MFC which is bloody annoying since Microsoft wrote both of them and if possible I'd like to avoid hours of "10 pixels up, compile, run, CRAP!, 3 pixels down, compile, run, CRAP!, 2 pixels left..." ect.Can anyone tell me how to create tool apps, or provide some links to good tutorials/examples of how to use MFC properly? I've never had any luck finding decent documentation on anything written by Microsoft :(   
Quote:but now I'm wanting to write a tool to create a material file that defines what shaders a model should use, which textures to load for it and what shader parameters those textures map to.I'd say look into scripting up your modeling tool. Whatever program (Maya,Blender,etc.) is already using shaders and such when the artist paints the model.  Add some extra information to the tool's shader (most support letting you add named attributes that export). This also has the benefit of WYSIWYG in the tool, since they also tend to already support (or have plugins that support) the major shading languages.Then, depending on your model pipeline, you'd either parse that extra information out of the model format, or create an export tool that does it when you save the file.   ;  I am also working on a game engine and I have written a tool for managing al kinds of resources, not just shaders and models, but also scripts, sounds etc. The game engine is written in C++ and Lua but the tool is written in C# using Windows Forms.As long as you don't need the tool to be bundled with the game itself you are free to write it in whatever language you want. The only requirement is that the tool can produce data files that the game engine can read. I my case, the tool writes Lua scripts and the game engine just parses these using the standard Lua interpreter, but you could just as easily write binary or text data files.So, my suggestion is, if you like .net and Windows Forms, just use those. You might end up having to write some duplicate code (eg. shader classes for both the tool and the engine), but it should not be that much work. Another approach is to use C++/CLI for the tool which is basically a managed version of C++. With it you can use your existing C++ classes and still use Windows Forms to make up the GUI.   ;Quote:Original post by KulSeranI'd say look into scripting up your modeling tool. Whatever program (Maya,Blender,etc.) is already using shaders and such when the artist paints the model.  Add some extra information to the tool's shader (most support letting you add named attributes that export). This also has the benefit of WYSIWYG in the tool, since they also tend to already support (or have plugins that support) the major shading languages.Then, depending on your model pipeline, you'd either parse that extra information out of the model format, or create an export tool that does it when you save the file.Yer that's the plan for later on, I've already hooked up a model exporter plug-in to 3DS Max (which is what I'm using for my modeling) that is exporting the geometry but the next bit for exporting the model requires me to put my material class in the model class and I just want to make sure everything works the way I want it to first so I have a good idea of exactly what I need to support in 3DS Max since I've not written a material plug-in for it before. I figured it'd be easy to test the material stuff works right first with an app that shouldn't take more than 10 min to write because all I need is to hook up a few input GUI elements to the stuff I've already written, but as is always my experience with Microsoft code it seems to be more trouble than it's worth :(.   