On 04/22/2011 11:20 AM, Daniel Gibson wrote:
Am 22.04.2011 19:11, schrieb Kai Meyer:
On 04/22/2011 11:05 AM, Daniel Gibson wrote:
Am 22.04.2011 18:48, schrieb Kai Meyer:
I don't think C# is the next C++; it's impossible for C# to be what
C/C++ is. There is a purpose and a place for Interpreted languages like
C# and Java, just like there is for C/C++. What language do you think
the interpreters for Java and C# are written in? (Hint: It's not Java or
C#.) I also don't think that the core of Unity (or any decent game
engine) is written in an interpreted language either, which basically
means the guts are likely written in either C or C++. The point being
made is that Systems Programming Languages like C/C++ and D are picked
for their execution speed, and Interpreted Languages are picked for
their ease of programming (or development speed). Since D is picked for
execution speed, we should seriously consider every opportunity to
improve in that arena. The OP wasn't just for the game developers, but
for game framework developers as well.
IMHO D won't be successful for games as long as it only supports
Windows, Linux and OSX on PC (-like) hardware.
We'd need support for modern game consoles (XBOX360, PS3, maybe Wii) and
for mobile devices (Android, iOS, maybe Win7 phones and other stuff).
This means good PPC (maybe the PS3's Cell CPU would need special support
even though it's understands PPC code? I don't know.) and ARM support
and support for the operating systems and SDKs used on those platforms.
Of course execution speed is very important as well, but D in it's
current state is not *that* bad in this regard. Sure, the GC is a bit
slow, but in high performance games you shouldn't use it (or even
malloc/free) all the time, anyway, see
http://www.digitalmars.com/d/2.0/memory.html#realtime
Another point: I find Minecraft pretty impressive. It really changed my
view upon Games developed in Java.
Cheers,
- Daniel
Hah, Minecraft. Have you tried loading up a high resolution texture pack
yet? There's a reason why it looks like 8-bit graphics. It's not Java
that makes Minecraft awesome, imo :)
No I haven't.
What I find impressive is this (almost infinitely) big world that is
completely changeable, i.e. you can build new stuff everywhere, you can
dig tunnels everywhere (ok, somewhere really deep there's a limit) and
the game still runs smoothly. Haven't seen something like that in any
game before.
The random world generator is amazing, but it's not speed. The polygon
count of the game is excruciatingly low because the client is smart
enough to only draw the faces of blocks that are visible. The very
bottom (bedrock) and they very top of the sky (as high as you can build
blocks) is 256 blocks tall. The game is full of low-level bit-stuffing
(like stacks of 64). The genius of the game is not in any special
features of Java, it's in the data structure and data generator, which
can be done much faster in other languages. But it begs the question,
"why does it need to be faster?" It is "fast enough" in the JVM (unless
you load up the high resolution textures, in which case the game becomes
unbearably slow when viewing long distances.)
The purpose of the original post was to indicate that some low level
research shows that underlying data structures (as applied to video game
development) can have an impact on the performance of the application,
which D (I think) cares very much about.
