Messages

1-

Spoiler

Glitch: I came across this glitch in the hotel's lobby when I had managed to fool the goons. When Chet stood up, the lady and the table between the sofas were drawn above Chet while the sofa in which lady was sitting was drawn behind the Chet. I re-walked him to the said place (after Chet had stood up and was free to move anywhere) and the result was same. Btw, I used Direct 3D 9 in the winsetup.

[close]

I don't know how the scene was created, but I think that may be related to the IgnoreWalkbehinds property. D3D9 mode cannot handle them properly.
If that's the case, I may suggest authors to review how they make the scene, and abstain from using IgnoreWalkbehinds at all, and use combination of Baselines instead (related discussion: http://www.adventuregamestudio.co.uk/forums/index.php?topic=48907.msg636468585#msg636468585).
I think this screenshot made by Andail is from "Ancient Aliens" as well?
http://www.esseb.com/andail/weirdness.png
I believe it is exactly the case of "ignore walkbehind" property.

On other hand, if no objects or characters had "IgnoreWalkbehinds", that might be "same baseline" ordering error, which cannot be easily fixed by developer at the moment... (unless fixed in the engine at some point).

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.

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

Oh come now, be serious.  None of those are right.

I believed "head" is correct

My guess for 1 is Life then.

Also 2.

Spoiler

Need

[close]

Here's a small test project I made with 3.3.0 beta 7 to demonstrate the issue.

Download Here

Open it in the editor and look in the Sprite Manager. You'll see I have created 3 new folders: SlotA, SlotB, and SlotA (again).

Ohhh. No, there aren't two "SlotA" folders. There are two different folders: "SlotA" and "slotA".
Ironically, it works well with both of them having names in same case, but does not work with them having same name in different cases.
Anyway: fixed!


Regarding other requests: I did not set myself a deadline, I just would not want to start time-consuming tasks for 3.3.0. Otherwise this will become an endless process . And some most people don't like it when the version is "in development", they look for "official releases".
I'll check how much time will these things may take to implement.

What I mean is, if you're drawing a sprite that uses alpha transparency onto a surface that doesn't have an alpha channel, that's not really a well-defined operation (in any part of the surface that was transparent due to magic pink), and the result is always going to be distorted in some way. Even if you did have a DrawImage blend parameter, asking it to blend without alpha still doesn't provide any good answer to how it should treat alpha-transparent pixels.

Hmmmmmm.... right.
Perhaps, in any way, there should not be any "special" way to handle magic pink on destination surface, because that would mean we would take it differently depending on whether we blend an image over or drawing this image itself (using magic pink as transparency).
So, I think, for now we are to define the "default" operation for DrawImage to use when painting RGBA with RGB. Two possible options are:
1) Plain copy RGB (discard source alpha);
2) Standard rgba->rgb alpha blend (ignoring destination alpha): this will produce pink hues on magic pink.

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.

If you're telling AGS to alpha-blend two sprites onto a surface that doesn't have an alpha channel (but does use magic pink), you're essentially asking for the impossible. The operation doesn't make sense.

Well, the thing is that we cannot explicitly ask AGS to "alpha blend" sprite to surface. At the moment there's only one available operation: DrawImage. Which may simply mean "draw as you can".
Maybe it is better to just make opaque copy to surface with no alpha, and wait for the times when DrawImage will have "blend operation" parameter?

I'm not sure if this is the right place to ask this, but is there an approximate time frame for when we should expect a general release of AGS 3.3.0?

I hoped to put couple more things in there which may take about a week. Then it will be a "release candidate" version, I think.
Anyway, there should not be anything that could prevent you from upgrading from beta to final release.

Sorry, but more on this topic...

mySurface.DrawImage (0, 0, graphicID, customTransparency);

And Iget the bug: whenever customTransparency is not exactly 0, the non-transparent parts of the sprite appear pink instead of having their own color and being partly transparent.

There are two cases: when the drawing surface you create has alpha channel and when it does not.

The first case is simple: the result should be alpha blending of two surfaces, while the overlaying surface may have additional transparency (although that does not work in AGS anyway, it does not draw anything instead).

The second case - this is the one that causes blending with pink now. But what is the expected behavior for this one?
What is absolutely true - the result cannot be translucent on its own, because the created surface does not "have" alpha channel (well, technically, it does, but AGS "pretends" it doesn't). It may have 100% transparent parts, though (like with magic pink). But what about blended colors? Should they be just copied over (taking their rgb part) as if it was simply opaque sprite drawing, or blended with the destination surfaces using source alpha, while treating transparent parts on destination as clear color (0,0,0) instead of magic pink?

I think that Calin Leafshade suggested the latter (http://www.adventuregamestudio.co.uk/forums/index.php?issue=424.0). Are there other opinions?
Sorry again, my brain is overworked :-.

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.

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.

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.

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.

Ok, I found the EXACT piece of code that screwes this.

This is how an object's baseline is fixed for D3D9:

Code: cpp

        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 .

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.

It is not listed in the documentation what the default of SetAudioTypeVolume is; is it 100? This is relevant for initializing the corresponding GUI sliders properly.

Afaik the default is the volume that you set yourself in the audio category properties. Select "Audio->Music" folder, and you'll see "DefaultVolume" property in the props table.
Also every single file has its own DefaultVolume. By default it inherits one from the folder (-1).
I don't know how to get that one in game though.

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...

Sleepy Hollow

Correct.

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.