On 15 January 2012 19:42, Kiith-Sa <42@theanswer.com> wrote:

I'm interested in game development using D, so I'll post my opinion.

I think the discussions here show how particularly specialized people
here are. I've seen some Manu's posts and it was clear that he is a person
in gamedev who thinks most development is like gamedev and can't see the bigger
picture.

I just want to clarify, I don't think this is a fair call, but I can see why you might think that.

I am obviously a professional gamedev, and I am interested in D. I'm just trying to illustrate my case that, for me to consider D for professional/commercial use, there are some (rather small really) features that I need to do my job.

I can see the bigger picture, but I'm not a representative of any other part of it. I can only present, with confidence, important points that are important to my industry.

I expect other people from other industries to make sure their perspectives are heard and assure they're covered.

I'm certainly not trying to turn D into a gamedev language, I'm just trying to encourage proper implementation of some key missing features that support being used in the gamedev environment (and for performance oriented systems programming in general actually).

I think my single point that started this whole thing off was something to the tune of: "As a high end company, we could not possibly choose D for a high end title until this feature existed"

From then on, it was just discussing details, and backing up my claim.

For a gamedev person, SIMD support is not simply a cool feature, it's
a gamechanger. Just like const, ranges, D threading features and so on. However,
his posts often show that he doesn't understand positions of other people in other
areas, e.g. people here working on scientific computing, who are also interested
in SIMD but their thinking of terms such as "vector" is completely different.

I don't actually see how it really affects other users, except with library maturity, they'll see faster libraries too.

Non-SIMD/conventional vectors are already well defined in D. Science will need to deal with arbitrary sized vectors, and arbitrary sized matrices. This is a fundamentally different topic than raw access to the hardware instructions (something like 50% of the CPUs silicone (excluding cache) that sit there dormant in any D program to date).

A nice library for use in scientific computing should exist for that audience (if it doesn't already), and I'm sure it too can implement some nice efficiency gains by using the low level API I have been proposing under the hood.

What most people don't seem to understand is that the SIMD API I've been pushing for in D will NOT be used directly by almost anyone. It's too low level for general use. It exposes the hardware facilities for optimisation in the most efficient way possible to facilitate *library development*. This can be games oriented, physics oriented, scientifically oriented, anything. It's all about the libraries :)

I think you're making the same mistake here - you have very little (or no?)
idea about gamedev and aren't exposed to game programmers, so you just assume
specific gamedev issues don't exist or are unimportant. I don't think you get
much of exposure to game devs when evangelizing D either - you don't evangelize
D in game companies.

I support this point. We discuss D fairly regularly at work. Most people don't have the time or interest to involve themselves in the NG or IRC. I just like making a noise, and it's nice to see progress in a direction that supports us.

I realise you're actually arguing on my side of the fence in general, but I just wanted to clear those points up :)