[ReaperAA]

I am really excited about this. If it fixes the performance issues and makes mouse movement better, then its a welcome fork.

[Zaxx]

Mouse movement is already great with the latest EDuke32 releases (input lag is basically gone now if you're not using vsync, it's a true game changer). Performance is not, there is a problem where the fps can randomly drop for a few seconds but that's a bug.

[Mark]

Its been many years since the last time I had any complaints about mouse movement. I guess I'm just lucky judging from the amount of complaints I've read here.

[Zaxx]

Yeah, mouse movement wasn't terrible for a while now, it gradually improved nicely, the only thing that held it back from feeling truly great was that it operated at a 30 hz refresh afaik. So even though it got smooth it was just a tad bit slow and input laggy, now it's not.

[Phredreeke]

Zaxx, on 03 February 2020 - 04:23 AM, said:

I think he mentioned that he wants to make a new renderer but that will happen later. Guess he wants to salvage Polymer or at least some of its features.

From what I can tell he’s not going to touch Polymer.

[Player Lin]

Phredreeke, on 03 February 2020 - 06:48 AM, said:

From what I can tell he’s not going to touch Polymer.

He clearly said that, he want one of the feature(or core features) of Polymer, but not the buggy, unoptimized whole mess.

This is what he said about his current progress:

Quote

The real answer lies in the middle, of course. It is true that there was very little being added to the existing code - most was replacing entire subsystems indeed.

Polymost is still there, at least the part that builds the geometry - but all the low level stuff has been completely removed, all the texture management, shader setup and lighting is done in the backend.
A quick overview over the biggest alterations:

• the entire file system code inherited from Build was replaced with a reworked and extended version of GZDoom's WAD manager to work more like a real virtual file system. For Blood I merged the 3 distinct file systems (directory, Blood.rff, Sounds.rff) together into one. It would require quite elaborate fuckery to use Blood's system in a way that could break this changed setup, but will make it a lot easier to design mods for. I think the advantages far outweigh the potential but mostly theoretical problems.
  
• the Build memory cache was entirely removed with no replacement. For technical reasons most that was put into it needs to be permanently loaded anyway so no real loss.
  
• Build OSD and configuration maintenance was replaced with ZDoom's console and config code.
  
• Polymer had to be entirely disabled for the time being. The main problem is that it needs too much support code outside the renderer and couldn't be as easily uncoupled from OpenGL as Polymost. I fully intend to bring its core features - but not the renderer implementation itself - back, once the entire engine is in a more stable state than right now. Actually, programming a new renderer that is better equipped to work with current graphics hardware would be where the real fun lies.
  
• Replacement of all menu code with ZDoom's menu engine (the last version before it got scriptified)
  
• Using GZDoom's backend for system maintenance and input. On Windows and Mac SDL is no longer used.
  
• Uses CMake as its sole building system.

source

Yeah, it looks like he changed a lot, also, the thread has some licensing related things if someone want to use Graf Zahl's code.

[Tea Monster]

oasiz, on 03 February 2020 - 03:49 AM, said:

I hope that any new renderer will still stay compatible with old maps.
Polymer might have it's share of problems but it at least works.

It dosen't though. The gloss/specular shader used in polymer does not equate to any creation software. People have resorted to pumping up specular counts 2 times in the def file just to try and get stuff to look like it should Thus it's nearly impossible to get a 'WYSIWYG' result when making models or textures for polymer. That isn't counting the light limitation from the performance issues. It can be argued that the problems with polymer contributed to the death of the modelling community at Duke4, if only partially.

For these reasons, there are few mods that use Polymer. Maintaining backwards compatibility with something that is so broken is going to hobble the future much more than it supports the past. Much better to state that Polymer mods are played with an old version of EDuke. Due to the number of polymer bugs, we specified this with HHR in the readme. "Play it with version 'X.XX' or it won't work". Fixing the outstanding issues with polymer's shaders will break the look of existing mods anyway.

oasiz, on 03 February 2020 - 03:49 AM, said:

Many rendering methods fall apart with the nature of Build's geometry and comparing Doom to Duke is a bit unfair. There is a reason why Quake/Doom can look so nice as they actually follow 3D standards closer and the geometry is fully static.
Build itself is OK but the things it allows you to do is like a bag of edge cases. If you try to obey rendering conventions or physics, you might end up just breaking things as so many things rely on quirks.

A new renderer must work with the game and not against it, otherwise why even use build when ultimately something like doom WILL serve better.
Creating a compatible renderer is not an easy task.

From posts he's made, it seems that Graf is confident that he can achieve this. Hopefully he's right. We will see.

[oasiz]

Tea Monster, on 03 February 2020 - 09:00 AM, said:

It dosen't though.

I am referring on keeping non-polymer stuff compatible, polymer to polymer surely has it's share of breakage but that wasn't my point.

It doesn't focus creating a franken-engine that doesn't really do some key duke/build things and is still inferior to simply using a more modern engine.
i.e. this was what something like PolymerNG was heading towards.
Polymer, despite all it's shortcomings is still (Nearly fully) compliant with the base feature set.

[axl]

i'm interested to see what he'll offer...

But right now, I can't really see the added value (for me that is). EDuke32, NBlood and the others already play smooth as hell and look pretty much exactly as the old dos versions.

[OpenMaw]

oasiz, on 03 February 2020 - 09:49 AM, said:

I am referring on keeping non-polymer stuff compatible, polymer to polymer surely has it's share of breakage but that wasn't my point.

It doesn't focus creating a franken-engine that doesn't really do some key duke/build things and is still inferior to simply using a more modern engine.
i.e. this was what something like PolymerNG was heading towards.
Polymer, despite all it's shortcomings is still (Nearly fully) compliant with the base feature set.

The point is that we already have a renderer to do that. Polymost, or the classic 8-bit renderer. Polymer is supposed to be the thing that takes Duke3D to the next level. It's broken. It's completely utterly fucked.

So yeah, if someone can come in and do a new version of this stuff and maybe light a fire up in this bitch, and get the community reinvigorated then so be it. That's what we want.

[Mark]

Every mod or TC I've been involved in since I started in 2010 has used Polymer. Broken,yes. Usable, yes. Frustrating at times, hell yes.
As far as using 3D models, a lot of critiques come from the animations. But now with easy access to high end anims with Mixamo and other programs, that limitation has been lessened.

I want Graf's new port to be a resounding feature filled success. But I will stubbornly stick to Eduke32 and Polymer. I don't want to stray from Mapster for editing. It took me 10 years to become a mediocre mapper in Mapster. I don't want to start over.

Attached File(s)

•  99999.png (108.38K)
  Number of downloads: 5

[The Battlelord]

Commando Nukem, on 03 February 2020 - 11:06 AM, said:

The point is that we already have a renderer to do that. Polymost, or the classic 8-bit renderer. Polymer is supposed to be the thing that takes Duke3D to the next level. It's broken. It's completely utterly fucked.

So yeah, if someone can come in and do a new version of this stuff and maybe light a fire up in this bitch, and get the community reinvigorated then so be it. That's what we want.

Yeah, when people in general will stop to think about things like "my hero and my community are bigger and better than yours" , often thinking like this:

Spoiler

Maybe a nice day we may end up to have a nice situation where people will respect each others and think more like "our heros vs demons, monsters and anything", like a dream team:

Spoiler

[Phredreeke]

No Caleb, I am disappoint.

[ReaperAA]

The official name of the port is "Raze" and its code is available on github now.

[oasiz]

Commando Nukem, on 03 February 2020 - 11:06 AM, said:

The point is that we already have a renderer to do that. Polymost, or the classic 8-bit renderer. Polymer is supposed to be the thing that takes Duke3D to the next level. It's broken. It's completely utterly fucked.

My point is that at least polymer got the base game right. It did take Duke to the next level but it didn't take it beyond.
Before you can go beyond, you need a foundation. Back during it's release it got so many things right to the point that polymost was considered obsolete, however the feature set was never finished and the potential simply fell flat. It was a huge improvement over polymost visually, it's in custom polymer-specific content where it starts to fall flat. It's not a renderer for going "beyond" and I think it's been proven enough times. Of course it had it's own share of issues with the base game as well depending on HW config but generally it worked quite well.

Look, I understand people are frustrated about it not going beyond but there is a very big importance on having a "build renderer" rather than a renderer that "sorta works with build"
Polymer tried to do the former but it never was completed. You can take shortcuts with the latter approach and get results but you end up with something that is more like a renderer that is looking to be a fork and not something compatible with build. My worry is that maps need to be able to be fully dynamic and support the key features, this is something that tends to be ignored and sacrificed just to get quick results. It's a huge uphill battle to get this working properly IMO. There are much better alternatives such as GZDoom itself if build specific quirks like lack of portal rendering and dynamic geometry are of no issue.

Polymer got the cake right, it juts lacked the cream and cherries. For base Duke3D back in 2009, the visuals did improve a lot, not to mention that it still has the best implementation of TROR. It's useless for anything else. Polymost has caught up quite a bit since.
Maybe I'm just irked when screenshots from doom get posted for reference.
These are all 3D euclidean BSP game worlds with static geometry with no portals, where you can simply do a lot more. Build is a completely different setup no matter how similar it looks on the surface.

All in all, I would really really like to see something to replace polymer outright, however many attempts have fallen flat throughout the years due to the unconventional feature set.
Can only really wish all the best for Graf, I hope to see something cool come out of this.

[Phredreeke]

Yeah, Polymer remedied a lot of Polymost shortcomings that have been resolved since then.

[Mark]

I'm no coder with inside information so my outsider perspective is that improvements likely could have been made to Polymer, but the people capable of making it happen disagreed on how to do it, got discouraged, so it didn't get done. Now its popularity has diminished so there is no longer any compelling reason to fix it. Too much effort for the 12 people that would use it.

[Phredreeke]

From Discord

Quote

terminx2019-11-30
Polymer is in kind of an unfortunate state
when we were exploring rendering options for the console ports of IF we talked about maybe reworking it into something usable but even Plagman said he'd probably just throw it out and redo it before trying to actually do something with it at this point

[Player Lin]

So, sounds like Polymer cannot be saved, even its dad probably doesn't want to save that mess, too bad.
But who know what will happens.

EDuke32 still a thing as Graf won't touch Polymer and suggests whoever want Polymer just stick on EDuke32(unless his new renderer finishs but that's long way to go) and Software(Classic) renderer will broken in his port, so he probably won't do things to the classic renderer.

[Radar]

He should include a "classic" rendering mode that flips the r_yshearing and r_shadeinterpolate flags in polymost accordingly. Calling it "classic" as opposed to "software" would not technically be a misleading term.

[oasiz]

Mark, on 04 February 2020 - 05:07 AM, said:

I'm no coder with inside information so my outsider perspective is that improvements likely could have been made to Polymer, but the people capable of making it happen disagreed on how to do it, got discouraged, so it didn't get done. Now its popularity has diminished so there is no longer any compelling reason to fix it. Too much effort for the 12 people that would use it.

There was PolymerNG but that was aiming to not keep compatibility and instead go it's own route. This would have resulted in an incompatible hybrid-approach that directly would break a lot of "what makes build, build" stuff without manual intervention.
It would have been incomplete as it was about to have a more naive approach to things like dynamic geometry. Sure it attempted to handle these as special cases (doors, quake, etc..) and have them still work but this would have likely broken anything that isn't strictly 1.5 duke stuff.
One of the headaches of build is that any wallpoint/sprite anywhere can move anywhere at any time, this basically forbids pre-computer visibility optimizations, a practice that is clear as day on pretty much every other engine.
NG seemed to aim for having this information pre-computed, it's just practically impossible, but the answer was instead to limit on what can be done.
If the simplification is not a big issue then build is very likely the wrong engine for your project as there are much better alternatives that not only can look pretty but are also extremely simple to work with (i.e. modern doom ports)

A fork was made, nothing stopped that, but this is not really something that should ever get merged to mainline as you'd have essentially a hard split on what works and what doesn't. This is where the disagreements came in.
Original Polymer despite all it's issues tried to at least keep the core game compatible from the get go instead of compromising, which puts us where we are today.

On the surface it might seem stupid bickering at each other and in a way it was, however a lot of it was done to make it clear that decision would need to change or it has to stay as a fork.

[oasiz]

Player Lin, on 04 February 2020 - 06:39 AM, said:

So, sounds like Polymer cannot be saved, even its dad probably doesn't want to save that mess, too bad.

Yes, this would need a rendering programmer to work on it and there has been nobody seriously to replace plagman. I don't think anyone in the current team is the right person to write one from scratch, let alone fixing a halfway implemented one. Pogo has been doing improvements on polymost however.

[axl]

I just tested Raze with Duke Nukem 3D. I gotta say : it feels very smooth.

[Player Lin]

axl, on 04 February 2020 - 07:32 AM, said:

I just tested Raze with Duke Nukem 3D. I gotta say : it feels very smooth.

It should, since most of low level things that caused some slow downs has been replaced.

[Fox]

Player Lin, on 04 February 2020 - 06:39 AM, said:

So, sounds like Polymer cannot be saved, even its dad probably doesn't want to save that mess, too bad.
But who know what will happens.

EDuke32 still a thing as Graf won't touch Polymer and suggests whoever want Polymer just stick on EDuke32(unless his new renderer finishs but that's long way to go) and Software(Classic) renderer will broken in his port, so he probably won't do things to the classic renderer.

It's understandable that he ditches the software renderer for a GL optimized project

Although there are some hacks he could try for Ion Fury skybox, the CON interface is already questionable on its own

[Kyanos]

I love how easily he dropped classic. Dead weight. Interested to see how it goes once polymost is out too, a true polygon based renderer will probably cause compatibility issues, but should handle the majority of the vanilla games ok, they didn't do anything too crazy like what I've seen with TROR exploits in polymer only maps.

[Radar]

It was expected considering GZDoom doesn't include the original software renderer either. Precisely why I use PrBoom+ instead.

[ReaperAA]

Radar 100 Watts, on 04 February 2020 - 12:22 PM, said:

It was expected considering GZDoom doesn't include the original software renderer either.

What are you saying? GZdoom has software render available.

[Phredreeke]

I suppose he's talking about some changes done to the way lighting is done in software renderer

[Radar]

ReaperAA, on 04 February 2020 - 12:35 PM, said:

What are you saying? GZdoom has software render available.

Graf Zahl said:

Any such code in ZDoom that got its life extended without addressing the fundamental problems it had eventually became unusable and had to be replaced in its entirety, the biggest offenders being the old menu code and the software renderer - where the latter one, despite the refactorings, still is very problematic because not everything could be properly cleaned up without breaking it. There's many other parts, too, which I cannot all list here, but there was a lot of code I have thrown out over the years and replaced it with something more modern.

Source