Messages

On Windows 10 at least, AppData is also a user-specific folder.

These are not environment variables, so not the same location as %APPDATA%.

It is probably also worth noting, these sample positions do not account for stereo (so don't multiply by two, to account for samples on the left and right channels).

Maybe it could work with mind mapping software, like Freeplane or FreeMind?

This is also complicated by built-in redirection in Windows, where writes to some un-writeable paths are redirected into the user profile without the user knowing. So potentially, when reading a relative path with no token it may actually be checking $APPDATADIR$, then any write which was redirected into the user profile when you tried to write to $INSTALLDIR$, and then $INSTALLDIR$. Personally I would say, leave what it is doing now as the default. There is an attempt to make old games work, you can never know in advance if the installation directory is writable, and people don't usually know about the redirection that is built into Windows. To be more flexible, you could just add one new game option with three file redirection options:

• Redirection on (current rules apply)
• Redirection off in debug mode only
• Redirection off

In your case (editing game data while making the game), you pick the second one.
If you want to release the game like that and not have to remember to switch redirection options, you pick the third one.

I also enjoyed this; very engaging.

"4 American footballs, out of 5".

Hopefully this qualifies for something...

** edit **
ags-help.chm doesn't seem to work? Everything is blank...

If launching from the editor and the file is flagged as coming from the Internet, it should offer to remove that flag for you. It you are opening it directly you would have to clear it manually. I wrote some instructions here (ignore the page title, the content was originally incorrect). The short version: right-click the file, choose properties, then click unblock.

https://github.com/adventuregamestudio/ags/blob/master/Engine/platform/windows/acplwin.cpp

// MS Windows DirectDraw and Direct3D renderers do not support a window
// which exceeds the height of current desktop resolution

Do you think the built in Allegro 4 OpenGL wrapper would be usable?
https://wiki.allegro.cc/index.php?title=Hardware_Accelerated_Allegro_(AllegroGL)

I found that fullscreen slowdown seems dependent on the graphics driver, as I lost all fullscreen slowdown when switching from on-board AMD graphics to an old AMD card. Is it still slow if scaled and using fullscreen mode, rather than a window? Otherwise the only solution I found was to change to a lower desktop resolution to remove the need for scaling.

I did go through the engine code to check where the slowdown is, and it did just seem to be the actual drawing to the display that caused the majority of the CPU load. I did change one thing which may drop CPU usage slightly (about 5 - 10% for me) so running on a recent engine build might give a slight improvement. You might suggest they try building the engine, as I would imagine someone using Arch would be okay with doing that.

Actually, making your own timer doesn't seem possible as you can only retrieve the time as an integer.

Did you mean "as seconds"?

Yes, DateTime.RawTime returns an integer, so it wasn't as 'raw' as I was expecting.

Actually, making your own timer doesn't seem possible as you can only retrieve the time as an integer. So for a different approach, I tried to fake it by smoothly decreasing the bar width on each game tick and set the width on the click event (but including a slight random element).

Code: ags

int STEP = 1;
int TARGET = 0;
int START = 200;

function repeatedly_execute_always() 
{
    if (BtnBar.Width > TARGET)
        BtnBar.Width -= STEP;
}

function room_AfterFadeIn()
{
    BtnBar.Width = TARGET + START;
}

function BtnBar_OnClick(GUIControl *control, MouseButton button)
{
    if (button == eMouseLeft)
    {
        int step = Random(3) + 10;

        if (BtnBar.Width <= 585 - step)
            BtnBar.Width += step;
        else
            Display("Win");
    }
}

You might have to tweak the numbers, but this way it isn't relying on the mouse events to directly work against the resizing of the bar.

As far as I know, the built-in timers are linked to game ticks and the time between ticks can increase depending on computer load and vsync settings. It would probably be more predictable to implement your own delta time (so check the time on each tick and increment a variable based on the time that has passed) as it will account for engine slowdown. You could also use a random element based on the bar width, so that it is easier when the bar is emptier and give some element of chance when you need to be clicking faster.

I think from all the engines in the table, MonoAGS is the only one which could function as a direct replacement (without re-scoping the whole project).

At the moment the game is not archived by Editor at all. Do I understand correctly that it must be put into archive to accomplish this?

Yes. If you don't want to package it on another platform you would have to write the game files to an archive format that supports the flag, set the flag on the script and the engine binaries, and not extract it until you are on a filesystem that can maintain the flag (i.e. don't extract and re-archive it on Windows). I guess it just needs a library that could write the file (maybe this one) or create an archive class that writes the file out manually.

1) When will you have an executable for Linux? The current version is a text file and depending on whether the user has marked the option "open as executable" You can run the game or you will open the text file.

I do not understand your question. There are executables for Linux, available with the installer, or as a separate package (in the first post). What "text file" are you are talking about?

It is the script that launches the executable, but it doesn't have the execute bit set
http://www.adventuregamestudio.co.uk/forums/index.php?topic=54571.msg636557425

Thanks, I've applied the changes there. If anyone would like to play around with it, this currently builds okay with AGS selected as the only engine:
https://github.com/adventuregamestudio/scummvm/tree/ags

I've added a note to the top of the readme file, on how to generate a project solution in Visual Studio that excludes all of the other engines, basically just run the project configuration manually and give it the same engine options you would use for the configure script on another platform/compiler.

Code: dos

--disable-all-engines --enable-engine=ags

Building all/stable engines should be fine too, but it does take a while (for me at least) and uses quite a lot of disk space.

For things I really like (and for contrast): Game.DoOnceOnly

If you are defining global state, you may as well describe what you are doing it for at the same time.

Also, I think it might be more flexible to have a generic object hierarchy for rooms (and scripts attach to any object). So the room is just another object and a child of a game object - potentially you can get a reference from parent to set global properties or properties in another room. I think it would be pretty easy to disguise this as the current setup (global script is on the game object, room script is on a pre-built room object with no children) so people can stick with what they know if they prefer to.

Can you expand on this? I'm not sure I completely got what you're aiming for here. Can you also explain which use-cases are you hoping to solve (or make better) with this?

As an example, if you had three objects which you need to check the state for some kind of puzzle, rather than just put them in a room and store the state in the room script, you have a base level object (one that would be extended with components to become the other type of game objects) and encapsulate the object state and functions in there. The idea being, if you didn't want to use it you don't have (just use the pre-extended objects), but you could take an empty object and manually assign the components (bitmap, events hooks, scripts, etc). So the parent object might have a function to validate the position of its children which is used as the puzzle logic, but may also have a bitmap (perhaps the three objects are on a tray) or blit to its own surface (perhaps it is a magic tray), and also provide routing for events to propagate (can fire events into its children, pass-on events from its parent, or claim events). When the puzzle is solved, just deactivate the parent to stop all scripts and events on the children, so I guess I'm suggesting it as an option to prevent having lots of booleans and if statements in a room script or global script (but you can still do it that way if you want as that is just one parent and one child).

AGS gets character movement and animation right. Other engines I've used move a character at 60 FPS regardless of the speed of the animation. I think this is mostly due to laziness and lack of consideration at the point of design.

It would be good if you could optionally decide which scripts are on a fixed frame rate and which will wait for vsync (perhaps just capped at 60 FPS). So the viewport and mouse cursor could be smoothly moved, but game speed is still configurable. i.e. separate the game events from the engine events, so when using the RenderAtScreenResolution setting you can get the retro look with smooth scrolling and interface. Doing this is Unity is pretty difficult, normally you end up with spritesheet jitter and pixels changing in width as they scroll, I think you had to point the camera at a render texture to work around that which didn't use to be available in the free version.

Also, I think it might be more flexible to have a generic object hierarchy for rooms (and scripts attach to any object). So the room is just another object and a child of a game object - potentially you can get a reference from parent to set global properties or properties in another room. I think it would be pretty easy to disguise this as the current setup (global script is on the game object, room script is on a pre-built room object with no children) so people can stick with what they know if they prefer to.

Also, directory based project structure (sprite is just an image file) with YAML datafiles instead of XML (so people can read it with just their eyes). I think just letting the compiler pack the sprites would be a big improvement for a lot of people. As an example:

The engine is extremely artist friendly, with the ability to slide easily into a production line. All images are read from external files, so updating graphics is as easy as copying files in Windows Explorer. Simply replace the old frames in the directory, and they are automatically updated in the game.