On Fri, Apr 22, 2011 at 12:31 PM, Kai Meyer <k...@unixlords.com> wrote:
> 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.) > Actually, the world is 128 blocks tall, and divided into 16x128x16 block "chunks." To elaborate on the bit stuffing, at the end of the day, each block is 2.5 bytes (type, metadata, and some lighting info) with exceptions for things like chests. The reason Minecraft runs so well in Java, from my point of view, is that the authors resisted the Java urge to throw objects at the problem and instead put everything into large byte arrays and wrote methods to manipulate them. From that perspective, using Java would be about the same as using any language, which let them stick to what they knew without incurring a large performance penalty. However, it's also true that as soon as you try to use a 128x128 texture pack, you very quickly become disillusioned with Minecraft's performance.
