From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by yquem.inria.fr (Postfix) with ESMTP id 0A2BCD55E for ; Thu, 28 Jul 2005 01:20:07 +0200 (CEST) Received: from ptb-relay03.plus.net (ptb-relay03.plus.net [212.159.14.214]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id j6RNK6pZ004569 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Thu, 28 Jul 2005 01:20:06 +0200 Received: from [80.229.56.224] (helo=chetara) by ptb-relay03.plus.net with esmtp (Exim) id 1DxvBv-0007Zi-KZ for caml-list@yquem.inria.fr; Thu, 28 Jul 2005 00:19:59 +0100 From: Jon Harrop Organization: Flying Frog Consultancy Ltd. To: caml-list@yquem.inria.fr Subject: Re: [Caml-list] Games Date: Thu, 28 Jul 2005 00:17:54 +0100 User-Agent: KMail/1.7.2 References: <1122484910.6768.133.camel@localhost.localdomain> <200507271413.41026.pal_engstad@naughtydog.com> In-Reply-To: <200507271413.41026.pal_engstad@naughtydog.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200507280017.55293.jon@ffconsultancy.com> X-Miltered: at nez-perce with ID 42E816A6.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; caml-list:01 o'caml:01 minor:01 minor:01 ocaml:01 low-level:01 simd:01 byte:01 alignment:01 low-level:01 ocaml's:01 unboxed:01 threading:01 renders:01 threads:01 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.0.3 On Wednesday 27 July 2005 22:13, Pal-Kristian Engstad wrote: > I've been looking into O'Caml, and I've written some tools > in it (caml is great for tools), but here's a couple of points > against it: > > 1. It doesn't support console platforms. > - The PC market is quite minor compared to consoles. =46irstly, the PC game market is minor compared to consoles in terms of=20 industrial profits. However, the console market is minor compared to the PC= =20 market in terms of the number of programmers. Secondly, what would it take for OCaml to support console platforms? > 2. It doesn't support low-level constructs. > - No SIMD (AltiVec/VMX) vector operations. > - No explicit assignment of (bit and byte) offsets > within a record. > - No explicit alignment specification. > - No inline assembly. =46rom my point of view, making a statement that that about ML really makes= me=20 think that you're pointing in the wrong direction. ML is all about _not_=20 exposing such low-level constructs. I think you should try forgetting about all of the subpoints you've made he= re=20 for a mini project (if you're interested in persuing this) just to see how= =20 important they really are. > 3. There is no controlled real-time GC. > - GC needs to run between frames, > and only for a controlled amount of time. OCaml's current GC is good enough for games, IMHO. > 4. There is no real support for unboxed data-types. > - This one is actually very important for consoles. Can you explain why this is particularly important for consoles? > For game-code (AI, behaviors, etc.), it is better suited, > though the GC issue is there. But it doesn't support much > of threading - be it through pthreads or cooperatively - > which renders it unusable to us. I know very little of threads but I believe your assertion is incorrect. I'= m=20 sure someone more knowledgeable than I will clarify... > So in the end, ... ocaml is nice as a tool, but it is by far > not usable for the game console world. So, I guess we'll stick > with C++ for a while... Your statement about OCaml's current suitability for games console programm= ing=20 is subjective. I think it would be more productive to try to objectively=20 state what work needs to be done in order to make OCaml suitable for games= =20 console programming. My guess is that you "only" need low-level bindings fr= om=20 OCaml to whatever library is exposed. Writing these bindings will probably = be=20 a lot of work though. Then it is a case of "suck it and see". As I say, I think you'll find that = the=20 GC is irrelevant. However, you may be correct about alignment issues etc., = in=20 which case you will need to move code from OCaml to C. That still leaves=20 plenty of interesting high-level code that can be productively written in=20 OCaml. However, I (and I don't think Skaller) was talking about games consoles. I = was=20 thinking (and gave the example of Darwinia) of the much larger number of=20 games that are written for fun, often by people in their spare time, for=20 desktop computers. I think there is a market here for educational material = to=20 teach these people how to program games more easily by using OCaml instead = of=20 C++. I'd bet that Darwinia, for example, would have been much easier to wri= te=20 in OCaml. I agree that OCaml is currently much better suited to this than t= o=20 consoles but consoles aren't everything... =2D-=20 Dr Jon D Harrop, Flying Frog Consultancy Ltd. Objective CAML for Scientists http://www.ffconsultancy.com/products/ocaml_for_scientists