[HiPhish]

Hello guys

I've been playin in eDuke for quite a while now and it's a shame there is no such project for Shadow Warrior and Blood. For Blood the reason is obvious, there was no source code released, and for Shadow Warrior is appears no one has interest in starting to write a port from scratch. This made me wonder, how feasible would it be to add support for Shadow Warrior (and possibly Blood) and maybe other Build Engine games.

Now please hear me out, before you start mentally pre-typing a list of differences in Duke Nukem 3D and Shadow Warrior and why we can't just dump the data files from SW into eDuke32. I have recently discovred the Doom source port Doomsday Engine, and one cool feature is that they support other games using the Doom engine as well: Heretic, hexen, HacX and Chex Quest (yes, seriously):

http://dengine.net/games

Originally those were different ports, but they were merged into one application. The common parts were moved into the main engine and the game-specific parts are used as game modes (libdoom, libheretic, libhexen). This way the parts shared by all games need only to be implemented once. I have been playing Doom over the last couple of days and I am very impressed, both by the user interface and the simplicity, especially when it comes to installing and managing addons and settings. This is why I'm wondering if it would be possible for eDuke32 to copy the modularity of Doomsday or even make a new source port in its image (Duke's Day Engine?).

[Lunick]

Well, there is Erampage32 I believe Shadow Warrior has been looked into and will be worked on when one of the eduke32 team members have free time as well.

[HiPhish]

I forgot to mention another advantage of Doomsday: common quality control. The eRampage port doesn't seems as active or well supporte as eDuke32 and there are only Windows binaries. The same goes for the two Shadow Warrior ports. In Doomsday if the common parts get improved all games profit, so fans of Heretic don't have to fear that their favourite game will be just neglected because the mor popular game gets all the attention. Of course game specific tweaks still need to be made on a per-game basis, but it's good to know that as long as one game is alive and working the other ones well be as well.

[Micky C]

IIRC eRampage was very hacky almost more of an experiment to see if it could be done rather than a fully fledged supported port.

I'm sure something minor was done with Shadow Warrior at some point though? I remember a shot of SW using spotlights from the polymer renderer.

[Lunick]

plagman did a very stripped back version of eduke32 to make Shadow Warrior work with it and Polymer. I think it was just a proof of concept.

http://forums.duke4....g-with-polymer/

[HiPhish]

Yeah, I've seen the proof of concept, so I know it is at least technically possible. I was just wondering if the dev team would be willing to take the task; I would try it myself, but I am nowhere near competent enough to get anything useful done, at least not without a lot of help.

[zZaRDoZz]

HiPhish, on 18 September 2013 - 01:50 AM, said:

Hello guys



Now please hear me out, before you start mentally pre-typing a list of differences in Duke Nukem 3D and Shadow Warrior and why we can't just dump the data files from SW into eDuke32. I have recently discovred the Doom source port Doomsday Engine, and one cool feature is that they support other games using the Doom engine as well: Heretic, hexen, HacX and Chex Quest (yes, seriously):

It should be noted that Chex Quest, HacX, Heretic and Doom2 all use the same exact engine, with a few tiny differences in Heretic's implementation. I think Hexen had its own bsp. With Build most games used their own version of the Build engine, with Blood and SW getting fairly heavy changes over the original Duke.

[TerminX]

The main difference there is that with DOOM, it was both the engine and a fully working game, whereas with BUILD you just got the engine and a simple test game that showed how things worked. To compare with modern games, it's like the difference between licensing the source code to a full game based on UE3, or building your own game on the UDK.

[Tetsuo]

Why hasn't anyone mentioned the TCs that have been made lately for eduke32 such as Blood CM? That may be the best way to go... TCs. Unless I was dreaming even erampage has been turned into some kind of TC to run with the latest versions of eduke32.

However and this may just be me but I'm sure all build games have at least something in common that could be modularized and the differences be put into plugins?

Also, I too am a fan of doomsday... the multichannel audio still needs some work compared to what's in gzdoom but I like it otherwise and the audio quality is great especially with the high res audio packs.

[Hendricks266]

zZaRDoZz, on 19 September 2013 - 06:02 PM, said:

With Build most games used their own version of the Build engine, with Blood and SW getting fairly heavy changes over the original Duke.

This is incorrect. All BUILD game developers received the engine component as compiled object files. All extra effects such as the ROR found in SW, Blood, and RR were added on the game side as extensions. The engine side is fully portable between them.

The real issue with integration is that all of the menu systems and game logic were written independently. While a start-up selector like ZDoom is possible, unification of common menu code would take some work.

[HiPhish]

So it is possible then? Would you guys be willing to take the challenge then or would it require too much refactoring? I took a look at Eduke's source code, it's all pure C, and I never used non-object orientated programing, so I can't be of any help. I know that Doomsday was written in C, but they are currently in the process of switching to object-oriented C++.

Tetsuo, on 19 September 2013 - 07:21 PM, said:

Why hasn't anyone mentioned the TCs that have been made lately for eduke32 such as Blood CM? That may be the best way to go... TCs. Unless I was dreaming even erampage has been turned into some kind of TC to run with the latest versions of eduke32.

Yes, I know about BloodTC, but it is not the same. To create a TC someone has to sit down and recreate every level and game mechanic by hand and rip all the assets, so it seems to make more sense to just recreate the game mechanics and make eDuke compatible. The other problem is the legal side; would you devote hours, days, months or even years to recreating a game faithfully, only receive a threat of legal action fromt the rights holders? A port is 100% legal, but a TC is giving people a way to play a commercial game for free. Sure, Shadow Warrior, Redneck Rampage and Blood are old games, but they are still on sale and you never know when a company lawyer will feel the urge to prove his importance to his bosses by shutting down an innocent fan project.

[Micky C]

The eduke team are essentially too busy to do anything like that. There are a lot of very important features that have been stuck half finished for years.

[Hendricks266]

HiPhish, on 20 September 2013 - 10:48 AM, said:

So it is possible then?

It is both possible and planned, at least for SW because we have the source. RR and Blood will never happen without the source or proper reverse-engineering. If anyone on the team cares, someday we will add support for the four BUILD games to which Les Bird released his source code.

HiPhish, on 20 September 2013 - 10:48 AM, said:

I took a look at Eduke's source code, it's all pure C, and I never used non-object orientated programing, so I can't be of any help. I know that Doomsday was written in C, but they are currently in the process of switching to object-oriented C++.

Sounds like you only know what you've been taught in school. There is not much difference between object-oriented and procedural programming when it comes to adding features to existing data structures. It's just that classes allow you to make your own object types. EDuke32 as it stands can be compiled as C++, and we are planning to move away from C in order to take advantage of classes for networking and Polymer updates.

However, in terms of merging the games in, there would not be much to gain by refactoring into classes. It's hard to explain but object-orientation specifically would not help--it may end up making it more organized but the workload would not change. (One minor detail that I've read about is that object-oriented games can suffer from performance overhead due to excessive pointer dereferencing.)

[Jimmy]

zZaRDoZz, on 19 September 2013 - 06:02 PM, said:

It should be noted that Chex Quest, HacX, Heretic and Doom2 all use the same exact engine, with a few tiny differences in Heretic's implementation. I think Hexen had its own bsp. With Build most games used their own version of the Build engine, with Blood and SW getting fairly heavy changes over the original Duke.

HacX and Chex Quest were total conversions though. You can play them on the original EXE (with Dehacked patches) for christ's sake. And Heretic and HeXen and Doom2 all have had their source codes released, which makes things a lot easier. Strife is interesting though. It's source was lost, so everything had to be rewritten. Ports were only mostly complete for a long time, but it looks like Chocolate Doom finally has a feature complete and mostly bug-free port.

At this point, Blood and Redneck Rampage would need to be programmed 'by hand' like Strife unless someone releases their sources.

[HiPhish]

Hendricks266, on 20 September 2013 - 03:48 PM, said:

It is both possible and planned, at least for SW because we have the source. RR and Blood will never happen without the source or proper reverse-engineering. If anyone on the team cares, someday we will add support for the four BUILD games to which Les Bird released his source code.

To be honest, I wasn't really expecting Blood support, even though it would have been awesome. Reverse engineering projects usually end up in eternal pre-alpha, the only successful project I know of is Exult (Ultima VII) and even that one is stuck in eternal beta. OpenMW (Morrowind) looks like it will hit version 1.0 (complete replacement of the original engine) by the end of this year, but OpenMW is a real exception in team organization and dedication.

Hendricks266, on 20 September 2013 - 03:48 PM, said:

Sounds like you only know what you've been taught in school. There is not much difference between object-oriented and procedural programming when it comes to adding features to existing data structures. It's just that classes allow you to make your own object types. EDuke32 as it stands can be compiled as C++, and we are planning to move away from C in order to take advantage of classes for networking and Polymer updates.

However, in terms of merging the games in, there would not be much to gain by refactoring into classes. It's hard to explain but object-orientation specifically would not help--it may end up making it more organized but the workload would not change. (One minor detail that I've read about is that object-oriented games can suffer from performance overhead due to excessive pointer dereferencing.)

Yes, I know that OOP only changes how you organize your code, it doesn't magically make more things possible. And you're right, OOP is what i have been taught, i never worked in C. Originally I was tught Java, then I moved to C# for Unity, but i am also familiar with C++ and the things C# tends to do automagically, like pointers.

[leilei]

Doomsday's not a very good example. It started life as jHexen, then jDoom and jHeretic and was popular for being 'that GL engine with the automatic lens flares stuck to everything oooh so modern!'. Since the Doomsday merge it's been stagnant ever since for more than a decade, still not even with Boom standards and most of the updates have to do with the launcher than the engine itself.

I think a more crazy example than Doomsday/Zdoom is FTEQW. It's a Quakeworld engine, that was hacked to run Quake.... and then Hexen II, Quake 2, and even Quake III Arena, all without need of "TCs" or any conversion. A lot of the stuff was about consolidating rendering and network protocol code (though software rendering did get dropped).

I don't see why this isn't possible for Duke and SW.

[Jimmy]

It's not impossible. Someone just has to put in the time and effort.

[Mark]

I would be satisfied with someone finishing or continuing what was started with SWP and Erampage if a total re-make is not done.

[Hendricks266]

An EDuke32 SW is happening soon.

I haven't forgotten about maintaining SWP either. I thought I'd make my current state of progress public. I was trying to debug some problems but GDB was always reporting incorrect line numbers, so I stopped. Before I do anything else, there is a sea of mundane compiler warnings that need to be fixed.

[ReaperMan]

Hendricks266, on 28 December 2013 - 09:53 AM, said:

An EDuke32 SW is happening soon.

[HiPhish]

Cool. Is this going to be a separate program or will it be part of eDuke?

[Hendricks266]

Separate at first.

[Mark]

Are we to assume it will stay without Polymer for now?

ADDED: With newfound popularity, the masses will be asking for an updated editor too.

[Micky C]

Mapster32 can already be used to make SW maps can't it?

[Hendricks266]

Mark., on 28 December 2013 - 10:34 AM, said:

Are we to assume it will stay without Polymer for now?

Everything on the engine side (or in ENet, JFAudioLib, and JFMact) will be in this EDuke32-ified SW. That includes Polymer. However, voxels still need to be implemented.

Plain Simple Garek, on 28 December 2013 - 03:14 PM, said:

Mapster32 can already be used to make SW maps can't it?

Yes, SW's map format does not vary from the BUILD standard that Duke also stuck to, unlike Blood and TekWar.

However, SW has its own "bstub", that the game maker could use to customize key functions and things, that is distinct from Duke's, and there should be binaries available for this too.

[Mark]

Thats good news then. For some reason I thought that Mapster could read and write the maps fine but the sector effects were completely different. SW using ST's instead of SE's etc... I guess I've been smokin' the good stuff again.

added: I tried it out. I had to drag over DUKE.GRP for Mapster to run, and create a batch file so Mapster uses the contents of the SW.GRP

[Hendricks266]

The SEs are completely different, but they're still plain old sprites that take xvel, yvel, zvel, etc. as their inputs. Nothing Mapster32 can't handle, though alt-pals and some other SW-specific stuff won't preview perfectly.

[Jimmy]

I think SW has a different player perspective too. I seem to remember maps were of a slightly different scale than Duke.

[Hendricks266]

Yeah, SW's maps and sprites are larger.

[Hendricks266]

SWP 4.3.3 beta 1

Extract over a 4.3.2 installation.

Report any problems; report crashes with swp.crash.log.

This is just a maintenance release of SWP. A real EDuke32-engine port is still planned.

(source)