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

Jump to content

  • 213 Pages +
  • « First
  • 204
  • 205
  • 206
  • 207
  • 208
  • 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   Danukem 

  • Duke Plus Developer

#6151

Would it be possible to associate an input bit with the new altfire key? It's useful to be able to check on whether the key is being pressed in contexts outside of the event code. I could do that before with the key I had bound to it. I'll have to do a significant amount of moving code around and rewriting otherwise. EDIT: I could set a var when the event fires, acting as a proxy for an input bit. But I'm wondering if there will be something in the input structure.

This post has been edited by Trooper Dan: 06 July 2019 - 12:00 PM

0

User is offline   Micky C 

  • Honored Donor

#6152

View Postpogokeen, on 26 June 2019 - 04:55 AM, said:

Thanks for the heads up about that issue, Micky C.

I'll take a look & get that fixed. Once I have a solution in place, I'll let you know here.


Any update on this? Ion Fury has priority of course, and this is a non-urgent albeit critical bug.

I also see that Ion Fury will be released on Mac as well next month. Does this mean that eduke32 will have mod support on Mac that works largely out-of-the-box?
0

User is offline   Hendricks266 

  • Weaponized Autism

  #6153

Please let me know if r7794 breaks anything related to collision.
0

User is offline   Danukem 

  • Duke Plus Developer

#6154

Quote

r7815 | hendricks266 | 2019-07-21 20:24:35 -0700 (Sun, 21 Jul 2019) | 1 line

Don't lock out cheats in skill 4 if FURY


I've always hated that in Duke, too, but I guess you want to preserve the original behavior.
0

User is offline   Forge 

  • Speaker of the Outhouse

#6155

View PostMicky C, on 26 June 2019 - 03:59 AM, said:

The slopes in classic mode are much more stable at extreme angles now, kudos to Nuke.YKT. They still become warped and fullbright at large distances though, not sure if that's possible to fix.

Using r7750 64-bit mode, the AMC TC crashes upon startup when using polymost but not classic. Using debug eduke32, the last line in the log reads as follows:

tilepacker: kdtree_reserveNode(): out of nodes


View Postpogokeen, on 26 June 2019 - 04:55 AM, said:

Thanks for the heads up about that issue, Micky C.

I'll take a look & get that fixed. Once I have a solution in place, I'll let you know here.

any idea what may be causing this?
I get:

gltexinvalidateall()
gltexinvalidateall()
polymost_glreset()
tilepacker: kdtree_reserveNode(): out of nodes
tilepacker: kdtree_reserveNode(): out of nodes


windows10x64
fx 8320
nvidia gtx 650 ti
polymost mode
eduke32_win64_debug_20190724-7842

Pretty sure it has something to do with the number of art files.

Appreciate the juggling act the dev team is doing for us. Really.

This post has been edited by Forge: 25 July 2019 - 09:17 AM

0

User is offline   TerminX 

  • el fundador

  #6156

Do you guys still use that SVN repo we set up for you a long while back? Are the contents of that repository something we can use to test the breakage?
0

User is offline   Forge 

  • Speaker of the Outhouse

#6157

View PostTerminX, on 25 July 2019 - 10:47 AM, said:

Do you guys still use that SVN repo we set up for you a long while back? Are the contents of that repository something we can use to test the breakage?

The AMC svn repo?
Yes. It is actively updated and has the most current content.
That is what I used to test & what gave me the error message in my last post.
0

User is offline   Paul B 

#6158

View PostHendricks266, on 15 July 2019 - 11:01 PM, said:

Please let me know if r7794 breaks anything related to collision.

Hi Hendricks, I've come across a collision problem that was never present in older builds and now is present. In my map The Rock I have a TROR sos stairwell. Duke is getting caught on an invisible white wall in one direction. Going down the stairs. Going up the stairs Duke doesn't get blocked. Bullets appear to pass through this invisible wall just not the player.

I'll try to collect more information for you about the problem and i'll post back here.

*** UPDATE *** Okay somewhere in download r7831 introduces the problem with Duke being blocked by an invisible wall. Or a wall that perhaps maybe overlapping due to SOS. This looks like an update by Terminx. My guess is the problem lays somewhere between R7826 - R7831

While I'm mentioning things. You guys might already be aware of this problem but climbing sprite ladders in these newer builds is no where near as good and sometimes not possible. This does impact the game play where levels rely on this function to work.

On the plus side I have noticed great improvements in FPS and game performance. As well improvements with TROR in Polymost and water surfacing SE 7 TROR sectors. Keep up the good work everyone! One day this engine will be able to handle my new overly used TROR map. Oops did I just spill the beans. =P

This post has been edited by Paul B: 26 July 2019 - 08:56 PM

0

User is offline   Micky C 

  • Honored Donor

#6159

The beans are spilled.

I have also been looking into a TROR clipping issue. This involves a TROR layer above the player that the player should (and normally can) jump through, where the ceiling is 11264 units above the floor. When the player is standing on the floor, or on a floor-aligned blocking sprite that is on the floor, the player can jump through no problem. However, if you lower the floor, and place either a floor-aligned blocking sprite or a view-aligned sprite such that the player is standing at the same height as before, the player cannot jump through.

I guess it's something to do with the player's height being exact that of the TROR ceiling? To simplify the above paragraph, the player can jump fine from a sector, but not from a sprite, if there's exactly that amount of room.

This post has been edited by Micky C: 27 July 2019 - 02:07 AM

0

User is offline   pogokeen 

  • EDuke32 Developer

#6160

The issue with the tilepacker should resolved now with r7849 & r7851. Thanks to Doom64hunter for spotting the bug! :dukecigar:
1

User is offline   Micky C 

  • Honored Donor

#6161

Thanks for applying the fixes.

I see over at dukeworld that 7874 is still the latest. Any idea when the next release will be available?
0

User is offline   Micky C 

  • Honored Donor

#6162

And I have finally learned to read! Ignore my last post :dukecigar:
1

User is offline   Micky C 

  • Honored Donor

#6163

A slope-related clipping issue.

The height of the ceiling firstwall seems to dictate the maximum height of the sector when you're trying to jump or jetpack into it. Looking at the image below, the player isn't able to pass above the red line. Ignore the TROR, this happens even without it. I've attached an example map. This is using 7885, currently the latest available.

Posted Image

Attached File(s)



This post has been edited by Micky C: 04 August 2019 - 05:24 AM

0

User is offline   Forge 

  • Speaker of the Outhouse

#6164

Maybe related, maybe not - to that non-tror "submarining" clipping issue I experienced using the boat in amc tc.

In a basic sos/ror situation - if the ceiling height of the room below is higher than the floor height of the room above, the player will clip into the lower sector simply by "boating" upon the upper room's floor and crossing a sector line of the room below.

it doesn't do it except under certain circumstances & there were submersible tror water sectors on the same plane not far from the basic sos/ror

I amended my post because I went senile with my description. It still probably doesn't make any sense

This post has been edited by Forge: 04 August 2019 - 06:44 AM

0

User is offline   Paul B 

#6165

View PostMicky C, on 04 August 2019 - 05:22 AM, said:

A slope-related clipping issue.

The height of the ceiling firstwall seems to dictate the maximum height of the sector when you're trying to jump or jetpack into it. Looking at the image below, the player isn't able to pass above the red line. Ignore the TROR, this happens even without it. I've attached an example map. This is using 7885, currently the latest available.

Posted Image


This sounds like we all are explaining and experiencing the same problem. Well said Micky. I've submitted a sample map to the devs here: https://forums.duke4...599#entry326599

This post has been edited by Paul B: 04 August 2019 - 06:50 AM

0

#6166

In r7885 only spacebar and enter skips the intro videos, the rest of the keys don't do anything. If this is intentional, could at least skiping with escape be added back?

This post has been edited by Lazy Dog: 04 August 2019 - 09:32 AM

0

#6167

View PostLazy Dog, on 04 August 2019 - 09:06 AM, said:

In r7885 only spacebar and enter skips the intro videos, the rest of the keys don't do anything. If this is intentional, could at least skiping with escape be added back?


Also, you can enter through the window in e1l1



This post has been edited by Lazy Dog: 05 August 2019 - 01:24 PM

1

#6168

View PostLazy Dog, on 04 August 2019 - 09:06 AM, said:

In r7885 only spacebar and enter skips the intro videos, the rest of the keys don't do anything. If this is intentional, could at least skiping with escape be added back?


Fixed in r7894, thanks.
1

User is offline   Sangman 

#6169

View PostMicky C, on 04 August 2019 - 05:22 AM, said:

A slope-related clipping issue.

The height of the ceiling firstwall seems to dictate the maximum height of the sector when you're trying to jump or jetpack into it. Looking at the image below, the player isn't able to pass above the red line. Ignore the TROR, this happens even without it. I've attached an example map. This is using 7885, currently the latest available.


Haven't checked in-game but should be fixed as of r7918 if the commit messages are accurate

This post has been edited by Sangman: 07 August 2019 - 03:43 PM

0

User is offline   Hendricks266 

  • Weaponized Autism

  #6170

r7919 updates our Windows version of SDL to 2.0.10. Please let me know if this introduces any new issues.
1

User is offline   Danukem 

  • Duke Plus Developer

#6171

Holy shit you are finally adding proper game controller support.
3

User is offline   Micky C 

  • Honored Donor

#6172

Looking at the change for r7955 about the bug of standing on sprites underwater making the player act as though they are not underwater.

Some maps actually use that as a feature, and there was the alternate workaround added where if the sprite has a hitag, then it does not display this bug.

Is this the sort of thing which should be restricted to the standalone builds? It may make some maps unbeatable. Not many, sure, but some.
0

User is offline   Forge 

  • Speaker of the Outhouse

#6173

View PostMicky C, on 11 August 2019 - 08:25 PM, said:

Looking at the change for r7955 about the bug of standing on sprites underwater making the player act as though they are not underwater.

Some maps actually use that as a feature, and there was the alternate workaround added where if the sprite has a hitag, then it does not display this bug.

Is this the sort of thing which should be restricted to the standalone builds? It may make some maps unbeatable. Not many, sure, but some.

BobSP4 uses the feature so the player can get to the bottom of an under water chasm quickly to preserve some oxygen in the player's scuba tanks.
This is just one map of many.

There is a map or two that also uses the feature to simulate spacewalks on the sides of crafts and across scaffolding between spaceships.

This post has been edited by Forge: 11 August 2019 - 09:03 PM

0

User is offline   HellFire 

#6174

Bugfixes like that should be enabled via an option in the menus (or a console flag, whatever), IMO.
0

User is offline   Hendricks266 

  • Weaponized Autism

  #6175

It would be trivial to change r7955 to only apply in FURY mode. Patches welcome because I can't mess with this right now.
0

User is offline   Micky C 

  • Honored Donor

#6176

It's not an urgent issue, and can be looked into after the dust settles from Ion Fury. Best of luck for the upcoming release!

Edit: Looks like giving the sprite an xvel of 1 rather than a hitag is what fixes the bug for individual sprites.

This post has been edited by Micky C: 12 August 2019 - 10:44 PM

0

User is offline   pagb666 

#6177

So... I just decided to flagellate myself by playin NAM/Napalm. With the latest eDuke releases there are these random ocurrences were the game just chokes in a huge lag spike for several seconds (music included) and then the game makes up for all missing frames. It happens more and less consistently at E1L5's beginning.
0

User is offline   Micky C 

  • Honored Donor

#6178

Found another clipping issue.

When you're standing on a sprite floor, and there are sprite wall-alligned sprites that should block you from moving sideways, the wall-alligned sprites no longer block you moving if you crouch. See the image below for an example area. Clipping works normally when you're standing on a sector.

Posted Image
1

User is offline   Danukem 

  • Duke Plus Developer

#6179

Does the spriteflag for movement interpolation on actors (htflags 8192) do anything these days? It seems like movement is smooth regardless.
0

User is offline   NightFright 

  • The Truth is in here

#6180

Ladies and gentlemen, it has happened.

Posted Image
Don't notice anything special? Hint: I am running this in Polymost. Still don't get it? Look at the sky. It is f*ing FLAWLESS! No more screwed-up rendering of skies with that "flat paper" look, forcing you to use skyboxes or running Classic/Polymer.
Get r8075 or later for this beautiful fix. Thanks a lot to Nuke.YKT for this important and long overdue patch!

This post has been edited by NightFright: 03 September 2019 - 01:40 AM

4

Share this topic:


  • 213 Pages +
  • « First
  • 204
  • 205
  • 206
  • 207
  • 208
  • 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