Messages

The newest builds work for me on iOS too. But I have not done extensive testing, really. I would also recommend not to update your source to the latest "refactory" or "master" version because this might have new bugs and will have zero benefit for only running on iOS.

When was the unsafe change made? I have a beta of Gemini Rue on iOS running on the Wadjet Eye boards at the moment, and we are getting a lot of crash reports.

Doesn't sound so good. If you have something that seems to be a general port problem please forward it to me. The most likely cause of crashes is still the multithreaded audio. If so I would expect it to mostly affect devices with multiple processor cores.

The problem is with the MakeAbsolutePath() function because it assumes that paths are always like Windows- oder Unix-paths. But on the PSP they are a weird mixture. You have sort of drive letters (like ms0: or ef0:) and forward slashes. I will commit a (temporary) fix.

The crashes are plugin related... again. It is most definitely something stupid that I did. I won't need crash logs because I can reproduce the errors.

Edit: I spoke too soon. The crash is in the script interpreter. Maybe misaligned data? I will investigate this further.

I uploaded new daily builds.

It is a port problem and it seems related to a recent change in the script interpreter. We will look into it.

if you still want the logs id appreciate a pointer for how to best compile for you?

If you are asking how to get them to me, you can just mail them to jjs@jjs.at. Maybe I am not correctly understanding the question though.

I can reproduce the problem. Pretty sure that it is because QFG2 moves the mouse cursor downwards onto the popped up action menu when selecting the "special" icon. If you then move the mouse up again it automatically closes that menu. This is exactly what happens on Android because the mouse cursor stays on the top of the screen under the finger.

If the "relative" mouse motion is selected in the engine settings this should not happen but of course the game becomes more cumbersome to play.

Not sure how to fix this but I will think about it some more.

Longpressing the "menu" button does not bring up the software keyboard?

The main issue for stability should be multithreaded audio processing. You can disable that in the settings menu. But the newest daily build has an additional fix in that regard so your crash might (or might not) be fixed.

Can you enable "Log debug messages" in the settings menu and upload your logcat file when it crashes again? It contains all kind of system messages, so you might want to remove everything that was logged before AGS started.

Ok, this is a real problem and I hope that it can be solved by setting the API level only.

Can you please try this version: http://jjs.at/temp/AGS_api11.apk

And if it doesn't have the desired behaviour, this one: http://jjs.at/temp/AGS_api8.apk

Unfortunately I don't have a device without hardware buttons and the emulator doesn't really cover this (there is a setting for deactivating the hardware buttons but it doesn't make the emulator show soft buttons).

I had changed the target SDK version to 4.1. That way it shows the default system styles for the menus, before it was always in 2.x style. Probably this change has removed that icon. But the onscreen keyboard should pop up if you longpress the "menu" (hardware) button. I must admit that I am not sure how that "soft menu" button worked before.

GR I have has version 3.21.1111, while you are using 3.21.1115... was the Steam version of the game rebuilt on later AGS?

The Steam version is certainly different. It has achievements and it doesn't use the snowrain plugin.

Are you supposed to get an achievement at that point in the game? Do you get the same error when playing the game inside Steam?

Not sure if looping sound really points to an audio related crash. If the engines main thread receives an exception the audio buffer will not be updated anymore (since the original engine is singlethreaded).

I don't know how this policy is enforced. Maybe they look at the system call imports and refuse the app if it uses library loading related APIs? Apps can at least write to their own (sandboxed) documents directory so theoretically they could unpack anything they like there.

That code you linked to wrote his own version of the operating systems DLL loader. If you place the library sections correctly in memory and allocate the data sections it of course works. That is the same way a user mode binary loader for e.g. an exploited game console loads programs. After you have loaded the library you can just get function pointers to the exports and jump to it.

Let's not forget that the engine does not currently run on anything newer than Snow Leopard (because Apple removed the Carbon framework). This is a separate issue to mono compatibility but not being able to test the game would be a dealbreaker too.

Hold down one finger for more than a second. It gets closed the same way.

Not sure how good it will be for playing the game though, it might not have all required keys.

One nice benefit of removing the encryption might be that games compress better. That being said, I don't know how good the encryption is at making everything look like noise.

Meh, I would leave the encryption as it is. There is no point in making it "stronger" because the engine is still open source and the key has to be stored somewhere.

I would say that the kind of person who rips off your art assets will more likely screenshot them instead of writing a decompiler no matter how easy or hard it is to do so.

But I never made a game, so I am no expert on this.

Perhaps there's a sense in just building game data separately without windows exe?

Yes please! Also compiling to a single file: http://www.adventuregamestudio.co.uk/forums/index.php?issue=319.0

Just tried that with the Linux build. It kinda works in the way that you can let the editor attach the game files (by replacing acwin.exe) but the game cannot find the data automatically. You still have to give the attached file as parameter but then it works. This could easily be changed in the engine though.

The attaching works because the data file has a file header at the end of it that indicates its length. So it can always find the real header regardless of where it is attached (IIRC).

E: Not sure how useful this is though. Especially Linux is tricky because of the different flavours that all have different library versions. So it could only be done by statically linking everything. The better idea is building packages for major distributions if you want to release (commercial) Linux games.

We could probably do with an OSX thread, but let me say this here: OSX is only supported up to Snow Leopard (10.6). Lion and Mountain Lion are missing frameworks necessary for Allegro 4.

I will also add libraries for Intel and PPC OSX to the respository so that building AGS is easier. Right now it is kind of a pain because you have to get the library dependencies from fink/macports and I think you have to compile Allegro yourself.

E: If you want to develop a game for cross-platform use you don't have to do anything special. As Crimson Wizard said, the ports just run with the Windows data files. For mobile platforms you might want to avoid high resolutions and dependency on a keyboard. Also only use plugins that are open source and available on all platforms (flashlight, snowrain, AGSBlend and Lua are fine).

If you want to compile with anything but Visual Studio 2008 you will get linker errors. This is because the libraries (especially Allegro) are built with that version and expect a certain version of the VC runtime. Building the debug configuration probably works with few tweaks but the release configuration does not link with anything but VC 2008.