[Mark]

Is that only a Polymost fix?

[oasiz]

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?)

[Mark]

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.

[MC84]

oasiz, 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.

[The Battlelord]

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?
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:

[Phredreeke]

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

[axl]

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

[pogokeen]

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!

[axl]

pogokeen, 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)

•  eduke32.log (5.93K)
  Number of downloads: 355

[axl]

axl, 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.

[Phredreeke]

NukeYKT says

Quote

set r_shadeinterpolate to 0 to get banding

[LeoD]

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

[Micky C]

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

[pogokeen]

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.

[oasiz]

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.

[Mark]

oasiz, 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?

[Mark]

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.

[Danukem]

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.

[DisgustedGrunt]

Trooper 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/

[Danukem]

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

[DisgustedGrunt]

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

[TerminX]

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.

[Danukem]

TerminX, 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.

[DisgustedGrunt]

TerminX, 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

[TerminX]

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

Lazy 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?

[DisgustedGrunt]

TerminX, 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?

[TerminX]

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

[Danukem]

TerminX, 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.

[DisgustedGrunt]

TerminX, on 06 July 2019 - 11:05 AM, said:

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

Thanks.

[Danukem]

TerminX, 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