ZDoom

ZZYZX wrote:I'm actually talking about whatever coordinate that often gets stored in the shaders as W and means distance from screen plane to the point (it's just that there is no vector4 IIRC and just easier to store it as Z, as Z is unused otherwise).
That's needed so that user code can take the -1..1 coordinates and draw with corresponding virtual screen size to scale their pictures according to the distance to the point.

Yes, but the problem is that the depth is unknown when you only have a Vector2 for the screen position. However, if you multiply the depth value with the vector returned by the unproject function I listed, then you get the vector you are interested in (which is exactly what the SSAO pass does, using the zbuffer to get the depth).

ZZYZX wrote:What does the regular HUD code do in this case? Does it render twice? It's not supposed to work outside of the drawing hooks, so maybe just use whatever matrix that's active in currently drawn half? (this may as well make zero sense because I don't know how VR works really)

It depends a bit on which VR mode, but it renders the HUD on a plane in the 3D world. I suppose the screen coordinate returned by a project function just needs to be relative to this plane. Simpler to solve than I expected, actually.

dpJudas wrote:Yes, but the problem is that the depth is unknown when you only have a Vector2 for the screen position. However, if you multiply the depth value with the vector returned by the unproject function I listed, then you get the vector you are interested in (which is exactly what the SSAO pass does, using the zbuffer to get the depth).

I was talking about project, where you give it X/Y/Z and it returns you screen X/Y + depth. That doesn't sound like impossible, I had this written in ACS.
Unproject can simply return count of angles for X and Y coordinates respectively. I think. So that the user can use those values to calculate vectors, coordinates, and everything. Although, given camera pitch and the software renderer...

Okay, I misunderstood what you wrote then. Thought you meant getting a Z value for the unproject.

dpJudas wrote:

ZZYZX wrote:I think this should be native and based on the active renderer, in Screen or StatusBar class. Probably sbar, since active statusbar affects viewport size.
Also, it probably should return a vector3 with -1..1 coordinates where 0 is the center of the screen, and Z coordinate would be the distance from the screen plane.

Assuming you're talking about eye/view space, the Z coordinate would always be 1. Getting from there to world space would mean multiplying with the inverse of the world to eye normal matrix (just doing the inverse rotate from Viewpoint is probably easier). To get the point the user clicked at requires a follow up ray shooting.

The code required to do the unproject and project looks like this (in pseudo C++):
(snip)

I'm interested in using this in ZScript, specifically ProjectViewToScreen so I can draw an icon on the player's HUD indicating where an object is in the world. I've translated this sample code into ZScript - faithfully, I'm pretty sure - but the numbers it gives back aren't quite right, which makes sense given that this doesn't seem to account for the player's position and orientation relative to the 3D point given. Is the "viewPos" argument in world space? How is it determined?

Yes, the ViewPos is in world space. It is the coordinates for the player's view screen. Bear in mind that ViewPos is also used for interpolating the camera's movement and keeping things sleek whenever the player moves, and subsequently why attached effects are ahead of the player -- or more specifically the player camera appears to lag behind.

Also used by quakes.

Anyway, already suggested, already on hold.

This is from Major Cooke in Discord. Putting it here so it won't get lost.

Major Cooke wrote: By the way, whoever wants cylindrical hitbox detection, ZScript allows it.
It was easier than I thought.

Code: Select all

override bool CanCollideWith(Actor other, bool passive)
{
    if (!passive)
    {
        if (!other)    return false;
        return (Distance2D(other) <= other.radius);
    }
    return true;
}
 

That only works for actor-to-actor collision. You still can't clip walls that way.

Do you think you are the first guy to implement it?
It won't work due to the "player is stuck and tries to run out" handling. When the engine detects that you are in a (square) hitbox of an actor, and that actor is supposed to be blocking, and you run at certain angle, that makes you noclip.

I think this ought to be included in a standard library, if not in GZDoom itself. It's a variant of the RandomSpawner.

In addition to what ZZYZX said there's also a bunch of other caveats. Bouncing is basically told to get shrekt so you'll have to manually do something about that. Assuming you have things like +BOUNCEONACTORS flags and stuff set up... No, Bounce.Actor won't help you. I tried. It just randomly assplodes at certain angles when it hits.

So this is kinda my solution to the whole situation of exploding when it's not supposed to.

Gez wrote:I think this ought to be included in a standard library, if not in GZDoom itself. It's a variant of the RandomSpawner.

Oooh, that's actually nice. I agree. But I dunno if Xaser's still planning on doing this thing or not.

We should just do a special forum library. Everyone makes a thread and contributes their code - in

Sounds great to me! And we can get feedback from anyone without them trying to edit it like it's a wiki page.

I'll take care of it later on when I get back to my computer then. If I forget please feature request it.