Messages

I would not trust the compiler as much. I don't think the checks are that burdensome - they only happen at the frontier in the API, which is not what I meant.

What fernewelten is refering to, probably, are checks that are done by the script interpreter during certain bytecode operations. Like - stack operations. They happen all the time, for every little move on the stack (I know that some were disabled in the past, but some may remain).

As for trusting or not the compiler, frankly in all these years there have been a minimal amount of errors found by these checks, maybe one in several years. fernewelten's proposal to have separate "production" interpreter, and "debugger" makes sense, in my opinion. (There has been a ticket regarding this, although it's more like a note, not a full plan: https://github.com/adventuregamestudio/ags/issues/843)



Then, there are things introduced during earlier rewrite, when trying to handle 64-bit problem, and backward compatibility, that may be bad, like virtual method calls in dynamic object wrappers. Where the old interpreter would simply access a memory pointer and read and write in a buffer, the new interpreter will dereference 2-4 pointers and maybe make a virtual method call.
In other operations, where old engine would do a simple pointer math (+/- a single value), the new one does more computation (e.g. see https://github.com/adventuregamestudio/ags/issues/869)
This all objectively slows things down, which may not be too much for a single operation, but will accumulate if there's alot of them, especially when working with dynamic arrays, i think. What makes things worse, some of these were probably necessary only in certain cases, but not all the time, yet affect many actions.

In any case, whether something slows things down or not, and how much, should not be guessed, it has to be measured.

Personally, I believe that it may be worth to go back to the old script interpreter and look at the system awhole, write down notes about the big picture, and search for a better solution to the problems which I and JJS were trying to solve with this rewrite. Maybe some of these problems have much better and simplier workarounds.

For the reference, there also is the earlier ScummVM AGS port done by fuzzie, from which I took some inspiration, and strangely we came to similar ideas about interpreter. My memories of it are vague now, but maybe it's worth checking out how she solved same issues in her rewrite: https://github.com/adventuregamestudio/scummvm/tree/ags



As for merging instructions, this also may be looked into in the parallel. There's an old thread about this here, but there has been no work on that. There's also a code optimizer written by rofl0r called "agsoptimize" here, from what i understand, it does not introduce new instructions, but squashes multiple into existing ones.

BTW rofl0r also has a tool that runs purely bytecode without the engine, if that's what you meant by "disconnect the AGS Script runner from AGS Engine"? it's called agssim:
https://github.com/rofl0r/agsutils/blob/master/agssim.c

This feature is included in the latest 3.6.0 beta 3 release.

This refers to restoring acsprset.spr; storing sprites as separate files is still in plans for the future versions.

I sent the codes to my friend who taught me this software, who has played dozens of games with it, she can see that my codes are not aberrant. So lines of code that worked for months don't work anymore, you don't have to believe me but this software has gone crazy, general bug, hacking or what, I can't even fix some problems.

Perhaps you could post them here and explain what does not work? If you look around these forums, you will see that many people have come with weird problems, and most of them were eventually solved.

Even if there's a bug in software, we must know what the problem is exactly, which script does not work as expected, and so on, otherwise nobody will be able to fix these. Just saying "software does not work" without actual, detailed examples will not solve anything, and this conversation will go nowhere.

[Common:]

Updated to Beta 3
(use download links in the first post)

Common:
- Discontinued "Windows Game Explorer" support in both Editor and Engine.

Editor:
- Editor will now create an empty spriteset file (acsprset.spr) if one is missing in the game project. Any existing sprite descriptions in the project will be kept, letting user to reimport these from sources.
- Added "File -> Restore all sprites from sources" menu command.
- Added "Apply" button on editor's Preferences dialog.
- Fixed blank rooms not assigned a default mask resolution.

Script API:
- Added GUIControl.Transparency property. This lets change individual transparency to any gui controls.
- Made Overlay.Width and Height properties settable, that let you freely scale existing Overlay.
- Added readonly Overlay.GraphicWidth and GraphicHeight properties that let read original overlay's graphic size (in exchange for Overlay.Width and Height).

Engine:
- Engine now renders GUI controls as separate textures when using hardware accelerated renderers. This may significantly improve perfomance in the high-resolution games and games with large number of GUI elements on screen.
- Fixed on_key_press not called sometimes.
- Fixed special engine key combos not working if the new style key handling was on.
- Fixed non-clickable controls stealing mouse clicks.
- Fixed ListBox items drawn over scrollbar in gui clipping mode.
- Fixed TextBox duplicating letter input.
- Fixed 16-bit sprite pixel corruption in 32-bit games.

Linux:
- Fixed engine failing to find game data in paths other than current working dir.

Hi, I mean maybe the under the hotspot options or region options (property window), there could be some functions to make a mirror from the hotspot. For example "Ä°s hotspot a mirror? true / false" and "Which region number ?  Region number : 1". Of course inside the room the right hotspot and region should be selected.

Are you speaking of making a visual effect that shows the character in a mirror?

This is of course not a problem of adding a property, but a much bigger problem of designing and coding such feature. Something like that has to be thoroughly planned first (what is expected from this function, how it is implemented technically, and so on). It's not even clear what should be shown in such "mirror", as the AGS rooms are not 3D, and engine has no idea about perspective, and objects opposing a "mirror".

Personally, I think in 2D games effects like that are better done with a script. Right now the mirror may be scripted, for example, using second character hiding under walk-behinds and showing in a certain gap. That's much easier to script such custom effect in a couple of rooms, rather than figuring out how to make a universal mirror function in the engine, that would suit everyone.


On the other hand, the region (or rather walkable area?) sounds seem like something that may be considered in the future, as right now game authors have to edit view frame sounds at runtime to achieve different walking sounds. Or at least something that would help to script this easier. Again, this is something that has to be thought through very well, there will be number of questions on how to do this, as sounds have to be played on particular animation frames only, and different sounds may be wanted for different characters.

Maybe you should add the mirror function under the hotspot options and the region sound property or options.

Please elaborate?

Hello Cassiebsg, Thanks for that info, I'll give it a try. So far I've done everything with ChangeView and SetView, it worked.
I still tested 2 levels, disaster. All the characters screw up, especially when there are Waits and sequences of animations, to turn their heads, change positions.

I may only repeat the previous advices: try to create a smaller separate scene, and experiment with small command sequences there, until you get them working correctly. Then when you have a working example, use it everywhere in your actual rooms.

Also, I recommend learning how to write and use your own functions. Functions are good to program short actions that you use alot; with them you'll have a short sequence of commands written once as a function, and then call that function whenever you need that sequence. If you learn how to use script modules, you may put these functions there and they will be available for use in any room (level).

As a random example, following function would lock character to a view, run a blocking animation, and unlock to a normal view:

Code: ags

function AnimateOnce(Character *c, int view, int loop, int delay) {
    c.LockView(view);
    c.Animate(loop, delay, eOnce, eBlock);
    c.UnlockView();
}

and then you may just do:

Code: ags

    AnimateOnce(player, 51, 1, 3);

Also, I recommend to not use view numbers, because it's easy to forget what they mean. Instead try using view names. For each of your View, AGS creates a view name in script, in all caps. For example, if you have a view called PlayerViewNormal in the editor, then in script you may do:

Code: ags

    player.ChangeView(PLAYERVIEWNORMAL);

This will make it easier for you to understand what is happening there.

What exactly effects the speed of AGS games?Would it be the graphics resolution,the filesize of the graphics,the amount of animations running at once,or something else?

All of that, and some other things. Using "raw drawing" commands in script may also be quite slow in high-res games. I.e. one thing is to have mostly static pictures on screen with some text, another - to have an arcade game with lots of moving parts.
Using the engine features incorrectly, or inefficiently will also slow the game down, even on the best engines.

Usually the good way to find an answer is to make a prototype of a scene and push it to the limit, put a max number of objects and action as you think you may get in your game, and see what happens on an average computer. If it does not work well, then find ways to reduce the work for the engine.

If the resolution of the game is scaled down to the users screen size would that make it run faster

Not at all. The scale of the whole game to the final size (the player's window) is performed as a single and very fast step. So it is the original (native) game's resolution that matters.

Although, frankly, I am not sure if you meant scaling down the sprites before importing into AGS, or scaling down the game when it's run. Some clarification is needed here.

It's the pathfinding that completely kills the gameplay. It stutters every time it processes movement paths, even on 486DX2.

To be fair, the original pathfinding was very slow and also buggy. IIRC it was based on a floodfill algorithm. We now use a different pathfinding algorithm (A*, where grid is built from a pixel mask) written by a contributor, which sped it up by a lot, and also works universally (from what i could tell). There's still a room for optimization.

Found a new bug in 3.6.0b2 - labels no longer "pass through" clicks to GUI elements below (lower z-order), even though their "Enabled" and "Clickable" properties are set to false (you also get the same behaviour when Enabled is true).

Fixed, should be available as this temp build here (when it finishes building):
https://cirrus-ci.com/task/5006924272893952

[The two characters were walking at the same time]

I don't understand when you mentioned you have an interface to change the player character which you did not code.

From what I understand, it was said about the walking behavior, not interface:

When I click on the ground, the man moves to this point. While he's walking, before, I could select another character and move him too. The two characters were walking at the same time. I didn't do anything to program it, it worked like that from the start. Now the first stops, I don't know why.

So, this doesn't look like a function from AGS. Are you using the Tumbleweed Template? Is this a function used from Tumbleweed?

Changing player character is a function in AGS too:
https://github.com/adventuregamestudio/ags-manual/wiki/Character#charactersetasplayer

It is impossible to answer your question, because there's not enough details about the problem. We know nothing about your game, or rooms, you gave a very obscure description.

When dealing with issues like that it is important to narrow down the problem, and describe them in most detail. Take one problem at a time too.

For example, you have issues with character walking, or turning (I could not understand this very well). Take that problem, describe what you were trying to do in your game, describe what kind of errors occur. Show relevant part of your script. Otherwise no one will be able to help you.


On another hand, what eri0o was suggesting: to leave your big project for a moment, and make a very small mini-game that contains only certain code, related to one functionality (like character movement, for example) from your bigger game, and test that code in a smaller game. Then take another piece of code and do the same, and so on. Such approach sometimes helps to flesh out separate parts of the game.

Is the number of objects per room increased in this version?

No, I would have noted that in the changes.

Maybe i could look into increasing it while this version is still in beta; but right now I'm busy on some perfomance improvements, so maybe later...

It's not just the line with encoding needs to be commented out, it's the general syntax for translation options: this is how the translation compiler differs the options from the text lines.

The manual:
https://adventuregamestudio.github.io/ags-manual/Translations.html#additional-options

Font options let you define certain font substitutes for this particular translation. All options begin with the comment opening and a pound sign: //# - followed by OPTION=VALUE kind of string where "OPTION" is the corresponding name.

Updated the downloadable version, in above post, and here:
https://cirrus-ci.com/task/5730993683300352

Now there are two options, in case acsprset.spr is missing:
* editor will ask on game load, if you want to try reimporting sprites from sources; if you say "no" it will create a dummy sprite file with just a placeholder for sprite image (slot 0).
* there's an explicit command in File menu.
(and of course "reimport from source" command in the sprite manager)

Note that borderless fullscreen is only available since 3.6.0.

It's also useful to know which graphic renderer does this happen with (Direct3D, OpenGL, Software, all).

[@WiseFrog]

@WiseFrog, I moved your question to the separate topic, because really would prefer general printscreen problem discussed separately from the key handling topic:
https://www.adventuregamestudio.co.uk/forums/index.php?topic=59881.0

There's a difference between importing SVG as bitmaps and using SVG directly. First can be done with some other tool which converts SVG to bmp or png. Second would require writing whole new functionality for AGS engine that would support vector graphics, as right now engine works only with raster (pixel) graphics.

On a side note, theoretically speaking AGS is capable of rendering textures in full 3D, that is, for example, it could render a sprite rotated at a given angle along non-z axis, to achieve similar effect as the water in this demo game (or race track in AGS Kart demo game).

The biggest issue is the lack of "3d pipeline" as some called it, or in human words - there's no script commands and internal functions that would let configure this at the moment.