Duke4.net Forums: Duke Builder Unfinished Build - Duke4.net Forums

Jump to content

Hide message Show message
Welcome to the Duke4.net Forums!

Register an account now to get access to all board features. After you've registered and logged in, you'll be able to create topics, post replies, send and receive private messages, disable the viewing of ads and more!

  • 2 Pages +
  • 1
  • 2
  • You cannot start a new topic
  • You cannot reply to this topic

Duke Builder Unfinished Build

User is offline   Mark 

  • Honored Donor
  • 2,783

#31

 Hendricks266, on 05 January 2019 - 02:09 PM, said:

Instead of inventing your own explanations for why we took the positions we did, you should read the words we wrote explaining ourselves.


Nah, its not worth the effort to go searching through a ton of posts spread out over multiple threads and time periods. So in your version of things you never stated a concern that you would have to support whatever ICD came up with. What color is the sky in your world?

There, we each got in our snippy little comment. Lets move on.

This post has been edited by Mark: 05 January 2019 - 05:37 PM

0

User is offline   Hendricks266 

  • EDuke32 Senior Developer
  • 6,255

  #32

My concern was that he was going to make something not worth supporting, but still attracting ecosystem traction.
0

User is offline   Mark 

  • Honored Donor
  • 2,783

#33

At one time it was also a concern that things were not going to be 100 percent backward compatible and a new fork would be started. You were dead set against it because of not enough resources to maintain both. Hence my earlier statement about being against branching off. You had a legit reason, but you were against it.

This post has been edited by Mark: 05 January 2019 - 05:49 PM

0

User is offline   Tea Monster 

  • Polymancer
  • 2,080

#34

 Jimmy 100MPH, on 05 January 2019 - 11:28 AM, said:

Which is funny because when I tell TeaMonster this he calls me a Luddite.


I've called you loads of things, but never specifically a ludite. :duketease:

Pretty much all the modellers that contributed to either the HRP or general model-based mods have moved on to other things. Parkar, Killd a ton, etc. All gone.
There may be many reasons for this, including the failure of DNF and/or the problems with Polymer that were never addressed, I can't say.

Making stuff for Polymer can be a nightmare. You can't light a map properly due to the performance issues. On top of that, there are problems with the shaders on models in Polymer, so that getting something to look right in EDuke can be a long, drawn out process of trial and error with tweaking the def file and reloading the model. We ran into a LOT of that in the HHR mod. One of the things I wanted to do with HHR was to prove that you could make something model based that looked good, and lived up to the potential of what Polymer could be. At the end of the project I came to the conclusion that Polymer wasn't ready for this. It needs the optimisation to get proper lighting and it needs the shaders fixed so that what you see in creation tools is sort of what you get in EDuke. When we were making HHR, there were people from other sites or projects who I could invite to do a mod. On reflection, I couldn't in good conscience bring them in to do battle with all the issues that Polymer has.

I do some work on the DHMP over on the Doomsday engine. They don't have the complex lighting model of Polymer, but instead rely on cubemaps to provide lighting to models. But they look good and they have an in-game shader editor where you can tweak various aspects of how your model looks to simply get the right results in game. This makes creating content incredibly easy in comparison to Polymer. They also use a modern model format, FBX, which allows for a lot more scope in using more modern modelling and animation techniques. Modellers can concentrate on making models, not on fighting the engine to make things look like they should do.

One other very important factor: during the development of Doomsday's new renderer, the developers specifically reached out to the community content-creators and got them involved in the development of the new renderer. This never happened with Polymer or any of ICD's multiple attempts.

This post has been edited by Tea Monster: 05 January 2019 - 06:15 PM

1

User is offline   Tea Monster 

  • Polymancer
  • 2,080

#35

Sorry, I'm full of flu and didn't read back enough to grok the conversation.

I don't think that having a new editor would fracture the community. As long as the editor spits out the regular duke format maps, then great. The more the merrier. The problem is going to be supporting all of EDuke's new features like TRoR. . The community isn't very big at the moment and it's not growing as far as I know. Having some new, easier to use tools would probably be a good thing. The Trenchbroom level editor has allowed more people to get into Quake editing, which is a good thing. The question with this is, who is going to develop this new editor and are they going to stick the distance and stay with it? It has to be able to create maps that support the current source port, or there is no point.


This brings us back to EDuke and Polymer RTX. With Polymer, we had Plagman come in and code a new engine, then fly away, never to improve or maintain it. Having something cool looking is nice, until it breaks and nobody knows how to fix it. Assume that ICD had produced a new render branch that was incompatible with EDuke32's regular, pan-platform code. Who would maintain it? Who would fix it if something was found to be wrong? It would be abandonware. You'd have a small group of people who used that branch (as it would eventually not be supported by the main branch of EDuke32) till it eventually became completely out of date as tech moved on to the next shiny thing. It's much better to have a new renderer, if they bother making one, to be part and parcel of EDuke32, and be easily maintainable by the current dev team. I would personally prefer something that wasn't as advanced as Polymer, as long as it worked and was useable.

TLDR: Having loads of different tools is great - as long as they are supported and maintained. Having different, mutually exclusive branches of your source port when the community is so small - not so good.
4

User is offline   Forge 

  • 7,824

#36

Abandonment can happen to any port. Eduke & mapster are not immune.

Maybe one day Voidpoint will make it big - but they can't sell build engine based games forever. Eventually the market will dry up & they'll have to move on to other platforms. Eduke will become a hobby, then a time waster and nuisance as they work on things to make a living.
Could happen.

The more backwards compatible ports and tools, the merrier.
1

User is offline   Jimmy 100MPH 

  • Trooper
  • 4,280

#37

I've maintained for quite a while that EDuke32 really needs to abandon the idea of backwards compatibility because frankly the Duke Nukem 3D codebase is fucking retarded. (Thanks Todd!) I'm not even a programmer and I can see that. There's just too much bullshit to work around with little payoff. I don't think it's worth it to make sure something like Starship Troopers or Grins of Divinity works out the box, but much less something like the Gate! I'd rather see mods get patches to work with a newer port. There's already a ChocolateDuke port (which I haven't played, but I'd assume is better than say JFDuke3D.) I'd say it'd be fair if EDuke32 and ChocolateDuke or some kind of equivalent were the two main Duke3D ports. This is just my useless opinion, but whatever.

View PostTea Monster, on 05 January 2019 - 06:10 PM, said:

I've called you loads of things, but never specifically a ludite. :duketease:

lmao love you m8 :wub:

View PostTea Monster, on 05 January 2019 - 06:10 PM, said:

Pretty much all the modellers that contributed to either the HRP or general model-based mods have moved on to other things. Parkar, Killd a ton, etc. All gone.
There may be many reasons for this, including the failure of DNF and/or the problems with Polymer that were never addressed, I can't say.

Honestly, I'd say this is for the best because their efforts were largely a waste of their time, beyond excellent additions to their portfolios.

View PostTea Monster, on 05 January 2019 - 06:10 PM, said:

One other very important factor: during the development of Doomsday's new renderer, the developers specifically reached out to the community content-creators and got them involved in the development of the new renderer. This never happened with Polymer or any of ICD's multiple attempts.

This is just my opinion but I don't believe that Polymer or ICD's renderers were ever intended to be finished. They were "wow" projects.

View PostTea Monster, on 05 January 2019 - 06:10 PM, said:

It's much better to have a new renderer, if they bother making one, to be part and parcel of EDuke32, and be easily maintainable by the current dev team. I would personally prefer something that wasn't as advanced as Polymer, as long as it worked and was useable.

TLDR: Having loads of different tools is great - as long as they are supported and maintained. Having different, mutually exclusive branches of your source port when the community is so small - not so good.

FUCKING THIS. Classic and Polymost look better than they have in ages, but man they really looked like shit for a long time. We I just need want a decent renderer with moderate features, that can be completed and bugs maintained by mostly anyone.

Coke costs a lot of money you know. - oasiz
1

User is offline   Mark 

  • Honored Donor
  • 2,783

#38

Even if it dies a slow death after 6 months or a year I would like to see an ICD offshoot. Hopefully before it died it would get a number of bugs worked out and it could continue to be used for years to come. Hey...that kinda sounds like Polymer. ;) ( yes, I'm generalizing )

whisper ( build it and they will come ) :lol:

This post has been edited by Mark: 06 January 2019 - 06:06 AM

0

User is offline   Tea Monster 

  • Polymancer
  • 2,080

#39

View PostJimmy 100MPH, on 06 January 2019 - 12:08 AM, said:

I've maintained for quite a while that EDuke32 really needs to abandon the idea of backwards compatibility because frankly the Duke Nukem 3D codebase is fucking retarded. (Thanks Todd!) I'm not even a programmer and I can see that. There's just too much bullshit to work around with little payoff. I don't think it's worth it to make sure something like Starship Troopers or Grins of Divinity works out the box, but much less something like the Gate! I'd rather see mods get patches to work with a newer port. There's already a ChocolateDuke port (which I haven't played, but I'd assume is better than say JFDuke3D.) I'd say it'd be fair if EDuke32 and ChocolateDuke or some kind of equivalent were the two main Duke3D ports. This is just my useless opinion, but whatever.

Just an idea (didn't say it was a good one), but there have been revelations that maybe GBX aren't as rabidly anti-mod as we thought they were. If you really want to push the envelope and do something graphically advanced, then get Syndroid's Serious Sam TC to play with. Or maybe the community can start an Unreal based TC?

View PostJimmy 100MPH, on 06 January 2019 - 12:08 AM, said:

lmao love you m8 :wub:

People will talk!

View PostJimmy 100MPH, on 06 January 2019 - 12:08 AM, said:

Honestly, I'd say this is for the best because their efforts were largely a waste of their time, beyond excellent additions to their portfolios.

I disagree, but that's MHO. There are loads of problems with HRP, but I'd need a thread to itself to address them. There is some good work in there, but there was never an attempt to properly art-direct the thing.

View PostJimmy 100MPH, on 06 January 2019 - 12:08 AM, said:

This is just my opinion but I don't believe that Polymer or ICD's renderers were ever intended to be finished. They were "wow" projects.

I fully agree. I've seen this happen before with other soft, where someone codes a new renderer as a portfolio piece. They get a job with another company and disappear. Strangely enough, ICD was involved with a similar situation with Doom 3.

View PostJimmy 100MPH, on 06 January 2019 - 12:08 AM, said:

FUCKING THIS. Classic and Polymost look better than they have in ages, but man they really looked like shit for a long time. We I just need want a decent renderer with moderate features, that can be completed and bugs maintained by mostly anyone.

I've suggested that Hendrix talk to Skyjake on the Doomsday port to see if they can work on something like what Doomsday has. It isn't as advanced as Polymer, but it works.
1

User is offline   Forge 

  • 7,824

#40

View PostJimmy 100MPH, on 06 January 2019 - 12:08 AM, said:

I don't think it's worth it to make sure something like Starship Troopers or Grins of Divinity works out the box, but much less something like the Gate!

They don't work 'out of the box' now, with eduke.
But some tweaking and file manipulation can get them to play.
I'd be happy with that in a new port.
1

User is offline   Tea Monster 

  • Polymancer
  • 2,080

#41

At one point, the Devs of Doomsday we're considering including the ability to load Duke 3D levels. That would be interesting, especially now as they have working multiplayer.

Not saying that would be the best way forward, but it would certainly be interesting.
0

User is offline   oasiz 

  • 819

#42

Doomsday stuff.. sure, but Doom is BSP and is based on static geometry, something pretty much every engine since after doom has used. Build just isn't that. It hasn't been designed with 3D acceleration and geometry like that in mind at all, down to fine detail. Everything is dynamic and practically everything can change to anything at pretty much any point. You can literally tell a build map to go fuck himself and it will happily comply. :P
i.e. rotation is not a matter of "rotate sector as an object - offset N" instead it's about dragging geometry wallpoints in real time based on a formula, and other "effects" can theoretically append to this rotation.
That's the hard part, you can ease the task an incredible amount (including MP) if you remove/simplify all of this, but why even use Build at that point, you're essentially re-creating approximations of end results and many other engines kind of have more ready groundwork for such approaches.

I'd honestly be happy with some removal of legacy baggage but it's still a matter of finding that mythical someone to actually be interested and dedicated to do an alternative :P

Currently my bets are on pogo, he has a very good understanding of the internals and is working damn hard currently on improving many downsides of polymost and even software.
2

User is offline   Mark 

  • Honored Donor
  • 2,783

#43

I know almost nothing about renderers but I remember attempting to understand something from websites explaining ways of fixing z-fighting and transparency issues in OPENGL. There were multiples ways listed with general examples. I know a few attempts have been made by our guys to address the issues and had some success but with unwanted side affects. Has pogokeen made any headway in solving these issues once and for all? If it happens I will post a video of me doing a happy dance. ( with clothes on, sorry Jimmy )

This post has been edited by Mark: 06 January 2019 - 08:24 AM

0

User is offline   oasiz 

  • 819

#44

Transparency issues in GL are plaguing IM just as well. Too early to say anything about that. There are more critical things to take care of first.
0

User is offline   Jimmy 100MPH 

  • Trooper
  • 4,280

#45

View PostTea Monster, on 06 January 2019 - 06:22 AM, said:

I disagree, but that's MHO. There are loads of problems with HRP, but I'd need a thread to itself to address them. There is some good work in there, but there was never an attempt to properly art-direct the thing.

I think we're on the same page. It needs art direction, but also the aim of it as just an asset replacement is completely off. It needs programming as well.

Coke costs a lot of money you know. - oasiz
1

User is offline   oasiz 

  • 819

#46

HRP started as a cool package to add detail to polymost during an era where photorealistic stuff was hot and whole art direction in gaming was still kind of searching for itself again having survived 90s CGI multimedia era. You have some guys aiming for photorealism, some for stylized art (with varying results) and some painfully handcrafted stuff. Not too much later Polymer comes to the scene and suddenly you have a pack of models and assets not really meant for any sort of shaders and with prebaked directional shadows in some cases to make things look more "3D".
As much as I appreciate the effort (I was following very actively during "Enhancing Duke's spritely appearance" era) , it's a mishmash of different time periods, styles and goals, sort of unavoidable.

It doesn't help that you can utilize some Duke texture in more ways than there are kama sutra positions.
1

User is offline   Mark 

  • Honored Donor
  • 2,783

#47

Let us never forget the "Nitpicker War".
1

User is offline   Tea Monster 

  • Polymancer
  • 2,080

#48

I said to Nightfright that you really should split the pack into polymer and polymost sections.

If something new came along, you'd probably want to take the more modern stuff and use it as a base for a new pack.

This post has been edited by Tea Monster: 06 January 2019 - 10:51 AM

0

User is offline   Tea Monster 

  • Polymancer
  • 2,080

#49

If IM is a success, why not hire a coder for a short term contract just to fix a few things?
0

User is offline   oasiz 

  • 819

#50

Coke costs a lot of money you know.
4

Share this topic:


  • 2 Pages +
  • 1
  • 2
  • You cannot start a new topic
  • You cannot reply to this topic


All copyrights and trademarks are property of their respective owners. Instead of reading this text, you could be playing Ion Maiden! ;) © 2018 Voidpoint, LLC

Enter your sign in name and password


Sign in options