Can a GZDoom-like engine be made for Build games?

[Graf Zahl]

You have to replace P_XYMovement and P_ZMovement and obviously not call things like P_TryMove and instead replace that and its subfunctions P_CheckPosition, PIT_CheckThing and PIT_CheckLine as well - plus P_SlideMove and a few other things. And very obviously it needs to be a mod option because it would break quite a few maps out there.

It's quite a bit of code that's involved here.

[SanyaWaffles]

I was definitely gonna say it needs to be a gameinfo option.

If only I was that good at C/C++ I'd try to undertake this. It could be great potential.

[Phredreeke]

M210 announced the other day that he has begun porting Powerslave/Exhumed to BuildGDX.

This would be the sixth game to be added (counting the Redneck Rampage series as one game)

[Graf Zahl]

So, no NAM or WW2GI? Or are they in the pipeline for later?

[Kinsie]

So, no NAM or WW2GI? Or are they in the pipeline for later?

There's header graphics in the JAR file for NAM and WWII (and Shadow Warrior, and Extreme Paintbrawl, and Legend of the 7 Paladins...), so they're definitely on the docket for the future.

[Phredreeke]

Right, I forgot about NAM. My understanding is it already runs that (but not WWII GI) through its Duke port.

[Dynamo]

Apologies for the bump, but since I found this thread interesting and it has been going on for a while, probably to be picked up again soon, although Jblade already mentioned this, since there are many people saying that there are no large scale duke3d/eduke32 projects being made, this is simply false: All you have to do is look at a project like AMC which is absolutely massive in scope, in fact it's probably the largest project in development for a classic FPS game:



And this is just one of several, there are others like Alien Armageddon or WGRealms or Imperium which make heavy use of new modding features and offer a lot of content. Obviously the community is nowhere near as big as doom's, but when it comes to gzdoom itself, there are not *that* many levelpacks built specifically for it (I for one am working on one such thing, but most projects like eviternity or BTSX are not built for gzdoom, as is known), so the amount of projects being worked on for eduke is not as minuscole as it may seem, comparatively speaking.

Either way, looking into the code and discussing these things can only help in getting a better understanding of both engines, and I'm glad to see Powerslave on BuildGDX will soon be a thing

[Graf Zahl]

What I am currently looking for is an actually working Shadow Warrior port whose source is in a compilable state. No matter what I tried, everything I found either needs outdated build systems and/or libraries or crashes right after building/starting a game. I haven't managed to get anything working in Visual Studio so far.

Does such a thing even exist? It's a bit weird that all the other Build games got some working support, except this one.

[MartinHowe]

This is Windows only (though it does work in WINE), old, and is in maintainance mode only:

https://github.com/Hendricks266/SWP

It still has a few crashes now and then. I managed to stop some of the worst ones, but no longer have any time to work on it and would need to learn a lot more about the Build engine than I do. Meanwhile, the EDuke32 team, as we all know, has its own priorities.

@Graf Zahl: You're a much more experienced coder than I so you may be able to do more with it.

[Graf Zahl]

What's the dependencies this needs? It doesn't have a MSVC project so I can't tell for sure how it works on Windows. So far I haven't managed to get it compiled.

[Kinsie]

It's worth noting that all the Shadow Warrior ports out there at the moment are based off the original source code release from 2005, which was a patched up copy of an incomplete archive of pre-release source code, and as such was just a little bit rough in some regards (saving and loading was unstable, and multiplayer in general was utterly trashed). Earlier this year the sources to the retail builds were salvaged via a combination of spelunking and reverse-engineering. They're still MS-DOS code, but they may be useful.

[Graf Zahl]

That's indeed helpful. I wasn't aware that the source was in such a bad shape overall, although it appeared quite rough - even compared to Duke Nukem .
Although the biggest problem at the moment is that the code is not 64 bit compatible. I can compile SWP as 32 bit but as 64 bit it spills an excessive amount of pointer truncation warnings, no need even trying to start it. Ken Silverman must have been insane when he decided to store pointers in ints, as this makes the entire backend in that port unuable and unfortunately this interface filters up to the game frontend as well. Making the engine 64 bit compatible must have been a hell of a task for the EDuke team, considering what a hack job it was.

EDIT: After looking through that code, the differences are actually minor but it definitely helps detecting some of the hacks SWP added (is there actually a Build port out there that does NOT resort to hacks when trying to add features? ). What was interesting is the original save code. Sigh, what a hack job. Sometimes I really wonder why some programmers totally fail to think ahead when writing something. That part was classic fire-and-forget style, no thought was invested in maybe - just maybe - having to recompile the code with a different compiler a few years later...

[Darkcrafter]

I just think nobody was aware that people will be playing this game more than 20 years after its release, so they decided not to push themselves up to writing a perfect code? By the way, Duke Nukem 3D is a very error prone thing, so they just released what worked back then and that was their agony, because time of 2.5d engines was already over in 1996, as quake outcasted everything. So they had to rush in order to sell at least something. Duke Nukem 3D is a great game, but the engine is so unfriendly towards mods and map making so, they just pushed the product that was already dead.

[Graf Zahl]

Sounds reasonable. But what the Shadow Warrior developers did is in a class all of its own - they used symbol files from the compiler to collect the addresses of savegame storable data. That's so utterly gross that I really have to question their motivation. It would have been easier to do this properly with an index table that gets compiled with the rest of the code.

[irukanjji]

There is Shadow Warrior ICED Port by ReaperAA

Powered by EDuke32 20170605-6143
Supports Shadow Warrior 1.2, Wanton Destruction, and Twin Dragon.
Has LUA scripting support. A lot of moddable attributes are exposed to LUA and the game now has a new lua script ST1 tag, so you can script your own level events!
Editor(aka SW Mapster) is now built into the game exe! SW Mapster is a modified version of Duke3D mapster. All the great features in Duke3D mapster work just fine in SW Mapster. So if you know how to make Duke3D maps, you should have easy time creating SW maps!.

Basic peer to peer multiplayer support. There are a lot of bugs with it, stay tuned as we fix them up!

Polymer, Polymost and Classic renderer support.

Support for HRP created content.

https://crozzbreed23.wixsite.com/icedsw/sw-iced-port

builds:
https://www.mediafire.com/folder/i1s9g3jbeh9y3/