Messages

[Update 26 August 2016:]

Instructions for building a standalone APK are available in the README of the OSD Android Studio project.

If anything there is unclear, please ask for help with that and I'll do what I can, but it's mostly straightforward.

* Install the necessary tools (Android Studio, JDK (not just the JRE), and NDK (available as a download through the Android Studio SDK Manager).
*** The OSD Android Studio project was made some time ago, and may need updating. I'm looking into several related things currently, but if this doesn't build please let me know.

* Use the jobb tool (part of the Android SDK, but see note below) to create an OBB file.
*** The tool published by Android has breaking bugs in the mainstream codebase that prevent it from working if you have a file size that is too small or too large. My jobbifier project is a replacement with fixes. You can download a prebuilt binary here, though I think that may be out-of-date (Update 26 August 2016: New version of tool uploaded to same URL 28 August 2016: Got automated building set up with GitHub, so the binary will now be hosted alongside the GitHub repo).

* Download the project files and be sure to include the git submodules. (Run "git submodule init && git submodule update" from a git command line inside your working directory for the project)

* Follow the remaining instructions in the README to replace the project's package name and resources.

From there you should be able to export a signed and aligned APK which is deployable over the Google Play Store. As I noted, some of these items may be out of date, but I will update them if they are non-functional.

P.S. You can create a personal fork of the OSD Android Studio project and set up a branch for your project. This will allow you to pull in any crucial changes made to the OSD project with minimized difficulty.

[Edit:]

It seems to me that it isn't an issue of lack of time so much as a lack of willingness to follow instructions. It is significantly easier to build a standalone APK using the methods I have already advised you to use than it is to switch your game to a new engine.

Edit: Sorry if I was a bit curt, but I've written more detailed instructions below. It isn't a unified, built-in (to the editor) process, but it's really not difficult (I promise).

Sorry for being unresponsive, but you should check out the Oceanspirit Dennis Android Studio project.

Integrating a full build process into the AGS Editor is likely too complicated to happen any time in the near future, but I have been able to port my jobbifier tool to C# using IKVM. This is an important first step because it includes a port of the required Java libraries for packaging your game files into an OBB file. This means that an editor plugin could be built to create the OBB file as part of building your game from the AGS Editor. Such a plugin could then also set up the necessary Android Studio project files to allow a two-step build process (build with AGS, then build with Android Studio)... I'll look into this approach and see what I can come up with.

[including]

I can confirm that using CW's branch (plus a few pull requests I've made: #349, #351, #352), the engine and editor (including AGS.Editor.Full.sln, not just AGS.Editor.NoNative.sln) can be built using Visual Studio 2015 Community (which is free!).

The official project files may not be able to be upgraded for some time due to other concerns, as CW explained above, but that will allow you to fully build everything without the Professional edition of Visual Studio.

[after]

Not entirely related, but CW, I can also confirm that with the pull requests I've submitted merged into your branch, I have successfully built the engine and editor with VS2015.

Aside from the pull requests, I also had to make sure to define the macro ALLEGRO_HAVE_STDINT_H and make one small patch to the Allegro almsvc.h platform header (don't #define int64_t and uint64_t). Also, the DirectX include folder must be listed after the Windows SDK include folders in the VC++ Directories.

Did a cursory glance over the posts here and didn't see this reported, sorry if I overlooked it.

Sprite 2008 in the "Default" template seems to have been changed or improperly imported as its magenta background is not being removed. To reproduce:  create a new game with "Default" template, run game and walk down. The other player sprites seem fine.

The problems I encountered were centered around the AlignedStream class. Trying to read saves without the AlignedStreams caused the engine to crash with an unknown error. Trying to add items like Characters or GUIs put things out of order somewhere though, and I wasn't able to figure out where. Trying to follow the flow of the binary file proved nearly impossible. I was going to start putting logging statements in, but time constraints from other life events just didn't permit it.

Dialogs and views were able to be added without any problem.

Well a function-local variable would always be reset every time the function is called anyway.

However, Steam doesn't have any issues with you "setting" an already set achievement, so there's no harm in calling the function more than once. If you're worried about the unnecessary callbacks, you could try to cache the results in-game, but that could easily get out of sync. A more efficient solution might be to use the engine's built-in scoring system, using game.score and GiveScore. You could then have something like:

Code: ags

function on_event(EventType event, int data)
{
  if (event == eEventGotScore)
  {
    if ((game.score >= 100) && (Game.DoOnceOnly("ACHIEVEMENT_01")))
    {
      AGS2Client.SetAchievementAchieved("ACHIEVEMENT_01");
    }
  }
}

Then whenever you call GiveScore and the score exceeds or equals 100, the achievement is set, without having to poll for it every single game loop.

When you were running the previous build, was the device running on KitKat (Android 4.4) or higher? Does that older APK still work? If so, please let me know which APK you were using previously, because there haven't been changes to the app since the last APK I provided, I just rebuilt the engine.

It seems that the issue is this one, because KitKat removed the ability to write to the SD card except into the app's private data folder.

Just to verify, could you test if Scourge of the Underworld works on your device? This standalone app explicitly uses its own private data folder as the save location. If this app works, then that pretty much confirms that your issue is that the Android OS is preventing writing anything to the SD card.

I'm not sure whether he would be interested in more long-term and extensive updates. I'll have to ask him.

As others have mentioned, some time ago there was some serious discussion on this front. My programming knowledge is relatively limited to my experience, and I have honestly never done anything of the kind or scale that I feel AGS deserves. I really do love the program and the community, but I would feel wary about an open-ended commitment of that sort, simply because I don't know if I could do it. Working with CW has helped me gain experience, despite his disdain that the project should have moved in a different direction. I will do what I can, where I can, but I'm not comfortable putting myself in that position. I am, however, always open to exploring these things as they come up.

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.

I wouldn't necessarily say I'm only interested in PC and Linux, but I don't own a Mac so development opportunities are extremely limited (all my attempts at a Hackintosh VM have been foiled by the fact that they run too slowly). I have been looking into Android, and the 3.3.4 and 3.4.0.6 builds both have not given me any issues except for the DIGMID patches problem (an error message at launch, but that's it -- the game still runs). I can correct that error for the launcher app, but I have not yet been able to get the MIDI driver to load properly in my standalone apps. I haven't had time to resolve that issue yet, though I recently had an idea that I don't think I tested previously. If you want to test standalone apps, Scourge of the Underworld, Scourge of the Underworld DX, Mighty Pirate, and WaffleQuest I are all AGS games.

Regarding dialog_options_render not updating often enough, you could also try working with dialog_options_get_active. That has to be run every loop AFAIK. At the very least, it should be invoked any time the mouse moves, so it can update the active option ID.

There's currently no way to know if the dialog GUI is visible, except when using custom dialog rendering functions (which you said you are, via the module). I'd have to do some testing to be certain, but I believe that rep_ex_always runs each game loop before dialog_options_render. Unless I'm mistaken about that, then it would be sufficient to simply use a bool to track whether the GUI was shown, setting it to false in rep_ex_always and then to true in dialog_options_render. AGS 3.4.0 introduces dialog_options_rep_exec, which may also be of use here, but I'd have to test it out to be sure (away from AGS right now).

I question the decision to give "basic" names to float variants, and specific names to integer ones.

Your rationale about the general use case might be accurate, but I picked the names I did to better mirror the existing methods, which all operate on floats.

I didn't have any particular purpose behind the module except filling in gaps for common functions that I particularly needed. These specific ones are probably general enough to warrant a built-in implementation, but I would rate it as very low priority (although, the implementations themselves are trivial, so...).

So far the only things in the pull request are the non-conflicting merged commits, so presumably those shouldn't present any issues to the code, but it does leave many features in an incomplete state. Any files with conflict were simply left out so far on this branch. I'll be working on that.

I hope to finish 3.3.5 on this week, after which I will be working on merging 3.3.5 into 3.4.0 (which will carry mouse fix as well).
I predict that itself may take about a week.

Just a head's up, I've been working on this myself actually. There are some big changes involving the mouse code (and maybe some others) that I may not have merged properly so I'll ask you to take a careful look at the merged features when I have it ready, since you know the code better than myself, but I've made quite a bit of headway here... a lot of the conflicts are entirely trivial.

I think it's probably this problem. Unfortunately there's no way for the plugin to know which version(s) of the Visual C++ Runtime any given user may have installed, though the engine itself does currently rely on the VC++2008 32-bit Runtime, so that probably would be the safest bet. I will take a look at recompiling all 6 plugins (AGSteam, AGSteamStub, AGSGalaxy, plus the "disjoint" builds of each) later today (hopefully) with VS2008 instead of VS2015.

Got an extra copy of Half-Life 2. PM me your email or Steam user name to claim.

*bump* http://www.adventuregamestudio.co.uk/forums/index.php?topic=53209.new#new

The instructions for various ports mentions that MIDI playback requires the DIGMID patches, and recommends using "Richard Sander's GUS patches". The instructions say to rename the "digmid.dat" to "patches.dat" and place it in "/sdcard/ags" (on Android, other locations on other platforms), but this apparently doesn't work. This causes the annoying "Error: DIGMID patches set not found".

I have found that by downloading the Gravis ULTRASND Files and extracting the "Gravis ULTRASND Files/ULTRASNDPPL161/MIDI" folder to "/sdcard/ags", Allegro is able to correctly load the MIDI patches and play back MIDI music! Presumably these patches could be built into a single patches.dat file, but that doesn't seem necessary, I don't believe there is a benefit to doing so, and based on current experiences with patches.dat, it may not even work correctly that way.

Regarding standalone Android apps, I am currently trying to determine the correct location for the MIDI patches, as the engine does not seem to read them back from "/sdcard/ags" nor from the game files' location. I will update this post when I am able to determine the correct location for this situation.

The game was made using a pre-release version of 3.2, in December of 2009. I don't know if it really warrants a general-purpose patch. That would require going back and trying to determine where AA was or wasn't being applied, and adding a lot of branching to the code. I don't think that this would really (reasonably) be the "expected" behavior... this game shouldn't have had AA enabled in the first place, being made at 320x240 resolution. Thank you for the response though.