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

Jump to content

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

#6121

Is that only a Polymost fix?

This post has been edited by Mark: 20 April 2019 - 02:52 AM

0

User is offline   oasiz 

  • Dr. Effector

#6122

Yes. This fix is only for polymost. Software was working correctly before.
Polymer isn't being focused on at the moment, I wouldn't expect anything there in the near future (if it has this same issue?)
0

User is online   Mark 

#6123

OK. I asked because I didn't know if the fix was a Build/ Eduke32 thing or just renderer specific.

Sadly yes, Polymer has its share of transparency glitches too. :lol:

This post has been edited by Mark: 20 April 2019 - 04:17 AM

0

User is offline   MC84 

#6124

View Postoasiz, on 19 April 2019 - 10:17 PM, said:

How about ONE UNIT of unfucked polymost transparency ?


Will this fix also translate to transparent mask walls? I use a heck of a lot of them in my mod (running polymost) and projectiles always disappear when passing behind them.
0

#6125

I thought that some old issues were fixed already, then, i made a video that include some new and some old stuff (r7618), sorry i had no time for the subtitles, so i'll write right here and in the video descritpion (in order).





1- Probably is not noticeable in the video but, usually when i fall down from the roof i strafe (W+A), and i release (W+A) before to come out to reduce falling damages (which still happens) but i can say that doing like that it fall faster than the usual (this started recently, probably because of the new clip behaviours).
2- Maybe am wrong but, i remember that the inactive/invicible enemies issue was at least improved (i tried many times and it happened a lot).
3- Some minor clipping problems with that door in E1L2 (the left side of the door is ok).
4- Were enemies spawns already fixed? Posted Image
5- I do not want harrass anyone but, the weird pipe bombs behaviour still there and is quite annoying in some place lol.
6- Opposite to point "2", inactive strong enemies get 1 hit killed.

BTW, i know that maybe the Texture Filter it was not that helpful but, actually with some mods like the DN64, it was not that bad, before to be removed:

Posted Image

This post has been edited by The Battlelord: 28 April 2019 - 11:10 PM

0

User is online   Phredreeke 

#6126

Also DN64 shouldn't use palette emulation so texture filtering wouldn't be a problem anyway <_<

This post has been edited by Phredreeke: 30 April 2019 - 01:37 AM

0

User is offline   axl 

#6127

I'm getting FPS drops on the latest builds using polymost.

I had no problems whatsoever with builds 7611 and below: rocksolid 144 fps (with vsync on).

But since build 7613 I'm experiencing minor FPS hickups: sudden drops below 144 followed with peaks above... Problem still occurs on the latest build (7621).

This post has been edited by axl: 30 April 2019 - 04:27 AM

0

User is offline   pogokeen 

  • EDuke32 Developer

#6128

Sorry that you are running into this issue, axl.

Could you enter the
glinfo
command into the EDuke32 console and post the resulting eduke32.log file here? Additionally, are you using any mods and are there any particular maps where the problem is most egregious?

If you can let me know, that would help me to replicate & fix the issue.

Thanks!
1

User is offline   axl 

#6129

View Postpogokeen, on 01 May 2019 - 05:10 AM, said:

Sorry that you are running into this issue, axl.

Could you enter the
glinfo
command into the EDuke32 console and post the resulting eduke32.log file here? Additionally, are you using any mods and are there any particular maps where the problem is most egregious?

If you can let me know, that would help me to replicate & fix the issue.

Thanks!


Here you go. I just played Holowood Holocaust. I'm not using any mod btw. Thanks for looking into this issue !

Attached File(s)


0

User is offline   axl 

#6130

View Postaxl, on 02 May 2019 - 01:18 AM, said:

Thanks for looking into this issue !


Update : setting the FPS max limit to match my screen refresh rate eliminates the problem.

Two general remarks:

1. I've noticed that the new build released yesterday (7657) removes the "classic" shading in Polymost and reintrodues a more "modern" variant. Personally I loved the classic software-like shading combined with Polymost. Wouldn't it be possible to set this as "optional" so that players are able to choose the shading style?

2. I've mentioned this before, but EDuke32 still needs some time to load custom skyboxes in Polymost. I compared it with DukeGDX (BuildGDX) and the loading of custom skyboxes there was almost non-existant.

Thanks.
1

User is online   Phredreeke 

#6131

NukeYKT says

Quote

set r_shadeinterpolate to 0 to get banding

1

User is offline   LeoD 

  • Duke4.net topic/3513

#6132

Automated synthesis build creation might be broken. Or was it just unfortunate commit timing?
0

User is offline   Micky C 

  • Honored Donor

#6133

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

0

User is offline   pogokeen 

  • EDuke32 Developer

#6134

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

User is offline   oasiz 

  • Dr. Effector

#6135

Btw, polymost cursor is unfucked in latest mapster. After all these years you can like FINALLY select shit without a virtual cursor and it will just work. Thanks to Nuke.
1

User is online   Mark 

#6136

View Postoasiz, on 26 June 2019 - 10:42 AM, said:

Btw, polymost cursor is unfucked in latest mapster. After all these years you can like FINALLY select shit without a virtual cursor and it will just work. Thanks to Nuke.

Hello, Satan? Did hell just freeze over? :D
0

User is online   Mark 

#6137

Wow, I see a 22kb changelog.txt file for revision 7743. Is that a new record?

I tried the latest 7750 in my project and other than have to readjust FOV, gamma and vis a slight bit, it seems to be running fine. I'll do more testing in the next couple of days.

This post has been edited by Mark: 26 June 2019 - 06:26 PM

0

User is offline   Danukem 

  • Duke Plus Developer

#6138

Quote

Normally I wouldn't be in favor of changing indexes that are already exposed to scripts around, but gamefunc_AutoRun is a locally handled key that doesn't have any script events associated with it, and gamefunc_Alt_Fire is pretty important to have up near the top wherever gamefuncs are listed.
------------------------------------------------------------------------
r7761 | terminx | 2019-07-06 09:30:43 -0700 (Sat, 06 Jul 2019) | 1 line

Replace gamefunc_Alt_Weapon with a gamefunc_Alt_Fire that works as expected
------------------------------------------------------------------------
r7760 | terminx | 2019-07-06 09:30:37 -0700 (Sat, 06 Jul 2019) | 1 line


I understand the argument for swapping those indexes, since you want Alt Fire to be listed closer to the top. However, by also changing the name of it from "Alt Weapon", it means that my cons will no longer compile until I change the name in my cons. Easy enough, but, I had been maintaining compatibility with an older EDuke32 revision from before the great clipping overhaul, which still has some bugs.

Why change the name of it? In the vanilla game, it swaps to the subweapon, it doesn't fire the weapon. If someone wants to make it fire a secondary fire mode, they can change the name in script.

EDIT: Also, since I already had a "SECONDARY FIRE", now it's confusing since everyone will assume that the new "ALT FIRE" does that function, which it doesn't.

This post has been edited by Trooper Dan: 06 July 2019 - 09:24 AM

0

#6139

View PostTrooper Dan, on 06 July 2019 - 09:19 AM, said:

I understand the argument for swapping those indexes, since you want Alt Fire to be listed closer to the top. However, by also changing the name of it from "Alt Weapon", it means that my cons will no longer compile until I change the name in my cons. Easy enough, but, I had been maintaining compatibility with an older EDuke32 revision from before the great clipping overhaul, which still has some bugs.

Why change the name of it? In the vanilla game, it swaps to the subweapon, it doesn't fire the weapon. If someone wants to make it fire a secondary fire mode, they can change the name in script.

EDIT: Also, since I already had a "SECONDARY FIRE", now it's confusing since everyone will assume that the new "ALT FIRE" does that function, which it doesn't.


it no longer swaps to subweapon, i hope it's a bug

https://forums.duke4...ey-doesnt-work/

This post has been edited by Lazy Dog: 06 July 2019 - 10:18 AM

0

User is offline   Danukem 

  • Duke Plus Developer

#6140

View PostLazy Dog, on 06 July 2019 - 10:03 AM, said:

it no longer swaps to subweapon, i hope it's a bug


Either that or TerminX decided to no longer have a key dedicated to switching to subweapons -- "Alt Fire" doesn't sound like it should switch to a subweapon, it sounds like it should cause the selected weapon to alt-fire.
0

#6141

View PostTrooper Dan, on 06 July 2019 - 10:15 AM, said:

Either that or TerminX decided to no longer have a key dedicated to switching to subweapons -- "Alt Fire" doesn't sound like it should switch to a subweapon, it sounds like it should cause the selected weapon to alt-fire.



Yeah, and Duke 3D doesn't have a single weapon that does that. it's great for mods, but i think the old "alt weapon" was useful for things like throwing multiple pipebombs (i had it bound to z). Also if a mod ads more subweapons, it makes switching easier.

This post has been edited by Lazy Dog: 06 July 2019 - 10:30 AM

0

User is offline   TerminX 

  • el fundador

  #6142

I changed the name because while I didn't think anyone was using the previous functionality, I wanted to be able to add it back in under the original name without issue if needed. I guess I can do that when I get a bit of free time later.
0

User is offline   Danukem 

  • Duke Plus Developer

#6143

View PostTerminX, on 06 July 2019 - 10:46 AM, said:

I changed the name because while I didn't think anyone was using the previous functionality, I wanted to be able to add it back in under the original name without issue if needed. I guess I can do that when I get a bit of free time later.


Alien Armageddon does use the previous functionality to swap between subweapons (that mod adds several subweapons to the game). Having both "Alt Weapon" and "Alt Fire" as separate functions makes sense to me. I guess I would move my "Secondary Fire" over to "Alt Fire" to avoid confusion and put it higher on the key binding list.
0

#6144

View PostTerminX, on 06 July 2019 - 10:46 AM, said:

I changed the name because while I didn't think anyone was using the previous functionality, I wanted to be able to add it back in under the original name without issue if needed. I guess I can do that when I get a bit of free time later.


but they key doesn't work now, you can't change between the shrinker and expander, for example

This post has been edited by Lazy Dog: 06 July 2019 - 10:54 AM

0

User is offline   TerminX 

  • el fundador

  #6145

View PostTrooper Dan, on 06 July 2019 - 10:52 AM, said:

Alien Armageddon does use the previous functionality to swap between subweapons (that mod adds several subweapons to the game). Having both "Alt Weapon" and "Alt Fire" as separate functions makes sense to me. I guess I would move my "Secondary Fire" over to "Alt Fire" to avoid confusion and put it higher on the key binding list.

Yep, that's the idea. No more having to hijack whatever random gamefunc closest to the top that you were willing to sacrifice to have the option actually visible in the menu.

Alt fire is also bound to the second mouse button by default.

View PostLazy Dog, on 06 July 2019 - 10:54 AM, said:

but it doesn't work, you can't change between the shrinker and expander, for example

Yeah, that's not what it's for. Have you been reading the posts in this thread?
0

#6146

View PostTerminX, on 06 July 2019 - 10:54 AM, said:

Yeah, that's not what it's for. Have you been reading the posts in this thread?


My bad, didn't understand. Just to be sure, is the alt-weapon key gonna be added back, as a separate key?
0

User is offline   TerminX 

  • el fundador

  #6147

Yes, it's added back now. Just wait for it to compile.
3

User is offline   Danukem 

  • Duke Plus Developer

#6148

View PostTerminX, on 06 July 2019 - 10:54 AM, said:

Yep, that's the idea. No more having to hijack whatever random gamefunc closest to the top that you were willing to sacrifice to have the option actually visible in the menu.

Alt fire is also bound to the second mouse button by default.


That's definitely an improvement, then.

A bigger improvement would be giving the modder control over which gamefuncs appear in the key/mouse binding menus, and in which order. But I guess that's hard to do.
1

#6149

View PostTerminX, on 06 July 2019 - 11:05 AM, said:

Yes, it's added back now. Just wait for it to compile.


Thanks.
0

User is offline   Danukem 

  • Duke Plus Developer

#6150

View PostTerminX, on 06 July 2019 - 11:05 AM, said:

Yes, it's added back now. Just wait for it to compile.


I'm making the switch, but unfortunately the game still crashes when changing a gamevar through the console. That means that to test certain things, it's still useful to be able to run an older revision, but that's impractical now that I'm making the script changes to accommodate the new keys.


So please fix the crash :D
2

Share this topic:


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