Biggest Issue with D - Definition and Versioning

[Manu]

On 15 January 2012 19:42, Kiith-Sa <42 at 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 :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20120119/668b89e2/attachment.html>