I think I finally understand what you're trying to do, septeven.

Until now, I assumed you were trying to access the preview directly (which would presume a browser running inside the wine prefix).

It might have something to do with the way wine handles networking. I'll look into it, once I've got more time (possibly on or after the weekend).

Got a Mac today (Mavericks freaking rocks. Even though it's dully lacking in the cat department )

I'll be able to test Construct 2 on two different Unices now.

What really interests me, btw. Will we be able to create and distribute wrappers or would this be against the EULA, Ashley?

My idea is to create a multiphase installer for both systems (will have to look into how to do this on Mac OS X, of course).

Essentially, it would dump all necessary files in a prefix called "Construct 2" or "Construct 2 <version number>" then asks whether the user wants to activate a paid license key. If that's the case, the installer will prompt for a license file which, once provided, will be copied right into the correct wine directory.

Depends on your definition of an emulator.

If what you're actually talking about is a hypervisor, sure. It should run rather nicely under Parallels.

If, however, you're talking about something like Wine (short for Wine Is Not an Emulator), the answer sadly is no.

Actually, I just realized I don't know how to write out the config file. Seems like wine.conf has been deprecated a long time ago.

Anyways. What I did to get where I'm now was rather straight forward.

env WINEARCH=win32 WINEPREFIX=~/.wine32 winetricks dotnet20 gdiplus mono210 vcrun2005 vcrun2008 vcrun2010

env WINEARCH=win32 WINEPREFIX=~/.wine32 wine construct2-r163-setup.exe
[/code:26cvci5a]

There's that distinct chance, I'm missing some libraries. Furthermore, my wine is a tad old (version 1.4.1).

septeven

Sure. Which one? x32, x64?

Beaverlicious

More like POSIX compliance should be the top priority. If it was more standards compliant and steered away from using too many Microsoft specific libraries, we would already be half way to a native port that could be used by creative people, rather than Windows users

EDIT: Here's a screencap from my almost finished AGS port, in case anyone is interested.

All that is left is a small, graphical installer (was going to use either Shellscript and Zenity or wxwidgets and Haskell for that) that automagically creates all files necessary to run the program and, perhaps, also contains a statically linked version of wine (not sure if that last part would work too well, though).

Was hoping to do the same for Construct 2, once the last issues are resolved.

Well. At the very least, it could be said that it's partly your responsibility.

After all, it's also crashing under Windows 7 x64 (the Tetris.capx I found in the Arcade doesn't ever open on my PC, but works splendidly on two older PCs with graphics drivers that date back to 2006).

IMHO your GUI implementation is somewhat flawed (whichever library you use. Windows Forms, supposedly?), as I don't know too many applications being this prone to crash. In fact, I recently ported Adventure Game Studio to Ubuntu (writing a Wine wrapper + installer) and it runs splendidly and without any error.

Just checked out Construct 2 R163 and it's almost working under Wine (Ubuntu 13.04) now.

Performance is fine and Node-Webkit preview should be easy enough to get working (I'm thinking cron + native Linux node-webkit).

The one thing that still always crashes the whole application is opening a project. It's also prone to crash during this process under Windows 7 Ultimate x64.

Is there anything that can be done about it? Some sort of hot swapping perhaps? In which case I'd manually input the whole project structure, rather than loading the project through the file menu?

Just hit a roadblock.

Created some tidy little scripts to handle stuff like project folder/file creation, SVN updates and commits, spritesheet creation, etc. They work great on their own. Unfortunately, I can't get them bound inside my project.

The Node Webkit "run" command works somewhat decent under Windows, but doesn't really seem to do anything for MacOSX and Linux.

I already simplified the whole process down to a simple shc compiled "mkdir" script, but that one won't execute either. Already tried all sorts of absolute and relative paths.

What exactly does the C2 implementation do differently from the default Node Webkit child_process command?

EDIT: Ok. Build a small application with a textbox and a call to the filemanager and figured the correct pathing this way. Turned out, I also forgot to tell mkdir the directory it was supposed to create a folder in.

My current project depends on a couple shell tools and applications written in C.

Unfortunately, I have yet to figure out how to use the NodeWebkit plugin's run command in an OS other than Windows.

Is there a way to do this, at all? Thus far, I've tried

• absolute paths ("home/user/nodetest/linux32/test")
• relative paths (/test)
• absolute paths set through the use of a variable (NodeWebkit.AppFolder & "/test")

The script I'm testing this with is an shc "compiled" shell script that basically places a folder called "Test" inside of the app folder (mkdir Test)

EDIT: Just tried with a graphical script based on Zenity. This one works spendidly, although mkdir doesn't work here either. Are there some sort of file system limitations keeping me from executing commands like mkdir and other coreutils? Since zenity works, it can't be a pathing issue.

EDIT2: Forgot to set the path mkdir is supposed to be executed in. Got it working now.

No need to switch my engine to OpenFL just yet.

It's missing one rather important piece of advice:

Don't ever make a Flappy Bird clone!*

*1:1 clone, that is. Something like Delirious Bird is pretty cool, actually.

Gave up on my idea of using XUL and decided to go with Node-Webkit for this one.

Saw that the Node-Webkit plugin supports child processes ("Run file") now.

I wonder if this would work under Unix, as well. Combining the engine with shell scripts or compiled graphical applications would be straightforward that way.

Then I might have assumed wrong ^_^

Oh well, he mentiont it at least, that it would take loads amount of work to port and maintain it.

As far as I can tell, scirra is a small team with ashley being the main programmer.

I think for such a porting project and maintenance, he would require a few clones.

Construct 2 is using a lot of Windows specific baggage, from the looks of it.

This could explain his past comments.

Truth be told. If I was him I would want to get rid of the baggage, no matter what. Not even because of a possible port to *nix but because of the maintainability.

Microsoft is prone to introduce software breaking API changes. What works now might not necessarily work with Windows 9 or 11 (never mind 10, as that's an entirely cloud based OS).