[PsychoGoatee]

Noticed the first switch you encounter in the first level of episode 2 flickers/disappears. Sometimes it's not visible, but as you adjust your view it flickers and is semi-visible sometimes. This only happens in Polymost mode, it displays fine in classic. Not sure about Polymer in 5312, since that crashes in the recent ones. But it does show fine in Polymer in version 5267 where Polymer works for me, but it still flickers in Polymost mode there too. Also flickers in Polymost mode in 5149, those are all the ones I've tried.

Tried it with different resolutions and settings etc, with and without and HRP in the folder, etc.

Nvidia 560ti card and whatnot, I posted my gl info log thingy and whatnot in the other topic made recently.

Here's a pic of the flickering switch thingy.

Attached thumbnail(s)

• 

[Zaxtor]

Usually does what when you overlap a sprite.
never seen that on a nonsprite wall.

In your case dunno what causes that.
Try to move the switch 1-2 pixels away from wall and see if it still does it.

[PsychoGoatee]

Zaxtor, on 30 July 2015 - 11:07 PM, said:

Usually does what when you overlap a sprite.never seen that on a nonsprite wall.In your case dunno what causes that.Try to move the switch 1-2 pixels away from wall and see if it still does it.

I'm not a mapper, that's from the Spaceport map in Duke3D. For what it's worth, it displays well in Megaton, I'm not sure what the difference in renderers are between eduke32 and that one.

[Zaxtor]

I ran on Polymost.F (w/e is called) and didn't cause any issues.
Even in Polymer.

Runs clean.

Maybe can be your video card or can be your EDuke32 version.

You use 32 or 64 bit?

I use 64 bit

[PsychoGoatee]

Windows7 64bit, yep I use the 64 bit versions of eduke32. I tried the latest version and a couple other versions.

[Zaxtor]

I see

I use W7 Home premium (legal version).
64 bit.

Maybe can be your video card.

[Mark]

In Mapster if you look at sprites placed on walls and zoom in all the way they are usually a fraction of a smallest grid square away from the wall. In this case the sprite looks to be EXACTLY on the wall which does cause flickering sometimes. It flickers for me too. I never noticed it before because I always play the game with the HRP and models enabled. I had to disable models to see the problem.

[filipetolhuizen]

I also see this happening here. Geforce 460gtx, latest drivers, Win7 32 bits.

[The Mechanic]

I've had the very same issue. Using the S2E1 switch, rendermode 0 shows switch perfectly, rendermode 3 shows the issue. As for rendermode 4 I'm never entirely sure what the hell is going on but switch does render correctly again.

Anyhow, when the switch is misbehaving, certain duke-to-switch angles reveal that either left or right portions of switch is visible, suggesting the sprite/wall angle is relevant and indeed elsewhere in the level where switches are NOT on angled walls I do not see the problem. Some kinda rounding error in angle calcs ? Whatever, as has been said, best to move sprites away from walls - moving S2E1's switch the smallest distance possible from the wall is, on my machine, enough to completely cure the problem. I suspect this only needs doing on angled walls ?

TTFN,
Jon

[Hendricks266]

The problem is with Polymost. You should not need to modify your maps to work around it.

[Daedolon]

Kind of looks like the sprite is pitched.

[The Mechanic]

Hendricks266, on 05 October 2015 - 02:39 AM, said:

The problem is with Polymost. You should not need to modify your maps to work around it.

If someone tries to use Polymer but their machine can't run it, doesn't Eduke (or just some versions?) drop back to using polymost automatically ?

TTFN,
Jon

[PsychoGoatee]

Hendricks266, on 05 October 2015 - 02:39 AM, said:

The problem is with Polymost. You should not need to modify your maps to work around it.

Doesn't Megaton use Polymost? It looks fine in Megaton.

[Hendricks266]

PsychoGoatee, on 05 October 2015 - 07:36 AM, said:

Doesn't Megaton use Polymost? It looks fine in Megaton.

As an exercise, you should think about the assumptions you're making here.

[PsychoGoatee]

Hendricks266, on 05 October 2015 - 11:22 AM, said:

As an exercise, you should think about the assumptions you're making here.

We're all friends here, could you explain what you mean? I'm just chiming in with a little tidbit of info from mild testing I did. I'm no expert on how these engines work. Keeping whatever info you have to yourself doesn't help anybody.

And for the record, odd to call something with a question mark an assumption isn't it?

I prefer eduke over Megaton for the record, if that keeps my feet out of the fire here. It just is notable that the glitch doesn't happen there, but does here. One of the very few things i can think of where it looks better there.I always play in Polymost because of the better mouselook.

[Mark]

Megaton is based on Jonof's port not Eduke so Polymer, Polymost doesn't enter into things. I could be wrong.

EDIT: It seems I was wrong. Thats what I get for speaking without ever using Megaton.

[Hendricks266]

This isn't personal. The assumption I was referring to is "EDuke32's Polymost is the same as Megaton's Polymost". All I was trying to do is point you in the right direction toward critical thinking that would make your question moot, especially given Megaton's reputation for glitchiness.

I'll quote TX.

Quote

yeah, there are some issues with wall sprites currently
I need to fix it (and it will be fixed before HTTKC is released)
basically the previous method of making them not fight was a GL hack that didn't hold up under GL ES
where it just changed the depth offset when drawing sprites versus drawing walls
so even though they were in the same positions they didn't fight because the data got written into the depth buffer at different locations
but, like I said, that didn't work right on GL ES and also didn't work right on specific GL drivers it seemed
so I started implementing a new method where instead of writing into different depth buffer locations it just moves the sprite away from the wall slightly before even transforming it into GL coords
but my detection of the sprites that need to be moved isn't 100% yet
the reason it happens in the first place is because 2048 different angles isn't enough granularity to represent the possible angles between wall points
it's not an issue for walls that are straight up and down or left to right but for diagonal stuff 2048 isn't enough
so you get cases where one angle has half the sprite technically in null space but the same angle +1 has the other half technically in null space

Trivia: Duke 64 avoids this problem in a similar manner by defining an unused cstat bit to mean "render this sprite moved slightly in the direction it is facing".

[Micky C]

PsychoGoatee, on 05 October 2015 - 07:36 AM, said:

Doesn't Megaton use Polymost? It looks fine in Megaton.

I'm confused Hendricks, isn't the fact that both ports use the same polymost yet the switch looks fine in Megaton a potentially important piece of information?

[The Mechanic]

Thanks for the additional explanation, it makes sense now.

TTFN,
Jon

[Mark]

Personally I don't mind working around the problem by moving the sprite a tiny bit away from the wall to play it safe. I have been doing it out of habit since probably my first map. I used to move it one smallest grid away from the wall. Now I just disable grid lock and drag it a little further away.

[TerminX]

Micky C, on 05 October 2015 - 01:24 PM, said:

I'm confused Hendricks, isn't the fact that both ports use the same polymost yet the switch looks fine in Megaton a potentially important piece of information?

They aren't the same Polymost. I rewrote lots of Polymost in EDuke32 to be based on regular floats instead of double precision floats so that we could run it on Android devices that don't have hardware support for manipulating doubles. This resulted in a huge speedup on PC as well, but there are still some issues like this to iron out.

So, Polymost in other ports uses the same algorithm to turn sectors and walls into polygons but most everything else is different at this point.

[Micky C]

Wow I had no idea that switching from double to single precision would have such a large impact on the framerate.

[LeoD]

TerminX, on 05 October 2015 - 08:07 PM, said:

They aren't the same Polymost. I rewrote lots of Polymost in EDuke32 to be based on regular floats instead of double precision floats so that we could run it on Android devices that don't have hardware support for manipulating doubles. This resulted in a huge speedup on PC as well, but there are still some issues like this to iron out.

Shouldn't these regressions be on top of the to-do list then....

[Helixhorned]

Hendricks266, on 05 October 2015 - 12:51 PM, said:

I'll quote TX.

I can't agree 100% with everything TX said, though I'm happy it's on his list.

Quote

basically the previous method of making them not fight was a GL hack that didn't hold up under GL ES
where it just changed the depth offset when drawing sprites versus drawing walls
so even though they were in the same positions they didn't fight because the data got written into the depth buffer at different locations

I don't think the previous method deserves to be called a hack. It did pretty much everything right: offsetting the per-fragment depth of a flat sprite by a "relative" amount, in the sense that it scales with its distance from the eye.

Quote

but, like I said, that didn't work right on GL ES and also didn't work right on specific GL drivers it seemed
so I started implementing a new method where instead of writing into different depth buffer locations it just moves the sprite away from the wall slightly before even transforming it into GL coords

In other words, offsetting them by absolute amounts. Thus, at a certain distance, a sprite ornamented onto a wall begin to depth-fight with each other. Also, IIRC the offsets are scaled by some sprite id (either the real or drawn one) -- when you have a lot of sprites, you get huge offsets.

Quote

but my detection of the sprites that need to be moved isn't 100% yet
the reason it happens in the first place is because 2048 different angles isn't enough granularity to represent the possible angles between wall points
it's not an issue for walls that are straight up and down or left to right but for diagonal stuff 2048 isn't enough
so you get cases where one angle has half the sprite technically in null space but the same angle +1 has the other half technically in null space

This issue is independent from the method of offsetting, I'd think.

As I said in PM once, I'd strongly favor reinstantiating the old method on the desktop. The new one might still stay as an experimental mode until it can yield demonstrably better results.

[Mblackwell]

So this offset code applies only in Polymost, right?

Would that explain the weird visual glitch I get (only in Polymost) when spawning a bunch of floor decals where they visibly shift around slightly if you spawn them rapidly?

[Danukem]

Just bumping this thread to emphasize that the reported bug can be seen in many maps and should be a high priority.

[TerminX]

Trooper Dan, on 18 October 2015 - 07:16 PM, said:

Just bumping this thread to emphasize that the reported bug can be seen in many maps and should be a high priority.

I understand. I'm working on it again now.

[ToiletDuck64]

I think that, whatever the compatibility fix is, there should be an option for disabling it and rendering them where they theoretically should be rendered, and if there are graphical glitches like this, then so be it.
Even if a lot of people, including 3D Realms in the vanilla maps, did broken stuff in their maps, and the vanilla Build engine let them get away with broken stuff in their maps, that does not make the maps "not broken". These errors are forgivable, but the maps are still broken. (Incidentally, I think the same way about how Mapster detects corruption in several vanilla maps (such as E2L6); I blame the vanilla Build editor for not at least letting people know about things that were broken.)

[TerminX]

I don't think you quite understand. These rendering errors don't occur in the original software renderer, only in the OpenGL renderers written after the fact. It's necessary to fix them in order for the game to look as it originally did.

[Mblackwell]

Yes, this bug is better than the alternative bug where due to a lack of any depth sorting all you'd see everywhere is a bunch of glitchy drawing basically EVERYWHERE in the vanilla game.