Topics

I wrote a tool that takes the ASC and ASH files and exports the SCM. That will sound more impressive once I finish setting up a project that uses this tool for fully automated builds (the process is already tested, I'm just getting things ready for a public release).

This tool is written in C# and works with Mono, so it can be used in Linux (despite the lack of an AGS editor for Linux as of yet).

Source and downloads are available on my Github.

After clicking on a GUI whose visibility is set in the editor as "When mouse moves to top of screen", the mouse cursor is repositioned to just below the GUI PopupYPos. This apparently happens no matter whether any script event is run, cursor mode is set, etc. The relevant script in the engine seems to be:

Engine/ac/gui.cpp#L290

Code: cpp

void process_interface_click(int ifce, int btn, int mbut) {
// ...
    if (rtype==kGUIAction_None) ; // line 290
// ...

But nowhere in that function nor any of the functions that call it does it apparently move the mouse cursor. I can understand the reasoning behind hiding the GUI if something actually happens, but if the click doesn't do anything then hiding the GUI seems to be counter-intuitive (e.g., player accidentally clicks on GUI background instead of button).

If it matters, I found this behavior on 3.4.1-b5.

[EXPERIMENTAL]

This is an EXPERIMENTAL build of the plugin for Android building. DO NOT use this plugin for releases!!

Downloads


Please view the README for instructions on using this plugin.

Source code

[Edit:] 19 August 2017, v0.0.3-alpha was released which permits the plugin to now function properly with AGS 3.4.0 (the latest stable version as of this writing). You need to download the plugin DLL and the "Android.zip" attachment as well. Extract "Android.zip" into "EDITOR_DIRECTORY/Android" (so, "EDITOR_DIRECTORY/Android/armeabi/libags_parallax.so", etc.), and the rest will work as detailed in the README.

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.

[FOSTER HOME]

I don't have any screenshots and also I am not the creator of this game, but there is a new game coming from Secret Fawful in February 2016 called FOSTER HOME. It's a really amazing short project with incredible graphics and a dark storyline that will leave you craving more from this outstanding developer.

Secret Fawful is also the developer of the award-winning upcoming game, A Night at Camp Ravenwood.

[DOWNLOAD]

DOWNLOAD

The MathsPlus module adds some additional Maths functions, including:

* float Maths.Abs(float)
* float Maths.Ceil(float)
* float Maths.Floor(float)
* float Maths.Max(float, float)
* float Maths.Min(float, float)
* float Maths.Round(float)
* int Maths.AbsInt(int)
* int Maths.MaxInt(int, int)
* int Maths.MinInt(int, int)

Requires AGS 3.4.0.6 or higher

[FULL]

The AGSGalaxy plugin: GOG Galaxy stats, achievements, and leaderboards for AGS!

FULL source code is available, as GOG Galaxy API is open-source (er... not strictly licensed? I don't seem to actually find the full source code for the API or client anywhere, but it definitely isn't licensed in a closed-source fashion)!

Download (see this post in deciding which version to download)


Cheers! For an example, please check out the Steam+Galaxy project.

[https://github.com/monkey0506/ags2client_demo]

This may be fairly mundane, but I have created a common interface for client plugins that AGS can use to communicate with clients like Steam and GOG Galaxy. In fact, those are the only two clients I know of presently that offer the whole game-library-with-achievements-and-so-forth type of "client", but it's always possible that others will rise up.

In related news, this does mean that I am working on a GOG Galaxy plugin! Hopefully that should be made available soon. As far as I know, the GOG Galaxy SDK is open source, so that plugin will also be fully open-sourced, unlike AGSteam. The official stub source code for AGSteam will later be updated to this much improved interface as well.

I created a demo project to show how this interface can be used to stub these client plugins rather simply. You can grab the source for that at the link below (the interface itself is a referenced submodule in a separate repo):

https://github.com/monkey0506/ags2client_demo

P.S. Additionally, this common interface should make it relatively simple for AGS devs to implement Steam and Galaxy features in a uniform fashion. That seems like it would be appreciated.

P.S.S. The Visual Studio solution files I provided for the demo are VS 2013 solution files, and the interface does make use of C++11 features. The demo was tested with AGS 3.4.0.5 and gave me no issues.

My only experience with trig was in Pre-Calculus in high school, 10 years ago. I am now finally enrolled in college, and I am considering taking trigonometry over the course of a 3 week mini-mester, starting next month. In preparation for that, teach me everything about trig, sage AGSers!

Thanks!

This is far from what I originally envisioned, but I'm pretty happy with how it came out given the time constraints and such.

http://i.imgur.com/d58cpeJ.gifv

This is slightly lower quality as I exported it as a GIF animation, which Imgur converted back to a video anyway, and it lacks the sound effects. Still, curious what people think of it.

This is my first-ever attempt at stop-motion, and we can't really make changes now, but feedback is appreciated.

[Yikes!]

This recent post in the Beginner's forum got me thinking about the implementation of Game.DoOnceOnly, and I came across this:

Code: cpp

int Game_DoOnceOnly(const char *token)
{
    if (strlen(token) > 199)
        quit("!Game.DoOnceOnly: token length cannot be more than 200 chars");

    for (int i = 0; i < play.num_do_once_tokens; i++)
    {
        if (strcmp(play.do_once_tokens[i], token) == 0)
        {
            return 0;
        }
    }
    play.do_once_tokens = (char**)realloc(play.do_once_tokens, sizeof(char*) * (play.num_do_once_tokens + 1));
    play.do_once_tokens[play.num_do_once_tokens] = (char*)malloc(strlen(token) + 1);
    strcpy(play.do_once_tokens[play.num_do_once_tokens], token);
    play.num_do_once_tokens++;
    return 1;
}

Yikes!

I don't think that CJ was using anything (at all) from the TR1 namespace, but C++11's unordered_set is available with VS2008 in the TR1 namespace (which I know is now used in some places), and seems like it would be vastly more efficient for this.

The implementation could simply be changed to:

Code: cpp

#include <unordered_set>
#include <string>

int Game_DoOnceOnly(const char *token)
{
    // TODO: move these typedefs somewhere more useful :P
#if (__cplusplus <= 199711L)
    typedef std::tr1::unordered_set<std::string> unordered_set;
#else
    typedef std::unordered_set<std::string> unordered_set; // don't use "using" syntax here to avoid additional checks for VS versions earlier than 2013
#endif
    if (strlen(token) > 199) // TODO: remove this limit from save game format?
        quit("!Game.DoOnceOnly: token length cannot be more than 200 chars");
    // TODO: REPLACE char** GameState::do_once_tokens with unordered_set* GameState::do_once_tokens
    //     NOTE: use a pointer to the unordered_set to preserve the size of the GameState struct (VS2008 reports sizeof(unordered_set) at 64)
    // TODO: REMOVE int GameState::num_do_once_tokens (now available as GameState::do_once_tokens->size())
    return play.do_once_tokens->insert(token).second; // all we need to know is whether insertion took place
}

GameState::num_do_once_tokens would probably be best left as an additional reserved space, since I know how touchy AGS is about struct layouts.

Is there any reason why anyone would object to this? Storing a pointer to the unordered_set isn't necessarily ideal, but it does preserve the existing layout and doesn't incur additional overhead as dereferencing was taking place anyway.

Game.DoOnceOnly likely isn't used as a speed-critical method, but this seems to me like a relatively simple optimization.

P.S. This would, of course, require other minor modifications, such as changing the method that writes the tokens to a save game, but iterating the unordered_set is extremely simple as well.

I don't have the time or the knowledge to work on this, but I had an idea that could maybe prove useful for implementing proper forward declarations. We already have all of the syntax and keywords that are needed (import and export are sufficient there), the problem AFAICT is that when a user tries to reference an imported item before it has been fully defined the engine isn't linking it properly.

I could be totally off-base here, but it seems like the compiler (which is also acting as the linker, isn't it?) should be able to tell at compile-time whether or not an invocation of an imported item has been appropriately linked to the full definition. Assuming that is correct (and eating my foot if it's not), then the compiler should be able to keep track of imports that aren't linked.

From that point (if I haven't derailed completely yet), it seems that the compiler should be able to just make one more pass through the symbols that have been fully defined, and check for any matching definitions. If it finds a matching definition, then it can link it.

Any thoughts on this? Could it work this way?

[both]

It's been discussed before, but as time goes on it seems increasingly as though porting to Allegro 5 would get AGS where it needs to be as a modern engine.

Allegro 5 is well documented, has better support for modern graphics drivers, has built-in threading support, makes up for a lot of the things AGS has hacked into A4 over the years, has UTF-8 string support, has prebuilt libraries for modern Windows compilers (so we could finally abandon both Visual Studio 2008 and the NoNative solution)...the list goes on.

Porting to Allegro 5 will be no small task. Allegro 4 builds a queue of events which are then processed as the game loop executes. Allegro 5 is instead event-driven, which will require major logical changes to the way the engine is coded. Also, there are many cases where there is no one-to-one conversion, though theoretically everything A4 does A5 can still do.

I have taken a look at starting in on this, but I'm not sure if just diving head-first into this will produce anything meaningful.

Would it be feasible to partition off the engine code into smaller segments, so changes can more easily be reviewed, and others could work on other sections? What might be the best way of breaking this up?

Also, it would probably be useful to use a C++ wrapper layer on top of Allegro 5 for RAII garbage collection and the like. I found one called "ALX", but it doesnt seem to conform to good C++ standards (e.g., it doesn't make use of the default case in switch statements, even when that is the desired result). If needed, it would be relatively simple to write our own wrapper layer.

Thoughts?

[always]

Since the editor can now target different platforms, there is a very good chance that users will need to maintain separate config files. It would seem obvious that when running the debugger, it should use the Windows config file. This would also make the debugger respect config changes made if the developer has run winsetup.exe directly from Compiled/Windows. However, there is also the "Build -> Run game setup..." option, which I have more of a question about.

Should this always be considered as modifying the Windows config file only? Or should it modify the global/default config file (Compiled/acsetup.cfg, copied when platform-specific config doesn't exist)? Should perhaps an option be added if the setup program is launched from the editor to specify which platform you want to change the settings for? Obviously "winsetup.exe" isn't going to be released on Linux, but it might make sense as part of the editor suite to edit the Linux config file that way.

Can anyone comment on that?

I'm taking an Intro to Game Design class as part of my degree program, and for our final exam we're meant to make a game using GameMaker.

My biggest issue so far is that the way it handles collisions doesn't make any sense at all.

Actually most of GML doesn't make sense either, but that's become a minor annoyance in comparison to the collision system. Getting the simplest of tasks to work properly in this program is nigh on impossible. The editor is specifically designed to showcase (and almost enforce) the drag-n-drop system, but testing for collisions using that is essentially saying that you don't want your game to work.

I'm honestly beginning to wonder if the people who designed this program had video game developers in mind. I don't think it was created for making video games.

Drawing so close to a working build process for Linux has got me thinking forward to building for Android as well. I actually started on a port of the ADT's jobb tool to C#. I couldn't find any existing libraries for creating/formatting disk space as a FAT partition though, so I'm working on porting the library that the jobb tool uses to C# as well.

This would add at least a few extra assemblies to the editor though. How does everyone feel about that? Is there a way that the editor could reference those extra assemblies only if they exist and Android is targeted for building?

Once that's out of the way, the game resources could then be packed into a single OBB file and the engine packed into the APK. Then the APK could have a prebuilt script to mount the OBB file as a drive and read the game from there. It's how I've gotten other AGS games (including large projects like Al Emmo) to run from a single APK.

Thoughts?

[copying]

This is an extension of a previous discussion brought up in my thread about building for Linux.

Through research as well as trial-and-error, I've attempted to come up with the most thorough, complete, and yes, even portable solution to create hard links from within the editor code.

Why do we need this? Particularly now that the build process is being split up to allow targeting multiple platforms from directly within the editor, the issue of copying files becomes particularly relevant. If your game's data files amount to several hundred megabytes or even reach into the gigabytes, then copying all of those data files into the appropriate build folders for Windows, Linux, etc. would become utterly obscene. Using hard links means that the actual data files can exist in exactly one place on your hard drive, but when you zip up your Windows or Linux folder, it grabs those files from wherever they're at instead of forcing you to have multiple copies of the files (think of it like a shortcut on your desktop, except you can also treat it like a normal file for zipping, etc.).

I wanted to post this here just to draw particular attention to it. Here's what I've come up with:

Code: csharp

        public static bool CreateHardLink(string destFileName, string sourceFileName, bool overwrite)
        {
            if (File.Exists(destFileName))
            {
                if (overwrite) File.Delete(destFileName);
                else return false;
            }
            ProcessStartInfo si = new ProcessStartInfo("cmd.exe");
            si.RedirectStandardInput = false;
            si.RedirectStandardOutput = false;
            si.UseShellExecute = false;
            si.Arguments = string.Format("/c mklink /h {0} {1}", destFileName, sourceFileName);
            si.CreateNoWindow = true;
            si.WindowStyle = ProcessWindowStyle.Hidden;
            if (IsMonoRunning())
            {
                si.FileName = "ln";
                si.Arguments = string.Format("{0} {1}", sourceFileName, destFileName);
            }
            bool result = (Process.Start(si) != null);
            if (result)
            {
                // by default the new hard link will be accessible to the current user only
                // instead, we'll change it to be accessible to the entire "Users" group
                FileSecurity fsec = File.GetAccessControl(destFileName);
                fsec.AddAccessRule
                (
                    new FileSystemAccessRule
                    (
                        new SecurityIdentifier(WellKnownSidType.BuiltinUsersSid, null),
                        FileSystemRights.Modify,
                        AccessControlType.Allow
                    )
                );
                File.SetAccessControl(destFileName, fsec);
            }
            return result;
        }

This supports relative or absolute paths, and should work with Mono (although I don't think there's a build of the editor that fully works with Mono to be able to test this on, it doesn't use any native code and specifies the appropriate linker file for Linux). It also attempts to make sure that appropriate security permissions are set on the hard link itself.

If I've overlooked anything else please let me know.

[NOTE: This is NOT a stable build intended for making or releasing games! You probably should not even attempt to run games created with this build.]

NOTE: This is NOT a stable build intended for making or releasing games! You probably should not even attempt to run games created with this build.

This build is designed as a diagnostic to help me track down any lingering issues with building the game data file from the editor's managed C# code, as a step toward building multiple target platforms from within the editor (building for Linux is on its way soon!). While this produces a Windows EXE, let me reiterate that you should NOT use or distribute this file, as it's not stable and could cause major runtime issues.

I need your help!

What I need is for several people to build your projects with this editor (MAKE A COPY FIRST!) and then verify that the game28.main.dta and the game28.dta files (in your project folder) are identical files. These are binary files, so you can't just open them in a text editor, and the bare minimum size is about 92 KB. Huge games (such as The Cat Lady) produce DTA files that are around 3-4 MB. There are several ways to verify that the binary files are identical - there are tools that can do this automatically, you can use a tool to check the SHA1 hash, or you can do what I've been doing and feed the output from a hex editor into a text diff tool (slightly tedious, but it lets me see exactly where the divergence took place).

I would like to go ahead and submit a pull request to merge this process (sans the messy debug stuff, of course) into the AGS 3.4.0 codebase, but I'd feel more comfortable if other people test it out first since it is such a huge change. I have tested it against several projects myself and all features seem to be properly accounted for in the newly output data files (as compared to the existing file format, meaning the engine should have no problem reading them).


Thanks!

Download

I've been meaning to look into this more than I've actually had an opportunity to, but it seems that the engine is currently reusing some functions in writing the game data file and in writing save game files. As most of you probably know, I've been working on porting the process of writing the game data file to the editor's managed C# code in order to make it easier for multiple target platforms to be built from within the editor. This has led me to the following questions:

* What data do the game data file and save game files currently have in common?
* What data do each of these (game data file and save game files) actually use/require?
* Aside from code reuse, what benefits are there behind keeping a similar/shared format between these files?

To be more specific, I'm pretty sure that GUI data (size, location, graphics, controls, etc.) is written the same way when building the game as it is when saving the game. While I appreciate that this removes duplicated code, some of the members used at run-time have no meaning or bearing whatsoever at design-time or compile-time while creating a bloated data file. These run-time members are written statically into the game data file as null/empty/junk values that are never used by the engine, but exist in the data file only as a form of padding to maintain similar offsets.

My current fork is still in the debugging phase, and when building larger projects there are several inconsistencies in the output game files (as compared to the pure native C++ build process), so I'm curious whether it is worth debugging if large portions may simply be replaced with calls back into the native code to maintain the existing format. Personally I think it would be better to split the format of the game data files and save game files, which could potentially result in drastically smaller game sizes (especially for larger projects I've helped out with like Gemini Rue or The Cat Lady), but I'd like to hear what others have to say before I make any final decisions (in the mean time, I'll keep debugging my work-alike port).

[that]

I'm working to move around some of the code for building the game data file, and I thought it would be a good idea to test building against a larger game to make sure that everything is working appropriately.

Well, I have the source for The Cat Lady laying around still, so I go to create a copy of the and oh my what the huh... the folder is nearly 5 GB. I'm pretty sure the game isn't that big. Oh well. That's life, I guess.