OpenMW, an open morrowind reimplementation

[Nicolay Korslund]

Saaa Wrote:

> Would you give them all then?  : )

Sure :)

For graphics I'm using Ogre, which is a complete 3d engine, while
SDL is a low-level graphics library. You can compile Ogre to use SDL as
a backend, but by default it uses GLX on Linux and D3D on Windows,
so I stick with the default.

Sound is a similar story, SDL is a low-level library (afaik, I haven't used
it that much), while Audiere is more high level. It's likely that I'll switch
to OpenAL at some point, because it's more mature and supports
hardware 3d audio, but it's not a high priority.

And input: I originally used SDL for input back when Ogre used SDL as
the default. But I had some problems with using SDL and GLX together,
because SDL-input is integrated with the SDL video component. It
worked, but not well. So instead I switched to OIS which is the
"preferred" input method for Ogre apps. I really liked SDL better
though. I heard some rumors that SDL might be decoupling the input
component from the video in the future, and if that's true (and it works)
I will switch back.

> First off, I do not know much about byte-code compilation but I'd reckon
> the optimizations in java are probably not something you can replicate on
> your own.

That's true. Promising Java-like performance is probably biting off a little
too much, especially since Java has JIT. (There are open source JITs though,
like LLVM.) On the other hand, there are languages like Lua which are
considered fast enough for games, and which are completely open source
as well (Lua uses the MIT-license.)

What I'm trying to say is that I probably won't have to reinvent this wheel
completely, only to modify an existing wheel to fit my type of carriage.

> When I think about it, its more important that the (user created) injected
> code
> (using the monster library) won't hurt the injected program, at least for 
> use in
> games. How do you cope with this? (ie. infinite loop)

That's a very good point, and it's one of the design goals of Monster. Scripts
(even compiled scripts) should be safe to run no matter where they come
from. That means not only handling infinite loops, infinite recursion, infinite
memory allocations and other bugs, but also protecting against intentionally
malicious code, ie. checking all input, protecting the file system, never
exposing pointers, etc.

Infinite loops and recursions are handled quite nicely already (currently it
throws an exception, but later you may have the option of killing the
offending object / function, etc.) Memory allocations will be handled in a
similar fashion later. The rest is largely up to the library user - for example,
if you expose a function that allows scripts to overwrite any file in the file 
system, then all the security measures in the world won't help you. I want
to make tools and docs that makes this as easy as possible though.

Nico