[REQUEST] AGS Editor - OS X Mountain Lion

[subspark]

We have an open source editor and engine, yet to date we only have an OS X runtime.

Is there anyone out there who also feels that the runtime is really only half the gem when it comes to a hardware-specific platform.
The thing I love about Apple gear is it's incredibly low-maintenance, inter-component stability at the factory level, and it runs one of the most practical to use OS's I've experienced since XP.

Working on a Macbook Pro is one thing, developing my game on it while flying from one end of the globe to the other is to be a treasured experience.
I can't surely be the only mate here with Apple gear who's torn between BootCamp, AGS game making lust, a Lion from the mountain, and an impossibly dark void inside the soul that can only be filled with a noble porting exercise.

JJS, Crimson, Electroshokker, Anyone interested in opening up a Mac branch for the editor?

[Stee]

I had a look at the draconian edition via monodevelop. Only when I saw constant compiler errors that seemed to me to be non issues (an error being thrown because xxx does not have a value set), did I realise how out of my depth I was (I'm barely competent at C# as it is).

Not really a Mac user myself, but I think getting the editor running on osx, even if its just to compile windows exe's at first, should be a priority for reaching new iCustomers.

Does it not work with any of the wine/crossover/etc implementations on Mac?

[Crimson Wizard]

JJS, Crimson, Electroshokker, Anyone interested in opening up a Mac branch for the editor?

Interesting how you've mentioned everyone except tzachs and Alan v. Drake, guys who were excessively working on editor in the past .
I am afraid you may strike me out right away, I know literally nothing about Mac, let alone porting to one. Will be able to help with general coding though if such need arises. But so far, I was mostly in refactoring the engine, editor is beyond my knowledge at this moment.

Anyway, if I understand this correctly, this is about making editor code compatible with Mono prior to anything else? This question was discussed before few times, for example it is mentioned here: http://www.adventuregamestudio.co.uk/forums/index.php?topic=46804.0.

[BigMc]

That would be great, because it would also mean that it would work on Linux. From what I read here, the Editor should basically work with Mono, but the problem is that AGS.Native is a mixed mode dll and that works only on Windows. Porting requires splitting AGS.Native into managed and unmanaged code. sonneveld started doing that, but he stopped and never uploaded his work in progress.

[Crimson Wizard]

problem is that AGS.Native is a mixed mode dll and that works only on Windows. Porting requires splitting AGS.Native into managed and unmanaged code.

While I did not do much changes to AGS.Native, except when changes in engine/editor shared code required that, I kept asking myself, how strong is the need to have a native code there at all. Surely, time and effort is required to rewrite everything to C#. Biggest problem is Allegro, I think; editor must convert all bitmaps and fonts to native Allegro format.

I wonder, how difficult that would be to make a stand-alone game compiler (as a native app), moving a) script compiler and b) graphics converter there?
Perhaps, more than one executable, like one for each task?

[Calin Leafshade]

I think one of the reasons that there is some native code in their was to reduce code duplication since both the engine and editor need to do things like draw GUIs.

Personally, I dont think thats much of a concern here.

CJ did start making a pure c# compiler but never finished it. Check the repo.

[Crimson Wizard]

I think one of the reasons that there is some native code in their was to reduce code duplication since both the engine and editor need to do things like draw GUIs.

Personally, I dont think thats much of a concern here.

That is not only a concern of (not) having extra copy of a code per se, but ensuring that both engine and editor use same data structures and corresponding algorythms (e.g. for reading/writing game data).
Having those functions rewritten in two languages would require extra effort to keep track on changes in the both apps.
Of course, there's nothing that would be impossible. But, as usual, time is what adds restrictions to everything we do.
I suppose that it would be faster to just move the code into stand-alone utility. That may be later rewritten in C#. But when I say "suppose", I mean that I make an assumption based on what I know... this need to be checked more thoroughly.

[subspark]

So a collection of separate apps for each major area of AGSEdit?
That might make stuff easier to port in a logical-sequential manner but would it be trivial to bundle it back up into an IDE again?

Perhaps the editor could be more easy to improve/fix/moderate this way generally.
A simple shell to house each independently managed component under a single interface?

[JJS]

Let's not forget that the engine does not currently run on anything newer than Snow Leopard (because Apple removed the Carbon framework). This is a separate issue to mono compatibility but not being able to test the game would be a dealbreaker too.

[subspark]

I agree now that Carbon is deprecated, a spanner was thrown into the works. But in a poetic irony, that spanner could be used to get AGS running in Cocoa. This would seem great from consumer perspective because the barrier of availability is substantially minimal.
Upgradng Snow Leopard to Mountain Lion ($20) is a quarter of the expense for an upgrade to Win 7 upgrade from a prior version and the process is done on the spot. $20 for an under 20 minute online OS upgrade. 

I've long appreciated why win software compatability comes in hops and skips but Apple have made upgrading your systems inexpensive and effectively seamless a little while ago.

I'd sure as heck offer my vote for a Cocoa powered AGS (Editor & Runtime) should any programmer be interested enough in exploring the potential. 

[BigMc]

I'd sure as heck offer my vote for a Cocoa powered AGS (Editor & Runtime) should any programmer be interested enough in exploring the potential. 

You may not believe it, but your vote alone will not convince any programmer to lift a finger.

[Calin Leafshade]

(lol)

[tzachs]

Note that while the native dll is the major issue here, the editor also needs some work to be fully mono compatible. I have made some improvements in that regard, but there's still more work to be done.

[BigMc]

I just realized that the Windows (Winforms) version of Scintilla would also have to be ported to Mono first. Any thoughts about that?

[subspark]

It's certainly a popular idea. It appears Winforms 2.0 has been ported over to runs under mono already:
http://www.mono-project.com/WinForms

[BigMc]

The problem is that the Winforms version of Scintilla does not work with Mono. FlashDevelop was never ported to Linux/Mac because of the same issue. It is easy to miss, because Scintilla works with Mono, but only using GTK+ instead of Winforms as GUI toolkit. Since the AGS Editor uses Winforms, Scintilla also has to use Winforms.

[Joseph DiPerla]

Has anyone considered re-doing the editor from scratch using c++ and wxwidgets? Or even using q7basic which compiles to the main 3 OS or QT itself? I know this would be a huge under-taking, but it might be one that could solve the cross-platform editor issue.

[Sslaxx]

QT has .NET bindings as well, but they've not been updated in nearly three years. Q7BASIC? Well, maybe, but as it'd require people to purchase it maybe not. WXWidgets also has .NET bindings, may be worth checking out?

Redoing the editor might well be the best way, but that'll require the compiler being fully separated from the editor code. Not sure if that's been done and added to the main branch at all, yet.

[Calin Leafshade]

Winforms works under mono in OSX. The GUI toolkit is not the issue really. The problem is the same as linux, namely all the PInvoke stuff and the named pipes used for debugging.

The PInvoke stuff needs to be replaced with pure .Net and the named pipes need to be replaced with a TCP socket. On the former Tzachs has done a lot of work. The latter will be more involved but the actual mechanism of debugging will remain the same, just the method of communication needs to be changed which is not a huge issue.

This is all aside from the fact that the engine itself does not currently work on OSX. Rewriting the editor would be a massive undertaking and is really not necessary. Mono is perfectly compatible with OSX.

[BigMc]

Winforms works under mono in OSX. The GUI toolkit is not the issue really.

I didn't say that Winforms + Mono is a problem on Linux/OSX. I said that Scintilla for Winforms does not work on Linux and Scintilla for Linux does not work with Winforms.