[pacman]

The sprites flicker and appear and disappear when I move the mouse, I think it's the sprites that are flat and are really close to the walls or other sprites. I have seen this happening in sprites tipically used near walls like posters, signs (like the one in here that says "Shop-n-Bag" but this sprite is apparently not close enough to the wall to create the glitch) and so on.

Polymost:



Polymer:



Classic:



Unfortunately Polymost is the one that is smooth enough and I don't like the other 2, but Polymost has this sprites glitch and is too distracting when this happens. Please fix.

[deuxsonic]

I can confirm this.

Also, surfaces that should be hidden seem to pop through as you move around. May be related.

[Daedolon]

The z-fighting issue in Polymost (also happens in Polymer but in different conditions) has been a major problem with EDuke32 for years now :/

[TerminX]

Daedolon, on 10 May 2016 - 11:45 AM, said:

The z-fighting issue in Polymost (also happens in Polymer but in different conditions) has been a major problem with EDuke32 for years now :/

I have yet another attempt to fix it staged in my tree currently. Stay tuned for all the things that will be broken in new, fun ways!

[Mark]

I know its of no help to original or older maps, but going forward it would be nice to modify Mapster to ever so slightly increase the distance of sprites placed on a wall. I do it manually and problem solved.

[pacman]

Mark., on 10 May 2016 - 03:07 PM, said:

I know its of no help to original or older maps, but going forward it would be nice to modify Mapster to ever so slightly increase the distance of sprites placed on a wall. I do it manually and problem solved.

But sometimes you want that extra precise as-close-to-wall posible sprite, for example cracks on walls, they have to be as near to the wall as possible otherwise it may look odd

[TerminX]

Yeah, and if you move it one unit away from the wall it won't look any different to the player and also won't z-fight with the wall.

[deuxsonic]

I would sacrifice performance for the option to double the precision...

[ToiletDuck64]

That Polymost screenshot doesn't look like a Z-fighting problem; there doesn't seem to be anything for the windows to Z-fight with.

Incidentally, I think that a lot of wall sprite Z-fighting issues result from faults in the original placement of the sprite, not the way it's being rendered; if I'm not mistaken, in classic rendering mode, sprites automatically "win" Z-fights against walls as long as the sprite's sector number is the same as the number of the sector in front of the wall.
Can non-classic renderers be made to give sprites "bonus points" (treat sprites as closer in Z-comparisons during rendering) just for being sprites, without changing the position the sprites are rendered at?

[pacman]

TerminX, on 10 May 2016 - 06:34 PM, said:

Yeah, and if you move it one unit away from the wall it won't look any different to the player and also won't z-fight with the wall.

Yeah have fun moving sprites from thousands of maps lol

[pacman]

ToiletDuck64, on 10 May 2016 - 11:05 PM, said:

That Polymost screenshot doesn't look like a Z-fighting problem; there doesn't seem to be anything for the windows to Z-fight with.

Incidentally, I think that a lot of wall sprite Z-fighting issues result from faults in the original placement of the sprite, not the way it's being rendered; if I'm not mistaken, in classic rendering mode, sprites automatically "win" Z-fights against walls as long as the sprite's sector number is the same as the number of the sector in front of the wall.
Can non-classic renderers be made to give sprites "bonus points" (treat sprites as closer in Z-comparisons during rendering) just for being sprites, without changing the position the sprites are rendered at?

Yeah, not only it happens with sprites near to walls, it happens here too:





so "just move the sprites away from walls" doesn't apply there

[Daedolon]

pacman, on 11 May 2016 - 03:58 AM, said:

Yeah have fun moving sprites from thousands of maps lol

It has been an issue with usermaps ever since 1996. For some reason the DOS version of BUILD/DUKE3D allows you to place sprites on walls towards south and east, causing the issue. The proper way to do this is to manually either move the sprites one or so build-units away from the wall with the grid locking off, or in 3D mode aiming at the sprite and pressing O to push it close to the wall.

[pacman]

Daedolon, on 11 May 2016 - 04:38 AM, said:

It has been an issue with usermaps ever since 1996. For some reason the DOS version of BUILD/DUKE3D allows you to place sprites on walls towards south and east, causing the issue. The proper way to do this is to manually either move the sprites one or so build-units away from the wall with the grid locking off, or in 3D mode aiming at the sprite and pressing O to push it close to the wall.

But this is not realistic. I want to play some maps with friends in coop, and I cant be like "brb, moving a ton of sprites from the agp.grp maps"
It's a waste of time, I just want to play when I get some free time after working, not spending it moving sprites, I mean it's insane.

And again, the other pic I posted shows the glitch on a regular window which has no walls behind it. Another example:

[deuxsonic]

Yeah I can get the z-fighting that looks similar to this to happen on Polymer where a sprite fights a wall, but transparent surfaces appear okay using it (for now anyway.)

[pacman]

so when this will get fixed?

[Mike Norvak]

I believe this only happens with 32bit builds...

[pacman]

Mike Norvak, on 15 May 2016 - 11:14 PM, said:

I believe this only happens with 32bit builds...

does a 64 build exist? i can only find eduke32

[LeoD]

pacman, on 16 May 2016 - 06:43 AM, said:

does a 64 build exist? i can only find eduke32

EDuke32 is only the name of the project nowadays. Look for _win64_ in the downloadable file names.

[pacman]

LeoD, on 16 May 2016 - 07:29 AM, said:

EDuke32 is only the name of the project nowadays. Look for _win64_ in the downloadable file names.

Im using the latest win64 build and I can confirm all the annoying graphic glitches seem to be gone. The fps are like 20-30 fps lower tho..

win32:



win64:




on this area when facing those windows, on both I get a big fps slowdown but notice win32 is 99fps and win64 78fps, but finally the annoying glitch is fixed in win64

same on this area, fps are higher in win32, but notice the sprite on the wall appears in win64:

win32:



win64:



I guess lossing 20-30 fps on average is worth not seeing every window and sprite next to walls flickering and stuff, it was giving me an headache.
It would be cool if win64 could find out why it's lossing those fps tho, I can notice the difference in smoothness.

[filipetolhuizen]

I'm having this issue as well. Quite annoying sometimes.

[Danukem]

filipetolhuizen, on 19 June 2016 - 08:27 PM, said:

I'm having this issue as well. Quite annoying sometimes.

The post right before yours said it was fixed, so, some of us are wondering whether you are using a recent enough version (r5775 is the latest as of now).

[TerminX]

Trooper Dan, on 20 June 2016 - 07:48 PM, said:

The post right before yours said it was fixed, so, some of us are wondering whether you are using a recent enough version (r5775 is the latest as of now).

Thanks, this comment inadvertently led me to discover that synthesis was broken. 5804 is building now and contains a fix that pertains to the issue discussed in this thread. It should address the fps hit reported by pacman.

Edit: OK, it's done.

[filipetolhuizen]

Trooper Dan, on 20 June 2016 - 07:48 PM, said:

The post right before yours said it was fixed, so, some of us are wondering whether you are using a recent enough version (r5775 is the latest as of now).

The issue I'm having is the visual issue on win32 builds, not the fps one on win64 builds.

[VinsaneOne]

Mike Norvak, on 15 May 2016 - 11:14 PM, said:

I believe this only happens with 32bit builds...

This 32bit r4593 didn't have that problem afaik. Been using that up to now because it's issue free. But then....

TerminX, on 20 June 2016 - 08:19 PM, said:

Thanks, this comment inadvertently led me to discover that synthesis was broken. 5804 is building now and contains a fix that pertains to the issue discussed in this thread. It should address the fps hit reported by pacman.Edit: OK, it's done.

...I thought I'd check out the most recent build r5805 (32bit) and this issue that I've never had before will ruin the map I've been working on and off for the past 4 yrs.


This issue also reveals secret areas hidden behind walls. Not good. Shows up in game as well as Mapster.

[VinsaneOne]

VinsaneOne, on 08 July 2016 - 11:00 PM, said:

This 32bit r4593 didn't have that problem afaik. Been using that up to now because it's issue free. But then....



...I thought I'd check out the most recent build r5805 (32bit) and this issue that I've never had before will ruin the map I've been working on and off for the past 4 yrs.
capt0000.png
capt0001.png
This issue also reveals secret areas hidden behind walls. Not good. Shows up in game as well as Mapster.

Has anyone come up with a fix or some kind of workaround?

BTW, the pic above is not one of the hidden areas, though I did mention that just below it!
Obviously, I wouldn't want to show them here since I intend to release it if and when I finish the damn thing.

[Danukem]

So this is still a thing. Shot taken in Polymer using the latest (July 4th) 64 bit build. The reason we keep belaboring it is that it didn't used to be a thing. It affects not only lots of maps but also some features. For example, mods such as DukePlus that put bullet and other decals on surfaces. Currently I'm in the process of changing my code so that decals are placed a little bit away from the surface so they don't glitch.

[Mblackwell]

Is it the same in polymost?

[Danukem]

Mblackwell, on 14 July 2016 - 02:49 PM, said:

Is it the same in polymost?

No, it is not. I just went through the same area of tthe map (Project Zero) using polymost, and everything rendered flawlessly. In Polymer it was happening a lot.

[LeoD]

Trooper Dan, on 14 July 2016 - 11:40 AM, said:

So this is still a thing. Shot taken in Polymer using the latest (July 4th) 64 bit build. The reason we keep belaboring it is that it didn't used to be a thing.

It seems to me that it happens way less often in older maps. I know they're usually less decorated, but still... Maybe some Mapster32 change contributes to this. And, IIRC, this issue does not show up on Intel HD (3000/4000?) graphics hardware for whatever reason. I don't have access to that Laptop right now, but someone else might want to check this.

[VinsaneOne]

Mblackwell, on 14 July 2016 - 02:49 PM, said:

Is it the same in polymost?

Trooper Dan, on 15 July 2016 - 12:08 AM, said:

No, it is not. I just went through the same area of tthe map (Project Zero) using polymost, and everything rendered flawlessly. In Polymer it was happening a lot.

Some of us see it happen in Polymost. Hence OP/thread title. Guess it varies per user configuration, hardware, drivers, etc...