Duke4.net Forums: Polymost makes flat sprites act weird (pics) - Duke4.net Forums

Jump to content

Hide message Show message
Welcome to the Duke4.net Forums!

Register an account now to get access to all board features. After you've registered and logged in, you'll be able to create topics, post replies, send and receive private messages, disable the viewing of ads and more!

  • 2 Pages +
  • 1
  • 2
  • You cannot start a new topic
  • You cannot reply to this topic

Polymost makes flat sprites act weird (pics)

User is offline   pacman 

  • 4

#1

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:

Posted Image

Polymer:

Posted Image

Classic:

Posted Image

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.

This post has been edited by pacman: 10 May 2016 - 05:57 AM

0

User is offline   deuxsonic 

  • 274

#2

I can confirm this.

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

User is offline   Daedolon 

  • Ancient Blood God
  • 833

#3

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

Lunick: I can't believe you can pre-order Duke Nukem 3D in 2016
1

User is offline   TerminX 

  • el fundador
  • 4,668

  #4

View PostDaedolon, 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! ;)

EDuke32 ? wiki ? svn builds ? bugs
Join us in #eduke32 on irc.freenode.net!
4

User is offline   Mark. 

  • Honored Donor
  • 1,696

#5

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

User is offline   pacman 

  • 4

#6

View PostMark., 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
0

User is offline   TerminX 

  • el fundador
  • 4,668

  #7

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.

EDuke32 ? wiki ? svn builds ? bugs
Join us in #eduke32 on irc.freenode.net!
1

User is offline   deuxsonic 

  • 274

#8

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

User is offline   ToiletDuck64 

  • 73

#9

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?

This post has been edited by ToiletDuck64: 10 May 2016 - 11:06 PM

0

User is offline   pacman 

  • 4

#10

View PostTerminX, 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
0

User is offline   pacman 

  • 4

#11

View PostToiletDuck64, 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:

Posted Image



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

User is offline   Daedolon 

  • Ancient Blood God
  • 833

#12

View Postpacman, 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.

Lunick: I can't believe you can pre-order Duke Nukem 3D in 2016
0

User is offline   pacman 

  • 4

#13

View PostDaedolon, 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:

Posted Image

This post has been edited by pacman: 11 May 2016 - 10:01 AM

0

User is offline   deuxsonic 

  • 274

#14

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

User is offline   pacman 

  • 4

#15

so when this will get fixed?
0

User is online   Mike Norvak 

  • Music Producer
  • 541

#16

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

User is offline   pacman 

  • 4

#17

View PostMike 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
0

User is offline   LeoD 

  • 473

#18

View Postpacman, 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.

Polymost HRP / Z-Pack: customize your HRP | User Map Maphacks
"Redneck Rampage has chickens. If you put a chicken in Duke3D then it's Duke3D with a chicken."
0

User is offline   pacman 

  • 4

#19

View PostLeoD, 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:

Posted Image

win64:

Posted Image


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:

Posted Image

win64:

Posted Image

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

#20

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

User is online   Trooper Dan 

  • Duke Plus Developer
  • 1,940

#21

View Postfilipetolhuizen, 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).
0

User is offline   TerminX 

  • el fundador
  • 4,668

  #22

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

EDuke32 ? wiki ? svn builds ? bugs
Join us in #eduke32 on irc.freenode.net!
1

#23

View PostTrooper 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.
1

User is offline   VinsaneOne 

  • 142

#24

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

View PostTerminX, 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.
Attached Image: capt0000.png
Attached Image: capt0001.png
This issue also reveals secret areas hidden behind walls. Not good. Shows up in game as well as Mapster.
0

User is offline   VinsaneOne 

  • 142

#25

View PostVinsaneOne, 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.
Attachment capt0000.png
Attachment 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.
0

User is online   Trooper Dan 

  • Duke Plus Developer
  • 1,940

#26

Posted Image

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

User is offline   Mblackwell 

  • Evil Overlord
  • 755

#27

Is it the same in polymost?

Music: The Rejected Applications (listen now)
EDuke32 || EDuke32 Wiki || Latest EDuke32 Snapshots
I'm getting too old for this shit...
0

User is online   Trooper Dan 

  • Duke Plus Developer
  • 1,940

#28

View PostMblackwell, 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.
0

User is offline   LeoD 

  • 473

#29

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

Polymost HRP / Z-Pack: customize your HRP | User Map Maphacks
"Redneck Rampage has chickens. If you put a chicken in Duke3D then it's Duke3D with a chicken."
0

User is offline   VinsaneOne 

  • 142

#30

View PostMblackwell, on 14 July 2016 - 02:49 PM, said:

Is it the same in polymost?



View PostTrooper 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...
0

Share this topic:


  • 2 Pages +
  • 1
  • 2
  • You cannot start a new topic
  • You cannot reply to this topic


All copyrights and trademarks are property of their respective owners and all comments are owned by their posters. Yes, our forum uses cookies. © 2004-2017 Duke4.net and Voidpoint, LLC

Enter your sign in name and password


Sign in options