From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id 57638D55E for ; Thu, 28 Jul 2005 02:04:15 +0200 (CEST) Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.86]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id j6S04EfW025845 for ; Thu, 28 Jul 2005 02:04:14 +0200 Received: from mac.com (smtpin07-en2 [10.13.10.152]) by smtpout.mac.com (Xserve/8.12.11/smtpout04/MantshX 4.0) with ESMTP id j6S03jxI011999; Wed, 27 Jul 2005 17:03:45 -0700 (PDT) Received: from [192.168.0.100] (dsl092-032-215.lax1.dsl.speakeasy.net [66.92.32.215]) (authenticated bits=0) by mac.com (Xserve/smtpin07/MantshX 4.0) with ESMTP id j6S03hjv011789 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 27 Jul 2005 17:03:44 -0700 (PDT) In-Reply-To: <200507271413.41026.pal_engstad@naughtydog.com> References: <20050726013444.GA32493@xmunkki.org> <1122484910.6768.133.camel@localhost.localdomain> <200507271413.41026.pal_engstad@naughtydog.com> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <2A3ECB07-10AB-4F4E-BD7D-9B9F42A954CF@mac.com> Cc: caml-list@yquem.inria.fr, Brian Hurt , xm@xmunkki.org, skaller Content-Transfer-Encoding: quoted-printable From: Paul Snively Subject: Re: [Caml-list] How to do this properly with OCaml? Date: Wed, 27 Jul 2005 17:03:24 -0700 To: Pal-Kristian Engstad X-Pgp-Agent: GPGMail 1.1.1 (Tiger) X-Gpgmail-State: signed X-Mailer: Apple Mail (2.733) X-Miltered: at concorde with ID 42E820FE.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; caml-list:01 ocaml:01 hash:01 minor:01 surprising:01 low-level:01 simd:01 byte:01 alignment:01 middleware:01 o'caml:01 o'caml:01 cached:01 unboxed:01 arrays: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.6 required=5.0 tests=PORN_URL_MISC autolearn=disabled version=3.0.3 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Jul 27, 2005, at 2:13 PM, Pal-Kristian Engstad wrote: > 1. It doesn't support console platforms. > - The PC market is quite minor compared to consoles. > I'd say that depends a great deal upon the type of game that you're =20 developing. For example, I don't find it at all surprising that Deus =20 Ex, developed for the PC first and ported to consoles, did much =20 better in the marketplace than Deus Ex 2, developed for consoles =20 first and ported to the PC. Consoles just aren't up to the kind of =20 more-than-point-and-shoot interaction that PCs offer and a title like =20= Deus Ex relies on. > 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. > Again, apart from consoles, which tend not to have the operating =20 system/middleware support we enjoy on other platforms and do have =20 interfaces to from O'Caml, it's not clear at all why this is =20 important. In any case, there is actually an AltiVec library for O'Caml. > 3. There is no controlled real-time GC. > - GC needs to run between frames, > and only for a controlled amount of time. > It would be interesting to see some experiments around GC and the =20 desire to have some kind of QoS guarantees around framerates. I =20 personally haven't been impressed with current claims of constancy in =20= framerates, and have found that the easiest way to get more bang for =20 my framerate buck is to have more VRAM so more stuff gets cached for =20 longer. > 4. There is no real support for unboxed data-types. > - This one is actually very important for consoles. > I dunno; I find having all-float records or arrays of floats unboxed =20 to be sufficient, but again, I suspect that if I were targeting =20 platforms with less in the way of middleware/OS support, I might be =20 more concerned. > 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. > So your point is basically that you wouldn't want to write your =20 renderer in O'Caml. Well, that's probably fair. But when you consider =20= that usually what you do is write your renderer in C or C++ and embed =20= a scripting language for the actual game logic (something I know you =20 folks at Naughty Dog know all too well, being famous for having a =20 Lisp-derived scripting language whose compiler is written in Common =20 Lisp), it stops seeming like much of a stretch to suggest that, with =20 a little elbow grease, someone could take OCamlSDL and lablGL and =20 write a quite respectable game for PCs and Macintoshes. Heck, the =20 game logic could even be compiled to native code, although mods etc. =20 would have to be bytecode-compiled in order to be dynamically =20 loadable. It'd probably still be worth it, and faster in the end than =20= titles developed with an embedded Lua interpreter or even the Unreal =20 technology and UnrealScript, which Tim Sweeney concedes is anywhere =20 from about 10x-20x out, performance-wise, from his C++. In any case, your claim about O'Caml's thread support is odd, since =20 O'Caml supports both pthreads and cooperative threading. But I don't =20 know what your requirements are, so it's hard to say much more than =20 that. > 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... > Yes, if in the console world you're stuck writing your own renderers, =20= this much is probably true. Maybe someday the consoles will give us =20 OpenGL and OpenAL and the conclusion will likely change. > Thanks, > > PKE. > --=20 > _ > \`. P=E5l-Kristian Engstad, Lead Programmer, > \ `| Naughty Dog, Inc., 1601 Cloverfield Blvd, 6000 North, > __\ |`. Santa Monica, CA 90404, USA. (310) 633-9112. > / /o mailto:engstad@naughtydog.com http://www.naughtydog.com > / '~ mailto:mrengstad@yahoo.com http://www.engstad.com > / ,' Hang-gliding Rulez! > ~' > > _______________________________________________ > Caml-list mailing list. Subscription management: > http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list > Archives: http://caml.inria.fr > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners > Bug reports: http://caml.inria.fr/bin/caml-bugs > Best regards, Paul Snively -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iEYEARECAAYFAkLoIN0ACgkQO3fYpochAqLw3ACeJRkss1ZwUUg6he54OdrxUjf+ M6oAoMEXuPAlobZpLtNlFPSctTjl5NvE =3Dl0tU -----END PGP SIGNATURE-----