Hi guys.
I'd like to announce a project I've been working on for some time - an open
source reimplementation of Morrowind. I've called it OpenMW, see
http://openmw.snaptoad.com
OpenMW is written almost completely in D, with some minor parts in C++
to interface with libraries. I'm using Ogre for graphics, and there's already
a discussion going (with screenshots) at
http://www.ogre3d.org/phpBB2/viewtopic.php?p=288886
My hope is that this project will make D more visible in the game dev
community, and prove that D has merit in that field.
One specific thing is that it connects D code with Ogre and other C++
libraries. Even though this is done in a way that is very specific to
openmw, it show that it can be done without much problem. (In fact it
isn't hard at all, the interface is not a complete low-level wrapper but
a small set of "medium-level" functions using extern(C). It will be even
easier with D2.0-style C++ linkage.)
For more info and shots, check http://openmw.snaptoad.com . Note
that it's still in a very early stage of development though.
Nico

Do you mean for graphics? Or for input? Or for sound? There's three
different reasons ;-)

How fast is monster?

It's still under development, so it hasn't been optimized much yet (and
I haven't really speed-tested it.) There are some other features I want
to do first, but if someone wants to use monster for a project then I
can probably start optimizing earlier.
But here's no reason it can't become as fast as any other byte-code
compiled language out there though (like Java, Lua, etc.)
Nico

Do you mean for graphics? Or for input? Or for sound? There's three
different reasons ;-)

Would you give them all then? : )

How fast is monster?

It's still under development, so it hasn't been optimized much yet (and
I haven't really speed-tested it.) There are some other features I want
to do first, but if someone wants to use monster for a project then I
can probably start optimizing earlier.
But here's no reason it can't become as fast as any other byte-code
compiled language out there though (like Java, Lua, etc.)

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.
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)

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

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.

Since Ogre is written in C++ and D1 can just use extern(c) methods there
are no simple bindings to such an engine. as he exposed in his initial
post you have to write a wrapper for such a thing so that you can expose
these wrapper methods to D via extern(C). i am not sure how this has
changed with D2.

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.

I guess he means Ogre uses Win32-api+D3D under windows where Win32-api
is responsible for window creation and D3D for graphic rendering. under
SDL+OGL, SDL is the part creating window and some other stuff aswell.
DirectX alone cannot exist, since it cannot create windows and those
necessary things.

I'm also interested in using OpenAL

You can take a look at the ArcLib Project for a start. It has a
SoundSystem build around OpenAL. For 3DSound it is not much more of work.

I guess he means Ogre uses Win32-api+D3D under windows where Win32-api
is responsible for window creation and D3D for graphic rendering. under
SDL+OGL, SDL is the part creating window and some other stuff aswell.
DirectX alone cannot exist, since it cannot create windows and those
necessary things.

Yeah, my bad, I thought some part of DX could create a window.

I'm also interested in using OpenAL

You can take a look at the ArcLib Project for a start. It has a
SoundSystem build around OpenAL. For 3DSound it is not much more of work.

ArcLib looks interesting, what is the advantage of using it for sound only
in
comparison with using derelict and raw OpenAL?

ArcLib looks interesting, what is the advantage of using it for sound
only in
comparison with using derelict and raw OpenAL?

I just mentioned it as a good start if u want to dig in using OpenAL. You
could of course also simply use the Sound package of ArcLib if it is
sufficient for your needs.

I meant it more like:
Does ArcLib offer stuff OpenAl doesn't?

Short answer: no. It is build around OpenAl, so basically it cannot
offer anything more. Ogg-loading is an exception cause loading these is
supported by ArcLib nativly. OpenAL nativly can only load from raw-bytes
or wav-files.

ArcLib looks interesting, what is the advantage of using it for sound
only in
comparison with using derelict and raw OpenAL?

I just mentioned it as a good start if u want to dig in using OpenAL. You
could of course also simply use the Sound package of ArcLib if it is
sufficient for your needs.

I meant it more like:
Does ArcLib offer stuff OpenAl doesn't?

ArcLib / Yage (where the base code of ArcLib openAL module came from)
will allow you to get quickly set up using OpenAL. It's the difference
between writing
openal.sound.open();
SoundFX snd = new SoundFX("file.ogg / wav");
snd.play();
openal.sound.process();
versus writing 500 lines of code yourself to accomplish the same thing.
You don't have to use ArcLib, just grab the zlib/png licensed openal
module, modify it, and use it in your own project. ;)

ArcLib / Yage (where the base code of ArcLib openAL module came from)
will allow you to get quickly set up using OpenAL. It's the difference
between writing
openal.sound.open();
SoundFX snd = new SoundFX("file.ogg / wav");
snd.play();
openal.sound.process();
versus writing 500 lines of code yourself to accomplish the same thing.
You don't have to use ArcLib, just grab the zlib/png licensed openal
module, modify it, and use it in your own project. ;)

Since it's a VM, I can limit the number of instructions a function / object is
allowed to execute per call. It's some ridiculously high number, but it
typically stops an infinite loop in less than a second.

Hi guys.
I'd like to announce a project I've been working on for some time - an
open
source reimplementation of Morrowind. I've called it OpenMW, see
http://openmw.snaptoad.com
OpenMW is written almost completely in D, with some minor parts in C++
to interface with libraries. I'm using Ogre for graphics, and there's
already
a discussion going (with screenshots) at
http://www.ogre3d.org/phpBB2/viewtopic.php?p=288886
My hope is that this project will make D more visible in the game dev
community, and prove that D has merit in that field.
One specific thing is that it connects D code with Ogre and other C++
libraries. Even though this is done in a way that is very specific to
openmw, it show that it can be done without much problem. (In fact it
isn't hard at all, the interface is not a complete low-level wrapper but
a small set of "medium-level" functions using extern(C). It will be even
easier with D2.0-style C++ linkage.)
For more info and shots, check http://openmw.snaptoad.com . Note
that it's still in a very early stage of development though.

Hi guys.
I'd like to announce a project I've been working on for some time - an open
source reimplementation of Morrowind. I've called it OpenMW, see
http://openmw.snaptoad.com
OpenMW is written almost completely in D, with some minor parts in C++
to interface with libraries. I'm using Ogre for graphics, and there's already
a discussion going (with screenshots) at
http://www.ogre3d.org/phpBB2/viewtopic.php?p=288886
My hope is that this project will make D more visible in the game dev
community, and prove that D has merit in that field.
One specific thing is that it connects D code with Ogre and other C++
libraries. Even though this is done in a way that is very specific to
openmw, it show that it can be done without much problem. (In fact it
isn't hard at all, the interface is not a complete low-level wrapper but
a small set of "medium-level" functions using extern(C). It will be even
easier with D2.0-style C++ linkage.)
For more info and shots, check http://openmw.snaptoad.com . Note
that it's still in a very early stage of development though.

Very very cool, though I do wonder about the legality of what you have just
done. I seem to remember a large number of commercial EULAs being more or less
Xerox copies of each other, and all of them very expressly disallow reverse
engineering of any kind.
I don't mean to be hostile, I'm just trying to know whether I can expect to see
you in the news. I can see it now... "Electronic Entertainment Mega-corp
Ubisoft sues Open-Source Programmer Nicolay Korslund for the
reverse-engineering of their ancient and discontinued title "Elder Scrolls III:
Morrowind," claiming that the act of writing a redundant game data file reader
constitutes reverse engineering and is a violation of Intellectual Property.
Representatives from Ubigroup were unable to comment at this time, though
damages in the order of $500,000 were discussed if programmer Korslund refuses
to completely destroy his work and renounce computer science for ever. Details
at eleven." Perhaps not that dramatic, but you understand where I'm coming
from. Then again, I live in America. Lawyers are a dime a dozen, so we get to
put up with a lot of legal nonsense. I think it's made me more than a little
paranoid.

Very very cool, though I do wonder about the legality of what you have just
done. I seem to remember a large number of commercial EULAs being more or less
Xerox copies of each other, and all of them very expressly disallow reverse
engineering of any kind.

Well, that's a very valid point. I'm not a lawyer so I can't definitely say
anything
about the legality of the software. Technically it is probably already in
violation
of the DMCA just by allowing access to the data without a copy protection
scheme.
That being said, openmw does not do anything that hasn't been done by
other software for years already (I did very little of the reverse engineering
myself), and there are similar projects (like ScummVM) that are going strong.
Furthermore, I'm not based in the US. I honestly don't see how openmw could
possibly contribute to piracy or hurt Bethesda Softworks in any way. In fact
it's more likely to increase the shelf-life of one of their products, but that
doesn't mean they will see it that way.
But I have no reason to make enemies with anyone, and I will do what they
ask me to, in the worst case take it down (but I hope it doesn't come to
that.) One thing to be very careful about though is trademarks, since
companies basically _have_ to protect them or else they risk losing them.
That's why I've called it OpenMW, but I will even remove the MW if I have to.
Nico

Very very cool, though I do wonder about the legality of what you have just
done. I seem to remember a large number of commercial EULAs being more or less
Xerox copies of each other, and all of them very expressly disallow reverse
engineering of any kind.

Well, that's a very valid point. I'm not a lawyer so I can't definitely say
anything
about the legality of the software. Technically it is probably already in
violation
of the DMCA just by allowing access to the data without a copy protection
scheme.
That being said, openmw does not do anything that hasn't been done by
other software for years already (I did very little of the reverse engineering
myself), and there are similar projects (like ScummVM) that are going strong.
Furthermore, I'm not based in the US. I honestly don't see how openmw could
possibly contribute to piracy or hurt Bethesda Softworks in any way. In fact
it's more likely to increase the shelf-life of one of their products, but that
doesn't mean they will see it that way.
But I have no reason to make enemies with anyone, and I will do what they
ask me to, in the worst case take it down (but I hope it doesn't come to
that.) One thing to be very careful about though is trademarks, since
companies basically _have_ to protect them or else they risk losing them.
That's why I've called it OpenMW, but I will even remove the MW if I have to.

Cool. The presence of other engine replacements does make your work much less
legally violate in my mind.
I don't know if you already have some place to keep your work, but in the event
that you'd like some place to stick your code you can use my site if you'd like
(http://www.fsdev.net/). It has Subversion and some nice bug trackers and
other gizmos that can be interesting to play with. Again, I don't know if you
already have something, but if you want it you're welcome to register a project
on my site.

I don't know if you already have some place to keep your work, but in the
event that you'd like some place to stick your code you can use my site if
you'd like (http://www.fsdev.net/). It has Subversion and some nice bug
trackers and other gizmos that can be interesting to play with. Again, I don't
know if you already have something, but if you want it you're welcome to
register a project on my site.

Thanks for the offer. But I've just recently signed up at sourceforge though,
and I'm in the process of moving my files over there.
Nico

I don't know if you already have some place to keep your work, but in =

the event that you'd like some place to stick your code you can use my si=
te if you'd like (http://www.fsdev.net/). It has Subversion and some nic=
e bug trackers and other gizmos that can be interesting to play with. Ag=
ain, I don't know if you already have something, but if you want it you'r=
e welcome to register a project on my site.

=20
Thanks for the offer. But I've just recently signed up at sourceforge t=

hough, and I'm in the process of moving my files over there.
Excellent. <server_admin hat>They have better uptime than I do,=20
anyways.</server_admin hat>

Hi guys.
I'd like to announce a project I've been working on for some time - an
open
source reimplementation of Morrowind. I've called it OpenMW, see
http://openmw.snaptoad.com
OpenMW is written almost completely in D, with some minor parts in C++
to interface with libraries. I'm using Ogre for graphics, and there's
already
a discussion going (with screenshots) at
http://www.ogre3d.org/phpBB2/viewtopic.php?p=288886
My hope is that this project will make D more visible in the game dev
community, and prove that D has merit in that field.
One specific thing is that it connects D code with Ogre and other C++
libraries. Even though this is done in a way that is very specific to
openmw, it show that it can be done without much problem. (In fact it
isn't hard at all, the interface is not a complete low-level wrapper but
a small set of "medium-level" functions using extern(C). It will be even
easier with D2.0-style C++ linkage.)
For more info and shots, check http://openmw.snaptoad.com . Note
that it's still in a very early stage of development though.

Very very cool, though I do wonder about the legality of what you have
just done. I seem to remember a large number of commercial EULAs being
more or less Xerox copies of each other, and all of them very expressly
disallow reverse engineering of any kind.
I don't mean to be hostile, I'm just trying to know whether I can expect
to see you in the news. I can see it now... "Electronic Entertainment
Mega-corp Ubisoft sues Open-Source Programmer Nicolay Korslund for the
reverse-engineering of their ancient and discontinued title "Elder
Scrolls III: Morrowind," claiming that the act of writing a redundant
game data file reader constitutes reverse engineering and is a violation
of Intellectual Property. Representatives from Ubigroup were unable to
comment at this time, though damages in the order of $500,000 were
discussed if programmer Korslund refuses to completely destroy his work
and renounce computer science for ever. Details at eleven." Perhaps
not that dramatic, but you understand where I'm coming from. Then
again, I live in America. Lawyers are a dime a dozen, so we get to put
up with a lot of legal nonsense. I think it's made me more than a
little paranoid.

Hi guys.
I'd like to announce a project I've been working on for some time - an open
source reimplementation of Morrowind. I've called it OpenMW, see
http://openmw.snaptoad.com
OpenMW is written almost completely in D, with some minor parts in C++
to interface with libraries. I'm using Ogre for graphics, and there's already
a discussion going (with screenshots) at
http://www.ogre3d.org/phpBB2/viewtopic.php?p=288886
My hope is that this project will make D more visible in the game dev
community, and prove that D has merit in that field.
One specific thing is that it connects D code with Ogre and other C++
libraries. Even though this is done in a way that is very specific to
openmw, it show that it can be done without much problem. (In fact it
isn't hard at all, the interface is not a complete low-level wrapper but
a small set of "medium-level" functions using extern(C). It will be even
easier with D2.0-style C++ linkage.)
For more info and shots, check http://openmw.snaptoad.com . Note
that it's still in a very early stage of development though.
Nico