ZDoom

by **Rachael** » Thu Jul 22, 2021 6:56 am

Enjay wrote: (Nice demo map BTW.)

Thank you.

Enjay wrote:if that was doable, then that would certainly be a better setup than what I suggested.

It's doable - the question is will anyone have enough time to invest into it. Or whether to consider if it's too hacky of a solution or not. Most of the time hacks like this introduce more problems than they solve - so I don't really know if this is a viable option or not.

by **Enjay** » Thu Jul 22, 2021 6:45 am

Rachael wrote:Then you have the "player blinking in and out of existence when crossing a portal" issue.

That was why I thought it would only be a conscious opt-in setting that the player would be aware of the consequences of. The more I think about it, the hackier it sounds though.

Rachael wrote:It might work if the player is only invisible to themselves, and not to others, for one frame after crossing a portal line, though.

If that was doable, then that would certainly be a better setup than what I suggested.

(Nice demo map BTW.)

by **Rachael** » Thu Jul 22, 2021 6:20 am

Enjay wrote:Would it be something worthwhile to code "if player is crossing a portal line/horizon, GZDoom will hide the sprite for [x]-tics"? Or is that something not worthwhile/not possible (like, perhaps, by the time GZDoom knows the player is crossing the portal, it's too late to make them invisible)?

I'm merely envisaging it as a performance option that people affected by the issue could enable. It would mean third party observers (multiplayer) seeing the player blink out of existence briefly, but that might be preferable to a player always seeing their own sprite as they cross a portal.

Or maybe that's not a valuable effort versus return coding effort?

I have seen the effect myself, but that was a long time ago in a particular setup and it was either addressed or my map changed to a point where it no longer happens.

Then you have the "player blinking in and out of existence when crossing a portal" issue. It might work if the player is only invisible to themselves, and not to others, for one frame after crossing a portal line, though.

by **Rachael** » Thu Jul 22, 2021 6:19 am

I made a quick example map that shows both a mirror and a portal loop where the player can see themself. (As an added bonus you can walk through the portal loop into ... the same dimension!)

by **Enjay** » Thu Jul 22, 2021 6:18 am

Would it be something worthwhile to code "if player is crossing a portal line/horizon, GZDoom will hide the sprite for [x]-tics"? Or is that something not worthwhile/not possible (like, perhaps, by the time GZDoom knows the player is crossing the portal, it's too late to make them invisible)?

I'm merely envisaging it as a performance option that people affected by the issue could enable. It would mean third party observers (multiplayer) seeing the player blink out of existence briefly, but that might be preferable to a player always seeing their own sprite as they cross a portal.

Or maybe that's not a valuable effort versus return coding effort?

I have seen the effect myself, but that was a long time ago in a particular setup and it was either addressed or my map changed to a point where it no longer happens.

by **Rachael** » Thu Jul 22, 2021 5:21 am

As far as I know, no, no option exists for that, but it probably wouldn't be too hard to make that a skin. Normally the player sprite *is* invisible but only in first-person mode. However, in order for portals to work properly, you must allow the possibility that if there is a portal "loop" that the player can indeed see themself. This is also true if the player encounters a mirror - as this is simply a portal that draws the existing scene in reverse.

by **ritaremton** » Wed Jul 21, 2021 9:10 pm

apologies. my bro changed the graphics settings of my lappie, without informing me, from [performance] to [quality] which resulted in the visual glitch. so both [gzdoom 4.5.0] and [gzdoom 4.6.0] would now produce the same visual glitch.

is there a command that could make the player sprite invisible but keep displaying the on-screen guns and hands? since the glitch (apart from low fps) is caused by player sprite not in sync with player position, i could make the player sprite invisible before passing through a portal, and make the player sprite visible back again after passing through the portal. since we usually use 1st person perspective and not 3rd person, this should not pose a problem. this should permanently solve all the visual glitches involving player sprite when using portals, even in very low fps.

- rita

by **Rachael** » Tue Jul 20, 2021 8:51 pm

That is not something that can be helped, especially since your frame rate is so low. With low frame it is a common problem with portals especially seeing your player sprite as you pass through them.

by **ritaremton** » Tue Jul 20, 2021 8:14 pm

hi. i may have found a visual glitch when using [gzdoom 4.6.0] with a wad containing [stacked sectors]. this glitch is absent in [gzdoom 4.5.0].

my machine specs:
processor: intel core i7-3740qm 2.70ghz
ram: 32gb
display adapter: intel hd graphics 4000
os: windows 8.1 64-bit
gzdoom 4.6.0: no mods.

tq.
- rita

ZDoom

stacked sectors visual glitch in gzdoom 4.6.0

Post a reply

Expand view Topic review: stacked sectors visual glitch in gzdoom 4.6.0

Re: stacked sectors visual glitch in gzdoom 4.6.0

Re: stacked sectors visual glitch in gzdoom 4.6.0

Re: stacked sectors visual glitch in gzdoom 4.6.0

Re: stacked sectors visual glitch in gzdoom 4.6.0

Re: stacked sectors visual glitch in gzdoom 4.6.0

Re: stacked sectors visual glitch in gzdoom 4.6.0

Re: stacked sectors visual glitch in gzdoom 4.6.0

Re: stacked sectors visual glitch in gzdoom 4.6.0

stacked sectors visual glitch in gzdoom 4.6.0