[KillerBudgie]

If that's not beauty, I don't know what is.

[axl]

NightFright, on 03 September 2019 - 12:04 AM, said:

Ladies and gentlemen, it has happened.
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. Is. Awesome ! Thanks Nuke.YKT !

[Radar]

NightFright, on 03 September 2019 - 12:04 AM, said:

Ladies and gentlemen, it has happened.

<snip>
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!

Not flawless for those of us playing with higher FOVs, but a great feature nonetheless.

[brullov]

Help! I want to put high res picture instead of "ATOMIC" sign (tilenum 2502). I define it like that:

texture 2502 { pal 0 { file "resources/tiles/ui/2502.png" } }

Unfortunately, it does not work. I've changed font with the same method and it works. File path is right, file name in folder is right too.

[Mark]

In newer revisions I've had a problem with some sounds located in a subfolder not playing while sounds in the root folder play. Try putting the texture in the root folder, adjust your def line and see if it works. Its a long shot but who knows. Maybe the 2 are somehow related.

[Doom64hunter]

The performance of the "voxel to model" conversion algorithm when switching to Polymost deteriorates as the size and detail of the voxel increases.

In the AMC TC, we have roughly 250 voxels of <500KB filesize, totalling about 16.5MB, and 13 voxels of filesize >500KB, totalling 8.6MB (the largest of these being about 1 MB).
The former group results in a conversion overhead of roughly 7 seconds, while the latter group results in an overhead of 6 seconds on my end. This suggests a disproportionate performance decrease with larger voxels.

(Note that the latter group of voxels requires a high level of detail in order not to look like trash ingame.)

Any hope for an eventual improvement on this front?

[VGA]

I haven't used eduke32 for some time. The most annoying problem with Polymer was some z-fighting, noticeable on fire hydrants and the switches that end the levels. Is that fixed?

[Doom64hunter]

NightFright, on 03 September 2019 - 12:04 AM, said:

Ladies and gentlemen, it has happened.


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!

I'm gonna be the outlier here and say that while this is more accurate to software mode, the old rendering technique in polymost made a whole lot more sense.
Go on episode 2, look at the moon and look up or down. I don't think it makes sense that the moon is moving with your view. Much rather it should stay where it is, which it did with the old approach.

[NightFright]

In the meantime, we have borderless window mode and non-power-of-two fix for Polymost skies. It's raining featurez, boiz. These are good days.

[Fox]

Doom64hunter, on 08 September 2019 - 02:51 AM, said:

Go on episode 2, look at the moon and look up or down. I don't think it makes sense that the moon is moving with your view. Much rather it should stay where it is, which it did with the old approach.

That is not a problem of the approach. The same thing has always happened in 8-bit mode. The reason is that the artwork for the sky is too short, and if it didn't move you would see gaps on the top and bottom (like it happened before in Polymost). The only except is E4L9 sky, which stay in the right place.

[oasiz]

You're better off using skyboxes in those cases, the old polymost method tried to fake what skyboxes do but it can only get there halfway.
I don't think it was ever intended as a permanent solution but it's just taken this long for someone to actually finally fix it,

I think the only negative is that for this to look more proper, you'd need to also enable Y shearing as with classic the sky would be "flat" against the geometry due to Y aiming simply being the same as scrolling a framebuffer viewport.

[NightFright]

Does the sky in E4L1 move under Polymost now? It doesn't in Polymer, at least last time I checked.

[The Battlelord]

Noticed a minor clip problem in E1L1 r8133 (it was probably present in some few previous versions, still present in r8234:



No idea if this affect other levels.
The music is also somehow different, a lot less loud too.

[Radar]

I personally love the new polymost skies, the only thing I'll mention is that it looks pretty bad if you increase the FOV. The sky art ends up getting stacked. IMO the sky art should remain static regardless of FOV level.

[LeoD]

The Battlelord, on 19 October 2019 - 08:41 PM, said:

Noticed a minor clip problem in E1L1 r8133 (it was probably present in some few previous versions, still present in r8234:

I can't confirm this (r8133/r8240).

[NightFright]

Doesn't really belong here, but didn't want to open a new thread for it, either, so...
Thanks a lot for adding that OPL3 emulator! I am sure a lot of people will appreciate this for retro-style playing sessions. In combination with low resolution, this can help a lot with creating a "throwback" feeling.

[Jmoc]

NightFright, on 21 October 2019 - 04:54 AM, said:

Doesn't really belong here, but didn't want to open a new thread for it, either, so...
Thanks a lot for adding that OPL3 emulator! I am sure a lot of people will appreciate this for retro-style playing sessions. In combination with low resolution, this can help a lot with creating a "throwback" feeling.

Who is the one who integrated the OPL3 emu? Gorgeus job, really. Nostalgia hits hard!

[Phredreeke]

That would be NukeYKT. NBlood and RedNukem have had it since the start

[TerminX]

Nuke.YKT wrote the OPL3 emulation and I handled the current integration into the audio library. I'm very glad to have it in since the MIDI output that ships with Windows sucks and what ships with Linux is generally silence.

[NightFright]

If Nuke.YKT were also able to implement a soundfont loader or a General MIDI device switcher, I would build him a f*ing statue. One way or the other, it's an amazing feature and deserves tons or praises.

[Hendricks266]

r8384 adds a WinMM MIDI device switching cvar.

[NightFright]

You magnificient maniacs. After all these years!

[3D Master]

The HRP Hud Model weapons are all too low, only about half of it is shown; does anyone know a solution?

I've tried "r_pr_hudyadd" (and the other axis commands) but they don't do anything.

[Doom64hunter]

What's going on with the laser tripwire rendering? Very often I get situations where the laser is not visible at all, such as here:



When it should look more like this:


No idea why this happens, it doesn't seem to be consistent at all. Sometimes the lasers appear, other times they don't.

[3D Master]

I noticed something really weird in my playthrough of the Launch Facility E1M6; episode one's secret level.

When you blow up the rocket, the rocket crashes into the ground instantaneously, the explosions continue to go off, but instead of seeing the rocket slowly come down, the rocket is already gone; except for the placed textures on the sides; the numbers, they come down at the right speed, and as such are just floating in mid air as they sink down into the ground.

[TerminX]

3D Master, on 24 December 2019 - 03:18 PM, said:

I noticed something really weird in my playthrough of the Launch Facility E1M6; episode one's secret level.

When you blow up the rocket, the rocket crashes into the ground instantaneously, the explosions continue to go off, but instead of seeing the rocket slowly come down, the rocket is already gone; except for the placed textures on the sides; the numbers, they come down at the right speed, and as such are just floating in mid air as they sink down into the ground.

It's like that in the DOS version.

[Fox]

Doom64hunter, on 23 December 2019 - 02:48 PM, said:

What's going on with the laser tripwire rendering? Very often I get situations where the laser is not visible at all, such as here:

duke0063.png

When it should look more like this:
duke0065.png

No idea why this happens, it doesn't seem to be consistent at all. Sometimes the lasers appear, other times they don't.

It's not a rendering problem

It's a problem with overlapping sectors

The tripbomb uses a setsprite function, which calls updatesector instead of updatesectorz

As a result, the LASERLINE sprites get inside of the ceiling in the sectors below

[3D Master]

TerminX, on 24 December 2019 - 04:39 PM, said:

It's like that in the DOS version.

No, it isn't.

[TerminX]

3D Master, on 24 December 2019 - 05:52 PM, said:

No, it isn't.

Damn, really? Someone had better tell CERN to knock it off with all of this Mandela Effect bullshit then, because now they've gone and edited all the videos taken with the DOS version on YouTube!

[Fox]

3D Master, on 24 December 2019 - 05:52 PM, said:

No, it isn't.