What would it take to just compile the editor multiplatform?

Started by 4sdfjkloe, Thu 05/02/2015 02:37:36

Previous topic - Next topic

4sdfjkloe

The games themselves can apparently be built for Win/Lin/OSX in the newest alpha release according to the 3.4.x post, that's already a common base for multiplatform.
The editor itself is Windows only because of the .net parts if I researched correctly.
Attempts at using mono seem to have been made but I don't see them in the downloads section yet so It doesn't seem like the recommended practice to me.
What exactly would be needed to simply take the editor code and let it compile a Lin/OSX-build that can do the same?
I'm asking primarily because Microsoft now open-sourced the .net core for Windows and announced the release of the Linux- and OSX-ports for the coming months:
http://blogs.msdn.com/b/dotnet/archive/2015/02/03/coreclr-is-now-open-source.aspx
QuoteToday, .NET Core builds and runs on Windows. We will be adding Linux and Mac implementations of platform-specific components over the next few months. We already have some Linux-specific code in .NET Core, but we're really just getting started on our ports. We wanted to open up the code first, so that we could all enjoy the cross-platform journey from the outset.

TL;DR: What parts of .net does the editor need, as soon as these are multiplatform-open source, could it just be compiled?

Gurok

If I recall correctly, the problem with Mono in the past was the mix of native and .NET code. Specifically, the AGS compiler is all native code. I don't know what the problem is exactly (perhaps a lack of Mono->Native interfaces) but I know others have pushed to have the compiler reimplemented in pure .NET. I'm not sure if this same native code limitation will apply with the newly open-sourced .NET. It'll be fun finding out.
[img]http://7d4iqnx.gif;rWRLUuw.gi

ChamberOfFear

Quick thought, if the .NET gets support for Linux and OS X, it appears that it will require .NET 5.0. I saw a thread in here somewhere where upgrading the choice of .NET compiler was being discussed, and the conclusion was that upgrade would be to maximum 3.5 to not lose support for Windows XP. .NET will require a minimum of Windows Vista SP2 for Windows users. That may be a problem.

On the other hand, gaining support of Linux and OS X is probably worth the cost of Windows XP.

monkey0506

As noted in the linked article:

QuoteWe have released the complete and up-to-date CoreCLR implementation, which includes RyuJIT, the .NET GC, native interop and many other .NET runtime components.

So it seems that once the port of CoreCLR to Linux and OS X is complete then porting the compiler to .NET could safely be seen as much lower priority. As it stands now, the lack of native interop was the driving factor behind moving the compiler code to .NET, although I wouldn't rule it out as not being worthwhile.

For what it's worth, there are other features that are still higher priority for the 3.4 release, so unless someone is dying to work on it, I'd say we just let it take the back burner until CoreCLR is sufficiently stable in its ports.

4sdfjkloe

Quote from: ChamberOfFear on Thu 05/02/2015 03:04:08On the other hand, gaining support of Linux and OS X is probably worth the cost of Windows XP.

To be honest it should generally be discouraged to use the good old XP nowadays. It's EOL since months (soon to be a year) and without updates potentially insecure. In my eyes the only valid reason to use it is to keep old software alive on a computer without Internet access*. It's just too bad Microsoft didn't wait for the Win10 release so users could have upgraded. May SteamOS pave the way for a bright FOSS future.

TL;DR: I must sadly agree.

*The airgap is no perfect isolation and even emulated the old software would have to be sandboxed for the same reasons XP shouldn't be used in production anymore.

blurymind

This fills me up with hope that there might be a linux/osx version of the editor soon.

Are there any developers around here interested in doing the compiler refactoring?

There are probably more mac osx+ linux users than there are winXp users at the moment. Winxp is no longer supported by microsoft, so it would be worth the sacrifice.

Crimson Wizard

#6
I do not really work with Editor much, but I'd like to have a clear vision on what our course of action may (should) be, because someday someone may start offering related changes and I will have to participate in deciding whether to apply them or not.

I don't follow C# / Mono development, so I would like to have an update, how realistic is it in general to make this C# Editor run on Linux/OSX, assuming it was made Mono-compatible?
Also, something I always wanted to ask, but did not: currently all Editor is made of WinForms. Does that work on Mono, or we would have to replace them with some portable GUI classes?

Note, that we always can try to remake such C++ parts as a script compiler into stand-alone application (I would say it is not that hard, since script compiler is separated into static library now).

PS. Regarding Windows XP argument above, there is this anonymous information feature in AGS that sends OS type to database. It's been 2 or 3 years since admins shared the statistics with me last time, I might ask them to make it more accessible.

tzachs

Quote from: Crimson Wizard on Fri 05/08/2016 12:11:56
Also, something I always wanted to ask, but did not: currently all Editor is made of WinForms. Does that work on Mono, or we would have to replace them with some portable GUI classes?
There is a WinForms implementation in Mono, but from what I read, it's lacking, and the recommendation is not to use it (and while you didn't ask,.Net Core does not support WinForms). Also relevant, I believe that ScintillaNet is Windows only so a different text editor should be used.

Crimson Wizard

#8
Quote from: tzachs on Fri 05/08/2016 13:05:29I believe that ScintillaNet is Windows only so a different text editor should be used.
I am currently trying to get in touch with Calin who was experimenting with replacing scintilla editor with more convenient C# one. It would be interesting to see if he had just any progress.

Also, what the heck is .NET Core? My knowledge of C# is several years behind, I am afraid.
EDIT: Ok I found out... so, is this .NET Core something that we should aim for?
I would really love if someone .NET savvy would take time to write a simple roadmap, because, as I said, it is not clear to me what way to go, and what to do if someone will start making pull requests changing editor into portable way (how to check if they are doing it right).

tzachs

Quote from: Crimson Wizard on Fri 05/08/2016 13:37:47
EDIT: Ok I found out... so, is this .NET Core something that we should aim for?
It's very hard to tell, as the water keeps changing (Microsoft is calling this "growing pains"). Mono has been around much longer so it's definitely more stable.
The new kid on the block, and the one we might want to keep an eye for, is the .net standard library. If we target it, theoretically we can compile for mono, .net core, .net framework, xamarin, uwp and more future platforms.

morganw

How about just getting the game compiler working multiplatform and making the config and resources a little more user-editable? If the script compiler is already in C#, is that the hardest part already done or is there something Windows specific to the game building process?

Crimson Wizard

#11
Quote from: morganw on Sun 28/08/2016 18:27:17If the script compiler is already in C#, is that the hardest part already done or is there something Windows specific to the game building process?
Script compiler is not in C#, it is written in C++, and thus it IS multiplatform, originally. There may be some issues with 64-bitness or endianess which were overlooked, because I do not think anyone was testing building it on non-Windows platforms yet, but these are solveable.

The script compiler is not portable as a part of mixed assembly, but it should be already possible to make it a portable stand-alone tool, because all the code is separated and built as a static library anyway.

As for compiling game itself (putting all data together), that may probably be made into separate tool run from command line as well. Actually, this was suggested in the very beginning, 4 years ago.

Regarding which language to use there, some people wanted to make everything C#, others wanted to have these compilers in C++, a matter of personal preference, I guess (so long as C# program can actually work on other platforms).



EDIT: I know I said this before, but I need to underline again, that we still do not have any design plan for the Editor. Like - none.
There should be one, or everyone will be changing the code the way they prefer. Like a list of clear goals, even if ideal.
(For example, this is such design plan I wrote before I started to work on savegames issue: http://adventuregamestudio.myjetbrains.com/youtrack/issue/AGS-4)
I could probably try to write one myself, but I am very busy with the engine, and fear that I won't be able to think for both programs. Editor is like a separate project with its own problems and needs.
If we had such design plan it would make it much easier, because when you know what to do, regular developers could add a thing or two sometimes, and there will be something to give for a willing contributor as a reference.

morganw

Quote from: Crimson Wizard on Sun 28/08/2016 23:22:13
I could probably try to write one myself, but I am very busy with the engine, and fear that I won't be able to think for both programs. Editor is like a separate project with its own problems and needs.
If we had such design plan it would make it much easier, because when you know what to do, regular developers could add a thing or two sometimes, and there will be something to give for a willing contributor as a reference.
I would be happy to propose something, but I'm slightly biased towards seperating out the game build tools and getting the editor data broken out into something that can just be placed on a filesystem and edited with more basic tools. I think this would be the easiest way to get any sort of multi-platform editor, if all that is needed is reading and writing XML plus a basic bitmap editor for room data. Presumably the room data is the largest problem here? Plus the sprite and audio cache building would have to be seperated as well. If it gets down to this point the choice of language for the editor is probably less important, as it would be doing so much less.

Crimson Wizard

#13
Quote from: morganw on Mon 29/08/2016 16:29:41I'm slightly biased towards seperating out the game build tools and getting the editor data broken out into something that can just be placed on a filesystem and edited with more basic tools.
In fact I would support your opinion here, and I believe that many other people will.

Quote from: morganw on Mon 29/08/2016 16:29:41Presumably the room data is the largest problem here?
Yes, currently rooms are biggest problem, for many reasons, because they are always kept in compiled binary state. This is a remains of the old (2.72) AGS editor when the game data had always same binary format both in editor and engine. Making room source saved in XML is one of the most important tasks for the editor.

morganw

Did any of the changes you described here ever make it into the main branch?

Crimson Wizard

#15
Quote from: morganw on Mon 29/08/2016 16:54:05
Did any of the changes you described here ever make it into the main branch?
No.
I think I mentioned this in the other thread, you need to be careful with those changes, because they were made to work with the "unlimited regions" feature, which is still not in the main branch. So, if that room saving code is to be resurrected, then it needs to be altered to match current state of room data.

morganw

I'll create a ticket on the new tracker (unless there is somewhere else?) with an initial plan. Even if it's changed entirely (I'm not overly familiar with the engine internals and data structures) hopefully it can be starting point.

SMF spam blocked by CleanTalk