Starnick

If you want to stop being at the mercy of companies and their pet languages like XNA and C#, or Objective-C for Apple, then go with C++.

 

Well, other posters before me brought it out...but as a professional developer who happens to work almost entirely with C#/.NET technologies (for non-game development, although in a field somewhat related...CAD software), I take umbridge with that statement. It's very narrow thinking to lump a programming language in with a framework or to refer to said framework as a language. It's not the same, and frameworks have a much shorter lifespan than languages. C# has grown to be popular more on its own merits than because of XNA (certainly helped).

 

Maybe we'll find out if anything will replace XNA when the next xbox is revealed (late may I believe now?). When sony unveiled the newest playstation they said they wanted to support indie development, I'd imagine their competitor would want to do the same.

Usually you have two types of "formats":

 

The first category are the ones that are either built for data exchange (e.g. collada, FBX) or simply are source assets (like .obj) that can be read/written by different modeling tools. Many times those are verbose human-readable (text/XML) formats too. Generally these source assets need to be processed (triangulated...normals calculated...etc) in some manner and/or are slow to load because you're parsing XML or text rather than binary data.

 

The second category is the format that usually source assets get compiled into, and usually are binary and specific to your application/game. The idea is to do offline-compiling of source assets into this type of format so loading models at runtime would be very fast (e.g. compact binary data that is very close to the in-memory representation of your models).

 

For the Direct3D or OpenGL API's, there is no set "model format"...you're simply dealing with buffers of primitives (lines, triangles, etc), however you organize those are completely up to you. It can be as simple as each mesh piece is just a vertex buffer and an index buffer.

 

There exist libraries out there to do model importing into a general data structure that you then can translate to your own internal format, one such library that you can look at is the Assimp C/C++ library. If you're working in C#, you can take a look at the AssimpNet wrapper too.

XNA uses the FX (Effects) format which is basically HLSL + some extras (like technique/pass syntax), and it has been deprecated. VS2012 will only work (at least out of the box) with HLSL fragments.

 

So you have to create the FX file manually, add your vertex/pixel fragments and define your techniques/passes. Pass0 in technique RibbonShader point to the entry functions for the vertex/pixel shaders that will be used for that pass. In the HLSL fragment that was created by VS2012, main() would be your entry point for that fragment.

http://msdn.microsoft.com/en-us/library/windows/desktop/ff476380%28v=vs.85%29.aspx

 

Basically, Get/Set PrivateData is so you can associate application-specific data to the object, e.g. set a "friendly" name to it for debugging purposes.

There isn't an easy answer when it comes to XNA - as the content pipeline is more or less intended to be an "offline" process. Also, its much harder to distribute programs that use the content pipeline at runtime since the end-user needs the XNA game studio to be installed.

With that said, for PC XNA applications, there isn't anything stopping you from loading models at runtime. Its just a matter of processing the content yourself, without the content pipeline. E.g. loading a model and storing the geometric data into your own data structures (vertexbuffers/index buffers) that get rendered.

I believe in XNA 4.0 the only (major) roadblock will be for an effect, as there is no way to compile an effect at runtime without the content pipeline.

Very nice, I didn't realize you've released code for your toolkit (I heard mentions of it a while ago). But yeah, exactly the process that I've went with.

FYI, TinyPG produces code for a scanner/parser/parsetree, so there isn't any runtime dependencies. All you write is a grammer (e.g. terminals, production rules to parse and evaluate technique/pass expressions, etc). It's a lot simpler than writing out your own parser by hand.

Scrapping things entirely may not be necessarily true. If you're aiming to make "Metro"/Windows Store apps, you will need to forgo the use of the effects API as the D3DCompiler is one of the "banned API's". Of course, the only managed D3D wrapper that supports Win8 is SharpDX, so it's a moot point for SlimDX.

And even then, you can still use the FX file format - the difference is you'd have an offline compiler tool that parses the format for techniques/passes in order to acquire the necessary shader profiles + entry points. So with the profile/entry point in hand, you can run the FX file through the D3DCompiler to get a ShaderByteCode object for each shader, then use that to create a reflection object to query all your meta data. Then write out the reflected meta data to a file, that gets consumed by your application at runtime - which would be your own implementation of Effects11 (or something completely different, either way...you use the meta data to automatically setup your constant buffers, bind resources, and manage the shader pipeline by directly using the Direct3D11 shader interfaces).

For parsing, you can use something like Tiny Parser Generator, which is a really neat little tool if you know how to create a grammar. This is a problem that I've been working on myself for my own software and the approach has been working out pretty well (and frankly, I love TinyPG). I also believe the MonoGame folks have adopted this method, so that may be a good place to gather some ideas.

FYI, to answer your original question about how to use an effect with shader reflection - you can get at the shader byte code via the effect pass (the shader descriptions, which are queried from the effect shader variable the pass contains), which you would use to create a shader reflection object. Even if you were using the effects framework, that's still a useful thing to do for other reasons, like constructing input layouts up front. From that reflection variable, you're able to query for other things, like constant buffers, and get information about shader variables and their types (class, size, members, etc). But of course, you don't really need to do that as most of that information is readily available in the effect descriptions anyways.

You're not alone regarding XNA's future, but its just an API, like the other posters said, do not equate that to the C# language. No one has mentioned SharpDX, but right now that seems to be the best choice for writing C# Win8 apps that take advantage of the new metro/windows store app style, directx 11.1, etc.

Here's another quote -

"Those who do, do. Those who can't, teach".

Not to throw a shoe at all academics, as some do great research. But there are those bad apples that just leave a bad taste in your mouth when you leave school.

Tools like debuggers help to shift through all the noise and pin point whats breaking and blowing up. That's not "lazy", that's being "smart".

When I said something along these lines to him, his reply was "What you call smart, I call lazy."

To be completely fair, I told him that using a debugger helped me with a lot of null references when I was trying to handle data from files that somehow never loaded up during runtime (something I've always thought was a fairly common, small mistake people make), and his response was that those situations rarely arise for him. To me that seems like a questionable claim, but again, I'm just a beginner. Furthermore, he said that he just uses error messages to let him know whenever something goes wrong. But isn't that in itself a flawed idea to begin with? Since you only put error messages where you expect errors to occur, when a problem pops up in an unexpected place your error messages won't mean anything.

In these situations I struggle to know when to be adamant about my point or open about the fact that I could be totally wrong.

Maybe he thought the problem was overblown, e.g. you should be checking if the data is there or not when you initially load up that resource. Either throw an exception or log an error. That then can get tricky, because do you simply cease execution or do you have a "MISSING" default resource that gets used. In my opinion, just blowing up or simply not showing anything (depends on the type of resource...I'm thinking in terms of some graphic resource here) is a bad idea as it doesn't help the developer pin point whats missing or at what point it was found to be missing without requiring the person to dig into the code.

Error messages (codes) vs throwing and catching exceptions is pretty hot debate among most people. At least in my office, its a nearly a religious argument between some people.

That's just plain arrogance there. Either that, or stupidity.

The whole point of an IDE that has great debugging capabilities is to make a programmer more productive. Its a tool in your toolbox (as the previous poster beat me to that analogy). Does this professor consider re-using code as being lazy?

Most commercial software is pretty big - hundreds of thousands of lines of code if not millions, usually with many complex layers. Tools like debuggers help to shift through all the noise and pin point whats breaking and blowing up. That's not "lazy", that's being "smart".

This ties in with what SiCrane recommended - a nice way to think about organizing interfaces is to divide them up by a specific job or responsibility. Your case of an "IPositionable" is a great example, as you may have many entity components that all have a position but when you're checking if a component is within range of an explosion you don't really care about if its a health component or whatever. Another example would be if all of your components had a name to identify them, and you have an interface "INamable" with a string property called Name. This way you don't have to worry about a dozen different entity component interfaces, when you only care about a specific function that is all common to the type of component you want to modify, which can make for a neater and more consistent design.

As the other posters mentioned, inheritance rules are different for interfaces compared to classes (concrete or abstract). The nice thing about abstract classes though, is you're able to implement logic that is common to all subclasses, while leaving more specific implementation details up to those subclasses. So both have their pros and cons.

Hi Folks,

Importing content is always a big thing, I'm sure XNA, SlimDX, or SharpDX users may appreciate this:

AssimpNET - Managed wrapper for the Assimp import library.

The wrapper currently covers the entire C-API that Assimp exposes.

If you use the content pipeline in an application, whoever wants to use that app has to install the full XNA game studio and not just the redristributable (e.g. what you download as a developer to create your app). So it's doable and probably more convienent than rolling your own content pipeline.

The latter of course is possible, but you have to do a lot of things yourself...e.g. read the source content files, parse the data, and load that data up in your own data types (e.g. believe you'd have to roll your own Model classes, stuff like textures would be easier but you'd have to do the image processing yourself). The potential sticky area would be with shaders since you do need the XNA content pipeline to compile those.

Yeah there's really not much of an equivalent to OGL immediate mode. As the previous poster said, DrawUserPrimitives is your closest bet, but at the minimum you need to specify your geometry in an array (probably do not want to keep recreating this as you're drawing your bones on the fly, instead create one and resize it when needed).

This is where something like "VertexPositionColor" comes in handy as that's a structure (and XNA has several such) that describes all the attributes (position, color, etc) at a single vertex. But basically behind the scenes, DrawUserPrimitives is still just a vertex buffer, one that is dynamic and circular (so the resource is enabled to be written to once a frame, nor is it re-created every frame if it runs out of space).

The answers to those questions can vary greatly and usually there isn't a right answer. Answers are highly subjective and tend to be based on what you're trying to do.

• I guess assets should be as low-poly as possible. So when is a Mesh/Model considered low-poly? Or do I just have to adjust the Models to the performance of my Editor?

One possible triangle count I've heard for onscreen characters (think player models in Team Fortress 2...or any shooter) are in the 2-3 thousand triangle range. But this really depends on what you're trying to do in your scene (e.g. LOTS of moving highly detailed characters) and what the object is. An ammo crate for example, that you run over in a FPS game should not be as highly detailed as the weapon your character is holding. Using another TF2 example, the weapon that your guy holds in the game (called a "view model") is a lot more detailed than a weapon you see on other players, because that model is right in the player's face all the time. So if you have content in your scene that may just be background fluff, you want that to be as low detail as possible because then the player might not notice or care because they're not prominent/high interest objects.

Sometimes its also an illusion, where you have a wall that's literally several triangles, but the player can't go beyond it so there's nothing beyond it (because there doesn't need to be anything beyond it) so from the perspective of the player it's a complete structure, but if you go outside where the player can't go, it's not.

This is also another thing with lots of games, where they have some sort of triangle budget they try to define up front. In a TF2 game you're generally in a closed environment with a set limit of characters running around. So you only have a handful of highly detailed objects, and a somewhat detailed map, and props that can range from tens of triangles (e.g. structures in the distance, outside the map bounds...) to hundreds of triangles or thousands of triangles if its a highly detailed point of interest that is very rare. This may or may not fly right in say a MMO where you potentially can have hundreds of highly detailed characters in the same area...

• What other Information should be saved to the Models while it still is in the modeling software (3Ds-Max, in my case)? Materials, Light...?

It depends on your model format. If you're working with 3DS, the default FBX (or X I guess..) model loader I don't think will do anything with cameras or lights in your scene. But basically it'll convert materials, node hierarchy (XNA seems to lump these in with "bones" to describe hierarchical transforms), as well as animations, that all can be used by the default XNA model. In XNA 4.0 you also get built-in animation.

However, you -may- want stuff like lights also imported (e.g. using 3DS as a sort of a scene editor), but you're going to have to tweak the XNA content pipeline for that I think.

• How to choose the right scale for the Models? What is a reasonable size for models which are later loaded into xna?

This varies a lot. Some modeling tools don't actually have a notion of meters or feet, just "units"...whatever they are. Some editors like 3DS do have a notion of working in feet or meters, but XNA doesn't have any idea what units are. A position at (3, 10, -5) has no implied meaning, except what you make it as. E.g. Every "unit" is a foot or a meter (so (1,0,0) is one foot or meter along the positive X axis).

Generally to help keep scale, you use a reference. E.g. say you define a character to be Y in height, and when building level geometry, you place that character and ensure your doors/hallways are just right. For another TF2 reference, say you're making a hat for one of the player models, the common way to do that is to import the player model into your modeling tool, and build your hat geometry using the character's head as a reference.

This of course means if you're loading assets from different sources, you will encounter a variety of scales. Some will have huge scales, others small scales.