Messages

It would be useful to be able to do it in script only, if just to simplify things. But I couldn't find any functions that send a keypress to the engine.

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

Cannot they use Wadjet Eye's old port? The game is old enough to be runnable by that version.

Sure but you need to know how to build things with XCode.

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.