Messages

If anyone is further pursuing a commercial version of JJS' amazing port, I'd be interested as a financial backer... I'd love to see this in a neat download with an easy game import coded in from our Archives... Send an email to Paul@8BitAirwaves.com if you're interested in putting this together, I just don't ha e the technical skills to do it myself!!

Wadjet Eye has tried throwing money at people for this project but everyone is a gentleman amateur and doesn't want to accept money

I checked the specs of iOS devices here: https://en.wikipedia.org/wiki/List_of_iOS_devices
Apparently, newest devices have like 1-2 GB of RAM, but previous versions had much less, like 128-512 MB. I do not know how actively older iPhones are used in general, and not sure whether it will be safe to hardcode default of 100 MB sprite cache for iPhone then. I can enable reading this property from config file though (do not see why not).

I tried setting to to 100mb and it didn't seem to make any difference to the first 5 minutes of Primordia. Ran fine but not any faster or better.

I've really let this go (busy on other stuff), but we at Wadjet Eye are interested in releasing our games on OSX. Our old port by Edward Rudd of Humble Bundle isn't up to commercial standards anymore. It would be fantastic if OSX compatibility was part of the standard project. If anyone knows of any OSX developers who would be interested in working on this project, let us know. Otherwise I might try and muddle through (but I'm not experienced on Mac.)

The issue with the sticking mouse cursor was the worst for us (that's fixed, right?), but we also had issues with the right click not working, which is really important for our games.

We also need some fixes done on some Steam Integration stuff, but that's probably not relevant to the open source project

There is work on porting the engine to OSX, but for now, most players find it easiest to use WINE.

I think M. Ouxx was wondering why you couldn't fake the keypress internally, rather than rely on a plugin. It's essentially just a question of appending a character to a string when a button in pressed, and that seems like it should be pretty straightforward.

By "internally" do you mean "in script" or "in the engine"?

I used the plugin to allow you to activate the keypress from within the script. So when you tap on a GUI element, it calls the FakeKeyPress() function to fake a keypress, and this allows me to simulate a keypress without significant recoding of existing games.

Can anyone tell, whether is would be acceptable to increase default sprite cache size to 100 MB for iOS device? We have a restriction in the iOS port code that limits cache size to 20 MB always (even regardless the config), and I do not know why is that so.

I don't know why either.

[adding]

Also, I heard monkey0506 is currently trying to make AGS support adding new objects into game without breaking saves, which (supposedly) should be easier than making universal update system.

Unfortunately this didn't work out. It was vastly more complicated than we suspected

I use a plugin to allow me to fake a keypress when a GUI button is pressed.

I don't understand why that would be required.

It's required for our games, maybe not for your games. Wadjet Eye games have a lot of puzzles where you need to type something into an in-game computer. Such as the scene in the Shivah where you must log into Rabbi Stone's computer to search for certain terms. So we need a keyboard system.

1) In your port, did you manage Right-click, and if so, how does AGS interact with the "fake" right-click from iOS? (the player actually holds one finger on the screen and taps the other finger while still holding). Do you simply intercept the regular right-click event in AGS o does it work differently?

I simply don't use right-click in iOS ports. I use a verbcoin system, with a hand for left-click and an eye for right-click. The two finger tap is too clunky for a commercial release, although it is necessary to be able to play a game compiled for PC on an iPhone.

2) How do you manage the virtual keyboard in the script? For example, let's say that the user is about to save his/her game by typing the name into a TextBox. What event makes the virtual keyboard appear on top of the game?

I gave up using the in-built virtual keyboard. It didn't work very well. I construct a virtual keyboard using GUIs within AGS and use a plugin to allow me to fake a keypress when a GUI button is pressed.

I think it'd be a great idea to hire someone to maintain AGS. The question for me is not *whether we* should do it or *how much* it would cost, but *who*? We at Wadjet Eye have offered several people money to update the engine in limited ways. I'm pleased to announce that Michael Rittenhouse (monkey_05_06) has signed a contract with us to do some small-ish paid updates that we desperately need as our "intern." I'm not sure whether he would be interested in more long-term and extensive updates. I'll have to ask him.

But as for professional contractors, the skill-set of "aging code compatible with 6 different platforms" is hard to find. I know that monkey_05_06 is only interested in PC and Linux and we really need someone to update the Mac and Android versions, which are basically non-functional at the moment.

So Does Janet Gilbert will put here or github source or method of this port ?   

AFAIK she keeps it open source and available for public use in her repository, but I do not really track her progress right now, so it is up to her to explain where you get the latest version and how you use it. I guess the fastest way is to contact her directly for this kind of info.

There is no real progress on Mac at the moment, but the version that StillInThe90s linked to is just fine for most uses.

It will always be open source. We literally *can't* make it closed source as AGS is open source - we'd be breaking the terms of agreement! Besides, we don't want to

Anyone know a Mac programmer? We'd like some things fixed

As I understand it, iOS devices are getting harder and harder to jailbreak. Is anyone using the jailbroken version of AGS right now?

What bugs do we currently have on Wadjet Eye's Mac games and installers? I'm making a list for fixing. Have they been fixed in the latest version of the official engine?

What bugs do we currently have on Wadjet Eye's Linux games and installers? I'm making a list for fixing. Have they been fixed in the latest version of the official engine?

I didn't mention it because it looked like an inevitable part of upgrading to 64-bit - it looked like some integers were upgraded from 32-bit to 64-bit in the save functions.

This should not be happing too, because we tried to make saving and loading independent on platform bitness to make saves portable from one system to another. Even endianess differences are handled.
I have only two guesses: the previous version you were using could have some bug in save system that we later fixed; and that difference is introduced by plugin(s), that save their own data.
Well, if not there's still some mistake in our code.

You know, there was! There was a bug with saving while background speech was onscreen. Maybe that was it.


Glad to know my work was helpful to you, Himalaya!

My main concern about merging further updates from the main AGS project is save game compatibility, as it always has been. The update to 3.3.3 broke everyone's saves, and I feel really bad about that, although there was nothing I could do. I need to be very cautious in merging updates for that reason alone. People who have bought a commercial game get pretty upset when an update invalidates all their saves!

Wait... what? What version were those saves made in? I am specifically trying to keep savedgames compatible to 3.2.1, as well as with previous 3.3 releases. If there was an incompatibility, it could be a mistake on my part. Why did not you mention this earlier?

E: I would also like to point out that it is possible to write savegames converter if nothing else helps.

Well, it's too late now!

I didn't mention it because it looked like an inevitable part of upgrading to 64-bit - it looked like some integers were upgraded from 32-bit to 64-bit in the save functions.

Good to hear from you, Crimson Wizard!

Some of my code is definitely incompatible with the main branch, mostly in the control system changes. It could probably work with some #define 's to make sure it only compiles on the right platform.

My main concern about merging further updates from the main AGS project is save game compatibility, as it always has been. The update to 3.3.3 broke everyone's saves, and I feel really bad about that, although there was nothing I could do. I need to be very cautious in merging updates for that reason alone. People who have bought a commercial game get pretty upset when an update invalidates all their saves!

As for the plugins, they work for me, but I can't guarantee that they are safe in general. We don't use many plugins (makes things easier!)

This is an absolutely spectacular post! I am awe inspired on the selflessness shown here. I know I was hoping to eventually post iOS versions of games, even for free.

I'm sure the AGS community here is eternally grateful! I know I am.

Thanks! :-)

I hope we can see more AGS games on iOS now! You still have to pay $99 a year even to release free apps, unfortunately.

1)Is 3.3.3 version safety for iOS 64 bit now?

Yes, the dev team have put a lot of effort into making AGS work with 64-bit now.

2)I heard .ogv theora codec is very slow on iOS is it right?

I don't know, I don't use it. I thought you were going to experiment and find out?

3)As Joseph said is here any way to ready Android port for Play Store too?

Nope! We used a porting service (Apportable). Last time I looked at it, the Android version needed *a lot* of work to be ready for commercial releases.

I've put a big post in the engine forum below about how I updated 3.3.3 to work on iOS. It serves as a complete guide to releasing an AGS game on iPhone or iPad. I didn't want it to get lost in this biiiiig thread so I made a new thread :-)

How to release an AGS game on iOS
---------------------------------

Hi, this is Janet from Wadjet Eye. I keep getting people asking how to release commercial AGS games on iOS, so I thought I'd write a full account, from start to finish. You can follow this (with reference to my fork of the engine) or you can just fork my fork (easier.)

Overview
--------

When I first released an AGS game on iOS, I based it on JJS's (Jochen Schleu's) brilliant port of 3.2.1. Over a couple of years the AGS project moved on but I was unable to take advantage of the updates due to my old code. I finally decided to take on the task of updating my port to the latest version (3.3.3), as well as adding new fixes to problems that have arisen as the iOS operating system has grown and changed. The biggest problems were that Apple now requires a 64-bit build in anything submitted to the App Store, and recent changes to iOS have made the engine unstable, crashing more frequently than I am happy with.

I decided to keep an account of the process, because people keep asking me what I did to get a version of AGS that can be published on the App Store. Jochen's version was aimed at people with jailbroken iPhones who wanted to put their existing PC AGS game collection on iOS. This wasn't ideal for Wadjet Eye as it didn't have the signings necessary for submission to the App Store, and also the controls were designed to be universal, so that any AGS game could be played, which ended up feeling kind of clunky for the Wadjet Eye style of interface (which is classic Lucasarts inspired.)

My version of this can be found at:

https://github.com/JanetGilbert/ags

Branch name: iOS

Feel free to fork it to your own account for your own use; AGS is open source after all!

Code Signing
------------

You need to go to the Apple Developer website to set up the code signing and profiles.

https://developer.apple.com/

Enroll in the Apple Developer program ($99 a year). You can't really avoid opening your wallet at this point; you can fuss about with jailbroken devices and old versions of XCode if you really like headaches and never want anyone else to play your game. :-)

Go to the "Member Center", and the "Certificates, Identifiers & Profiles" section.

Go to "Certificates", and make yourself  "Development/iOS and App store" and "Production/App Store and Ad Hoc" certificates.

Go to "Identifiers" and add an App ID for your game (eg com.wadjeteyegames.YourGame)

Go to "Devices" and add the UDIDs for all devices you will be testing on personally. You used to have to add all beta tester UDIDs here, but Apple has now added a service called "Testflight" that makes this unnecessary. The UDID is the string under "Identifier" for your device if you open Windows/Devices from the XCode menu.

Go to "Provisioning Profiles" and make "iOS App Development", "App Store" and "Ad Hoc" profiles.

Go back to XCode. Open the XCode/Preferences menu item. Go to "Accounts" and click the "+" sign in the bottom left to add your Apple ID. Any time you make a change in Apple Developer, you need to come back to this page, click the "View Details" button, and then the refresh arrow in the bottom left of the details page. The profiles should then refresh. If some seem to be missing, leave it a while and try again. I am honestly not sure why sometimes this doesn't work. Sometimes exiting XCode and re-trying seems to help. It's magic. If anything ever goes wrong with compiling your game that doesn't make sense, refresh, clean and rebuild. Solves 90% of all possible problems.

Create a Project
----------------

Duplicate the ags project and open it in XCode (open ags.xcodeproj)

Rename the project to your project name. Slow double click on the name of the project in the top-left (just above something that says something like 1 target, iOS SDK 8.2). Type in your project name (eg YourGame). If you can't see the game name, click on the icon in the top left that looks like a folder. Don't ever rename the game in any other way; XCode needs to rename a bunch of internal things that get really borked if you try to edit the .xcodeproj in a text editor. I found out the hard way!

Click on the name of the project in the top left. You should now have a pane which has a project and a target, hopefully both called YourGame.

There are two sections in the middle horizontal column of the screen, one labelled "Project" and one labelled "Target", which should both be named "YourGame." This section is called "General Target Settings"

The "Project" is the game project overall, and the "Target" is a subset of that. I use multiple Targets to make different versions of a game with different files included, all in one big project. I use this feature often when making Mac games for Steam/non-Steam, but I've never made more than one Target for an iOS game. Some things need to be set in *both* "Project" and "Target", so if something doesn't seem to be taking effect, check that it is the same in both "Project" and "Target."

General Target Settings
-----------------------

*** Project ***

** Project Info **

Set iOS Deployment Target to 5.1.1. You have to enter this in the box manually. This version is significant because it allows you to retain compatibility with the iPhone 3G, and also use 64-bit builds. If you don't care about compatibility with older devices, set it higher.

** Project Build Settings **

* Architectures tab *
Architectures: Set this to $(ARCHS_STANDARD_INCLUDING_64_BIT)
Valid architectures: Set this to arm64 armv7

* Code Signing tab *

Set the Debug Code Signing Identities to your Developer ID, and the Release code signing identities to your Distribution ID.

Set the Debug Provisioning Profiles to your Ad Hoc profile, and the Release Provisioning Profiles to your game's Provisioning Profile.

Remove "-gta" from Other Code Signing Flags/Debug. This allows the app to be deployed on Jailbroken devices, but prevents it compiling to be released on the App Store.

*** Targets ***

** General **

* Identity tab *

Bundle identifier: Don't set here, set in "Info"
Version (CFBundleShortVersionString): The version of the game displayed to users. Try 1.0. Increase every time you publish a new version to the public. 
Build (CFBundleVersion): The internal build number. Increase by every time you publish externally (even to Testflight)

* App Icons and Launch Images tab *
Set up your icons here! You need to use an "Asset Catalogue"

Here are Apple's constantly-changing icon size/launch screen size requirements: https://developer.apple.com/library/ios/documentation/UserExperience/Conceptual/MobileHIG/IconMatrix.html

Ugh. They literally add more required images every iOS version update. This used to be nice and simple.

When you add the icon asset catalogue, you need to drag the appropriate sized icons to the box (from Finder.) This is like a cute little puzzle game. Watch out for the 2x and 3x sizes - this means that you need an icon 2 or 3 times the listed size (eg 57x57 x2 = 114x114)

The launch image asset catalogue is much the same, except it doesn't tell you the pixel sizes. Click on the icon in the top right that looks like a box with a vertical line on the right side. This gives you some stats including the expected size of the image.


** Info **

Ensure the Bundle Identifier is set to the same thing as in Member Center/Identifiers, and the Status Bar is initially hidden.

** Build Settings **


* Architectures tab *
Set "Architectures" and "Valid Architectures" to same as "Project"

* Code Signing tab *
Set "Code Signing Identity" and "Provisioning Profile" to same as "Project"

Remove "-gta" from Other Code Signing Flags/Debug. This was to allow the app to be deployed on Jailbroken devices, but prevents it compiling to be released on the App Store.


** Build Phases **

* Run script *

Remove the script relating to code signing (it begins "export CODESIGN_ALLOCATE" and ends "fi") - this is code allowing the engine to run on jailbroken devices and will interfere with compilation of a version that can be submitted the the App Store.

Schemes
-------

Schemes are necessary for compiling the game. At the very top of the screen, just to the right of the "Play" arrow button, there should be a label that still reads "ags". Click on "ags", then select "Manage Schemes" from the drop-down. Delete the "ags" scheme. Then use the "+" to create a scheme named "YourGame"


The Project Navigator
---------------------

This is the section of the screen to the left, where you renamed the project in the section "Create A Project." It has several views - ensure you are using the top-left view, by clicking on the top-left icon that looks like a single folder.

*** Resources ***

This section is what you will be looking at most often. You need to add the files ac2game.dat, audio.vox, speech.vox, ios_ipad.cfg, ios_iphone.cfg and any other data files your game requires. Add them by dragging from Finder.

ac2game.dat is just your windows .exe renamed. You can snip out the unnecessary executable parts by opening it in a hex editor and searching for the string "PADDING". There is a block of text that repeats "PADDINGXX" for a bit, then "CLIB". Chop out everything before CLIB (but leave CLIB). This saves a little space.

If you wish to make more than one variant of a game, you can create multiple targets, and include different resource files for each target. I find this very useful for OSX to make different builds for Steam and non-Steam.

* .cfg files *

Here's what I use (with the variants for iPad)

[misc]
config_enabled = 1
rotation = 2
translation = default
[controls]
mouse_method = 0
mouse_longclick = 1
[compatibility]
clear_cache_on_room_change = 0
[sound]
samplerate = 44100
enabled = 1
threaded = 0
cache_size = 10
[midi]
enabled = 1
preload_patches = 0
[video]
framedrop = 0
[graphics]
renderer = 0
smoothing = 1 (0 on iPad)
scaling = 1
super_sampling = 1 (0 on iPad)
smooth_sprites = 1 (0 on iPad)
[debug]
show_fps = 0
logging = 0

The variants for iPad produce a "blockier" more pixelated look that I like (but some people do not), as opposed to a blurred "anti-aliased" look that I prefer on the iPhone. Experimentation is key here to find out what works for your game.

Since there is only one (universal) build, I include settings files for both iPad and iPhone and select the right one at runtime.

Libraries
---------

The standard version of AGS has only 32-bit libraries. Apple no longer accepts builds without 64-bit libraries.Obtain these from me or just look in my fork of AGS (ios branch) and take them. There are also XCode projects for these libraries available in my fork of AGS if you need to recompile them.

Code Changes
------------

Here is an overview of the changes I made to the code to get Wadjet Eye Games running smoothly. My plan was to make them play as if they had been designed for touch-screen platforms, with no awkward work-arounds that betray their PC origins.

To see exactly what I did, take a look in my fork of AGS, "iOS" branch.

*** Path to game files ***

The game files are added in Resources, and copied over to the root of the iOS App. (YourGame.app.) This is not where AGS expects to find them.

The engine is still working under the assumption that you are running on a jailbroken device and you will manually copy over into the documents folder and select your game files. I remove the ability to select files, and just load the default file name (ac2game.dat) in the root folder.

*** Dragging and Dropping ***

("Drag'n'Drop")

This commit ("Drag'n'Drop") removes the ability to run standard PC AGS games in a jailbroken iPhone, (by removing the ability to right-click) but allows much finer control over touchscreen controls in script.

JJS designed the iOS controls to be one-finger-tap for left-click, and two-finger-tap for  right click. This was to allow existing PC versions of games to be played on iOS device.

I re-wrote the game script to use a verb-coin interface on iOS, making a right-click unnecessary.  The game script is able to tell when and where the user's finger is pressed to the screen, and when it is removed. This allows taps and tap-and-drags to be simulated in-code.

*** Tap past dialogue ***

("Tap past dialogue on mouse up, not down.", "More responsive dialogs")

The engine, by default, skips past dialog when you press your finger to the screen. I changed this to when you press and release, because the other way was accidentally activating the next dialog option.

*** Wadjet Eye Utils ***

("Added AGSWadjetUtils plugin")

This is a plugin that exposes some useful functions to the script.

FakeKeyPress() allows the script to pretend a key was pressed. This is used in Gemini Rue's combat system (which was key controlled on PC, button controlled on iOS) and for making a software keyboard (the built in keyboard does not look nice in a game, has some characters that AGS cannot display, and the close button is too small.)

It also has some functions for achievements, but I couldn't get them working. Anyone who wants to fix them up, tell me how you did it!

*** Cutscene skipping ***

("Cutscene skipping")

In PC AGS games, you skip cutscenes by pressing "Esc". Lacking a keyboard, I needed some other way. It needed to be something implemented at engine level because the script is blocked in cutscenes.

I first experimented by skipping cutscenes with a long press (hold the finger to the screen for a long time) but it was too easy to activate. So I hit upon swiping the finger from left to right at the top of the screen.

I'm not sure how many players use this feature, since most adventure games get played only once, due to being roughly the same each time. It was more a feature for debug (It gets OLD watching the same cutscenes every game) which I left in for people to use or not, depending on whether they remembered it existed.

*** Set Mouse Position ***

("Fixed mouse position")

Simple fix to the scaling of the mouse position. Without it, you can't correctly set the mouse position from script. I use this to place the cursor neatly in the middle of the screen when you change scenes.

*** Config Files ***

("Load different config files for iPhone and iPad")

ios_ipad.cfg is loaded on iPad, and ios_iphone.cfg on iPhone. The difference is in the scaling and smoothing settings, to give an "anti-aliased" effect on iPhone and a sharp, pixelated effect on iPad.


*** Misc bugs & bug-ettes ***

Small, but important.

("Memory leak in ReadString")
("Sound crash bug fix")
("Dismiss Display() boxes on mouse up, not mouse down")
("Fake keypress support")
("Hide status bar")
("Move iOS-specific classes")
("Bug: Keypress not detected")
("Restore audio after phone call")
("Crude hack to restore audio after answering phone call")


*** 64-bit ***

This was a beast of a bug. Apple introduced a requirement that all games must include a 64-bit build, but that meant that I needed to recompile all the dependencies with a 64-bit slice. The last time the libraries were compiled was in Ye Olde Times by JJS.

The system that JJS used to compile the libraries was called cmake. He wrote scripts for this that simultaneously patched the library code (with his bug fixes) and built them. Unfortunately the latter half of the process (building) was very outdated and no longer worked.

The system I came up with was to comment out the building portion of the scripts and just run the patching portion (see my commit "Allegro patch only"). Don't forget to use chmod u+x to get permission to run the scripts (which are in the ags\ios\buildlibs\armv7 folder)

I then made the resulting source files into an XCode project, and built the library as a Cocoa Touch Static Library. I built it for the required architectures armv7 and arm64. Set "Always search user paths" in "Build Settings" to "Yes" and set "User Header Search Paths" to "${SOURCE_ROOT}/[LIBNAME]/include ${SOURCE_ROOT}/../../nativelibs/fat/include" (or whatever needed) or else you will get errors like "Lexical or preprocessor issue 'internal/it.h' file not found" (double-click on the paths and ensure they are recursive). Remove the autogenerated files called something like allegro.h and allegro.m from the project or else you get a lot of errors like "Semantic Issue: Unknown type name 'NSString'". "Product->Destination" must be a real iOS device you have plugged into the computer, or else the Product will not be created even though the build apparently succeeds.

Then I encountered a different problem. I added the resulting library to my project and I got errors complaining "Undefined symbols for architecture x86_64" which turned out to mean that XCode expects a library containing both iOS device architectures (armv7, arm64) AND iOS simulator (i386, x86_64) architectures.

Unfortunately XCode can't build all these simultaneously in one library. You need to build for both device and simulator separately, then combine them using a command-line tool called "lipo"

First: build for device (Product->Build For->Running) THEN build for simulator (Product->Build For->Testing). Note that by default the  "Run" scheme is Debug, which you don't really want. So "Edit Schemes" and on the "Info" tab for "Run", set the "Build Configuration" to "Release". To build for simulator, you must set a simulator as "Destination"

Then use lipo to combine the two in the following way.

lipo -create Release-iphoneos/liballegro.a Release-iphonesimulator/liballegro.a -output liballeg.a

Use lipo to test success:

lipo -info liballeg.a

Desired result: Architectures in the fat file: liballeg.a are: armv7 i386 x86_64 arm64

Next
----

That should give you a working version of the AGS engine, but you still need to alter the script of your game to work with the engine. The most important thing to do is to remove all instances of needing to right-click in the game, because if you followed my instructions, you can now only left-click by tapping on the screen. I'll write a post in the future describing the process I go through to update the script of our AGS games to work well with iOS.

Feel free to email me with any questions at janet@wadjeteyegames.com. AGS is open source, and so is my fork, so you can fork it yourself if you want, or use any of my alterations freely.


https://github.com/JanetGilbert/ags

Branch name: iOS