OpenMW, an open morrowind reimplementation

[Saaa]

> Saaa Wrote:
>
>> Would you give them all then?  : )
>
> Sure :)
>
> For graphics I'm using Ogre, which is a complete 3d engine, while
Where are those D bindings? :)

> 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.
You compare D3D with SDL, shouldn't that be DirectX with OpenGL+SDL.

>
> 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.
I'm also interested in using OpenAL.

>
> 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.
Thanks for your thoughts.

>> 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
Did you just solve the halting problem  ; ) or is it timebased?

> 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.
I should look into how these things are handled. That is what the extern
keyword is for, right :)
I would like to be able to cap the size/cpu-time/memory usage.