next »

[Zaphos]

Also correct me if I'm wrong, but I think XNA asks for 2.0 pixel and vertex shaders, not 1.1.

It's 1.1 in general, but some things do require 2.0
http://msdn.microsoft.com/en-us/library/bb203925.aspx

[Alex May]

Yeah the content pipeline is ridiculously complicated from an outside viewpoint, and not having taken the time to understand it (I have put in about four hours of work in trying to decipher it - clearly not enough ) I can't appreciate its simplicity from the inside It's one of the two major things (distribution being the other one) that stops me from using XNA.

That said I've always used OpenGL so I'm really happy using it with C#.

[lemmy101]

"If all you're doing is simpler 2D, this is IMHO going to be _more_ productive than XNA because you don't need to jump through all their stupid hoops regarding the content pipeline, you can keep it super-simple."

If all you're doing is simpler 2D, drag drop PNG/TGA/GIF/BMP etc into the solution. Go:

Texture2D tex = content.Load<Texture2D>("filename");

Woah! Some scary hoops to jump through there!

Also I think that entire diagram can be boiled down to:

Input file -> Processor for that input file -> output file. I REALLY fail to see where the nightmares are.

The content pipeline, if anything is the most dumbed down newbie proof thing ABOUT XNA, IMO.

Incompatibility issues, I'll concede is a big problem, but arguments about productivity or complexity against XNA hold absolutely no water, I'm afraid.

Also, if you fancy nightmares, try working on a PS2.

[Alex May]

The content pipeline, if anything is the most dumbed down newbie proof thing ABOUT XNA, IMO.

Incompatibility issues, I'll concede is a big problem, but arguments about productivity or complexity against XNA hold absolutely no water, I'm afraid.

If that's the case then the tutorials need to reflect that instead of obfuscating it into a scary thing.

When I was loading bitmaps in the way you suggest I was somehow made to feel as though I were circumventing the content pipeline and doing it all in the wrong way by not writing my own processors. And don't even start trying to teach me how to load in my own custom formats with this system! I took one look at that stuff and ran a mile - the tutorials need rewriting I think.

[dmoonfire]

I'm biased, mainly because I work on the Linux side of things most of the time (which means no XNA anyways since Mono.Xna never really went anywhere). I also inherited a OpenGL 2D library called BooGame that is written with C# on top of Tao.OpenGl (among other things).

I think XNA has a lot of potential, but for me it really suffers from lack of cross-platform functionality, which is normally a big thing for me (I ignored it for the demake, mainly because of time). That and I like OpenGL a lot more than most graphics platforms (but I'm getting comfortable with Irrlicht also).

Both libraries (XNA and Tao) are getting more polished as times go on. It used to be getting Tao working was a pain in the ass, now its mostly dropping the right DLL's in your bin directory (and the .config if you are on Linux, though I ended up writing a shell script to update the .config's). XNA, some day, will get to the same point, Tao just has a slight head start (and helps that it really has less features).

Tao has the drawback that it isn't CLS-compliant. OpenTk aims for that, and is pretty polished, but I find that OpenTk tries to do too much to really make me happy (to integrate BooGame into it).

[Robotacon]

I'm currently porting my 2D motor from XNA to SDL going from C# to C++ and the only reason for this is to get away from the horrors of the XNA prerequisites.

Developing with XNA is a blast in every other aspect and everything is real simple but I think most of that is because of C# which could just as well be Java or any other language with garbage collection. The content pipeline is child's play. If you ever need to touch any code there are loads of examples on how to process data that way.

Porting from one library to another is reeeeeeally boring but I still feel it's worth it at the end and if nothing else the engine gets a deserved polish after the massive sprint to get something finished for the demake competition.

[Zaphos]

I think the person who developed the xbox version of n+ actually used C# -> C++ as their development strategy; first they got it working in C#, then they ported it back to C++.  It makes some sense, although I doubt I'd have the patience to actually do the language port.

[r.kachowski]

What I'm hating about xna is the fee they charge to let you use your 360 as a testing platform. It's as if I have to pay for the privledge of providing them with content.

Also

* install .net up to required version for platform
* update DirectX
* install XNA redist
* update DirectX again.

Trying to get someone with little computer literacy to do this just so they can help you out with testing is difficult at best.

Having said that, if there was an official XNARequirementsInstaller.exe that contained everything it'd make it seem a lot less painful.

[theparticleman]

There seem to be two topics going on here, neither of which is the topic that Lemmy actually started.  I'll address the two active topics, plus attempt to contribute to the original one.

Topic 1 - C# as a (game) development language: I haven't used C++ for as long as lemmy has, but I have used both C++ and C#, and I can say that for almost anything I would take C# over C++.  It's faster, easier and I personally am more productive.  Some of it is the IDE and some of it is the language itself.  If you really need your app to be cross platform and Mono doesn't fulfill your needs, then of course look elsewhere.  With no malicious intent to exclude my Mac and Linux using friends, I personally figure that if my app can run on 95% of the computers in the world (talking .Net in general, not XNA in specific) then I'm doing pretty good (and Mono and virtual machines might make that percentage even larger).  Faster, easier development + runs on almost all computers = win for me.

Topic 2 - XNA as a game development platform: I'll be the first to admit that I'm no XNA guru, but I have used it a bit and found it extremely simple to take a 2D sprite and display it on the screen.  Maybe I just found better tutorials that some others here.  And I just did 2D stuff, so I can't speak for how the development of a 3D game would go.  Obviously XNA is no GameMaker in terms of ease of use, but for someone with programming experience who wants to get into game development it seems like a very powerful yet approachable platform.  XNA is obviously not the only choice and may not be the best choice in all situations, but I think it is a valid choice in a lot of situations.

Original Topic - XNA installation incompatibilities: It's unfortunate that Microsoft doesn't seem to be more concerned about installation difficulties like these.  It has a real potential to stifle XNA development.  Lemmy, I'm sure you've investigated this, but it's my only thought.  Have you tried making a VS deployment project?  I would think that Microsoft would have support for XNA in deployment projects, but I don't know.  That might be a more robust solution, if you're not already using that option.  That's the only thing I can think of, aside from having people install the XNA SDK, which would be a little ridiculous.


As an aside rant, please don't dismiss a programming language or development platform if you haven't used it (especially if you're just dismissing it because of the company that produces it).  All programming languages and development platforms come with tradeoffs.  If you're familiar with those tradeoffs I'd much rather hear about those than "Why are you using X programming language?  It sucks!"  Sorry for the rant.

P.S. Just thought of this, you might try asking about the installation problems on stackoverflow.com if you haven't already.  That's turning into a great resource for programming related knowledge.