Messages

I don't know if it's a lot, and I should have to calculate for the whole data of my game.

I must admit that 2.5 MB is not a lot today, especially compared to the rest of the game data.

Having very long script files is also impacting the RAM ?

Yes, script are compiled, and compiled scripts are loaded by the engine fully. The bigger script is, the bigger memory it requires.
Usually script sizes are in kilobytes though, but this may be more if they also include large global arrays of fixed size.

When you talk about disk cache : what do you mean ? How to use that in AGS ?

Save data into the custom file, remove it from the variables. When necessary - load it back. There are file commands in ags script:
https://adventuregamestudio.github.io/ags-manual/File.html
But the disk cache is the last resort, you probably won't need this. Unless you are close to the game completion and found that your script data takes too much memory.

If I understand you well, instead of having an array like cartes[150] that is initialized at game_start, I should have instead only one 'cartes' instance, and a function like :

I mean rather - have these cartes stored in files, and loaded, as scripting everything in a function will likely require same memory. The point of this solution is to not have all of this data mentioned in script.
But this solution comes with extra problem: you need to save these files prior to using them in game. This means that you also need some kind of a "map editor", either scripted as a AGS game, or separate tool.
Alternatively, you may describe maps in a text format and parse them in script, for instance using IniFile module.

EDIT : when I run my game, I just had a look at the Task Manager, and it displays 408,5Mo in the Memory Section. Does it mean I'm using 408,5Mo over 3GB ?

That likely means your active process(es) are using 408 Mb total.
I think "Mo" is "Megabytes" in French?

EDIT 3 : I don't understand what are the custom saves. What's about ? Instead of AGS saves ?

You may save and load your own files from script. This way you can write only data that you need for your game to remember.
How to work with custom files in AGS:
https://adventuregamestudio.github.io/ags-manual/File.html

Again, this is an option, and you may look into this after you deal with other problems.

I wonder how many data can be stored in an AGS game.

This depends on the system you're running it on.

E.g. on Windows the engine is still distributed as a 32-bit app, which means that it cannot exceed 3 GB of RAM (iirc). If we build a 64-bit program, then it will allow much more. But it will never be able to surpass what the player has on their computer, obviously. If player has 2 GB RAM, that's it (and portion of that RAM will always be used by an operating system).

If you have a plain struct, then you dont have to guess, instead calculate the size of the struct. Your struct is mostly ints. One integer is 4 bytes. Sum up all the ints and arrays of ints you have, and you'll know how much it takes exactly.

If you have too much data, the general approach, for engines and games, is not to have literally everything loaded at the same time. Instead, have only 1 instance of a struct representing current location, and have actual data saved in files. Load one part of your world at a time, and replace it when the player moves outside.

In memory keep only things that may change. If that's convenient, you may make a second struct for that, having only data that can be changed, and have such structs for each "left" area where player may return to later. When player leaves the area, copy respective data from the "main" struct to the "memory" struct. When player enters previously visited area again, copy from "memory" struct to the "main" struct.

If that is also too much, there's still a resort: use disk cache. Basically, write the data for the inactive parts of the world to files, and read from these as player returns to them.

And since you are doing your own type of game, I strongly recommend considering custom saves instead of using AGS own saves: this way you will only save what your game actually needs.

[Linux subfolder]

Hello, I've added to the main AGS folder "libagsshell.so" and "ags_shell.dll".

TBH I was unaware the linux version of this plugin exists. But if it does, and suppose to work, note that you should add this libagsshell.so file in the Linux subfolder of the Editor's program folder.

The *.so files do not appear in the project tree, but if they are found - they will be copied to Compiled/Linux/libxxx of your game.

[there are still 2 and 3]

there are still 2 and 3 that are open if someone finds this thread.

2) More engine- than editor-related, but having the audioclip DefaultVolume property be accessible and modifiable by script would be incredibly useful; for example, to be able to easily do fading footsteps, among many other situations.

I already replied to this above (my comment), but might reiterate, that I disagree that this should be done through clip's DefaultVolume, as the clip as a central resource that may be used from several objects, even simultaneously.

For the given case, in my opinion there could be a volume control for particular sound/animation user instead. In general, imo, we need to move away from controlling clips idea towards the idea of controlling audio source.
For a draft example, literally have a AnimationVolume property in Character and Object.

If there are other cases where this solution won't work, we need to discuss these and investigate solution separately.

EDIT: this unfortunately would only let to set volume, but not other playback properties, available at the AudioChannel. It would be curious to figure out whether there may be a good solution to automatically receiving an audio channel where the frame is playing. On the other hand, is it wise to give full control to frame playback? E.g. user then may even rewind it indefinitely until replaced by another sound...

I think the only way do fix this in the current engine is to resize the sprites in the animation frames dynamically in script instead, as Cassiebgs mentioned above, as this will let more gradual change.
That would affect the perfomance though; which may or not be a concern (depends on number of things).

The setup has an option for this ("smooth scaled sprites"); if you turn that on characters are scaled using the resolution the game is running at rather than the native one.

To clarify, that option is "Render sprites at screen resolution".
"Smooth scaled sprites" enables antia-aliasing during rescale afaik.

However, I am not certain if this option would help, as, judging by the above posts, the issue is not necessarily that the character is pixelated, but that scaling is done in rough steps.
Although tbh I don't see anything wrong in the above video either, so may be mistaken about the problem.

It also might be that the new "import ttf" dialog is also wrong, and should be designed differently. As an option it may be reversed to its old looks if it was more correct.

It could be an option, yes. So far, the "Import at font's point size" option hasn't done anything for me in most cases. How does AGS calculate the font's point size anyway, given that, as you said above, a true vector font doesn't really have a specific/default point size?

I think there may be a misunderstanding too. "Import at font's point size" also uses the number field, it tries to import the font at the typed size. But it uses "point" term incorrectly, as it seems. So the correct title would be "Import at this font's size".
The difference between two these options is that the first option imports at the size given by user, and the second searches for the font size that results in particular full font height (ascender + descender).
I may either remove the second option if it's not useful, or reorganize fields to make it more clear that both options use the number field.

But at least this confirms that AGS is calculating the total font height correctly as 14 (when the "resize ascender" option is active).

Erm, this particular option is a backward compatibility feature, and is meant mostly for fonts which made specifically for AGS in the past. Because ascender is resized to match the demanded font size, this option may result in font glyphs being drawn lower, adding vertical space above the letters.

The problem with 3.6.0 is that it still uses unmodified templates from 3.5.*, and therefore when you create your games all the properties are adjusted for importing these older projects.
We need to update the templates to have the recommended settings for 3.6.0, with "resize ascender" off, and other changes.

[pixel]

However, this is incorrect because as mentioned above, the pixel size is 11

I'm not certain if I understand this. AFAIK the TTF is not supposed to have a fixed pixel size itself, its pixel size depends on the point size it's used at, as well as some characteristics.
In the description it sais "font is designed to be displayed at 11px and multiples thereof", but afaik that does not mean that "the font is 11px".
Where may I see the information about point size 8 corresponding to 11px?

AGS asks for the size you want to import the font at, and it's the "Point size" property it displays.

UPDATE: I've read a bit about this, and apparently AGS editor uses "Point" term incorrectly there. I think it's meaning is rather "Import size", as in something that user requested.
TBH this specific may be due to how the importing process works with the library that we're using.

It also might be that the new "import ttf" dialog is also wrong, and should be designed differently. As an option it may be reversed to its old looks if it was more correct.

On a side note, testing this font in 3.2.1 produces same results as 3.6.0, judging by the font looks (when importing with same size parameter).

UPDATE 2: Running under debugger, i can see that when the font is imported with the size "11", its data sais "size 11x11". However the font rendering library calculates final size by summing "ascender + descender", which results in a higher height (13). AGS uses this reported number to show as "Font Height".
What puzzles me further is that under the same circumstances the actual size of letters on screen (tested by screenshot) could be 14px (capital letters).
Perhaps, 11x11 is some kind of a control size, not directly related to particular letter(s).
I wish I knew more about TTF fonts.

[pixels]

I have a font that is 11x11 pixels (this one), however, when I import it, AGS says it has a point size of 11 and thus a pixel height of 14:



However, this is incorrect because as mentioned above, the pixel size is 11, which corresponds to a point size of 8.

Please check the value of "TTF font adjustment" property?

And what about the ekeyCtrlLeft and ekeyCtrlRight ? Have they been deleted ?

They have been added in 3.6.0, were not declared earlier. The values themselves should be valid in earlier versions.

Oh, I see ! But is there a way to fix it ?

Probably won't do this for 3.5.1, as it's a rare problem and there's a workaround (posted above). We may look if it's possible to improve in 3.6.0 version.

EDIT 3 : in the same "theme", is "eMouseWheelNorth" and "eMouseWheelSouth" should work with a tactile pad of a PC ? (I don't know the english name for that, but you know, the tactile zone where your fingers can simulate the mouse, like for a smartphone. Scrolling can be done by using two fingers).

I don't know. But we recently received a bug report that touch pad does not register some command for the right click on Linux in 3.5.1, and later this was confirmed to work in 3.6.0. Perhaps you could test in 3.6.0 to see if it works there.

I encounter this problem : when I press "enter", it generates something that would be done by pressiong CtrlK or something like that (a combination of 2 keys, but NOT the "enter" key).

It's a known issue that eKeyCtrlM has the same code as Enter/Return.
This may be noticed by comparing their values in the key codes table in the manual: https://adventuregamestudio.github.io/ags-manual/ASCIIcodes.html

The workaround is to additionally test if ctrl is pressed as

Code: ags

if ( IsKeyPressed(eKeyCtrlLeft) ||  IsKeyPressed(eKeyCtrlRight) )

I use Oggs, so it’s not the issue with MP3s. Also I was assuming it was because of the SDL_sound update, but I’m probably wrong on that. If it helps, the version of the alpha I tested where the issue was not present was alpha 10. Is there an archive of previous versions where I can download alpha 10 again to make the test games for comparison?

Certainly, we have all the releases on github:
https://github.com/adventuregamestudio/ags/releases

specifically 3.6.0 alpha 10:
https://github.com/adventuregamestudio/ags/releases/tag/v.3.6.0.9

The downloads are attached at the end of the post, under "Assets".

Thing is, that SDL_Sound library is not participating in playing the sounds, but only in loading (decoding) them. So if anything affected this was elsewhere.

[Engine:]

Engine:
- Updated SDL_Sound lib to recent version, this is purely internal change but it's unknown if this will lead to anything noteable in particular.

Unfortunately this seems to have brought back the annoying issue that was in the previous audio system.

Does this happen with any random clips? I may test with the older library version, or make test builds for others to try.

DateTime is a struct, you need to get an instance of one, and also retrieve some values, as it cannot format on its own.

Something like

Code: ags

DateTime *now = DateTime.Now;
String desc = String.Format("AUTO: %d / %d / %d / %d : %d : %d",
        now.Year, now.Month, now.DayOfMonth, now.Hour, now.Minute, now.Second);
Display("TEST: %s", desc); // just for a test
SaveGameSlot(1, desc);

["Modules & Tools"]

Maybe "Modules & Tools" for a full board name? Modules may refer to both script modules and plugins, and tools term covers everything else.

[room overlays]

Another interesting option that may complement objects is room overlays. We may say that AGS has two "layers" or "spaces": GUI space and room space. These have their own coordinates and their own object sorting.
Overlays are dynamic objects that may be created and deleted at will. They are currently existing in the "gui space", always above the room. Since 3.6.0 Overlays may also sort among GUI, so their use is improved.

It should be possible to support creating overlays in the room space, where they will be positioned in room coordinates, and sorted among the room objects and characters.

As overlay is nothing but a sprite, with no built-in interaction or advanced behavior, these are ideal for temporary visual effects.

So, trying to clarify the situation.

Technically, the limit of room objects may be removed. This would require rewriting some parts of the engine, where program is relying on object list having a fixed size. Also changing something in the script API, where the global array of room objects (declared as "Object object[];") may be replaced either with a dynamic array (like "readonly Object *object[]") or a property in Room class (like "readonly attribute Object *Room.Objects[];"). Either way has its pros and cons, but either this is doable.

The problem, however, is bigger than simply the number cap.
The room objects in AGS are "static", in the sense that they are only created in the editor. They cannot be created or deleted in script, during game run. All of them also stay in memory all the time, and part of their state is also kept in memory even after player leaves (unless that's a non-state-saving room, one with number above 301).

In this situation, if we remove the object cap completely, I'm afraid that will encourage misuse of AGS. People who would want to create non-adventure games, such as arcades, strategy games, or other kinds of gameplay involving very large amount of objects, would simply set up hungreds of these or more in the editor, not realizing that they are using an inefficient method, resulting in suboptimally made games.
You may of course say that's it's better than not being able to create a game at all, but I beg to differ. It's been said that AGS is a hobbyist tool, many AGS users sadly do not have a full understanding of program work. In the past I witnessed on many occasions how people create games in a way that seem most straightforward for them, but is often inefficient, leading to bad habits and badly optimized games. This may not be always noticeable on PC, especially with small games, but becomes pretty clear when the game becomes bigger, or is ported, for example, to mobile or console device with lower capabilities.

What I believe is that the true solution lies in featuring dynamically created objects: when you may create these objects as these come into play and delete them as they are no longer necessary. This is of course going to be a significant change in paradigm for AGS, but would allow to make non-point&click games easier and more efficient.



Before that is done, there are still methods to achieve "open world" games in AGS. They are not as straightforward, but feasible.

One method that I may mention is called "object pool". I personally used it myself when making couple of arcade games in AGS, and maybe other people did in the past.
The idea of this method is to reuse same list of objects, moving them into player's view and away from the visible room bounds, assigning them different look and roles.

This method is not a "dirty hack", and not specific for AGS, other engines use it too sometimes. Even creating and deleting objects dynamically sort of work as an object pool internally (or maybe, "logically").

I was planning to publish my arcade script at some point, demonstrating this, but did not manage yet. The games I worked on belonged to other people, and i'd have to detach my scripts from these games and set up some dummy art, etc, so that would require time. But I have posted a simple module that helps to keep the track of "object pool": https://www.adventuregamestudio.co.uk/forums/index.php?topic=58853.0

The biggest issue with this, and similar approaches is that you cannot configure starting object positions in the editor. Instead you'd have to setup these as either a script data, or in custom files. For these kinds of games it also may be better to create your own level editing, either make an in-game level editor, or a separate tool if you know how to.

[[REDACTED]]

[REDACTED]

I'm sorry, I deleted my previous replies, because realized that did not give full picture of a problem (and potential solution), and what I wrote first may be interpreted incorrectly.

I will think about how to explain this better and post a new one.

I apologize for the possible confusion.