Duke4.net Forums: EDuke32 2.0 and Polymer! - 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!

  • 207 Pages +
  • « First
  • 200
  • 201
  • 202
  • 203
  • 204
  • Last »
  • You cannot start a new topic
  • You cannot reply to this topic

EDuke32 2.0 and Polymer!  "talk about the wonders of EDuke32 and the new renderer"

User is offline   Darkus 

#6031

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:
https://i.postimg.cc/FHZZY6cq/monstblock1.png

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

https://i.postimg.cc/XY3L7WZd/monstblock2.png

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:

https://i.postimg.cc/1RkM2wsW/monstceil1.png

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

https://i.postimg.cc/TYnQ61PT/monstceil2.png
2

User is offline   oasiz 

  • Dr. Effector

#6032

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

User is online   NightFright 

  • The Truth is in here

#6033

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 post has been edited by NightFright: 21 March 2019 - 06:50 AM

1

User is offline   TerminX 

  • el fundador

  #6034

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

User is offline   LeoD 

#6035

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


View PostFox, on 20 March 2019 - 06:37 PM, said:

The intend is to reproduce the results from classic mode.

View PostPhredreeke, 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"

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

User is online   Phredreeke 

#6036

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)

  • Attached Image: duke0395.png


This post has been edited by Phredreeke: 21 March 2019 - 05:53 PM

2

User is offline   LeoD 

#6037

View PostPhredreeke, 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. :dukeaffirmative:
0

User is offline   Trooper Dan 

  • Duke Plus Developer

#6038

View PostNightFright, 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.
1

User is online   NightFright 

  • The Truth is in here

#6039

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

User is offline   Jblade 

#6040

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

User is offline   oasiz 

  • Dr. Effector

#6041

View PostLeoD, 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.
3

User is online   Phredreeke 

#6042

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.

This post has been edited by Phredreeke: 22 March 2019 - 03:41 AM

0

User is offline   oasiz 

  • Dr. Effector

#6043

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

User is offline   Mark 

  • Honored Donor

#6044

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

This post has been edited by Mark: 22 March 2019 - 08:14 AM

0

User is offline   TerminX 

  • el fundador

  #6045

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. ;)
6

User is offline   Mariusz 

#6046

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

This post has been edited by Mariusz: 23 March 2019 - 12:11 AM

0

User is offline   Trooper Dan 

  • Duke Plus Developer

#6047

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

http://static.tvtropes.org/pmwiki/pub/images/indyswap_4458.jpg
4

User is offline   MusicallyInspired 

  • Buy Mage's Initiation!

#6048

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

User is online   NightFright 

  • The Truth is in here

#6049

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

User is offline   Mark 

  • Honored Donor

#6050

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

User is offline   Darkus 

#6051

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

User is offline   Lazy Dog 

#6052

View PostDarkus, on 23 March 2019 - 01:04 PM, said:

can't go underwater in E3L3.


neither in E3L1
0

User is offline   Lunick 

  • Snazzy Ex Tazzy

#6053

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

User is offline   Lazy Dog 

#6054

View PostLunick, 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

This post has been edited by Lazy Dog: 24 March 2019 - 04:51 PM

0

User is offline   Lazy Dog 

#6055

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

User is offline   Lazy Dog 

#6056

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

This post has been edited by Lazy Dog: 30 March 2019 - 11:58 AM

1

User is offline   Lazy Dog 

#6057

a new problem in e3l1


0

User is offline   TerminX 

  • el fundador

  #6058

Thanks for the report!

Edit: should be fixed in r7468
1

User is offline   Lazy Dog 

#6059

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

This post has been edited by Lazy Dog: 30 March 2019 - 12:52 PM

0

User is offline   TerminX 

  • el fundador

  #6060

The problem in the video is fixed in r7470.
1

Share this topic:


  • 207 Pages +
  • « First
  • 200
  • 201
  • 202
  • 203
  • 204
  • Last »
  • You cannot start a new topic
  • You cannot reply to this topic


All copyrights and trademarks are property of their respective owners. Instead of reading this text, you could be playing Ion Fury! ;) © 2019 Voidpoint, LLC

Enter your sign in name and password


Sign in options