[Darkus]

I'll continue my feedback of the new version here, a little reminder:

Quote

Things I noticed (not really problems):

- When you're shrinking/growing, now the point of view gradually move up/down instead of being instantaneous. (you can even use the third person mode)

- The texture filter option and the console command 'r_usetileshades' are gone (maybe temporary?)

Now the problems:

- When you crouch down over a ledge, you fall

- In E1L2, I was bumping invisible walls (probably the upper floor) in the dark corridor near the lift.

- Still in sector over sector effect, you can still collide enemies when they are in the other sector of the one you are.

- When coming out from the underwater with a sector that uses TROR effect, the view stick temporary to the ceiling.

I also found that the monsters are affected:

Walking monsters can't climb up sectors, for example, they can not climb stairs anymore.

example map:


When they encounter a small step, they're blocked, like bumping a regular wall:



Sprite height was also affected, example with a trooper flying down below an arch:
In old versions, the sprite collide the wall until half of the sprite is below of the ceiling:



But now, it's the bottom of the sprite:

[oasiz]

I also ran in to these collision issues in IM where monsters would be blocked like that ... could explain it.

[NightFright]

I can confirm the "invisible wall" in front of the E1L2 elevator, also with r7443. Something really bad happened here. Approaching the elevator frontally won't work, you gotta hug the wall.

[TerminX]

OK, I'll look into that today if I have time.

[LeoD]

LeoD, on 20 March 2019 - 05:51 PM, said:

I don't see the point here. What's the benefit of this intentional regression? Who would want that?

Fox, on 20 March 2019 - 06:37 PM, said:

The intend is to reproduce the results from classic mode.

Phredreeke, on 20 March 2019 - 06:42 PM, said:

I think the idea is that when a map is designed, it should work the same in all maps, not have maps that are "classic only" or "polymer only"

TerminX, on 20 March 2019 - 08:09 PM, said:

Yep, it's so maps look the same in both renderers.

Well, I have to admit that these answers aren't more satisfying than the log message ... has this really any potential to interfere with a mapper's intentions? Can someone point me to example maps/locations or screenshots?

[Phredreeke]

Here's one example of the wrapping bug. For new levels made using Polymost/Polymer you risk the opposite - it looks right in those renderers but wrong in classic.

Since levels already exist built around the wrapping bug the better option is to make Polymost/Polymer match classic.

Edit: A non-Duke example would be the grandfather clock at the start of E3M2 in Blood.

Attached thumbnail(s)

• 

[LeoD]

Phredreeke, on 21 March 2019 - 05:34 PM, said:

Here's one example of the wrapping bug. For new levels made using Polymost/Polymer you risk the opposite - it looks right in those renderers but wrong in classic.

Thanx, man. Now I may go to sleep in peace.

[Danukem]

NightFright, on 21 March 2019 - 06:47 AM, said:

I can confirm the "invisible wall" in front of the E1L2 elevator, also with r7443. Something really bad happened here. Approaching the elevator frontally won't work, you gotta hug the wall.

This seems to be an SOS related issue. The wall you are actually bumping into is on the floor above you that the elevator leads to. It's the wall that has a CANWITHSOMETHING against it. I discovered this by using DNDEBUG and opening the debug map.

But there's a stranger thing. The wall blocking bug exists in versions of mapster long before the bug existed in gameplay. I opened up a normal E1L2 using mapster r7140, and the wall in the upper floor blocks you in 3D mode if you are in the corridor below, just as it now does during gameplay.

[NightFright]

Well, I guess we cheered a bit too early with the Polymost upgrades. ROR in, SOS out.

[Jblade]

just have some patience, they're working on it.

[oasiz]

LeoD, on 21 March 2019 - 04:47 PM, said:

Well, I have to admit that these answers aren't more satisfying than the log message ... has this really any potential to interfere with a mapper's intentions? Can someone point me to example maps/locations or screenshots?

Normally users won't see any immediate change out of this. If more than anything, it just means that mapper's intention will now always be obeyed when previously it could shift annoyingly between renderers. Now mappers can produce maps that work for a larger player base without issues. If you've seen cases where textures shift around between side-by-side comparisons, this is the fix. Nothing else. Classic is the reference renderer and has always been, any change is usually related to imprecise calculations and case by case decision has to be made if something should be left "correct" or changed, i.e. screen warping doesn't need to exist in polymost.

There are many things in Duke that are mathematically "wrong" due to not being real 3D, going mathematically correct will break stuff. When working with 3D, your options are quite often limited to these correct implementations of 3D instead of cycle saving approximations. When you have an engine with 20+ years of content designed for these approximations, you can see breakage some times.

This specific case mostly applies to the hacky relative texture setup that build has in the first place and how it does texture mapping. Math is not 100% and some times the texture mapping doesn't match between renderers on i.e. larger surfaces with sloping.


NF: SOS should still continue to work as usual, there are obviously issues with that, but in IM for example we have multiple maps where this isn't an issue.
It seems to be related to portal traversal as I managed to fix this in one case by removing a visual connecting window between lower/upper part. Although this is just speculation based on experiments.

[Phredreeke]

I guess technically you could make the opposite change for IM since you don't have legacy maps to support. But then you end up having separate versions of Classic and Polymost for IM, which would be undesirable when IM support is to be added to mainline eduke32.

[oasiz]

In a sense, yes, we could do the opposite but that's not really needed. It's not really a handicap, more an annoyance that you only run in to at random. You eyeball texture panning for classic only to find that it doesn't work 1:1 in polymost or the other way around. No need to break compatibility when you just end up eyeballing texture panning regardless.

Oh and IM is already in mainline, it just doesn't load the assets specifically shipped with the preview campaign.
I can just grab eduke or mapster from synthesis builds and drop it to my dev dir otherwise.

There is a compilation flag that does change some minor hardcoded duke things that can't be done at CON level (or would be silly to do) like start up windows, some hardcoded game logic etc..

[Mark]

Trooper Dan, on 21 March 2019 - 11:09 PM, said:

This seems to be an SOS related issue. The wall you are actually bumping into is on the floor above you that the elevator leads to. It's the wall that has a CANWITHSOMETHING against it. I discovered this by using DNDEBUG and opening the debug map.

But there's a stranger thing. The wall blocking bug exists in versions of mapster long before the bug existed in gameplay. I opened up a normal E1L2 using mapster r7140, and the wall in the upper floor blocks you in 3D mode if you are in the corridor below, just as it now does during gameplay.

I noticed the problem in Mapster long ago as far back as 6927. It works fine in game though. It was in my remade version of E1L2 for the HHR project so I never reported it because I assumed it was something I did.

[TerminX]

We're looking into the E1L2 thing now and we've even managed to reproduce it in an original copy of BUILD.EXE in DOSBox. Looks like we've got an authentic original Build Engine bug to fix.

[Mariusz]

Help. I can not launch the Bedrone map.
The last working version of eduke32 is 7395

[Danukem]

TerminX, on 22 March 2019 - 11:26 PM, said:

We're looking into the E1L2 thing now and we've even managed to reproduce it in an original copy of BUILD.EXE in DOSBox. Looks like we've got an authentic original Build Engine bug to fix.

Be careful when you mess with that stuff!

[MusicallyInspired]

Really? In original Build? I don't remember ever running into that (no pun intended).

[NightFright]

Which unholy bug have you unearthed with these Polymost changes? Kill it with extreme prejudice!

[Mark]

It must have been a benign bug because it hasn't been a problem until recently.

[Darkus]

Found another issue in the new version: when underwater, you move slighty faster up and down. This is visible when turning on/off the jetpack underwater while going up/down.

Also, I can't go underwater in E3L3.

[DisgustedGrunt]

Darkus, on 23 March 2019 - 01:04 PM, said:

can't go underwater in E3L3.

neither in E3L1

[Lunick]

Darkus, on 23 March 2019 - 01:04 PM, said:

Found another issue in the new version: when underwater, you move slighty faster up and down. This is visible when turning on/off the jetpack underwater while going up/down.

Also, I can't go underwater in E3L3.

The speed is fixed in r7449, unsure if the other issue is fixed in r7450

[DisgustedGrunt]

Lunick, on 24 March 2019 - 03:31 PM, said:

The speed is fixed in r7449, unsure if the other issue is fixed in r7450

Tried in r7451, can't go underwater in either map

[DisgustedGrunt]

the elevator is not 100% fixed, try going back and forth, you sometimes still get stuck

[DisgustedGrunt]

e3l1 and e3l3 underwater fixed in 7467, also e1l2 elevator completely fixed

[DisgustedGrunt]

a new problem in e3l1

[TerminX]

Thanks for the report!

Edit: should be fixed in r7468

[DisgustedGrunt]

another one, this time in e1l6



also, i noticed eduke is using way too much memory, sometimes over 1gb of ram, and i'm not running any graphical mod. my graphic card is a Intel HD 4400, so maybe that's the cause?

i wasn't running any huge maps or anything, checked before recording and it was using 1,4 gb

EDIT: high memory usage only in polymost

[TerminX]

The problem in the video is fixed in r7470.