OOP, faster data layouts, compilers

[Kai Meyer]

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.