(solved) Walkbehind issue with DirectX 9

[Radiant]

Thank you! What about characters that have 'ignorewalkbehinds' set? Probably the same applies.

[Crimson Wizard]

Thank you! What about characters that have 'ignorewalkbehinds' set? Probably the same applies.

Sorry, I am mistaken, this makes objects not ignore walk-behinds.

I am thinking maybe there is other way to make them work, without hacking their baselines...

Regarding your question, yes it does the same for characters.

[Khris]

Actually, looking at the manual, I found this:

NOTE: enabling this property does not currently work properly when using the Direct3D driver.

But: I'm not sure if you would ever really need this property. The example issue given in the manual (a picture on a wall that the character can walk behind) is very easily resolved by changing the pictures baseline to 1 pixel below the walkbehind's, isn't it?

[Radiant]

You might not need it, but it's pretty convenient at times and substantially used in some games (e.g. mine, currently). If this function was never intended to work with Direct3D, I would recommend removing it entirely (even without enforcing new-style scripts), so that people don't accidentally use it.

[Crimson Wizard]

This is all because in Direct3d walk-behinds are treated as separate sprites too, while in DX5 they are pre-applied by cutting out regions from chars and objects (or something like that).

Now, at first I thought I could add some flag that would tell z-order sort when the object or character should be above walkbehind, but the problem is that sorting is done using "qsort" algorythm, which does not compare all possible pairs of elements (which is good for speed).
For example, if a character is compared with "ignore walkbehind" object, then the object is put down. Then the walk-behind is compared to object, it is put even more down (because it gets ignored). So not only the object will appear on top of walk-behind, but even character. So, this won't work so simply.

[Crimson Wizard]

By the way, isn't it the same issue Andail is having in Ancient Aliens?
http://www.adventuregamestudio.co.uk/forums/index.php?topic=48907.msg636466627#msg636466627

If this function was never intended to work with Direct3D, I would recommend removing it entirely (even without enforcing new-style scripts), so that people don't accidentally use it.

Actually, I would support making IgnoreWalkbehinds property deprecated. For it breaks the room layers logic. It is basically same thing as make a special layer that would overlay one other layer, while staying beneath third layer, which yet hides beneath second one.

I am sure Escher would love this.

Spoiler

[close]

But it makes things really confusing. To think of it, walk-behind can be thought as simply another object, we just re-use the room background to save memory, isn't it?

Unless someone can think of a situation when there's no other way to achieve the wanted effect without this property, I'd vote to deprecating it and advise people to never ever use it in the future.

[Radiant]

Well, I'd have to rewrite a bunch of code, but from a programmer's point of view I agree with you. However, I do think using the function should generate a compiler warning in future builds of the AGS editor.

[Crimson Wizard]

I think it is possible to make a hack in the engine which would resort things with "ignore walkbehind" property and put them before walk-behinds after they were sorted normally.
This will slow things down... but how much - I don't know. Maybe not so much, all depends on number of stuff in the room.

[StillInThe90s]

Is there any way of in-game checking which driver is being used?
It would simplify some of the d3d adaptation of older code.

[Crimson Wizard]

I think it is possible to make a hack in the engine which would resort things with "ignore walkbehind" property and put them before walk-behinds after they were sorted normally.

Okay, that was written in the late night by me. Simple resorting wouldn't solve this, because of the possible situation, described by myself few posts above (see Escher's pic). I am currently thinking about maybe copying piece of "ignoring" object over walk-behind. But seeing how many times I misjudged the complexity of work, I won't make any hastly promises.

Is there any way of in-game checking which driver is being used?
It would simplify some of the d3d adaptation of older code.

I think System.HardwareAcceleration (boolean) will work for this.


Other than that. Radiant, I see you marked this topic as "solved". But, AFAIK, there's still a problem of randomly different z-order sorting of the things having identical baseline.

[Radiant]

Other than that. Radiant, I see you marked this topic as "solved". But, AFAIK, there's still a problem of randomly different z-order sorting of the things having identical baseline.

Good point, but I'm not sure that "newer versions of AGS are consistent with respect to Z-order whereas older versions are not" counts as a bug   It may need a warning if importing a game from older versions, but otherwise I don't really see a problem here.

[Crimson Wizard]

Other than that. Radiant, I see you marked this topic as "solved". But, AFAIK, there's still a problem of randomly different z-order sorting of the things having identical baseline.

Good point, but I'm not sure that "newer versions of AGS are consistent with respect to Z-order whereas older versions are not" counts as a bug   It may need a warning if importing a game from older versions, but otherwise I don't really see a problem here.

But they are NOT consistent...
http://www.adventuregamestudio.co.uk/forums/index.php?topic=48907.msg636468572#msg636468572

[Radiant]

If I understand correctly they're consistent within D3D, but not within Dx5?

[Crimson Wizard]

If I understand correctly they're consistent within D3D, but not within Dx5?

Well, as far as I see from the test... but I was speaking about differences between Dx5 and D3D.

[Radiant]

I think then the underlying question is, should the engine continue to support Dx5? The reason I'm asking is because a recent post by Dave Gilbert indicates that many contemporary computers (e.g. anything on Windows 8) do not work with Dx5 anyway. DirectX 9 was released in 2002, so I don't think it's a big deal to require people who want to play newer AGS games to download it, if they haven't already. This is similar to how the current AGS editor requires .NET, which was also released in 2002.

This probably needs broader input from the community, though; but I'm not sure it's worth the hassle fixing a complex issue in Dx5 layering at the moment.

[Gilbert]

The DX5 renderer should remain, unless we are going to abandon 8-bit modes (which is the proper time I abandon AGS). AFAIK D3D9 doesn't work with 8-bit modes, unless it's changed recently.