* Re: [Caml-list] Ocaml and games
2002-01-22 21:35 ` [Caml-list] Ocaml and games Matthew D Moss
@ 2002-01-22 21:43 ` Will Benton
2002-01-22 23:53 ` Eric C. Cooper
` (6 subsequent siblings)
7 siblings, 0 replies; 29+ messages in thread
From: Will Benton @ 2002-01-22 21:43 UTC (permalink / raw)
To: caml-list
On Tue, 2002-01-22 at 15:35, Matthew D Moss wrote:
> I am once again learning good 'ol ML language from college days, and
> thought it might prove an interesting way to implement a game idea I
> have (my idea requires little to no graphics, but IIRC there is a
> ocaml-GL binding somehere).
On a similar note -- is there a tutorial on learning OpenGL with ocaml
(or even just on lablGL in specific) anywhere?
wb
--
Will Benton | "Nicht wie die Welt ist, ist das Mystische,
willb@acm.org | sondern daß sie ist." --L. Wittgenstein
**GnuPG public key: http://www.cs.wisc.edu/~willb/pubkey
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
^ permalink raw reply [flat|nested] 29+ messages in thread* Re: [Caml-list] Ocaml and games
2002-01-22 21:35 ` [Caml-list] Ocaml and games Matthew D Moss
2002-01-22 21:43 ` Will Benton
@ 2002-01-22 23:53 ` Eric C. Cooper
2002-01-23 0:58 ` Ian Zimmerman
` (5 subsequent siblings)
7 siblings, 0 replies; 29+ messages in thread
From: Eric C. Cooper @ 2002-01-22 23:53 UTC (permalink / raw)
To: caml-list
On Tue, Jan 22, 2002 at 04:35:50PM -0500, Matthew D Moss wrote:
> Just curious and wondering if anyone is doing (or has links to) games
> coded with OCaml... looking to get some opinions on overall structure
> and/or feelings as to how well it is working for that.
Not sure if this is the kind of game you're thinking about, but I
wrote a couple of card games to teach myself labltk. (I've since
switched to lablgtk for most things, but it seemed more accessible at
the time.) One is a blackjack program that's pretty usable; the other
is a set of programs for one small aspect of poker (identifying best
hands in Hold'Em and Omaha). Let me know off-list if you want the
code, or more info.
--
Eric C. Cooper e c c @ c m u . e d u
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
^ permalink raw reply [flat|nested] 29+ messages in thread* Re: [Caml-list] Ocaml and games
2002-01-22 21:35 ` [Caml-list] Ocaml and games Matthew D Moss
2002-01-22 21:43 ` Will Benton
2002-01-22 23:53 ` Eric C. Cooper
@ 2002-01-23 0:58 ` Ian Zimmerman
2002-01-23 1:23 ` Yaron M. Minsky
` (4 subsequent siblings)
7 siblings, 0 replies; 29+ messages in thread
From: Ian Zimmerman @ 2002-01-23 0:58 UTC (permalink / raw)
To: OCAML
Matthew> Just curious and wondering if anyone is doing (or has links
Matthew> to) games coded with OCaml... looking to get some opinions
Matthew> on overall structure and/or feelings as to how well it is
Matthew> working for that.
Well, one of my big projects (which I postpone ever further ..) is a
chess problem solver/tester. I think ML will prove ideal for that.
Probably not what you wanted, but anyway.
But first I have to finish this hack ... :-)
--
Ian Zimmerman, Oakland, California, U.S.A.
GPG: 433BA087 9C0F 194F 203A 63F7 B1B8 6E5A 8CA3 27DB 433B A087
In his own soul a man bears the source
from which he draws all his sorrows and his joys.
Sophocles.
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
^ permalink raw reply [flat|nested] 29+ messages in thread* Re: [Caml-list] Ocaml and games
2002-01-22 21:35 ` [Caml-list] Ocaml and games Matthew D Moss
` (2 preceding siblings ...)
2002-01-23 0:58 ` Ian Zimmerman
@ 2002-01-23 1:23 ` Yaron M. Minsky
2002-01-23 3:29 ` Doug Bagley
` (3 subsequent siblings)
7 siblings, 0 replies; 29+ messages in thread
From: Yaron M. Minsky @ 2002-01-23 1:23 UTC (permalink / raw)
To: caml-list
For what it's worth, there's a cute little gravity-simulation toy I
coded up for my 4-year old planets-obsessed nephew that I recently
released on to the web. It's fun to play with, although the simulation
method used to do the physics (a basic 1st order approximation) is
pretty bad. Still, under most circumstances it works ok. Besides, you
can do fun things like make planets bounce when they crash, intead of
simply merging. It's also got planet traces, zooming in and out and
panning. Lots of cute little toys.
It makes use of labltk, mostly through the canvas widget. And it works
on Windows and Unix.
http://planets.homedns.org
I'd be very welcome to contributions, by the way, especially to anyone
who wants to code a 4th-order runge-kutta approximation.
y
On Tue, 2002-01-22 at 16:35, Matthew D Moss wrote:
> Just curious and wondering if anyone is doing (or has links to) games
> coded with OCaml... looking to get some opinions on overall structure
> and/or feelings as to how well it is working for that.
>
> (I am also reminded, having seen another email by Chris Hecker, that he
> mentioned something along these lines at his talk at the last Game
> Developers Conference.)
>
> I am once again learning good 'ol ML language from college days, and
> thought it might prove an interesting way to implement a game idea I
> have (my idea requires little to no graphics, but IIRC there is a
> ocaml-GL binding somehere).
>
> ________________________________________________
> NOTE: My email address has changed! Please delete any old email
> addresses you have and use only the address shown below.
>
> Matthew D Moss
> moss@usermail.com
>
> -------------------
> Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
> To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
>
--
|--------/ Yaron M. Minsky \--------|
|--------\ http://www.cs.cornell.edu/home/yminsky/ /--------|
Open PGP --- KeyID B1FFD916 (new key as of Dec 4th)
Fingerprint: 5BF6 83E1 0CE3 1043 95D8 F8D5 9F12 B3A9 B1FF D916
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
^ permalink raw reply [flat|nested] 29+ messages in thread* Re: [Caml-list] Ocaml and games
2002-01-22 21:35 ` [Caml-list] Ocaml and games Matthew D Moss
` (3 preceding siblings ...)
2002-01-23 1:23 ` Yaron M. Minsky
@ 2002-01-23 3:29 ` Doug Bagley
2002-01-23 5:20 ` Chris Hecker
` (2 subsequent siblings)
7 siblings, 0 replies; 29+ messages in thread
From: Doug Bagley @ 2002-01-23 3:29 UTC (permalink / raw)
To: Matthew D Moss; +Cc: caml-list
Matthew D Moss wrote:
> Just curious and wondering if anyone is doing (or has links to) games
> coded with OCaml... looking to get some opinions on overall structure
> and/or feelings as to how well it is working for that.
>
> (I am also reminded, having seen another email by Chris Hecker, that he
> mentioned something along these lines at his talk at the last Game
> Developers Conference.)
>
> I am once again learning good 'ol ML language from college days, and
> thought it might prove an interesting way to implement a game idea I
> have (my idea requires little to no graphics, but IIRC there is a
> ocaml-GL binding somehere).
Have you looked at the hump?
http://caml.inria.fr/hump.html#Games
Also, I found a link a while ago for a small doom-like game written in
Ocaml with openGL which looked kinda neat:
http://www.stanford.edu/~rbridson/spiff.shtml
cheers,
doug
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
^ permalink raw reply [flat|nested] 29+ messages in thread* Re: [Caml-list] Ocaml and games
2002-01-22 21:35 ` [Caml-list] Ocaml and games Matthew D Moss
` (4 preceding siblings ...)
2002-01-23 3:29 ` Doug Bagley
@ 2002-01-23 5:20 ` Chris Hecker
2002-01-24 3:02 ` Matthew D Moss
` (2 more replies)
2002-01-23 8:39 ` Sven
2002-01-23 15:35 ` Xavier Leroy
7 siblings, 3 replies; 29+ messages in thread
From: Chris Hecker @ 2002-01-23 5:20 UTC (permalink / raw)
To: Matthew D Moss, caml-list
>Just curious and wondering if anyone is doing (or has links to) games coded with OCaml... looking to get some opinions on overall structure and/or feelings as to how well it is working for that.
I'm writing a commercial game in Ocaml right now (and for the past year, and for the next year ;). I'm reserving judgement on the overall worthiness of Ocaml for games until I actually finish and ship a robust product, but it's been fun and educational at least.
Some short thoughts:
- Performance seems to be totally acceptable so far, but I haven't been focusing on optimization yet, and the options are limited for optimizations-in-the-small short of dropping to C or modifying the compiler, so I'm slightly worried about it in the future. The GC performance predicability and smoothness is a huge looming shadow on the horizon that may or may not materialize, I have no idea.
- Lack of a debugger for native code sucks (not helped by the lack of the bytecode debugger on non-cygwin Win32 builds, and the debugger's not great even when it works after rebuilding for cygwin, in my experience so far).
- The toplevel has been a win (sometimes just as a pseudo-debugger).
- Linking of bytecode and native code would be good. Currently if you're using bytecode (debugging, compile speed, toplevel, etc.) and you need to optimize something, dropping to C is your only choice, which is silly.
- Lack of overloaded operators (needing op. for floats), overloaded functions (need mult_matrix_vector, mult_matrix_matrix, mult_scalar_vector, etc.), and "let mutable" makes imperative mathematical code (most of what I've done so far, since the game uses a lot of physics simulation) messy and overly verbose.
- Closures are great. Variants are great. Pattern matching is good. Code is easier and faster to refactor than in C. I've noticed that code seems to get smaller as I add more features, which is fun and non-intuitive. ;)
- Rigid for-loop structure is lame, recursive functions not as readable (and floats are boxed across them).
- The library has been useful, although it desperately needs an orthogonality pass.
- Labltk was fine for prototyping, but I now have my own Win32 thing I wrote because TK's a pig and unstable. LablGL is working fine but I expect to write a thinner layer over OpenGL/D3D before shipping.
I've got a much bigger list that I'll post at some point. Overall, I don't regret deciding to use Ocaml.
>(I am also reminded, having seen another email by Chris Hecker, that he mentioned something along these lines at his talk at the last Game Developers Conference.)
My talk was about programming language features that C/C++/Java/C# don't have but that seem useful, not about Ocaml specifically.
Chris
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
^ permalink raw reply [flat|nested] 29+ messages in thread* Re: [Caml-list] Ocaml and games
2002-01-23 5:20 ` Chris Hecker
@ 2002-01-24 3:02 ` Matthew D Moss
2002-01-24 6:59 ` Chris Hecker
2002-01-25 20:22 ` Daniel Phillips
2 siblings, 0 replies; 29+ messages in thread
From: Matthew D Moss @ 2002-01-24 3:02 UTC (permalink / raw)
To: Chris Hecker; +Cc: caml-list
> I've got a much bigger list that I'll post at some point. Overall, I
> don't regret deciding to use Ocaml.
Thanks for the short list. :) This is the kind of information I was
hoping to hear about, although thanks to all for the samples (and the
kind pointer to the Hump, which I now know about).
>> (I am also reminded, having seen another email by Chris Hecker, that
>> he mentioned something along these lines at his talk at the last Game
>> Developers Conference.)
>
> My talk was about programming language features that C/C++/Java/C#
> don't have but that seem useful, not about Ocaml specifically.
Yes, I remember the talk. I know you weren't speaking specifically of
Ocaml, although I wasn't clear about that in my first email.
________________________________________________
Matthew D Moss
moss@usermail.com
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [Caml-list] Ocaml and games
2002-01-23 5:20 ` Chris Hecker
2002-01-24 3:02 ` Matthew D Moss
@ 2002-01-24 6:59 ` Chris Hecker
2002-01-25 20:22 ` Daniel Phillips
2 siblings, 0 replies; 29+ messages in thread
From: Chris Hecker @ 2002-01-24 6:59 UTC (permalink / raw)
To: caml-list
Replying to my own post here...
>- Linking of bytecode and native code would be good. Currently if you're using bytecode (debugging, compile speed, toplevel, etc.) and you need to optimize something, dropping to C is your only choice, which is silly.
I thought I might explain this one a bit in case it wasn't clear why you might be _forced_ to optimize something (as opposed to just wanting to). This is intimately related to the "debugger for native code" issue as well. I'm not trying to be condescending at all here, I just don't know if everybody on the list is used to writing time-dependent interactive code or not, and the thing I'm going to describe is kind of surprising at first (at least, it was for me when I figured it out, and it seems to be for other game developers). And, I'm not trying to beat the horse (since we know how Xavier loves that sort of thing :) of this specific bytecode-native linking thing, this is just using that as a jumping-off point. So, anyway, if you already know this, hit delete, if not, maybe it's useful to know...
The idea is if you have a system that's got an interactive feedback loop in it that has a certain type of time-dependent behavior, then there's a floor beneath which your performance can't drop or things don't work. I don't mean "things go slow so it's annoying", I mean the system actually stops working. All that's necessary is that you have a system that's time to complete is proportional to the time over which you'd like to run it. So, for example, physics simulation is like this: if you ask a [nontrivial] physics simulator to simulate from t0 to t1, the bigger t1-t0 is, the longer it will take to give you an answer back. Graphics can behave like this as well if you've got stuff like viewer-dependent level-of-detail; the longer your timestep is, the farther the camera moves, so the more level-of-detail changes your system needs to make, so the longer it takes to render the frame.
If you've got this kind of feedback loop in your application, and if your framerate drops below a certain magic threshold (that's dependent on the system, obviously), then it takes longer to generate each successive frame and things grind to a halt. In other words, you have the start time of t0 and the end time of t1, and you generate the frame at t1, and if it took longer than t1-t0 seconds, then t2-t1 is going to be even longer, so it takes even longer again, and you get this:
t1-t0 < t2-t1 < t3-t2 ...
And you're screwed. This is known among some in the game industry as "The Evil Feedback Loop." :) You can sometimes work around it with fixed steps and whatnot, but if you're trying to debug actual behavior where the user is interacting with the system, you're pretty much stuck with it at some point.
So, this relates to byte/native linking and native debugging because if you're using the bytecode compiler for debugging (or any of the other reasons) and you run into this problem, but the native code is fast enough, you have a nasty decision to make: you can either rewrite the slow part in C so you can keep using bytecode, or you can move to native code and give up the debugger.
Anyway, hopefully that is interesting to somebody...
Chris
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [Caml-list] Ocaml and games
2002-01-23 5:20 ` Chris Hecker
2002-01-24 3:02 ` Matthew D Moss
2002-01-24 6:59 ` Chris Hecker
@ 2002-01-25 20:22 ` Daniel Phillips
2002-01-25 20:53 ` Ken Rose
2002-01-25 22:16 ` Chris Hecker
2 siblings, 2 replies; 29+ messages in thread
From: Daniel Phillips @ 2002-01-25 20:22 UTC (permalink / raw)
To: caml-list
On Tue, 22 Jan 2002 21:20:33 -0800
Chris Hecker <checker@d6.com> wrote:
> The GC performance predicability and smoothness is a huge looming shadow on the horizon that may or may not materialize, I have no idea.
Do you have any specific thoughts on this that you can share yet? Have you done any tests?
I've been trying to understand of the implications of garbage collection in soft real-time programs.
If the GC is not purely incremental -- if it has to do some sort of full collect every so often -- and if the time needed to do such a full collect is comparable to or longer than one game cycle, then you are stuck, aren't you? Is there anything you can do?
The time needed to do a full collect is proportional to the amount of live data in the program (right?). The only thing I think that could be done would be to move some of the data out into a C or C++ module.
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [Caml-list] Ocaml and games
2002-01-25 20:22 ` Daniel Phillips
@ 2002-01-25 20:53 ` Ken Rose
2002-01-25 22:16 ` Chris Hecker
1 sibling, 0 replies; 29+ messages in thread
From: Ken Rose @ 2002-01-25 20:53 UTC (permalink / raw)
To: Daniel Phillips; +Cc: caml-list
Daniel Phillips wrote:
>
> If the GC is not purely incremental -- if it has to do some
> sort of full collect every so often -- and if the time needed
> to do such a full collect is comparable to or longer than one
> game cycle, then you are stuck, aren't you? Is there anything
> you can do?
Not necessarily. Most games have a series of "levels", or something
similar, with a pause for the human to congratulate himself, and for the
program to swap data around. If you can make the full collections run
(only) then, you're OK.
- ken
--
----------------------------------------------------------
Ken Rose Voice: 760.728.6993
VM Labs, Inc. FAX: 760.728.6993
520 San Antonio Rd. Email: kenr@vmlabs.com
Mountain View, CA 94040 : rose@acm.org
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [Caml-list] Ocaml and games
2002-01-25 20:22 ` Daniel Phillips
2002-01-25 20:53 ` Ken Rose
@ 2002-01-25 22:16 ` Chris Hecker
2002-01-25 23:00 ` Thatcher Ulrich
1 sibling, 1 reply; 29+ messages in thread
From: Chris Hecker @ 2002-01-25 22:16 UTC (permalink / raw)
To: Daniel Phillips, caml-list
>> The GC performance predicability and smoothness is a huge looming shadow on the horizon that may or may not materialize, I have no idea.
>Do you have any specific thoughts on this that you can share yet? Have you done any tests?
Nope. It's just that the "conventional wisdom" is that GC will hurt performance, so I'm worried just on principle. :) I haven't seen any indication that it will yet, however.
As the other poster said, doing full collections between levels seems like a reasonable thing to try.
I'm also slightly worried about the "write barrier" thing, which I've seen posted about but don't fully understand yet. To avoid GC activity I may want to keep some arrays around and reuse them, but apparently as they migrate into the old heap then you get the write barrier thing going on. Hopefully this won't be a problem either, but I don't know yet (I don't know if I understand it correctly yet, either).
Lots of fun adventures on the horizon, I'm sure...just hopefully no show-stoppers. ;)
Chris
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [Caml-list] Ocaml and games
2002-01-25 22:16 ` Chris Hecker
@ 2002-01-25 23:00 ` Thatcher Ulrich
0 siblings, 0 replies; 29+ messages in thread
From: Thatcher Ulrich @ 2002-01-25 23:00 UTC (permalink / raw)
To: Chris Hecker; +Cc: Daniel Phillips, caml-list
On Fri, 25 Jan 2002, Chris Hecker wrote:
> > The GC performance predicability and smoothness is a huge looming
> > shadow on the horizon that may or may not materialize, I have no
> > idea. Do you have any specific thoughts on this that you can
> > share yet? Have you done any tests?
>
> Nope. It's just that the "conventional wisdom" is that GC will hurt
> performance, so I'm worried just on principle. :) I haven't seen any
> indication that it will yet, however.
>
> As the other poster said, doing full collections between levels
> seems like a reasonable thing to try.
>
> I'm also slightly worried about the "write barrier" thing, which
> I've seen posted about but don't fully understand yet. To avoid GC
> activity I may want to keep some arrays around and reuse them, but
> apparently as they migrate into the old heap then you get the write
> barrier thing going on. Hopefully this won't be a problem either,
> but I don't know yet (I don't know if I understand it correctly yet,
> either).
I have no real-world experience to share concerning OCaml's garbage
collector, but there's an informal description of how it works here:
http://para.inria.fr/~doligez/caml-guts/Sestoft94.txt
It's linked off the "Papers" section of the OCaml web site:
http://caml.inria.fr/ocaml/papers.html
Anyway, I'll speculate, because I've long pondered using GC in games:
based on that description, OCaml's GC is *exactly* the ideal type of
collector for interactive games. It's generational, which is good for
overall efficiency, and the old generation is collected incrementally,
which means it processes a single "chunk" at a time, rather than the
full heap. I haven't even looked at the API, but in theory the ideal
way to run a collector like this in a double-buffered game program
(like many console games) is to:
1) make sure the worst-case time to process a chunk is under say 2ms.
Do this by sizing the chunks appropriately or whatever. Disclaimer: I
have no idea what Ocaml GC's real-world latency is for processing a
chunk.
2) at the end of rendering, before displaying the back buffer, look at
the timer and decide whether you have 2ms to spare before the next
vsync. If so, then run the GC for one chunk -- it's practically free.
If not, then don't; hopefully you'll catch up in subsequent frames.
Basically, if your average allocation rate is below some threshold
(and you have some extra room on the heap to amortize any peaks), and
you run the GC enough, you'll *never* see a GC pause.
If you're triple-buffered, or you don't wait for vsync, then this
trick doesn't work, but in those cases you probably care much less
about an extra 2ms GC latency now and then.
The deal with a write barrier is that any time you write to a pointer
variable that's stored in the old generation of the heap, the GC must
know about it (so it can keep its incremental state synchronized). If
you're reading, or just writing data variables, the write barrier
should be irrelevant (although I don't know how it's implemented in
practice, so I'll shut up now).
-Thatcher
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [Caml-list] Ocaml and games
2002-01-22 21:35 ` [Caml-list] Ocaml and games Matthew D Moss
` (5 preceding siblings ...)
2002-01-23 5:20 ` Chris Hecker
@ 2002-01-23 8:39 ` Sven
2002-01-23 15:35 ` Xavier Leroy
7 siblings, 0 replies; 29+ messages in thread
From: Sven @ 2002-01-23 8:39 UTC (permalink / raw)
To: Matthew D Moss; +Cc: caml-list
On Tue, Jan 22, 2002 at 04:35:50PM -0500, Matthew D Moss wrote:
> Just curious and wondering if anyone is doing (or has links to) games
> coded with OCaml... looking to get some opinions on overall structure
> and/or feelings as to how well it is working for that.
>
> (I am also reminded, having seen another email by Chris Hecker, that he
> mentioned something along these lines at his talk at the last Game
> Developers Conference.)
>
> I am once again learning good 'ol ML language from college days, and
> thought it might prove an interesting way to implement a game idea I
> have (my idea requires little to no graphics, but IIRC there is a
> ocaml-GL binding somehere).
I have a sample gl + gtk little program, which is supposed to become a
landscape editor, but in its very early state. It could serve you very well, i
think, as an example at least. I could send it to you if you are interrested,
please ask me. It is GPLed code though (but copyrighted by me only, so other
arrangements could be made).
Friendly,
Sven Luther
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
^ permalink raw reply [flat|nested] 29+ messages in thread* Re: [Caml-list] Ocaml and games
2002-01-22 21:35 ` [Caml-list] Ocaml and games Matthew D Moss
` (6 preceding siblings ...)
2002-01-23 8:39 ` Sven
@ 2002-01-23 15:35 ` Xavier Leroy
7 siblings, 0 replies; 29+ messages in thread
From: Xavier Leroy @ 2002-01-23 15:35 UTC (permalink / raw)
To: Matthew D Moss; +Cc: caml-list
> Just curious and wondering if anyone is doing (or has links to) games
> coded with OCaml...
A few years ago, François Pessaux wrote two impressive 3D rendering
engines (of the kind found in first-person shooter games) in OCaml:
http://guinness.cs.stevens-tech.edu/~fpessaux/
The first one (OCamlDoom) is entirely software-based and renders
"2.5D" scenes as found in Doom. The second one (OCamlQuake) is full
3D and exploits hardware acceleration via the Glide library. Both
deliver very decent frame rates.
- Xavier Leroy
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
^ permalink raw reply [flat|nested] 29+ messages in thread