(solved) Walkbehind issue with DirectX 9

[Radiant]

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.

[DazJ]

Agreed. This is a pretty big issue for me. Is it the driver or is it down to specific hardware issues?

[Crimson Wizard]

Can you give an example of what is happening (how to reproduce)?

[Igor Hardy]

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.

[Andail]

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.

[Yeppoh]

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.

[miguel]

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.

[Dave Gilbert]

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.

[Radiant]

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?

[Andail]

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.

[miguel]

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.

[Dave Gilbert]

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.

[Andail]

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.

[miguel]

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.

[Khris]

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.

[Dave Gilbert]

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?

[Calin Leafshade]

I too, have never encountered this issue despite messing around with AGS a lot and always in D3D.

[Ali]

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.

[Khris]

D3D is running fine on my machine, too. It seems to be a graphics card / driver issue.

[Calin Leafshade]

It sounds to me like a z-sorting issue of some kind and it would make sense that certain drivers resolve z-sorting differently.