Re: [Caml-list] How to do this properly with OCaml?

From: Paul Snively <psnively@mac.com>
To: Pal-Kristian Engstad <pal_engstad@naughtydog.com>
Cc: caml-list@yquem.inria.fr, Brian Hurt <bhurt@spnz.org>,
	xm@xmunkki.org, skaller <skaller@users.sourceforge.net>
Subject: Re: [Caml-list] How to do this properly with OCaml?
Date: Wed, 27 Jul 2005 17:03:24 -0700	[thread overview]
Message-ID: <2A3ECB07-10AB-4F4E-BD7D-9B9F42A954CF@mac.com> (raw)
In-Reply-To: <200507271413.41026.pal_engstad@naughtydog.com>

-----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  
developing. For example, I don't find it at all surprising that Deus  
Ex, developed for the PC first and ported to consoles, did much  
better in the marketplace than Deus Ex 2, developed for consoles  
first and ported to the PC. Consoles just aren't up to the kind of  
more-than-point-and-shoot interaction that PCs offer and a title like  
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  
system/middleware support we enjoy on other platforms and do have  
interfaces to from O'Caml, it's not clear at all why this is  
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  
desire to have some kind of QoS guarantees around framerates. I  
personally haven't been impressed with current claims of constancy in  
framerates, and have found that the easiest way to get more bang for  
my framerate buck is to have more VRAM so more stuff gets cached for  
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  
to be sufficient, but again, I suspect that if I were targeting  
platforms with less in the way of middleware/OS support, I might be  
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  
renderer in O'Caml. Well, that's probably fair. But when you consider  
that usually what you do is write your renderer in C or C++ and embed  
a scripting language for the actual game logic (something I know you  
folks at Naughty Dog know all too well, being famous for having a  
Lisp-derived scripting language whose compiler is written in Common  
Lisp), it stops seeming like much of a stretch to suggest that, with  
a little elbow grease, someone could take OCamlSDL and lablGL and  
write a quite respectable game for PCs and Macintoshes. Heck, the  
game logic could even be compiled to native code, although mods etc.  
would have to be bytecode-compiled in order to be dynamically  
loadable. It'd probably still be worth it, and faster in the end than  
titles developed with an embedded Lua interpreter or even the Unreal  
technology and UnrealScript, which Tim Sweeney concedes is anywhere  
from about 10x-20x out, performance-wise, from his C++.

In any case, your claim about O'Caml's thread support is odd, since  
O'Caml supports both pthreads and cooperative threading. But I don't  
know what your requirements are, so it's hard to say much more than  
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,  
this much is probably true. Maybe someday the consoles will give us  
OpenGL and OpenAL and the conclusion will likely change.

> Thanks,
>
> PKE.
> -- 
>   _
>   \`.       Pål-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
=l0tU
-----END PGP SIGNATURE-----