Messages

Is any news for MAC port? Is it in WIP ?

It's on my list to at least get an automated build going soon of what's there. There's been a few port efforts that I probably need to look through.

Any there any ports that I don't know of?

• My SDL port - https://github.com/sonneveld/ags/tree/sdlwrap (there was an osx build)
• Humble Bundle port - https://github.com/humble/ags-geminirue/tree/humble-release-3.3.0 (old pull request here: https://github.com/adventuregamestudio/ags/pull/109 )
• Janet's ios work https://github.com/JanetGilbert/ags/tree/ios (some might be osx relevant) (some changesets here: https://github.com/adventuregamestudio/ags/issues/278 )

I've placed the MIDI patch file in the same folder as android.cfg and my game folders (/storage/emulated/0/AGS/) and named it patches.dat (file size 19MB)
I'm trying out all of the special edition Chzo Mythos games (5 days a stranger etc..) and am unable to get any MIDI music working (works on PC)

I'm seeing this exact same issue with both the Android and PSP builds.

This is the digmid file I downloaded from the recommended site (http://www.eglebbk.dds.nl/program/download/digmid.dat):

Code: ags

Name:    digmid.dat
Date:    2/10/2015
Size:    19 MB (19,971,986 bytes)
--------
SHA-1:    044fa525b26e7715e80cde24bce0b20e6a306ce4
MD5:      9dd5a6205cdf3af1abe80d1c92c4b857
CRC32:    43f0a36c

It _could_ be related to this commit https://github.com/adventuregamestudio/ags/commit/9b40be2355036db85e113a62e8beb87c8afcdc90 but I suspect it was an issue before but now we get an error message.

When I have time I plan to work on this. Not sure financial backing is necessary?

I have a PSP, I'll give it a try as soon as I have the time and post here.

Sweet!  If you have a chance, could you compare with JJS's own builds?

Does anyone still use the PSP port?

1. It builds not only main branches, but all the pull requests; this means that you may make pull request to our repository, even if in sake of test, and you get your version compiled.

Also it means that we can find out if your modifications have broken any of the ports without having to manually build them all ourselves and before we merge into master

Replacing the default game is still needed : http://www.adventuregamestudio.co.uk/forums/index.php?topic=52650.msg636520245;boardseen#new

Is that the thread you meant to link?

Also, I've put up the history of Demo Quest on github. Pull requests welcome! : https://github.com/adventuregamestudio/ags-demo-quest

Smoking cat person is correct.  I think in innosetup you can use {userdocs} & {commondocs} to point towards the user's documents directory or the public writable all users documents directory. (See http://jrsoftware.org/ishelp/topic_consts.htm#userdocs ) The interesting thing will be to see how this works in XP and newer OSs. Also if we're installing as an admin, there seems to be some questions as to which user {userdocs} refers to.

Probably will need to create an option in the installer to select either option. See http://stackoverflow.com/questions/8176661/change-from-userdocs-to-commondocs or http://stackoverflow.com/questions/10940518/setting-destdir-from-inno-pascal

What about Android builds? Wouldn't it be nice anyway to offer an apk of stable releases?

hah sure, I just forgot to put it down.

The build server will probably stick with VS2008 SP1 until we can be sure it's safe to move to a newer version of VS. It would be useful to have tests in place and sources for all the prebuilt libraries that we still use.

Ah sweet!  Thank you.

Hullo,

I'm not sure if this has come up before, but I'd like to start up a collection of AGS scripts that have appeared in games.  I would hopefully use them as test cases for the AGS compiler.

Has anyone done anything like this in the past?  Would other people be interested in it?  I suppose the scripts wouldn't make sense without the rest of the game resources though.

Nick.

edit: hrm, maybe I should have posted this in the editor forum

Hah oh hey that's me.  Mr Crimson Wizard posted most of the relevant details.

A few things on my todo list for the build server:
- setup linux, android, ios, osx, and psp builds and os builds
- setup osx builds
- implement tests then automatically run them as part of a build job <-- in progress
- build the installer (I have something working on jenkins but I think TeamCity is much nicer)
- support user forks of ags repository
- build plugins
- get a domain name for the build server (the ec2 address is temporary) http://teamcity.bigbluecup.org/
- register for TeamCity's open source pricing so I can support more users/build agents
- build games! (would probably require changes to AGS)

I think anything that stores absolute paths should be in a separate file such that is obvious that it only for that machine/user.  That way you can ensure you don't commit machine/user specific information into your repository.

That would be pretty amazing wouldn't it.  I am keen to look into it if others are.

I like the idea of a feature list.  We could define all current features as a classic profile.  That would allow you to start deprecating features. Possibly introduce profiles like how OpenGL has a core profile and a compatibility profile.  Newer engines for iOS and and Android will be able to explicitly state which features they will support.

Do we want to worry about people being able to degrade functionality but still allow the game to run (ie, to be able to run on an engine with reduced functionality because of memory?).  That would mean that the game would need to allow feature checks via scripting and only abort if the game explicitly tries to use a feature the game doesn't support. (Maybe have the option to abort up front or during runtime)

As for versioning features, I'm not sure that is a good idea. You'll just have the same versioning issues that you're trying to avoid if two people work on the same feature in two branches. It might be better to have the features fine grained enough that the two people working on the feature will just add a new feature string. (although APIs tend append version numbers to names, ie function_name and function_name_2, but you know if if you have function_name, it will always do what it says it did)

However, there could be feature limits.  Say a feature only allows X widgets on the screen at once, the game could check what limits are set, and set it's resource usage accordingly. That way the same game could work on both low and high end systems.

Would plugins also define features?

I'm not sure encoding any information in the version string is a good idea. Probably just best to stick to semantic versioning where minor version changes are guaranteed not to break things.

Well I started splitting ags.native so there was a native dll linked with a managed dll via swig.  I got far enough that you could open a project and view most resources but I stopped halfway through trying to get the project saving working. I haven't had time to work on it lately.  When I get back home I'll try and remember to push the changes I made to my github repository if someone else would like to continue working on it.

It all looks good.  I won't be able to contribute in the short term as I'm a bit busy with other things at the moment.  You're welcome to use/borrow/ignore my code if you like!  I do think that eventually there needs to be a product manager/benevolent dictator to make some decisions about the direction of AGS.  Possibly someone like CJ but with more time I suppose!

$10 for all 5 games! The whole thing is a 1.2gig download.

http://www.gog.com/news/release_quest_for_glory_i_v

rps: http://www.rockpapershotgun.com/2012/05/10/so-i-want-to-be-a-hero-quest-for-glory-i-to-v-on-gog/
reddit: http://www.reddit.com/r/Games/comments/tgike/quest_for_glory_i_v_released_on_gog/

Also TIL that AGD's qfg2 remake supports migrating your game character.

I didn't know it was possible to submit a patch, it's CJ himself who suggested this procedure.
Is it common practice to make a patch out of source files rather than compiled files? That sounds awkward.

Oh yes, if anything, it's much better to produce a patch for text files since you can easily see what's changed.  A single patch file can be emailed without needing svn commit access.  See http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-patch.html (I'm assuming you're using tortoisesvn and on windows)