Duke4.net Forums: Graf Zahl Razes EDuke32 game code from his fork - Duke4.net Forums

Jump to content

  • 12 Pages +
  • 1
  • 2
  • 3
  • Last »
  • You cannot start a new topic
  • You cannot reply to this topic

Graf Zahl Razes EDuke32 game code from his fork

User is offline   Master O 

#1

I know it's old news by now, but what do you guys think about this?

https://forum.zdoom....hp?f=12&t=67139
0

User is offline   Zaxx 

  • Banned

#2

Nah, as far as I know this will be based on EDuke32 stuff and the point where it could benefit from the advantages of GZDoom is very far off. So "new Build Engine being developed" is entirely false but it could end up being "GZBuild" sometime in the future.

But here's how Graf Zahl put it when he was asked about the point of all this:

Quote

Why? Why not? I started with this because I had problems getting VSync to work properly in EDuke and because I wanted true color rendering back and a better music system than the Windows system MIDI synth. I tried BuildGDX but had other problems with that (e.g. the Java backend not recognizing all keys on my keyboard - and its VSync also did not work) From that I just went on, ending up changing more and more until I was able to plug the entire GZDoom backend into it.

You may ask the same question about the retro Doom ports. We already have PrBoom - do we really need Crispy and Retro? Apparently their developers have fun doing it. Shouldn't that be enough?


Anyway this will be interesting to see:

Quote

Actually, I ripped out all OpenGL code from Polymost, there is nothing left from the GL 1.1 code path and even less from the "modern GL" code path. This part is entirely new code, as is the texture manager. To be clear: There is not a single line of OpenGL accessing code left from EDuke. I also completely rewrote the shader it uses for rendering on modern hardware.


This post has been edited by Zaxx: 02 February 2020 - 07:35 AM

1

User is offline   NightFright 

  • The Truth is in here

#3

"New" is indeed misleading, it's just yet another Blood port. In general it's good the game gets so much attention these days, but 1) BloodGDX is already my port of choice and 2) I am missing love for Shadow Warrior.

This post has been edited by NightFright: 02 February 2020 - 07:38 AM

0

User is offline   Zaxx 

  • Banned

#4

Yeah, me too but it will have support for SW and Ion Fury too so it's coming (just like SW is coming to EDuke32) and apart from the Capstone games it will be a "complete Build package". Overall it's just cool that there are alternatives if you want to play some Build games and well, it's Graf Zahl so you know he'll do good work that can help the Build community in a number of ways.

This post has been edited by Zaxx: 02 February 2020 - 07:54 AM

0

User is offline   Master O 

#5

View PostRadar 100 Watts, on 02 February 2020 - 09:55 AM, said:

[CITATION NEEDED]


https://zdoom.org/downloads

https://github.com/c.../commits/master

This post has been edited by Master O: 02 February 2020 - 10:41 AM

2

User is offline   NightFright 

  • The Truth is in here

#6

We've been waiting for a port being able to handle all the important Build games for far too long, it's about time.

Stuff like Tek War can be ignored, Capstone games were nothing more like utter garbage, anyway. Civvie's Tek War video is all you need to watch. No coherent game design to be found there at all. But it was enough for a few good jokes about the most ridiculous aspects.

This post has been edited by NightFright: 02 February 2020 - 11:38 AM

1

User is offline   Fox 

  • Fraka kaka kaka kaka-kow!

#7

I'm looking forward to it.

Graf has way too much free time, and can do massive amounts of programming.

Quote

a better music system than the Windows system MIDI synth

He's not wrong, Eduke32 sound system sucks ass

(There have been some significant improvement in the sound area, but it's still based on the old code)
4

User is offline   NightFright 

  • The Truth is in here

#8

The real questions: Why is it done by HIM, with EDuke32 while he is a (G)ZDoom guy and only NOW?

This post has been edited by NightFright: 02 February 2020 - 01:28 PM

0

User is online   Phredreeke 

#9

View PostRadar 100 Watts, on 02 February 2020 - 01:09 PM, said:

You guys are aware he's just forking EDuke32 and its related projects, right?


He's using EDuke32 and related projects for the game code, and he's also using Polymost for generating level geometry which is passed onto his own OpenGL backend. I don't see why he wouldn't do the same for music playback.


View PostNightFright, on 02 February 2020 - 01:27 PM, said:

The real questions: Why is it done by HIM, with EDuke32 while he is a (G)ZDoom guy and only NOW?


My guess is EDuke32 removing the r_usetileshades CVAR was the final straw that pushed him to fork it
0

User is offline   NightFright 

  • The Truth is in here

#10

Main issue I have with this: A guy from the Doom community is beating us to it. Doesn't feel right...

This post has been edited by NightFright: 02 February 2020 - 01:43 PM

0

User is offline   Kyanos 

#11

Multiplayer?
0

User is online   Phredreeke 

#12

I don't get why people think this would solve the multiplayer issue when GZDoom itself needs its own fork for it...
3

User is offline   Zaxx 

  • Banned

#13

View PostRadar 100 Watts, on 02 February 2020 - 01:36 PM, said:

Why doesn't he offer his contributions as an addition to EDuke32?

Guess because he's adding stuff from GZDoom and he's making alterations that wouldn't sit well with EDuke32's current state. For example I quoted that he ripped out all the old OpenGL stuff which is great but it also comes with issues regarding compatibility with older hardware, it may even have a performance cost. GZDoom doesn't really run on toasters anymore, it needs slightly newer hardware than it used to as newer stuff is implemented.

Anyway I'm just happy he's doing it because GZ is an incredibly experienced programmer who has a lot of issues with Build so chances are that through his different perspective he can find different or better solutions to certain problems Build ports can have. We'll see what comes out of it, hopefully he won't fail like Kaiser failed with Blood lately.

This post has been edited by Zaxx: 02 February 2020 - 02:45 PM

1

User is offline   Kyanos 

#14

View PostPhredreeke, on 02 February 2020 - 02:35 PM, said:

I don't get why people think this would solve the multiplayer issue when GZDoom itself needs its own fork for it...

I'm completely ignorant about doom ports, so I asked.
Has GZ mentioned multiplayer build at all?

nevermind i found a quote

Quote

I'll be honest here: Unless someone else is helping out here, I won't be able to maintain the multiplayer/networking side. That'd completely bog me down and leave no room for the things I'm really interested in, like working on the renderer.


This post has been edited by Photonic: 02 February 2020 - 02:58 PM

0

User is offline   Hank 

#15

To OP - best wishes to him. We'll simply have to wait and see what he can bring to the table.
He has not beaten anyone to anything. EDuke32 is fucking complicated to work with.

This post has been edited by Hank: 02 February 2020 - 03:02 PM

2

User is offline   Jimmy 

  • 1776 World Wide

#16

Yeah this is much ado about nothing.
2

#17

I concur that as of yet, this is a nothingburger. The impression I've gotten from sometimes looking at the development board whenever getting a mod for ZDoom, is that Graf has short bursts of brilliance in-between disappearing for months or arguing with people over slights real and imagined.

Of course, I don't really notice these kinds of things to begin with, so I'm probably not the target audience for a different port. Unless he adds something like Decorate to Build. Would that even be necessary? I'm not sure how difficult it is for someone to add new weapons and enemies into Build...
1

User is offline   Tea Monster 

  • Polymancer

#18

New eyes, new mind applied to problems. It's not going to be a straight 'rip' of EDuke or Polymost from what he's said.

He may just fix some things that the EDuke32 devs haven't got round to. The more the merrier.

Even if all he does is replace the rather busted Polymer with GZDooms PBR renderer, it will be well worth it.

This is some work that a guy called Arl did using just sprites with normal/roughness maps.

https://i.imgur.com/4ObnSDA.png
3

User is offline   Zaxx 

  • Banned

#19

View PostRadar 100 Watts, on 02 February 2020 - 07:03 PM, said:

So imo the scope of this fork is not clear.

I think that if you read through the full thread then the scope becomes clear but it's early days, this won't mature into a good port in a week and if you look at the "teaser" it's clear there are still lots of problems to solve.
0

User is offline   Fox 

  • Fraka kaka kaka kaka-kow!

#20

View PostNightFright, on 02 February 2020 - 01:42 PM, said:

Main issue I have with this: A guy from the Doom community is beating us to it. Doesn't feel right...

That would be really underestimating the amount of work necessary.
3

User is offline   NightFright 

  • The Truth is in here

#21

Guess it's time to wait for the result. In the end it doesn't really matter who's doing it if it's done right.
1

User is offline   Zaxx 

  • Banned

#22

View PostNightFright, on 03 February 2020 - 03:01 AM, said:

Guess it's time to wait for the result. In the end it doesn't really matter who's doing it if it's done right.

What's "it" though? I mean this is not really a port that we need (though if Doom Builder would be compatible with Build as a result...): EDuke32 doesn't have serious issues (bugfixes, optimization and "future proofing" are the stuff that should be in focus now, other than that the port is great, it's done), BuildGDX and NBlood is getting more and more mature, etc. These days this is one of the biggest problems I have with EDuke32 and stuff like this is hardly game breaking:

So cool, a new port is being worked on with the potential of some new features and improvements but none of those will be game changers. The way I see it this "GZBuild" could be a good alternative for people who want something other than the "Crispy Duke" approach of EDuke32: less vanilla, more of a rendering powerhouse.
0

User is offline   oasiz 

  • Dr. Effector

#23

View PostTea Monster, on 02 February 2020 - 11:23 PM, said:

New eyes, new mind applied to problems. It's not going to be a straight 'rip' of EDuke or Polymost from what he's said.

He may just fix some things that the EDuke32 devs haven't got round to. The more the merrier.

Even if all he does is replace the rather busted Polymer with GZDooms PBR renderer, it will be well worth it.

This is some work that a guy called Arl did using just sprites with normal/roughness maps.



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.

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

User is offline   Micky C 

  • Honored Donor

#24

I'm not sure how much you've read up on this, but it sounds like he's using polymost to generate the geometry, and then separate code to do the actual drawing. Whether it works perfectly or not remains to be seen, but he's not making a renderer from scratch at least.
1

User is offline   Zaxx 

  • Banned

#25

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

User is offline   ReaperAA 

#26

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

User is offline   Zaxx 

  • Banned

#27

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

User is offline   Mark 

#28

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

User is offline   Zaxx 

  • Banned

#29

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.

This post has been edited by Zaxx: 03 February 2020 - 06:23 AM

0

User is online   Phredreeke 

#30

View PostZaxx, 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.
0

Share this topic:


  • 12 Pages +
  • 1
  • 2
  • 3
  • 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