[Plagman]

I really haven't been doing a good job of keeping track of all the issues people report. Right now they're spread out across a zillion threads of this forum and I have no hope of finding them all, which is a shame, especially if you went through the trouble of building a test map I could look at. For a while I tried to push the EDuke32 bug tracker on Sourceforge, but that didn't really catch on since you had to register a separate account, and the interface was a general pain in the ass. That's fine. Can we try putting them all up there?

http://wiki.eduke32....er_Deficiencies

Basically if there's still a problem with Polymer that you know about and that's not listed on this page, can you create a map that makes it easy to reproduce, attach it here (or put it somewhere where it'll stay), and add an entry to the above page with a link to it?

I realize most of you already reported these issues in separate threads, but at least this way it won't be buried...

[Spiker]

Nothing really serious but for me mirrors get black or partially black at certain angles when standing next to the.

Attached thumbnail(s)

• 

Attached File(s)

•  eduke32.log (25.34K)
  Number of downloads: 167

[Fox]

As I posted in the other thread, the shading is different for sprites rendered on the level and displayed on the screen:

Spoiler

As you can see above, the dropped Pipebomb is similar to the weapon in 8-bit mode, while in polymost it is completely different.

Since it lists issues with the skybox, one problem I am contantly facing is that Polymer still renders the paralaxed sky texture even if you replaced / removed it with CON at some point.

Spoiler

Polymost



Polymer

[Micky C]

I'm not sure if it was ever fixed or not (it wasn't fixed soon after I reported it anyway), but don't forget the issue where shadows cast from spot lights by sprites have a messed up angle (its as though they are wall alligned sprites facing the same direction as the spotlight, so when the sprite is to the side of the spotlight the shadow is almost a straight line due to the angle being so thin).

Also last I checked sprites/models don't cast shadows when they're positioned behind spot lights.

Edit: And lets not forget the draw distance It's so obvious it's easy to forget sometimes.

[Fox]

There is the infamous bug of translucent sprites making holes in sprites behind it.

Spoiler

[The Commander]

*ATI cards cast no shadows with any spotlights.

Not that I can test this any more since last week.

[Hank]

Cody, on 03 March 2013 - 08:37 AM, said:

*ATI cards cast no shadows with any spotlights.

Not that I can test this any more since last week.

well, I can confirm this.
Should anyone actually have the time and resources to address this, I could test it.

[Fox]

Texture doesn't overwrite tint for models:

Spoiler

In the image above, the model has the exact same texture and palette of the wall behind. However the model still displays the tint on top of the palette specific texture.

[Hendricks266]

^ It's always been like that, even in Polymost.

[Fox]

Which is a bug, right?

[Hendricks266]

Yes. The intended purpose of alt-pals is not to blend them with tints.

[Plagman]

You're saying if you define a skin for a model/texture for pal N, and have a tint for the same pal, it uses that skin and applies the tint on top of it? Both in Polymost and Polymer? Since forever? Was that also the case in JfDuke?

[Fox]

Sort of. I remember that waa~ay back then I pointed out that the HRP model for the Expander Crystal had pal 2 tint applied on it. I think it was fixed, at least for screen models.

[Mark]

I'm not sure if I should post it here or not because it involves the use of a con mod running under Polymer. Maybe the mod exposes a Polymer problem. I'm not sure. Its the Darkus flashlight mod. It was mentioned before about the huge FPS hit and stuttering when enabling the mod. It doesn't matter if its SE 50 light with or without shadow casting, or if you use an SE49 light. Even if the flashlight is turned off with a key press the problem is still present. I spent many many hours tweaking and testing in my Graveyard map. For some reason stairs and slopes are a big FPS hit and are one cause of the stuttering. In some instances with slopes, they can be a few small floor sectors of debris by a broken wall. Or just a broken slab of sidewalk. If I remove the slope of those small sectors there is a slight increase in FPS. If I remove them totally, in many cases the FPS jumps even higher. The included pic shows the player on the top stair. FPS is 15. Inch forward one step to be off the stairs and FPS jumps back up to 60. This happens on most stairs in the map. And the weirdest part is that I have one set of stairs that does not have any problems and it's built identical to the one a little ways away with the problem.

Another source of stuttering occasionally is when crossing the border between 2 ordinary flat surfaces with nothing special about them. They were split apart for texturing reasons. Just as you cross from one to the other FPS can drop for an instant from 60 down to 20 and then right back up to 60.

Attached thumbnail(s)

• 

[Helixhorned]

Mark., on 31 March 2013 - 06:17 AM, said:

Even if the flashlight is turned off with a key press the problem is still present.

Then the cause of this bug should be investigated first. I presume that the flashlight mod is rather small? Then it should be easy to reduce the test case. Can you provide a link to the mod?

[Mark]

here it is I'm using the version where an SE50 with a pal of 10 is placed in the map.
My link

[Helixhorned]

Oh, I remember that one. Re-reading it, it seems odd that the update is done from EVENT_GAME which runs for every sprite (not actors only) in the map. Does it get better if it's done from something per-player like EVENT_PROCESSINPUT?

[Mark]

That is beyond my knowledge. I copy and pasted the code into a blank EDUKE.CON file and adjusted light settings.

[Helixhorned]

Simply replace "onevent EVENT_GAME" by "onevent EVENT_PROCESSINPUT" in the CON file.

[Mark]

I'll give it a try. I glanced at the wiki and thought it also required some getinput commands which is why I thought it was beyond my skills.

EDIT: WOO HOO Come here big boy. I want to give you a big wet kiss. All glitches seem fixed. Why didn't this happen months ago.

[Plagman]

BTW, it wasn't posted here but I just fixed the issue where ART offsets wouldn't apply correctly to flipped sprites, in case that's helpful to anyone. I fixed it separately in Polymost and Polymer.

[Gambini]

Yeeeha!

[Hendricks266]

I wonder how this affects the hanging slime babe and the hackish "yoffset" def parameter I added to fix it.

[NightFright]

While checking out some mods, I have noticed that there seems to be an issue with rendering sprites used as platforms, bridges, "gap covering" material or the like. I dunno if this is an issue with OpenGL rendering in general or just Polymer, since I am not using Polymost at all.

I can provide an example screenshot later, but right now I can name the beginning of the last (fifth) map of the original WGRealms. There are two green, square-shaped columns/pillars to the left and right of the central pyramid (pretty much right after you open the first door and step outside - just walk straight), with sockets at the bottom and on top. The top sides are realized with sprites, and if you look at it from below, you wouldn't see anything but the skybox. This is a bigger issue with bridges since sometimes, you don't even see that you can get on top of them (or that there even is one). The upper side is always rendered properly.

[Helixhorned]

Yup, that was my fault.

[NightFright]

It's probably known already, but I have noticed that Polymer seems to have issues with rendering some sorts of parallaxed skies. E.g. at the end of E2L2 "Himalayan Hell" in "The Gate", there is a portal which should have a star sky texture inside (see Mapster32 screenshot below). This renders incorrectly in Polymer.

There are more examples, but I guess they are all related to this. Another example is E3L2 "Martian Red Light District" of the same map pack (palm reader pedestal, see below). Any way to solve it, or is it a map-specific problem?


*UPDATE June 29, 2013*

Found some more problems:
- First one can be checked in ROCH 4, outside area where you can reach the manor. Seems there are issues with drawing "railing" sprites.
- Second one is more severe, and it might affect a lot of custom maps. In MaTH Pak, check the outside area of the "Factory" (second map, MATH_02). Note the considerable texture misalignments all over the place. For some weird reason, the game also won't render the custom skybox and use the star sky instead. Software rendering works fine. Check the comparison screenshots.