Forum ‹ C# ‹ Mono Port

[BigJKO]

How far are you with the Mono port, that you mentioned in the FAQ? Just can't wait to be able to write the entire thing on my Mac, instead of having to dual-boot to Windows all the time..

Awesome, awesome work you guys have done on Player.IO, btw. Love the fact that it's become it's own seperate entity. Should drive even more people to use this awesome API.

[mindfoolgames]

I can second this question and the compliments.

I'm very excited to work with this API and (unfortunately) I'm typing this message on my Windows laptop instead of my MacBook Pro.

[Cyclone103]

I'm guessing pretty soon, it would open this up to a whole new world of developers. It might even be in the next release if you are lucky.


On a side note: You all use macs, and I use Windows, but I can't make ipod apps like I want to because I'd have to jump through so many hoops. Wish I could dual-boot mac osx on my laptop >.<

[Toby]

Wish I could dual-boot mac osx on my laptop >.<

There's ways to get macs on non-apple machines. Just not legal ones.

[Oliver]

Hi Guys,

First of all, we're actually using macs internally in our company -- I've personally been a mac user since well before it was trendy (1990) so i totally share the desire to run on top of mono.

I've been following mono (and monodevelop, the developer tool) development for the last couple of years, and seen it's steady progression.

Mono has recently launched a product that makes it possible to build iPhone apps with Mono (it's called MonoTouch), so they're currently putting a lot of effort into their mac software.

I spent some of the weekend trying out our software under mono, and i did run into a few limitations (cheifly that mono doesn't support a method called DuplicateAndClose() on sockets). I've changed some stuff around and added some conditionals such that the development server now should startup on os x.

However, in my testing i realized that it's not yet a perfect world:
- Debugging doesn't work under os x under monodevelop
- The mono compiler is much slower than if i boot the same machine into windows and compile with the microsoft compiler. It's still plenty fast for game projects, but it's noticable for larger projects.
- We're using WinForms for the layout of the development server, and the os x port is not really totally stable. There are a few minor graphical glitches and flicker.

In the next release we're doing you should be able to a) install mono and monodevelop and then b) download the package and boot the solution in monodevelop on mac.

Keep in mind that this is first steps, and very unsupported and alpha etc...

Currently i would recommend buying a VMware fusion+windows7 license and running visual studio under that -- That's what i do when i develop from under os x (normally i dual boot into windows).

[Cyclone103]

Again sorry to be offtopic, but MonoTouch is really limited (I've also looked into it, dragonfiresdk has much more)


The development server is a really crucial piece for creating the game, it offers so much control for when you are just starting the project.

[Oliver]

First steps are in the new 1.0.3 release; please give feedback, again: very unsupported for now...

Release notes for 1.0.3

[Benjaminsen]

Still a but buggy but workable.

[BigJKO]

Hooray, it builds and runs. But it asks me to update to v.1.0.3?

[Oliver]

What? really? which project did you start up ? (it's the very new download you used right?)

[BigJKO]

Yes, I just replaced all the files in my project, with what was in the new download (the seperate 1.03 in Download)

Also, this error: "SocketConnection.ReceivedBytes ERROR: The requested feature is not implemented., Appdomain: Test Server.exe" But the server still seems to work fine, though.

EDIT: Wait, that was just an error displayed in the development server. Back in MonoDevelop I got this:

"unable to bind to endpoint:192.168.1.34:843
Error:Access denied
System.Net.Sockets.SocketException: Access denied
at System.Net.Sockets.Socket.Bind (System.Net.EndPoint local_end) [0x0006c] in /private/tmp/monobuild/build/BUILD/mono-2.6.1/mcs/class/System/System.Net.Sockets/Socket.cs:1794
at hh.b (System.Net.IPEndPoint A_0) [0x00000] in <filename unknown>:0
unable to bind to endpoint:127.0.0.1:843
Error:Access denied
System.Net.Sockets.SocketException: Access denied
at System.Net.Sockets.Socket.Bind (System.Net.EndPoint local_end) [0x0006c] in /private/tmp/monobuild/build/BUILD/mono-2.6.1/mcs/class/System/System.Net.Sockets/Socket.cs:1794
at hh.b (System.Net.IPEndPoint A_0) [0x00000] in <filename unknown>:0"

[Benjaminsen]

What example game did you copy the .NET Libraries and playerio folders from?

Just wants to make sure that we did not accidently released an old server in one of the examples.

/Chris

[BigJKO]

The NewGame example. I'll try with the others, to see if I get the same errors.

EDIT: FridgeMagnet works fine. Must be an old server in NewGame.

EDIT: Sorry, this is my fault. For some reason, I'm not able to see the .NET libraries folder, which is why nothing worked in my game's folder, where I copied everything except the .NET libraries folder. Why isn't OS X showing the folder? Christ, sometimes I get so confused..

Solved it. Snow Leopard was just hiding weirdly named folders, apparently. Including .NET libraries.

[BigJKO]

This is freaking annoying. Because it's hidden, it won't actually allow me to overwrite it. And it's only hidden, because of the "." at the start. I can't unhide it, unlock it, overwrite it. This is the first time OS X's simplicity really annoys me..

[Benjaminsen]

Here is how I solved it.
http://www.macworld.com/article/51830/2 ... inder.html

[BigJKO]

Thanks! Now everything is working like a charm.

[Oliver]

Ahh... it's called ".NET Libraries" and the . causes it to be hidden. Gotcha! -- Will probably be changed in the next release.

[BigJKO]

Also, it seems like MonoDevelop doesn't output a .dll into the "output" folder, like Visual Studio does.

[Benjaminsen]

Also, it seems like MonoDevelop doesn't output a .dll into the "output" folder, like Visual Studio does.

The output DLL is actually copied using an compile action, which is why the DLL does not appear in the Output folder. Naturally this will also be fixed in the future, but the Mono focus is on actually making it stable.

[azuanagames]

What is the status of the Mono port?

I can't seem to find the status anywhere... I'm not really ready to work on my game just yet, but I wanted to start looking into it. playerio definitely seems to be what I want to use! But I would much rather work naively on the mac than have to boot to Windows or use vmware fusion...

Thanks,
Azuana Games
http://www.azuanagames.com

[Benjaminsen]

There is no specific mono port, the project as it works with mono develop but might act a bit strange some time. We are fixing bugs towards more stability with every release.

[azuanagames]

This will seem like a silly question.

Do I compile the server myself? I only see a .exe in my download of the LocalServer. Or does the mono platform somehow allow me to run the exe?

Thanks for the quick response!

[Benjaminsen]

This will seem like a silly question.

Do I compile the server myself? I only see a .exe in my download of the LocalServer. Or does the mono platform somehow allow me to run the exe?

Thanks for the quick response!

Simply open the project file with mono develop, then hit F5 to compile and run the project. That should be all it takes.

[danielm]

Hi,

could you give an update for the latest release regarding Mono support? I have tried it, and it seems to work basically. The file is still not moved to the Output directory, but that is not a big deal I guess. The server monitor has refresh issues, which seem to be resolvable by switching tabs. A bit flaky. I have not tried debugging.

While on first sight it does seem to be "good enough", I feel that it would be a big risk to rely on it, if it keeps being unsupported. After all, Player IO is a closed platform, and any investment in gamecode written for your server is not easily going to be transferred. So I am still undecided whether it would be smart to go with it, even though I think that your services hit all the right spots. Going with a closed platform would be a risk in any case, but even more so using it in an unsupported manner.

I have also quickly tried VMWare, but XP drives me bonkers and it just didn't work well (fast) enough. I am not sure about getting a Windows 7 license, if I don't know yet whether I will be satisfied with the work flow.

Also, a question: Is the resulting bytecode from the Mono compiler basically equivalent to the one created by VS, i.e. will it run the same when executed on the server or would "production" code still benefit from being compiled by the MS compiler?

[Oliver]

Hey Daniel,

I'm very happy that you've asked this question!

We're slowly moving towards better mono support -- our goal is to have as good an experience developing with Player.IO on Mac OS X as on Windows!

There are two components to this;
a) How well our software works with Mono
b) How well Mono works with Mac OS X

Mono has only fairly recently begun spending serious time improving their tools on OS X: Last year I would not recommend anybody to use MonoDevelop, but since they've launched MonoTouch they're spending a lot more time and effort on getting the Mac experience to be as good as on other platforms.

There are still holes though, for instance our development server uses Windows.Forms for the GUI, but their implementation is not quite as stable as the original Microsoft one, which is what's causing the glitchy UI you mention. And our server relies on a socket method called DuplicateAndClose which is not avaliable on Mono, so we've had to implement a sorta nasty workaround.

So, Mono is moving forward, and you can bet your hat that we're paying close attention!

With regards to our own side; As recently as version 1.8 which was released this week, we've done changes to improve the experience on Mac OS X w/ mono: It's the reason why there is no longer any folder in the package with a name starting with the dot (".") character. It used to be called ".NET Libraries", and now it's called "Microsoft .NET and Mono" (or something similar to that, i can't remember precisely).

We have a future plan to decouple the UI from the underlying server in the development server, and perhaps provide either a console or a native os x window interface, but I don't think we'll get to it anytime soon, since there is so much stuff with higher priority right now.

In other words, we're committed to improving the experience with Mono&Player.IO, but it's something that will probably happen slowly as they both improve together.

With regards to VmWare: On my own MacBook Pro, a compile is about 1.5x faster in VS2008 under VMWare (Win7) than if i compile the same project with MonoDevelop under OS X. The test project i tried is many, many thousands lines of code and the MacBook has 8GB ram, so your mileage might vary. You'll also have to setup cross-virtual-machine networking if you're developing with Flash under Mac OS X and Visual Studio under Vmware.

Your last question about bytecode: YES, The assemblies produced by the Mono compiler are fully compatible with Microsofts .NET, so if you can deal with the rough edges of Mono/MonoDevelop you'll have no problems doing your development on a Mac OS X machine and simply deploying the final .dlls as you would if they were compiled by Microsofts compiler.

The short answer is go ahead and use MonoDevelop under OS X if you can live with the small rough edges. There is when you finally deploy your finished .dlls there will be no difference.

I hope this answers your questions, feel free to follow up with more if you got any, and be sure to show us what you're building. We love to see what people are up to!

Best,
Oliver

[danielm]

Cool, thanks for the detailed answer. I guess I will just forge ahead with MonoDevelop then, keeping VS as a back-door in case of trouble. A native/Gtk GUI or text console for the server eventually would be excellent.

[Benolds]

I'm new to Player.IO and I'm on a Mac, so after reading this thread I decided to try MonoDevelop. I've got the FridgeMagnets example to work, but I have two problems.

First, after I start up the local server with Mono, and then start up the game in flash, after about 15 seconds I lose connection to the server and get this message in MonoDevelop: The application was terminated by a signal: SIGHUP

Also, how do I get a DLL file with MonoDevelop? I can't find it anywhere. Do you have to do anything special to create one?

Thanks

[tomoprime]

Where do I find the Mac version of Player.IO? I wanted to test the Dev server locally with my Unity machine (Mac).

If I try to run the server on a separate windows machine my Mac Unity client gets "Access Denied" errors. Note I hardcoded the ip address to the windows box in mushroom game. I allowed the windows firewall to open the ports. Sometimes I get through and can do testing. 7 out of 10 times I cannot.... Note if I deploy the webplayer to a second windows machine it cannot connect to the dev server either.

My client is not using localhost but it seems that way. So where can I download the Mac port to do some testing on?

[Oliver]

Hey,

There is no particular special mono-port of the development package, you're supposed to be able to use the current one.

We're not officially supporting Mono yet, and there are a lot of different issues left before we'll officially support it, so for now you'll get a much smoother development experience by running the development server in a virtual windows machine.

- Oliver

[Jos]

I get it kind of working. The "login" panel opens. I enter my user name and password, and when i click the 'Login" button, i get a:

Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_PROTECTION_FAILURE at 0x00000000bf7fffdc
Crashed Thread: 0 Dispatch queue: com.apple.main-thread

Which seems pretty horrible. I figure i've got some incorrect version of the Mono-lib. I downloaded the latest version (2.10) rather then the long-term stable (2.6). I think i'm going to try installing that next.