Messages

[coincidental factor]

If two overlays have the same z-order, their per-frame order is based on the cosmic rays hitting the earth and the energy flowing through ley lines in that precise quantum moment, which makes them flicker to the front and back.

  Funny... but I think this is not the case: if you watch carefully you can see that flickering is not random, it always happens at same moment on same overlay when player is in same position. There is something in the engine code which makes player position influence overlays draw order. 

It's not literally "random", as in Khris's joke. The actual result is determined by the number of game elements, their z-orders, and std::sort algorithm. As character moves around, its z-order changes (with y coordinate), which affects overall sorting. Elements with equal z-order will be treated depending on a coincidental factor. This result is actually deterministic in a given environment, but it won't help to know how it's received, and should not be relied upon, that's the point. (Hypothetically, it may even depend on C++ library implementation used when compiling the engine, so different versions of engine on different platforms may have slightly different result.)

[undefined]

Yes, I assigned same Zorder to all objects which in "real world" would lie down on same floor tile. But they are drawn bottom-up, so I don't get why the final result is not as I would expect.

What would "bottom-up" mean, logically? The overlay sorting is only defined by ZOrder parameter. The sprite sorting in AGS is done using a standard std::sort algorithm, where if two or more elements have equal factor, their relative order is undefined. Their order of creation does not mean anything in this regard.
EDIT: hmm, I thought this is mentioned in the manual, but it's not, so i have to add a clarification...

To make their order defined, we'd need to introduce another parameter, that would be used when zorder of two elements is equal. Historically AGS does this for GUI: if two GUI has same ZOrder, then it will also compare their IDs. But it does not do that in rooms (well, I mentioned that above).

If you want them to be reliably "bottom-up", then there are at least two natural solutions:
1) Have them have explicitly different zorder;
UPD: note that zorder may be negative too, so in case of a floor, you may make floor tiles have sequences of zorder < 0, to ensure they never draw over characters and other elements.
2) Paint the stacking tiles on a single overlay (as much as possible without breaking sorting among other overlays and characters).
UPD: you may even draw floor tiles on a room background, instead of creating overlays.

The parts that disappear and reappear seem to be in the same spot as a bunch of background overlays; is it possible they have the same z-order value? As in, cannot be sorted reliably?

This may be the case; I recall that in some separate case AGS also compared object ID, which corresponds to their order of creation. Perhaps same could be applied to the drawing sort. The problem here though is that ID sequences are not shared through all the object types (for example, there may be roomobject with ID 1 and character with ID 1, and overlay with ID 1).

To improve this situation in the future we'd need to setup a certain rule for how the sorting is done among all the objects which have equal zorder/baseline.

The solution for now may be to give these tiles slightly different ZOrder.

Another solution that could be tried here, in my opinion: merging multiple static tiles, that are located in the same position, on a single overlay, instead of creating a separate overlay for each tiny element.

@rongel
Another update: https://cirrus-ci.com/task/5986584122621952

So, all of this is not related to fading, or making GUIs visible, even following triggers the problem:

Code: ags

function btn1_OnClick(GUIControl *control, MouseButton button)
{
  Wait(40); // Move mouse away from the button while game is paused
}

I noticed that you have a setting that when interface is disabled, GUI should "display normally". This may be an essential difference between yours and my test games.

[EDIT:]

I define ZOrder of all my overlays only once at room creation, but I see various overlays changing draw order while character moves around them: sometimes overlay A is drawn over overlay B, other times B gets over A while character moves around; how do character movements influence overlays zorder?

Hmm, unless that's a scripting mistake of some kind, this might be a sorting issue in the engine. Character movement influences only how character itself appears compared to other elements, not how elements appear in relation to each other.

Do you have a script example demonstrating this behavior? Alternatively, is it possible to download a game.ags file somewhere, to let me test this under debugger?
I will try to set up my own test too.

EDIT:
Here's my test game that creates N room overlays randomly in the room, in "Before fade-in" event:
https://www.dropbox.com/s/by18sil7hozd99z/test--360overlayssort.zip?dl=0
I do not observe same effect there. But maybe my game setup has differences.

Are you sure you do not recreate overlays repeatedly, for example, or change their Graphic, etc?

[Things that don't work:]

Things that don't work:
- Fading out and fading back in the GUI (that has the button) with Tween Module
- Making another GUI visible after clicking the button (no Tween Module, no fades). This seems the most strange one to me.

I can send my test game if it's easier to see what I mean.

I could not reproduce this using the temp 3.6.0 build (which I linked above). I guess I will have to see this in your game...

I tried your game, and this crash is caused by the line

Code: ags

import bool GUIControl* getAgentMarker(this Character*);

This line has a syntax mistake (bool followed by GUIControl*), but Editor crashes when trying to report the error.
This crash seem to be fixed in an updated 3.5.1 (see latest patch here: https://www.adventuregamestudio.co.uk/forums/index.php?topic=60441.0).

Anyways, the correct line should probably be

Code: ags

import GUIControl* getAgentMarker(this Character*);

As far as I know, TweenFadeOut calls Visible = false secretly when transparency reaches 100, so that's same case in practice.

So, you are making whole GUI invisible, not just the button?

Well, I just created a new view (585) with exactly the same sprites and now it is working. I don't know why it was not working with the 583. As a test I have deleted the 583 and created back again and it doesn't work again. It seems that this view number is not working, at least in my project.

Is there anything in scripts triggering on view 583? Like some code in repeatedly_execute_* functions, which tests if player's view is 583 and changes it? Perhaps do "Find in project" for "583".

I seem to have fixed this, the temp build download will appear here, in about 1 hour:
https://cirrus-ci.com/task/6686114136719360

EDIT: should be available now.

Looks like I managed to reproduce it in a new test game. I made a button with all the different graphics, then when I click it, it does this:

Code: ags

function btn1_OnClick(GUIControl *control, MouseButton button)
{
  btn1.Visible = false;
  Wait(40);
  btn1.Visible = true;
}

Yes I see now; looks like I fixed one thing but broke another... This happens in both 3.5.1 and 3.6.0.

[3.6.0.37]

So earlier I used the version 3.6.0.37 and everything worked well. I have a GUI button that has a normal image, pushed image and a mouse over image. After I click the button, I make it invisible. Then, if I make it visible again, it will show the normal image (it's reseted to the default look). So all is well.

After updating to 3.6.0.40, the button behaviour changed. When I make the button visible again after clicking it and hiding it, it still displays the mouse over image (the button is highlighted). This happens even if the mouse isn't over the button. The only way to "reset" the button to the normal image, is to hover the mouse over it again, and then move the mouse away from it. This behaviour might have started already in the previous RC 4 version.

I cannot reproduce this, in a test game I made button acts properly when becoming visible again. I tried both making button invisible and whole gui invisible (and visible again).

I may mention that between 0.37 and 0.40 I did one fix related to button update after interface gets disabled and enabled (on game pause/unpause). Maybe this is connected somehow, but so far I cannot tell what went wrong.

Can I see your game somehow, is it available for download?

I am wondering if the engine gives some troubles when having more than x views in the game.

Does it work with any random view, like view 1, 2 etc?
Is it absolutely certain that view 583 does exist?
Sorry for stupid questions, I had to be sure.

BTW, I just wanted to mention, that you don't have to use raw numbers. For each View AGS generates a constant, which name corresponds to view's name in capital letters. For example, if your view is called PlayerView, then it will be PLAYERVIEW, and you can do:

Code: ags

Isaac.ChangeView(PLAYERVIEW);

Please tell, in which situation do you call this? What function; and are there any other view-related commands around these lines?

What happens if you use same command elsewhere, for instance, in game_start, or when starting some room which is easy to test, in "before fade-in" event?

Please tell, what is the version of AGS exactly you are using? This may be found in Help -> About menu.

Do I understand correctly, that there's no error message whatsoever, and the program just terminates?

Is it acceptable for you to upload your game project somewhere for AGS developers to test it? This may be done through PM on this forums, for example, and we promise that we won't distribute your game sources.

If not, we will need to think how to diagnose this problem...

Do you use any source control utility with your project (SVN, Git, and so forth)?  If yes, then you could go back in history and find a change which started causing this problem.

Alternatively, one solution (which may be quite slow) is:
1) make a full project backup
2) start removing rooms and scripts, until you reach a state at which it no longer crashes.
This will narrow the problem down a bit.

You can either use F1 and search in the Editor manual

It does not search for the parts of function names in the offline manual either, for some reason.

This looks like some possible issue with the search in both cases, because there are several "CreateFrom***" functions belonging to DynamicSprite.
Maybe it cannot reliably search for parts of function names.

Both answers are: "no", but there may be workarounds (of varied levels of ugliness).

For the first case, the existing workaround is known as "object pool", when you create alot of hidden objects in the editor, and then reuse them at runtime, remembering which ones are "in use" and which are "free". Same works for characters, and anything else. That is how arcade games were created in AGS in the past.

For the second case, depending on which particular functions do you want to use, you may sometimes utilize a hidden "reference object".
For one example, if you make a hidden object, you could animate it and make Overlay follow that animation, by setting current object's frames in late_repeatedly_execute_always.
For pathfinding, you may order a transparent object to move around, and sync Overlay's position with it.

Alternatively, you would have to reimplement these functions in script.

Is there a "GetNumberOfWalkBehindsInTheRoom()" method?

Not really, when in the editor users are presented with max areas always, regardless if they use them all or not.
The supported number of areas is hardcoded and may depend on the engine version (may be found in the manual hmm, manual is missing these), but absolute maximum is always 256, because that's a 8-bit mask.

It may be possible to scan the area mask on room load and check which pixel colors are present; afaik AGS does that for walk-behinds when cutting them into separate sprites.