In a recent thread, it was mentioned that walkbehinds or baselines are treated differently in DirectX 9, and that this may cause conflicts for games developed with the DirectX 5 model in mind. Indeed, I'm seeing numerous walkbehind issues when running my game on DX9. Can someone please elaborate what the difference is and how to avoid in-game glitches? Thanks.
(edit) Solved: turns out that IgnoreWalkbehinds works differently in Dx5 than in Dx9; specifically, in Dx9 it is equivalent to simply setting the object/character's baseline to a very high number.
Agreed. This is a pretty big issue for me. Is it the driver or is it down to specific hardware issues?
Can you give an example of what is happening (how to reproduce)?
For example Snakes of Avalon is a game made with DirectDraw 5 set as the default graphic driver. If the player switches to DirectX 9 in the setup, then all the baselines (as well as transparencies) get screwed - things that faded out and are not supposed to be seen are still there, things that should be hidden behind other things are not etc.
The current version Snakes was made and compiled with the old 3.0 or 3.1 editor. I was planning to updating it to the new engine in the near future hoping it'd fix issues like this one.
Ancient Aliens - I can only play this using direct, but it will cause some objects to "forget" their baselines and be rendered in front of the character when he passes by. It looks completely awful.
The problem that the character and the objects have a tendency to 'forget' their baseline in D3D9 is something I got a couple of times. It had mostly happened when the y position of the character is the same as the baseline of the object, and I can speculate, since D3D9 mostly uses floats to calculate positions, the rendering messes up because of a rounded float or something like that. It happens too with walk-behinds since they are processed as objects in the D3D9 renderer. It also happens with characters when two are overlaping and have the same y position. Often flip-floping with behind and front of each other.
I managed to find a way for that problem to occur less frequently. I discovered this with scripted disappearing objects, where suddenly the character appeared in front of an object when another one is visible, and appeared behind the same object when that other one wasn't visible.
To avoid that I had to make sure no object and walk-behind have the same baseline value (always have a difference of 1, for example). Doing so, objects forgetting their baseline didn't happen anymore or very rarely.
Quote from: Andail on Sun 01/09/2013 18:03:41
Ancient Aliens - I can only play this using direct, but it will cause some objects to "forget" their baselines and be rendered in front of the character when he passes by. It looks completely awful.
Sorry to hear that, I made AA on my laptop witch doesn't support pixel shaders and that lead to all development being based on dd5.
Quote from: Nefasto on Sun 01/09/2013 19:50:55
The problem that the character and the objects have a tendency to 'forget' their baseline in D3D9 is something I got a couple of times. It had mostly happened when the y position of the character is the same as the baseline of the object, and I can speculate, since D3D9 mostly uses floats to calculate positions, the rendering messes up because of a rounded float or something like that. It happens too with walk-behinds since they are processed as objects in the D3D9 renderer. It also happens with characters when two are overlaping and have the same y position. Often flip-floping with behind and front of each other.
I managed to find a way for that problem to occur less frequently. I discovered this with scripted disappearing objects, where suddenly the character appeared in front of an object when another one is visible, and appeared behind the same object when that other one wasn't visible.
To avoid that I had to make sure no object and walk-behind have the same baseline value (always have a difference of 1, for example). Doing so, objects forgetting their baseline didn't happen anymore or very rarely.
Huh. That explains a lot. I was well aware of this happening, but didn't know it was a direct3D specific issue. I learned long ago to never give two object walkbehinds the same value as each other, and I do it automatically now. When all the threads about object walkbehinds getting screwed up appeared I was confused because it never happened to me! Now I know why. :-D
So would the same issue happen if an object has a baseline of Y=100, and the player character happens to walk on that same coordinate?
Miguel, could you take a look at your game with switched drivers, and confirm that the objects in the intro (backstage the club) have baselines that somehow coincide with the position of the character (granted you can replicate the bug)? Maybe it would be useful to know exactly when this occurs.
Without looking at the code I assure you that I had to set walkbehinds on and off to achieve the intro in the backstage pub. There is a table with a walkbehind, a glass (object) and then 2 more glasses (objects) as well. all this had me switching WB's on and off and while some could just be at the bottom of the canvas, some didn't.
I'll look at it soon.
Quote from: Radiant on Mon 02/09/2013 10:29:25
So would the same issue happen if an object has a baseline of Y=100, and the player character happens to walk on that same coordinate?
No, because the character's baseline is not set to 100. If the character is at Y coordinate 100, that's just the character location - NOT the baseline. By default, the baseline is 0.
Quote from: Dave Gilbert on Mon 02/09/2013 13:07:56
Quote from: Radiant on Mon 02/09/2013 10:29:25
So would the same issue happen if an object has a baseline of Y=100, and the player character happens to walk on that same coordinate?
No, because the character's baseline is not set to 100. If the character is at Y coordinate 100, that's just the character location - NOT the baseline. By default, the baseline is 0.
This I don't get. Surely the baseline of the character is where it stands, and updated accordingly? That's how the game knows if the character should be rendered behind or in front of stuff.
Just checked the code and there are no matching baselines for objects or hotspots. Characters may "step" on them though but not stand on their exact Y location.
The Character's Baseline property isn't updated whenever the character moves, but AGS will only use it to determine drawing order if it isn't 0, otherwise it'll use the character's .y
So whenever the character is standing on y = 100, their Baseline might still equal 0, but their effective baseline, as used by AGS to determine the order in which the screen is drawn, is of course still 100. And at this point the Direct3D screws up, it seems.
Huh. Interesting. I've never encountered this myself, and after launching ten commercial AGS games (all in Direct3D mode) I have yet to hear about it happening to anybody else. It is sounding like the objects are set up in a very specific way which is causing this problem, and I am curious to know what it is.
Does this only happen if two objects are in front of each other? And then the player steps on the Y coordinate equal to one of the baselines and then one of the objects gets pushed to the back? What are the actual effects here?
I too, have never encountered this issue despite messing around with AGS a lot and always in D3D.
I just want to echo Calin. I've always used D3D and never noticed this problem - it is very concerning to think that some people might be experiencing it with D3D games though.
D3D is running fine on my machine, too. It seems to be a graphics card / driver issue.
It sounds to me like a z-sorting issue of some kind and it would make sense that certain drivers resolve z-sorting differently.
Quote from: Calin Leafshade on Mon 02/09/2013 19:48:13
It sounds to me like a z-sorting issue of some kind and it would make sense that certain drivers resolve z-sorting differently.
One the one hand, that makes sense, but on the other hand... I don't see why I haven't gotten this complaint before. Ten games, all using Direct3D, sold to at least ten thousand people. Even if this only affected a small number of drivers, it seems like this would have come up at least once in one of WEG's games. Either I'm doing something differently when I set up my objects, or I've been very very lucky. It makes me think that there is something specific in the way that those objects are being set up - in addition to the driver issue - that is causing this problem.
It occurs to me - how often does a character stand at exactly the same Ypos as a walkbehind? It looks bad if a character passes through a walkbehind, so surely most of the time the walkable area is setup in such a way as that rarely if ever happens? Could that contribute to why lots of us haven't noticed?
Yes. This strikes me as typically something that many programmers just intuitively don't do, so it won't happen to them.
That... makes perfect sense! There's no practical reason for the player character to have the same Y position as an object, and be behind that object at the same time. I suppose this would only be a major issue when you have one object in front of the other. If the character is at the Y position of the object in front, the front object will jump behind the object in back. Theoretically, anyway?
In Ancient Aliens, which, I admit, is the only game I've encountered this bug in - there are some objects on a table. In DirectDraw, they're drawn properly behind the main character when he passes in front of the table.
If I switch to Direct3d and try the same scene, the objects will inexplicably end up in front of the character, and he can walk several pixels up and down (along the Z axis) with the problem persisting, so it's not a matter of just one pixel.
(http://www.esseb.com/andail/weirdness.png)
There's plenty of space between the near edge of the table and the bottom of the screen for the character to walk, but he will never end up in front of the objects.
It could be those two objects have the same baseline number? I know that caused a lot of havoc in Puzzle Bots (which I made in Direct3D mode!) and object baselines would often react very unpredictably. I didn't realize what was happening at the time, but I did notice that using different baseline numbers for every object fixed the problem. I've made a habit out of using different baseline numbers for objects ever since, which would explain why this has never happened to me (or - at least - why I never NOTICED it happening to me!).
I can replicate this.
Interestingly, the mouse cursor text will still properly show "Chet" when hovering over a part of the wallet that should be obscured by the character, so it's a purely graphical issue.
Here's a wild guess: the sorting algorithm used by Direct3D assumes that A.Baseline is always either less or greater than B.Baseline, which makes both objects end up at the end of the sort list and thus drawn in front of everything else.
When you create a new object, if you don't specify its baseline manually then the object's base becomes the baseline, right?
Quote from: Ali on Mon 02/09/2013 20:00:35
It occurs to me - how often does a character stand at exactly the same Ypos as a walkbehind? It looks bad if a character passes through a walkbehind, so surely most of the time the walkable area is setup in such a way as that rarely if ever happens? Could that contribute to why lots of us haven't noticed?
Well, it can happen when we have a background of a field with high weeds for example and we want the characters to go through those weeds. We draw enough layers of objects or walkbehind and the characters can go through the objects/walkbehinds to give the illusion of shuffling through the weeds.
This is one example of a situation where the characters can have a matching y-position with the baselines.
To better illustrate, if an artist/level designer wants to do stuff like this :
(http://yeppoh.stage-select.com/www/comics/nefadv/nefadv_30.jpg)
Good example, Nefasto, but I didn't meant to imply this wasn't a problem. I was just trying to work out why so few of us had noticed it. I'm sure the same thing could happen with mist/fog, a waterfall, a forcefield or anything else which a character can walk through.
It's okay, Ali. I wanted to add this example as a key point to also strengthen your statement.
This kind of examples aren't found very often in AGS games. It takes its share of time and work to create (assets and/or walk-behind masks) and setup in the editor. It can become an hassle, depending. Which is also why few of us noticed the problem with the walk-behinds and all.
We now know that it's not hardware-related too as it's still the same with a different card.
The baseline acting weirdly indeed.
I created 4 mutually overlapping room objects with the same overriden baseline.
With DX5 the drawing order of objects is following (from the topmost): 1st, 4th, 3rd, 2nd. (!!!)
With D3D: 4th, 3rd, 2nd, 1st (reverse to object index)
I would not dare to say that DX5 mode is the one that acts properly here... I'd rather say that D3D acts at least consistently.
I am also more than convinced that before fixing anything we must consider what IS the correct behavior.
EDIT: I added character with the same basline to this, and
With DX5: the character overlaps all objects except the 1st, which overlaps the character.
With D3D9: the character overlaps all objects...
It looks like with the DX5 the 1st object in the room has incorrect inconsistent drawing order... I will make same test on other computer to see if the results will stay the same.
In this case, it strikes me that D3D has the correct behavior.
However, there is a real bug aside from this inconsistency. Please check the savegame linked below with the build of Heroine's Quest I sent you earlier. The door in this room (object 2) has an Y position of 138 and a baseline of 133. The heroine is standing at Y 151, yet she is displayed underneath the object. This error does not happen if I use winsetup to set the graphics driver to DirectX 5. I would really appreciate it if you could look into this, as it is a very important issue for HQ, and presumably other games.
http://crystalshard.net/test/agssave.000
OK, I'll do.
But I'd really appreciate instructions on how to create such situation in a simple test game (this will be easier to work with). I'll see what happens if I just reconstruct this in a one-room game...
I'll likewise try to reconstruct it; this just came up during beta testing (in about two dozen different rooms...)
GOTCHA.
The key is in setting the IgnoreWalkbehinds flag of an object. With DirectX 5 an object that ignores walkbehinds is still placed in its normal layer, but ignores walkbehinds. With DirectX 9, an object that ignores walkbehinds is also placed in front of other objects and characters that it should not be in front of.
I found a place in engine where it sets an internal flag only if hardware acceleration is supported.
Disabling that flag makes D3D9 place objects same way as DX5, but screws flipped view frames when character is beyond walk-behind.
What would you suggest? Using ignore_walkbehinds, it's technically possible to set three objects/walkbehinds/characters so that A is behind B, B is behind C, and C is behind A. It wouldn't surprise me to learn that hardware-accelerated 3D doesn't support that.
Ok, I found the EXACT piece of code that screwes this.
This is how an object's baseline is fixed for D3D9:
if (objs[aa].flags & OBJF_NOWALKBEHINDS) {
// ignore walk-behinds, do nothing
if (walkBehindMethod == DrawAsSeparateSprite)
{
usebasel += thisroom.height;
}
}
This left me is total confusion. The object's baseline is simply modified to be higher than anything.
No wonder characters appear behind.
I commented out the line, and now characters are properly drawn over the objects.
EDIT: Err, okay, I am wrong, now objects fail to overlay walk-behind :(.
Thank you! What about characters that have 'ignorewalkbehinds' set? Probably the same applies.
Quote from: Radiant on Tue 24/09/2013 15:11:58
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.
Actually, looking at the manual, I found this:
QuoteNOTE: 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?
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.
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.
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
Quote from: Radiant on Tue 24/09/2013 15:44:05If 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
(http://upload.wikimedia.org/wikipedia/commons/f/fe/Escher_Cube.png)
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.
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.
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.
Is there any way of in-game checking which driver is being used?
It would simplify some of the d3d adaptation of older code.
Quote from: Crimson Wizard on Tue 24/09/2013 22:10:17
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.
Quote from: StillInThe90s on Wed 25/09/2013 04:45:47
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.
Quote from: Crimson Wizard on Wed 25/09/2013 08:28:00
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.
Quote from: Radiant on Wed 25/09/2013 10:03:13
Quote from: Crimson Wizard on Wed 25/09/2013 08:28:00
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
If I understand correctly they're consistent within D3D, but not within Dx5?
Quote from: Radiant on Wed 25/09/2013 10:21:50
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.
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.
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.