Duke4.net Forums: EDuke32 2.0 and Polymer! - Duke4.net Forums

Jump to content

  • 213 Pages +
  • « First
  • 181
  • 182
  • 183
  • 184
  • 185
  • 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   Tea Monster 

  • Polymancer

#5461

Something is definitely weird in how models are rendered in Polymer. Models appear correctly lit back in ver. 4593. In more recent versions (Can't remember the version No. But in August of this year), Models look very dark. This is not a model issue as the same models appear completely different in the two versions of the renderer.

Posted Image
Same model, same level, same lighting, different SVN version.

This post has been edited by Tea Monster: 04 September 2016 - 01:25 AM

0

User is offline   Micky C 

  • Honored Donor

#5462

That was the new feature introduced in 4596; the ethnic diversity shader.
5

User is offline   Tea Monster 

  • Polymancer

#5463

Diversity through programming, the wonders of modern technology!
0

User is offline   Mblackwell 

  • Evil Overlord

#5464

View PostTea Monster, on 04 September 2016 - 01:24 AM, said:

Something is definitely weird in how models are rendered in Polymer. Models appear correctly lit back in ver. 4593. In more recent versions (Can't remember the version No. But in August of this year), Models look very dark. This is not a model issue as the same models appear completely different in the two versions of the renderer.

Posted Image
Same model, same level, same lighting, different SVN version.



Er... can you narrow it down more?

There's there's about a thousand revisions since that one.
0

User is offline   Mark 

#5465

IIRC its gone back and forth a couple of times during that span. I've lost track of the various revisions brought up each time this has been a problem during that span.Sometimes a tweak was made and a revision worked better but still not quite right. I think his point was that its not a model problem which was a possibility during some of those discussions. I'm pretty sure TM has been in PMs with a couple of the devs descibing details.

From what I can gather, as soon as normal maps are applied ( with any settings ) the diff map refuses to illuminate from light sources.

This post has been edited by Mark.: 04 September 2016 - 01:44 PM

0

User is offline   Mblackwell 

  • Evil Overlord

#5466

But if you can narrow it down to the first bad commit then they can work out the root of the problem.

Edit: You said 4593 was good. Try 4600 (for example).
0

User is offline   Mark 

#5467

Thats all "been there and done that" a few times already. The problem is elusive and we have people busy with other things and real life so a complete solution hasn't appeared. The people with the best chance of fixing it have the info from past posts and PMs on the subject.

The first bad commit was whatever came after 4593. And since then there have been a few attempts of fixes that were partially successful and then later on after another update it seemed broken again.

So other than 4593 and the next revision, there is not a clear cut case of "this version worked perfect and this one doesn't". There isn't an easy comparison to make for tracking purposes.

This post has been edited by Mark.: 04 September 2016 - 02:54 PM

0

User is offline   Mblackwell 

  • Evil Overlord

#5468

The best chance really is to find the first bad commit. :D

If you send me a test setup I can bissect it.
0

User is offline   Mark 

#5469

4593 was the last working public revision. Start from there.

After 4593 there were a series of many dozens of uncommited revisions before the next public release. I went through this with Hendricks and we had it narrowed down to about a dozen or so IIRC. But then it got dropped for whatever reasons. I no longer remember the range he was checking last time. It was a long time ago.

This post has been edited by Mark.: 04 September 2016 - 03:01 PM

0

User is offline   Tea Monster 

  • Polymancer

#5470

Mark narrowed down where the problem started, which version it was and all this has been forwarded to both TX and Plagman. We've been talking to them about this for a while now.
0

User is offline   Mblackwell 

  • Evil Overlord

#5471

View PostMark., on 04 September 2016 - 02:58 PM, said:

4593 was the last working public revision. Start from there.

After 4593 there were a series of many dozens of uncommited revisions before the next public release. I went through this with Hendricks and we had it narrowed down to about a dozen or so IIRC. But then it got dropped for whatever reasons. I no longer remember the range he was checking last time. It was a long time ago.

That's why I suggested r4600. It's the first revision with explicit changes to Polymer. If you send me a test case I can verify it and bug people about it.
0

User is offline   Hendricks266 

  • Weaponized Autism

  #5472

Can you forward the email chain to me or add me to that PM (or bump it if I already am)?
0

User is offline   Mark 

#5473

Tm should have that info.

I looked back through my PMs and there were multiple conversations spread out over time. One of them was concerning a framerate drop. It also by coincidence revolved around 4593 being the last good one. :D

Thats the one you and I were bisecting the crap out of. :D

This post has been edited by Mark.: 04 September 2016 - 03:32 PM

0

User is offline   Jmoc 

#5474

I don't know if this is the right place to say that, but did you have a look at the "new" Duke Nukem 3D 20th anniversary?


Those lights reminds me of Polymer....
0

User is offline   Player Lin 

#5475

I guess everyones on Duke4.net should already know the weird textures with extra maps shit World Tour trailer. :D
0

User is offline   Tea Monster 

  • Polymancer

#5476

Yeah, and it isn't actually Polymer and has SFA to do with this thread.
0

User is offline   Jblade 

#5477

Any check of a userdef or something similar so we can detect if the player's using widescreen mode? Using it messes up the angle of skyboxes (I don't know enough about what widescreen actually changes beyond the immediate visual appearence of everything being 2x as tall so I can't really explain the issue well enough) so I need to figure out a way of making it work in both modes.

This post has been edited by Jblade: 12 September 2016 - 01:39 AM

0

User is offline   Hendricks266 

  • Weaponized Autism

  #5478

xdim and ydim are available in CON, but are you asking for read access to r_usenewaspect?

Maybe your skybox problem is an oversight in the source. Could you show screenshots?
0

User is offline   Tea Monster 

  • Polymancer

#5479

Any progress on the dark rendering or the transparency problems?
0

User is offline   Jblade 

#5480

View PostHendricks266, on 12 September 2016 - 03:17 AM, said:

xdim and ydim are available in CON, but are you asking for read access to r_usenewaspect?

Maybe your skybox problem is an oversight in the source. Could you show screenshots?

Sure - here's two pics of widescreen on and off showing the problem. When widescreen is off the skybox matches the player's horiz perfectly, but turned on it doesn't seem to take on the same horiz value or whatever. The purple building shows this in effect.

Attached thumbnail(s)

  • Attached Image: widescreenon.jpg
  • Attached Image: widescreenoff.jpg


This post has been edited by Jblade: 12 September 2016 - 03:53 AM

0

User is offline   Apiai 

#5481

Hi,

I don't understand why sometimes I see some 3D models (pigcops gibs and ejected ammos) in classic mode (eduke r5811 + Dukeplus 2.40)

How is it possible ?
0

User is offline   Danukem 

  • Duke Plus Developer

#5482

View PostApiai, on 12 September 2016 - 10:57 AM, said:

Hi,

I don't understand why sometimes I see some 3D models (pigcops gibs and ejected ammos) in classic mode (eduke r5811 + Dukeplus 2.40)

How is it possible ?


That's Dukeplus, it's not EDuke32's fault. Pigcop jibs do not exist in sprite form, so you will still see models for those even without the HRP (by the way, you can't really mean classic, because there is no way that the classic 8-bit renderer is rendering models). You will also see some other models such as the shell casings and some of the new guns. If you go through the Dukeplus menu you can turn some of that stuff off.
0

User is offline   Jblade 

#5483

Projectiles that are set to explode after bouncing a certain number of turns no longer explode now - they just bounce around until they stop and then bounce on the spot indefinitely.
0

User is offline   Mblackwell 

  • Evil Overlord

#5484

turn off explodeontimer 16384

alternatively make sure both 16384 and 64 (timed) are set and define range.

This was broken before.
0

User is offline   Danukem 

  • Duke Plus Developer

#5485

View PostMblackwell, on 15 September 2016 - 09:07 AM, said:

turn off explodeontimer 16384

alternatively make sure both 16384 and 64 (timed) are set and define range.

This was broken before.


Just to be clear: what exactly was broken? Projectiles that explode after a certain number of bounces have worked for as long as I can remember.
1

User is offline   Hendricks266 

  • Weaponized Autism

  #5486

 Mblackwell, on 15 September 2016 - 09:07 AM, said:

This was broken before.

"Bouncing in one spot" sounds pretty broken in its own right.
0

User is offline   Mblackwell 

  • Evil Overlord

#5487

View PostTrooper Dan, on 15 September 2016 - 10:18 AM, said:

Just to be clear: what exactly was broken? Projectiles that explode after a certain number of bounces have worked for as long as I can remember.


Timed projectiles.
0

User is offline   Mblackwell 

  • Evil Overlord

#5488

View PostHendricks266, on 15 September 2016 - 03:39 PM, said:

"Bouncing in one spot" sounds pretty broken in its own right.



If you have 16384 (EXPLODEONTIMER) set but not 64 (TIMED) set then the game doesn't read RANGE as the TIMER so it can't figure out when it should explode.
0

User is offline   Danukem 

  • Duke Plus Developer

#5489

View PostMblackwell, on 15 September 2016 - 09:19 PM, said:

If you have 16384 (EXPLODEONTIMER) set but not 64 (TIMED) set then the game doesn't read RANGE as the TIMER so it can't figure out when it should explode.


Got it. I'm pretty sure that I have always had both of those set on my timed projectiles because the documentation said to do so.

By the way, what would be the use case for having one flag set but not the other?

This post has been edited by Trooper Dan: 15 September 2016 - 10:48 PM

0

User is offline   Jblade 

#5490

I don't know what the conclusion here is but the projectile in question isn't set to explode on any kind of timer, they're supposed to just bounce 6 times or whatever and then explode at the end. This isn't working anymore.
0

Share this topic:


  • 213 Pages +
  • « First
  • 181
  • 182
  • 183
  • 184
  • 185
  • Last »
  • You cannot start a new topic
  • You cannot reply to this topic


All copyrights and trademarks not owned by Voidpoint, LLC are the sole property of their respective owners. Play Ion Fury! ;) © Voidpoint, LLC

Enter your sign in name and password


Sign in options