Hi Chyman,

> This way the appropriate set of dlls can be right included
> and thus non-technical people don't need to worry about
> the details of WINE and its configuration.

Yup, that's what the potential is anyway, but whether this works well or not depends on how robust WINE is in the particular remaining areas that MoI uses. But removing mshtml.dll from the equation gets rid of the biggest blocking area.

The other thing that would be good about using WINE is being able to run under WINE would also mean being able to run on Linux as well. With Linux it would probably rely on someone installing a WINE build for their particular distro.

I should be able to know more once I complete the full Webkit conversion and then run some tests.

- Michael

The other goal for the Webkit conversion is actually to help stabilize the Windows version as well. Right now since MoI depends on mshtml.dll if there is some kind of installation problem with IE (like some kind of manglement in the registry) it can mess things up for MoI. The new Webkit based version of MoI will distribute Webkit along with the MoI installation so it is much more self contained and less affected by mild registry corruption.

Also one other problem with mshtml.dll is that it gets updated to new versions pretty frequently when new versions of IE get installed, and it is not too unusual for there to be slight differences in behavior between some different versions, which is another source of instability.

It's taken me a lot longer than I had originally thought to do the conversion, but it should be worthwhile for the Windows version as well when it is done, just to have better long term stability.

There are also other parts to the conversion as well, like scripting in MoI is now handled by the JavaScriptCore library that is a part of Webkit, rather than using the Microsoft JScript.dll .

- Michael

Thank you for the detailed explanation, Michael, I know to appreciate that.
Reducing prerequisites and dependencies is always good in SW development.
I am looking forward patiently, don't want to keep you off of coding any longer... ;)

Chyman

I used some crossover-wine solution on the mac.. they all sux!
Sorry, but that is no elegant solution with a good workflow.

I just bought MoI because I vote for a Mac Version!

I used OsX since MS came with Vista and that was good choice, wish MS would have improved XP only.
(Win7 = Vista SP1, Win7 = Vista+WinMobile).

Win 7 has some changes to the memory managment that fixed up stuff that was poor in Vista and the drivers have caught up. It's just not a good idea to try and load it on older hardware, but the new computers work well with it. With Vista, there werent even new computers ready.

Hi Robert,

> I used some crossover-wine solution on the mac.. they all sux!
> Sorry, but that is no elegant solution with a good workflow.

The WineBottler system is a little different since it packages up WINE with a single application into a regular application bundle so that it runs as if it were just a regular application.

If that works well it should make for a smooth workflow, you would not need to do any kind of special process for installing or launching things.

But it still remains to be seen how well WINE will support the particular areas of Windows that MoI will continue to be using for some time.

If the WINE and WineBottler system does not work well for MoI then there probably won't be a Mac version in the near future. If they do work well then there could be one.

- Michael

I'm curious how well MOI performs with Remote Desktop on a Mac which doesn't support DirectX. However, OpenGL seems to work fine locally with Google Earth. I don't suppose that there is a hidden preference somewhere? If MOI's code doesn't depend on DX9, would adding an optional OpenGL implementation in 2.x be a huge project?

Fraser

Hi Fraser, actually I sent you an e-mail reply about that a couple of days ago - maybe check your junk mail folder to see if it went there?


> I'm curious how well MOI performs with Remote Desktop
> on a Mac which doesn't support DirectX. However, OpenGL
> seems to work fine locally with Google Earth. I don't suppose
> that there is a hidden preference somewhere?

OpenGL can work in some situations like that because it has a software-only fallback renderer. So it's able to generate something in cases where hardware acceleration is not present. However that tends to be extremely slower than actual video-card assisted hardware accelerated rendering, so it's something that will only really be feasible for low complexity things.

Direct3D9 does not have that kind of software-only renderer, so if you don't have a hardware card to use with Direct3D (which will be the case if your display is via Remote Desktop) you won't be able to get a display.

So no, there's no hidden preference for that - MoI requires a hardware accelerated device to be present for the display in order for it to be able to work.


> If your code doesn't depend on DX9, would adding an optional OpenGL
> implementation in 2.x be a huge project?

Well, the code currently uses DX9, so it does depend on it right now.

For the most part though it just sends over a bunch of polygon and texture data - this part is not very hard to do with OpenGL as well. But there is one particular part which is more tricky though which is displaying text - that currently uses a DirectX specific library and switching that over will require a good replacement.

That part will take a while, possibly involving numerous tests with a few different candidates. That's not terrible but still will be fairly time consuming. I probably won't be able to incorporate that into the v3 timeframe, since I have already spent a huge amount of time just removing the mshtml dependency and moving to Webkit, so my time budget for conversion type tasks is kind of way over the limit already for v3. As soon as I'm done with the webkit conversion I really want to switch to more regular feature development for v3 rather than more conversion type work, other than some fine tuning if needed for WINE support.

So no, I do not expect to have an optional OpenGL implementation for MoI v3 - maybe in some future version though.

Thanks,
- Michael

Hello Michael,

just curious, did you had a look at the WebGL library? It integrates hardware accelerated 3D graphics into WebKit by defining a JavaScript binding to OpenGL ES 2.0, perhaps that could be of interest for v4.... but don't know how well that renders text... Anyway, just came across that...

Kind greetings,
Chyman

Hi Chyman, MoI needs to push over a lot of raw data like a lot of polygons and textures so MoI needs stuff like direct memory access to the pixel data of the textures and things like that. Script code is not really the best at doing that kind of low level number crunching type stuff for performance, compared to C++ code.

- Michael

You could go crazy and do a nativeclient (http://code.google.com/chrome/nativeclient/) implementation =P

:) But it would be cool if NaCL would get some broad acceptance - it could be a great system for implementing high performance web apps if it worked on more than one browser.

I think that you even have to manually turn on support for it in Chrome...

- Michael