Miguel de Icaza Calls For More Mono, C# Games

[curaga]

(editing still broken in Opera)

Also when there is an example on the MSDN page, it usually doesn't explain anything. Most times I've had to google for how to use things, and it's stackoverflow not MSDN that gives a good answer.

[BlackStar]

I disagree, in the last few weeks I've found MSDN to be lacking compared to the usual man pages (man2/3). It usually has "this thing can do things" and a dozen links to subpages that say the same for the methods of the class. The man pages have proper descriptions, examples, and usage info.

The manpages are references, not documentation - but that distinction aside, let's test your assertion.

man DoesSaveUnders
The DoesSaveUnders macro returns a Boolean value indicating whether the screen supports save unders.

That's... not really helpful at all. What's a "save under"? Well, tough, no mention of that in the manpages.

Let's try something else:

man XScreenNumberOfScreen
The XScreenNumberOfScreen function returns the screen index number of the specified screen.

Oh really? How about saying something useful like, for instance, what is the acceptable range of screen indices or possible error conditions? Documentation isn't about stating the obvious, it's about documenting expected behavior.

And it's not just the odd function or macro, the whole Xorg manpage package is filled with such gems. I swear, finding a function that's properly documented requires a goddamn divine intervention! And we are talking about Xorg, the core of every single effing graphical Linux/Unix distro, being an essentially undocumented mess! Not only that, but internet searches don't bring up stackoverflow or anything, but random unanswered mailing list questions with obscure references to dead tree books - of all things.

This problem is not by any means specific to Xorg. Outside of common terminal commands and the kernel, proper documentation is quite scarce. OpenGL manpages? Less than 20% coverage, and with frequent mistakes and typos (apparently misconverted DocBook/MathML). OpenAL? Slightly better.

That's really not something you see in MSDN.

Certainly could be I've only stumbled upon the spots you mentioned. I doubt that's likely.

You might have hit a weak spot, but that's not something that happens often. Thing is, the MSDN documentation is actively maintained by Microsoft employees and the community. We have side-by-side versions for each Visual Studio release, ranging back to VS6 (1998 or so). APIs such as as Direct3D and XAudio are meticulously documented with explanations, code samples and tutorials. The documentation covers everything under the sun, from games/xbox/mobile/desktop/web to kernel drivers - with all information concentrated on a single, indexed location.

Balmer may be a nutjob, but he really meant that "Developers" chant (clicky).

[curaga]

Yes, the X man pages suck, I heartily agree there. On the GL docs, I've only used the web ones, and the formulas are broken in all of them.

[BlackStar]

Yes, the X man pages suck, I heartily agree there. On the GL docs, I've only used the web ones, and the formulas are broken in all of them.

Make sure you use a browser with MathML support, i.e. Firefox or Opera. Chrome and IE9 don't support MathML, so they won't work...

[makomk]

The CLR doesn't completely do away with memory problems. I monitor VMs running a mission-critical legacy application written in C# that starts off using ~70MB of memory and can bloat out to 1.5GB if it hasn't crashed for some other reason.

Not just that, but at least historically speaking some code used to run fine under Microsoft's .Net CLR but leak memory like a sieve under Mono. In particular, there's a open source clone of the Second Life servers called OpenSim that's written in C# and it was unusable under Mono for ages. Miguel de Icaza helpfully investigated and accused the developers of spreading FUD because in his tests - which involved starting the server up but not actually connecting any clients to it or using it - Mono used less memory than Microsoft .Net. This was of course both true and completely useless. I think the OpenSim developers eventually tracked it down to the fact that Microsoft's .Net implementation could garbage collect certain threading-related resources safely but Mono required them to be manually freed.

The manpages are references, not documentation - but that distinction aside, let's test your assertion.

man DoesSaveUnders
The DoesSaveUnders macro returns a Boolean value indicating whether the screen supports save unders.

That's... not really helpful at all. What's a "save under"? Well, tough, no mention of that in the manpages.

You really don't want to be programming directly against Xlib anyway.

[blackiwid]

So what you bring here with such xorg-docu and so on, thats what I mean with modular, some stuff in linux and in the long run all stuff in linux gets better and better, but you never get a refactor everything at the same time action. So we see the msdn docu is better than the worst docu of linux stuff and way behind looking against the better stuff.

As a developer-beginner I was happy about the docu I got in Java the class-references, so you had anything to bring something alive, able to do what you want, but you dont think of all catches and you dont make it perfekt or even nearly perfekt the first time you develop it. So you can learm by getting errors or stuff and make it bit for bit better so you have after 5-10 refactorys everything right. The same is with the msdn docu they look the same.

When you instead get examples you have something that somebody programmed and thought about it some times so its not the basic it does somehow work, its a way better startpoint, there is stuff done around it that makes sense in 99% of the cases, so you maybe have only have to refactor 1 or 2 times if not zero times.

python doku are mostly good examples so this docu is way better

mono is a bit cracy exception maybe, because normaly the development structure is mostly clearly definied by the lisense and the structure who programms it. So if you have a company you get some monolitic stuff that has nearly the same midlevel quality everywhere, so no really sucking quality also thats good. but then you also have mostly some problem with lisences and if not that then with community-integration (Openoffice as example), in free projects you cant make such syncronized projects who have very strict conventions in each detail.

But mono is here on of the only exception I know, because they take the api from such commercial project and fill it with some implementation. So its a mixture of both modells. So if you somewhere want to start that it can only happen in this way. And we see that the open development-structure is more efficient they have less people less manpower but bring good stuff out anyway, as example look at libreoffice it gets faster more features and stuff than openoffice did ever theyr development modell is just better, timing releases instead of stupid feature releases where 1 shit feature that nobody wants can stall a release for 2 years, plus the openness so that whoever even differen companys can put in what they want (if its not total crap)


I heared that somewhere in the past, dont know who has invented that or if its proven by studies, but what I heard was, that "single people or small groups make often either extremly bad or extremly good work, bigger groups tends more to make medium quality stuff", because of that I think such modular creation works better because yes on some parts there come bad results but, if there are more than one group/persons who make such resolution someone will make a great resolution often. its more democratic not top-down only also.

[JanC]

Recently I have started to learn the Python language. So I'm a bit interested in it's speed as well.

I read some good things about Cython beeing much faster than CPython. But in it's current state it's probably still (heavily) developed and it's not officially a Python implementation (their FAQ).

Cython is actually a language on its own, which is more or less a subset of Python extended with a.o. static types and a compiler that translates it to C, which then in turn gets compiled by e.g. GCC. You can use it to extend Python with native compiled code similar to how you can use e.g. C, C++ or Fortran, but provides a language which looks a lot like Python and has niceties like automatically handling Python types.

Also there is the tool Freeze which creates C code out of Python. I would guess that it would be also faster than python interpreted programs. But like I said I'm not a experienced programmer. I have some C, C++ and now also Python knowledge, but nothing near expert knowledge.

This does not create C code from Python, it bundles a python interpreter and the (byte)compiled version of all source files in your program into one executable file, so that you can distribute it to other people without having to list what Python version they need, what dependency modules they need, etc.

[Togga]

I'm not a programmer myself, but as far as I know it is much simpler to create a game in C# than in C++ or C languages.

I'm a programmer and I can assure you that this simply is not true. It's amateurs argument by people blinded by marketing they cannot see through. In fact .NET comes with so much baggage that in the long run, your in for some deep digging you couldn't even imagine in the beginning. My recommendation is to avoid.

[darkcoder]

A simpler look at things

I saw people commented on things like performance of C# against X language, or difference in syntax or garbage collection logic. But things can be more easier and simpler to look from another perspective.

To code for games, specially multiplatform games you need to work on portable standards and AFAIK Microsoft C# implementation is exclusively for MS Windows. XNA Game Developer kit (the 3D addon) is based on DX which is again a Windows only product. Right now there is not a complete 100% implementation of either C# and XNA on Mac, Linux or Mobile. Mono is a nice project, but it came late on implementation due to be designed outside of mainstream.

If Microsoft really wanted to make C# a competitor for Java it should have made it open and multiplatform from day one. Addressing the issues the big Java user base had at the time, that need for an open implementation with native looking interface, 3D extensions, while being like Java a multiplatform language. Today with all that C# would be the standard (HTML5 dejavu). Sadly they missed the train.

The question now, which language is gonna add all that and bury both Java and C# for good.

[ChrisXY]

To code for games, specially multiplatform games you need to work on portable standards and AFAIK Microsoft C# implementation is exclusively for MS Windows.

What exactly does that mean?

Take manic digger (started as alternative minecraft client, is now trying to do some own things):

http://manicdigger.sourceforge.net

AFAIK it's written in c# and it runs great with mono.

Sure, it's not the most complex game in the world but it shows that it can work.

Right now there is not a complete 100% implementation of either C# and XNA on Mac, Linux or Mobile. Mono is a nice project, but it came late on implementation due to be designed outside of mainstream.

That's more to the point. But game devs don't seem to use the newest and greatest features much anyway... Seeing even so many AAA games are released as 32 bit binaries only...