News:

Use the "Forum Search"
It may help you to find anything in the forum ;).

120.0 for OSX using Cocoa/Quartz

Started by Ashley, May 29, 2014, 11:17:18 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Ashley

I wanted to play around with the new double-height and climates features, so I compiled this (couldn't get the OSX SDL app to work).

simutrans_120.0rc_3.dmg - (7.8mb - sha1: 8c20bf20e42494edbed120ec43892acd80dc2abc) - Fix issues with click-drag view scrolling.
simutrans_120.0rc_2.dmg (7.8mb - sha1: dc9154f0148aa93a67b347f6cfdc5ca7c6b4cf5e) - This includes pak64 120.0 in the app bundle, but you can add other paksets.

The app menu has two links to open file locations (cmd+O - opens the user directory ("~/Library/Simutrans") with saves/screenshots etc, cmd+B opens the simutrans folder in the app bundle so you can easily put in new paksets).

Only tested it on OSX 10.9.

Update: fixed some bugs.
Use Firefox? Interested in IPv6? Try SixOrNot the IPv6 status indicator for Firefox.
Why not try playing Simutrans online? See the Game Servers board for details.

TurfIt

Can you post the source? I'd like to see how it compares performance wise with the SDL2 backend.

A few issues:
The OSX window starts out larger than the game rendering area, although the ticker does extend all the way to the right edge. See attached screen shot. Resizing the window fixes.
The mouse button is acting like the right button. i.e. It scrolls the map (and rather hyper at that!). While construction tools work, the inspection tool does not. Clicking on objects in the gameworld results in nothing.
settings.xml doesn't get created if you close the app with the red dot OSX button. Not trapping the right message maybe?
Why changing the user directory location yet again? It would be nice if it didn't change every version...


Quote from: Timothy on May 29, 2014, 11:17:18 AM
(couldn't get the OSX SDL app to work).
SDL1, or SDL2?  Binaries from Sourceforge, or self compiled?

Ashley

#2
Source is on github: https://github.com/tbentropy/Simutrans-OSX

I tried the pre-compiled SDL version from here: http://sourceforge.net/projects/simutrans/files/simutrans/120-0/simumac-120-0.zip/download

It works if I install the SDL2 framework myself manually.

Left-mouse drag-to-scroll when using the inspector tool is a feature of 120.0 I believe (welcome on the Mac too since right-click drag-to-scroll is a pain with a trackpad). Clicking things with the inspection tool works for me though, so that's weird. I'll try it with a mouse instead of the trackpad.

Other two points are probably fix-able, I shall tinker some more.

The user directory ought to be ~/Library/Simutrans (Application Support is apparently for "non-document specific files which aren't essential for the application to run" - so pak files maybe?), I was also thinking that making the game look for pak file folders in this location as well as in the app bundle would be a good idea (since opening the bundle and sticking in more files is kinda ugly).

Edit: Fixed most things except the weird scrolling which I can't reproduce.
Use Firefox? Interested in IPv6? Try SixOrNot the IPv6 status indicator for Firefox.
Why not try playing Simutrans online? See the Game Servers board for details.

Ters

I'm a bit torn over whether pak files bundled with the executable is a good idea. If there is a bundle for one's only preferred pak set, it's unbeatably convenient. But for those who like rare pak sets or want to customize the bundled pak sets a little, it sounds a bit ugly indeed. Now messing inside a bundle on Mac might not be much different in uglyness from poking around in Program Files on Windows or /usr on Linux. For that reason, an ability to load pak sets from the user directory could make sense for all platforms. A drawback is that it doubles the number of possible setups that must be considered when doing development, testing and support.

Ashley

#4
The way I'd do bundling is to bundle a zip of the pakset and have the application unzip it into the user directory on first run, then it could be customized or additional paksets added by the user in a location which makes sense. Ideally there'd be a UI in the application that provides a listing of paksets online and lets the user download them too (I contemplated doing this but decided that doing it specifically for the Mac platform would be a waste of effort since it doesn't benefit other platforms, it needs to be something built into the game itself really).

Having the user modifying the app bundle means you can't do code signing and also means you can't just download an updated version of the app without going in and adding your paksets again every time.

When I was contemplating distributing Simutrans on the Mac app store I decided that the easiest way to do it would be to simply create multiple "Simutrans" games, each with a different pakset bundled. E.g. "Simutrans pak128", "Simutrans Comic" etc. Given that the game package without pakset is only about 11MB having duplicates wouldn't be that much of an issue if someone wanted more than one pakset version. It would simplify the user experience dramatically and work better with the app store distribution/update model. Those who wanted greater flexibility could just download the standalone version and customize to their hearts content of course :)

(Having it on the app store would require faffing about with sandboxing though, not impossible by any means and I made some progress on it).
Use Firefox? Interested in IPv6? Try SixOrNot the IPv6 status indicator for Firefox.
Why not try playing Simutrans online? See the Game Servers board for details.

prissi

Windows does not require such and GUI for pak set download, since it is delegated to an external program. (On the MAC it is just calling a terminal script, get_pak.sh) However, there are probably some graphical installer for the mak who can run an NSIS script (or something similar) for downloading pak sets.

MCollett

Quote from: Timothy on May 30, 2014, 09:05:36 AM
The user directory ought to be ~/Library/Simutrans (Application Support is apparently for "non-document specific files which aren't essential for the application to run" - so pak files maybe?), I was also thinking that making the game look for pak file folders in this location as well as in the app bundle would be a good idea (since opening the bundle and sticking in more files is kinda ugly).

"document specific files" (i.e. saved games) shouldn't be in the Library in the first place: they should be ordinary, visible files that the user can keep anywhere he pleases, not just in some hard-wired save folder (and ideally, open with a double-click).  Anything else that you might put in the Library (pak files, settings, simuconf, addons, ...) seems to me to fit under Application Support.

Best wishes,
Matthew

Ters

Quote from: MCollett on June 05, 2014, 10:02:46 PM
"document specific files" (i.e. saved games) shouldn't be in the Library in the first place: they should be ordinary, visible files that the user can keep anywhere he pleases, not just in some hard-wired save folder (and ideally, open with a double-click).  Anything else that you might put in the Library (pak files, settings, simuconf, addons, ...) seems to me to fit under Application Support.

Best wishes,
Matthew

I don't think anyone will be writing a usable file system browser for Simutrans anytime soon, so we're kind of stuck to one directory. In fact, few games give you an ability to place save games in different directories. Some programs that do offer a save/open dialog fail to take into all possibilities. A program at work simply can't save into the Documents folder, since it deals with directories rather than folders, and the directory behind the Documents folder is located on a network share, which it knows nothing about.

Simutrans does however mix "documents" and "non-documents" in one directory (and subdirectories thereof).

Double-clicking should be possible. Most of it might be implemented already.

Ashley

Added complication for OSX is that in order to save/load files from arbitrary locations on the filesystem while using app sandboxing you have to use the native Cocoa file browse dialog - else you can't access anything outside of the sandboxed filesystem.

The app store version of Sim City 4 for OSX is a reasonable demonstration of how it would need to work, save games live under:

/Users/<username>/Library/Containers/com.aspyr.simcity4.appstore/Data/Documents/SimCity\ 4

The idea is that each app gets its own virtual filesystem which it can't read outside of, and where it puts all its app-specific files. Users can access this filesystem themselves through Finder, but the application can only access the "outside world" through the save/load file dialog built into Cocoa.

(All only needed if we wanted to put Simutrans in the OSX app store)
Use Firefox? Interested in IPv6? Try SixOrNot the IPv6 status indicator for Firefox.
Why not try playing Simutrans online? See the Game Servers board for details.

Ashley

simutrans_120.0rc_3.dmg - (7.8mb - sha1: 8c20bf20e42494edbed120ec43892acd80dc2abc)

This version should fix the issues with scrolling.

TurfIt, did you have a chance to do a side-by-side performance comparison? I am not seeing that much of a difference between this and the SDL2 version myself.


How much interest is there in making a distribution for the mac app store? I would just go ahead and do it, but it's $99 for developer membership and the ability to submit apps there.
Use Firefox? Interested in IPv6? Try SixOrNot the IPv6 status indicator for Firefox.
Why not try playing Simutrans online? See the Game Servers board for details.

TurfIt

Quote from: Timothy on June 13, 2014, 04:44:17 PM
TurfIt, did you have a chance to do a side-by-side performance comparison? I am not seeing that much of a difference between this and the SDL2 version myself.
Haven't had a chance to look yet.


Quote from: Timothy on June 13, 2014, 04:44:17 PM
How much interest is there in making a distribution for the mac app store? I would just go ahead and do it, but it's $99 for developer membership and the ability to submit apps there.
Aren't there licensing problems with the app store?

Ashley

Use Firefox? Interested in IPv6? Try SixOrNot the IPv6 status indicator for Firefox.
Why not try playing Simutrans online? See the Game Servers board for details.

prissi

GPL is not allowed. I think there is not enough Artistic Licence around for Apple to bother ...

Ters

One can speculate that the reason Apple doesn't allow GPL is that GPL requires that source code is available from all distributors offering binaries. Artisitic license doesn't have that requirement. Neither does the far more common BSD-style licenses, nor the not-quite-so-common-for-code-as-for-images Creative Commons licenses.

But there is also the possibility that Apple requires some Apple-specific clauses in licenses for things published through their store. Big companies put all kinds of sneaky and arrogant requirements in the terms of use these days.

MCollett

Quote from: Ters on June 14, 2014, 11:27:45 PM
One can speculate that the reason Apple doesn't allow GPL is that GPL requires that source code is available from all distributors offering binaries.
[...]
But there is also the possibility that Apple requires some Apple-specific clauses in licenses for things published through their store.
As I understand it, the problem is that when you download from the Apple store, one of the terms of service is that you promise not to give copies to other people.  This is entirely reasonable for commercial software, but incompatible with the GPL, which does not allow any constraints to be placed on further distribution.  Permissive open source licences do allow redistribution under additional constraints, so are legally compatible with Apple store distribution (even though the rule in question is pointless for them).

Best wishes,
Matthew

prissi

The artistic licence requires a sourcecode for any modified distribution. There is not really a difference to the GPL. (Which is principle could be a printout on tone slabs or microfiches).

The difference is that the GPL says "You may not impose any further restrictions on the recipients' exercise of the rights granted herein." while the Artistic Licence says "You may" i.e. you can distribute and if you do you must add a copyright note. See here for GPL.

Ters

Quote from: prissi on June 15, 2014, 09:44:52 PM
The artistic licence requires a sourcecode for any modified distribution. There is not really a difference to the GPL. (Which is principle could be a printout on tone slabs or microfiches).

The difference is that the GPL says "You may not impose any further restrictions on the recipients' exercise of the rights granted herein." while the Artistic Licence says "You may" i.e. you can distribute and if you do you must add a copyright note. See here for GPL.

As far as I can gather, there are two key difference between GPL and Artistic License in this regard.

One is that the former would require the source code to be available in the App Store, whereas the latter makes it possible to distribute to provide the source code by other means. This is perhaps a rather strict interpretation of of GPL 6d, dismissing App Store as simply a "network server". I also consider 6c as not applicable, along with 6a, 6b and 6e obviously. (6d also seems to be the strictest in section 6.)

The other is that GPLs requirements apply equally to modified and unmodified distributions, whereas Artistic License only require these things for modified distributions. Will Apple modify contributions when putting them in App Store?