Raze officially revealed!

[mjr4077au]

That commit will be one hell to port, though, because I have done some massive changes to that piece of code myself and merging that together will not be easy. So definitely not in the first release - if I wanted to merge that I'd have to postpone the release.

What precisely did that code improve? His commit message was a bit unclear and I haven't been able to check it out.

When you play the game without vsync, even with a framerate cap of 60fps, there's zero discernable input lag. To me it pretty much plays as well as any other SDL game like GZDoom, Yamagi Quake II etc. With vsync on, you can definitely tell but it's still significantly better. GZDoom has the finest vsync implementation I think I've seen in any game, even at 60Hz.

There's another commit where he changes the vsync mode from glFlush to glFinish. I don't know enough about the API to say whether that's better or worse.

[Redneckerz]

I'm interested to see how this plays out within the community, I can see this becoming the de-facto standard but I'm worried some of the original devs might adopt a "Bernie or Bust" attitude and not be supportive. Hoping for the best though, I think some of your comments have hit nerves but since you're producing solutions and its no longer talk, I'm hoping for a much warmer reception.

That's definitely the sentiment i am getting aswell. Graf is definitely critical of the original Build code - At appropiate times, and sometimes not. But that's what it is - Criticism towards the original Build code. As it stands - Terminx and Hendricks have a clear view on this project for now, and a lot of personal investment in it to go along.

However, i do firmly believe that if the clear advantages are presented without scrupules (Which AFAIK is Graf's intention anyway) curiosity will turn into attention.

As they say - the world is holding its breath in.

That commit will be one hell to port, though, because I have done some massive changes to that piece of code myself and merging that together will not be easy. So definitely not in the first release - if I wanted to merge that I'd have to postpone the release.

What precisely did that code improve? His commit message was a bit unclear and I haven't been able to check it out.

I recall Terminx referenced this on the discord a few days ago, but i'd have to check first. From what i recall it had to do with how game logic functions.

[mjr4077au]

That's definitely the sentiment i am getting aswell. Graf is definitely critical of the original Build code - At appropiate times, and sometimes not. But that's what it is - Criticism towards the original Build code. As it stands - Terminx and Hendricks have a clear view on this project for now, and a lot of personal investment in it to go along.

The difference is Graf has been programming professionally since 1994 (when I was only 4 years old ), whereas I think the EDuke32 guys are more hobbyists and tinkerers. That explains the bolt-ons without the true fixes that I think are widely accepted as necessary (refactoring of code, etc).

The worst thing they've done which I hate is that they didn't fork the Duke3D code for Ion Fury, and I think they've kind of fucked it to make Ion Fury what they wanted to be. The clipping still isn't right for Duke 3D, etc. I think the idea was use the Duke 3D code so that fixes can be applied to both, but it just hasn't worked.

I know all the other build games that aren't based on Duke 3D code will be impossible to merge as one, but it would be nice for games like NAM, WW2GI, Redneck Rampage etc (all the Duke 3D-based games) to be one single game source, similar to Doom, Hexen, Heretic, etc. I'm not sure how feasable that is in time and whether these games have other quirks that make such a merger impossible.

[Graf Zahl]

There's another commit where he changes the vsync mode from glFlush to glFinish. I don't know enough about the API to say whether that's better or worse.

That very much depends on the hardware. If you are lucky it helps, but it can easily cause the frame rate to drop from 60 to 30 if done at the wrong time. But it's not the reason why EDuke has such VSync problems - at least not on my system. Simply put: They are doctoring around in the wrong place.
When I was analyzing the problem I got nowhere until I realized something: The VSync problems tended to get worse when more textures were created - which ultimately led me to the comclusion that on modern hardware the performance of legacy texture code can be really bad. Refactoring it to use modern features made the VSync problems completely go away for me in the Polymost renderer and so far all testers have confirmed that.

[mjr4077au]

There's another commit where he changes the vsync mode from glFlush to glFinish. I don't know enough about the API to say whether that's better or worse.

That very much depends on the hardware. If you are lucky it helps, but it can easily cause the frame rate to drop from 60 to 30 if done at the wrong time. But it's not the reason why EDuke has such VSync problems - at least not on my system. Simply put: They are doctoring around in the wrong place.
When I was analyzing the problem I got nowhere until I realized something: The VSync problems tended to get worse when more textures were created - which ultimately led me to the comclusion that on modern hardware the performance of legacy texture code can be really bad. Refactoring it to use modern features made the VSync problems completely go away for me in the Polymost renderer and so far all testers have confirmed that.

That sounds great! I like to play it with skyboxes that Fox made here and as gorgeous as they look, the amount of weird stuttering etc that they cause makes them not worth it.

[Graf Zahl]

I know all the other build games that aren't based on Duke 3D code will be impossible to merge, but it would be nice for games like NAM, WW2GI, Redneck Rampage etc to be one single game source, similar to Doom, Hexen, Heretic, etc. I'm not sure how feasable that is in time and whether these games have other quirks that make such a merger impossible.

Agreed here, unfortunately Nuke.YKT's efforts with porting Redneck Rampage sort of undermined that goal because he gutted the engine to enable demo compatiblity. So now we have two ports that are identical for large parts but have other elements that are bound to cause problems with merging. I'm also not quite certain if there won't be clashes with the scripting because both code bases uses certain values for different things.

What I don't see as a realistic effort is trying to make an engine that has all features available for modding at the same time - the way some things were implemented by the later games make it extremely hard to do this cleanly. With the Doom engine games things were a lot better separated, so it wasn't necessary to litter the entire code with "if (game_1)..." "if (game_2)..." checks.
Even in the best case scenario this will be a HUGE amount of work.

[mjr4077au]

Agreed here, unfortunately Nuke.YKT's efforts with porting Redneck Rampage sort of undermined that goal because he gutted the engine to enable demo compatiblity. So now we have two ports that are identical for large parts but have other elements that are bound to cause problems with merging. I'm also not quite certain if there won't be clashes with the scripting. Some constant values are clashing and with that tendency of scripts using literal numbers this must be handled very carefully.

What I don't see as a realistic effort is trying to make an engine that has all features available for modding at the same time - the way some things were implemented by the later games make it extremely hard to do this cleanly. With the Doom engine games things were a lot better separated, so it wasn't necessary to litter the entire code with "if (game_1)..." "if (game_2)..." checks.

As much as I love the nostalgic feel of the demos, they absolutely should not hold back progress. With every new release of Doom and Duke3D, they had to redo the demos anyway, so I don't know why people get so hung up on it?

I definitely think the availability of the game features in a singular function is a pipe dream. They're all fragmented in their implementation because no one had any idea what the engine was doing, they just received the object module and were left to their own devices. *If* that was to be a consideration, it'd definitely be the lastthing on the list. If considered though, perhaps instead of if or switch statements to select the compatible function, perhaps reimplement the particular function right and fix the games with maphacks?

[Graf Zahl]

As much as I love the nostalgic feel of the demos, they absolutely should not hold back progress. With every new release of Doom and Duke3D, they had to redo the demos anyway, so I don't know why people get so hung up on it?

Don't ask me. But you have noticed yourself how important this seems to be - important enough to feature reduce the engine to its base set before adding the new game... ?

I definitely think the availability of the game features in a singular function is a pipe dream. They're all fragmented in their implementation because no one had any idea what the engine was doing, they just received the object module and were left to their own devices. *If* that was to be a consideration, it'd definitely be the lastthing on the list. If considered though, perhaps instead of if or switch statements to select the compatible function, perhaps reimplement the particular function right and fix the games with maphacks?

In this case it's not the underlying engine but the design characteristics of Duke Nukem. Both Blood and Shadow Warrior have an actor system that logically resembles Doom's, i.e. you got actors that can be in different states. States are tables of data. Merging two games based on such an architecture would be doable, provided you keep the data separate - unfortunately there's no two Build games based on the same engine working like this so there's nothing to merge.
Duke Nukem's game code is an entirely different beast. Instead of data tables there's some huge functions with switch/case blocks checking all states for all actors in the same function - rinse and repeat for sectors and walls. And now we have 5 games - 6 if you count Ion Fury - reusing all the same numbers and making subtle changes to some of the existing code - that all needs to be handled in a compatible fashion. No, this is not pretty...

[mjr4077au]

If people want demos, there's Chocolate Duke 3D for that, and for me personally if I want that nostalgic feel, I'll fire up my old Pentium MMX. I play source ports for the improvements they provide, so much so that on my retro PCs, I have zero interest in playing doom on it.

Is the lack of data tables because the original source was C and not C++?

[Graf Zahl]

No, just some badly structured code. Doom was also C, and so were the other Build games but their code base was magnitudes better organized.

[mjr4077au]

Thanks, I appreciate all the insight

[Gammli]

I'm interested to see how this plays out within the community, I can see this becoming the de-facto standard but I'm worried some of the original devs might adopt a "Bernie or Bust" attitude and not be supportive. Hoping for the best though, I think some of your comments have hit nerves but since you're producing solutions and its no longer talk, I'm hoping for a much warmer reception.

One thing's for sure, comments such as this:

The difference is Graf has been programming professionally since 1994 (when I was only 4 years old ), whereas I think the EDuke32 guys are more hobbyists and tinkerers.

Are not making a good impression.

The worst thing they've done which I hate is that they didn't fork the Duke3D code for Ion Fury, and I think they've kind of fucked it to make Ion Fury what they wanted to be. The clipping still isn't right for Duke 3D, etc. I think the idea was use the Duke 3D code so that fixes can be applied to both, but it just hasn't worked.

Often stated but factually wrong:

But when it comes to the collision (like in this case), it actually broke fury even more than it did for duke
There were months where you could even barely work around without getting randomly killed/stuck, ladders did not work at all, etc..
Not knowing the full story it's easy to say that this was done with Fury only in mind but it wasn't. I would say that Fury had much more issues than Duke did, it took months of workarounds from mappers/scripts to make things work again. Things were actually quite broken until the last weeks if I'm being honest.

Clipping was changed because it was on the roadmap even without Fury. Besides, clipping issues are actively being solved as development continues.

[Phredreeke]

Agreed here, unfortunately Nuke.YKT's efforts with porting Redneck Rampage sort of undermined that goal because he gutted the engine to enable demo compatiblity. So now we have two ports that are identical for large parts but have other elements that are bound to cause problems with merging. I'm also not quite certain if there won't be clashes with the scripting because both code bases uses certain values for different things.

I suspect it was that he needed something closer to vanilla Duke to graft the reverse engineered differences from RR onto, and demo compatibility just being a happy accident.

[mjr4077au]

One thing's for sure, comments such as this:

The difference is Graf has been programming professionally since 1994 (when I was only 4 years old ), whereas I think the EDuke32 guys are more hobbyists and tinkerers.

Are not making a good impression.

Neither does having this comment misrepresented on discord, either. There's a big difference in my comment vs. "The EDuke32 devs are only hobbyists / tinkerers" which is how it was paraphrased. The paraphrased version comes across as derogatory when that was never the intention at all.

I'll be extremely conscientious of my commentary as I don't want this thread shut down or turned into a shit show, no one really does. This is all towards the good of the community who love and appreciate the game they've played as a kid and I love seeing the continued improvement for this game, be it from SVN nighties for EDuke32, or code such as what's forthcoming.

[mjr4077au]

Agreed here, unfortunately Nuke.YKT's efforts with porting Redneck Rampage sort of undermined that goal because he gutted the engine to enable demo compatiblity. So now we have two ports that are identical for large parts but have other elements that are bound to cause problems with merging. I'm also not quite certain if there won't be clashes with the scripting because both code bases uses certain values for different things.

I suspect it was that he needed something closer to vanilla Duke to graft the reverse engineered differences from RR onto, and demo compatibility just being a happy accident.

I think its intentional, which is fine if that that's his desire: https://github.com/nukeykt/NBlood/commit/3326c457b5ec09b7243f0332dfa1c76ca9622b43