Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
Grimm

Everybody Come Together

Recommended Posts

Something I've noticed from my limited experience with source ports, mainly from what I read here, is that some ports have really cool things that others don't. For example, EDGE apparently lets you make new creatures from scratch (thus allowing endless amounts), Boom and/or Marine's Best Friend have friendly monsters, jDoom apparently looks awesome, and ZDoom has scripting, which others mave or may not have. So . . . when the HELL are all these kickin' features gonna get thrown into one port to create the ULTIMATE version of Doom?!?!?!?!?!?!?! Something that's kept me back from source ports for so long is the lack of continuity between them (like the apparent Hell that get's raised when you start throwin' OpenGL ports in [whatever they are]), and sometimes, the seeming lack of a communtity effort to make the best version of Doom we can. I realize this is harder than it sounds, but come on, the authors made 'em in the first place, didn't they?

Share this post


Link to post
RTDscout said:

...lack of a communtity effort...

Lack of community effort? If it weren't for community effort, we wouldnt have source ports to begin with. I think there's plenty of community effort.

making a source port = lots of work for no money

Be thankful that we have any ports at all :)
In all seriousness, if your really intent on this "Ultimate Port", why dont you program it yourself?

Share this post


Link to post
Assmaster said:

Lack of community effort? If it weren't for community effort, we wouldnt have source ports to begin with. I think there's plenty of community effort.

making a source port = lots of work for no money

Be thankful that we have any ports at all :)




In a way he's right. What annoys me most is that apparently each developer team is doing their own thing. There is a community of people who play Doom but not one of people who are programming for it. Imagine what could be if all those guys worked together to create the ultimate source port. But it is obvious that that will never happen. The goals of the various teams are just too different. If at least everybody could agree on Boom as minimum specs it would help a lot. But even such a simple thing isn't possible and that is telling a lot.

Share this post


Link to post

That just proves my point. These developer dudes need to converge, or, if nothing else, at least someone should combine 'em.

If I knew how to program, I would put 'em all together.

Share this post


Link to post

* myk hears the echoes of Lee Killough's whispering voice...

Share this post


Link to post
RTDscout said:

if nothing else, at least someone should combine 'em.


Believe me, that is much easier said than done. (I tried and failed miserably) Nobody can keep up with all the developments going on. Besides, some source ports are so different that combining them is impossible. I quess we have to live with the current engine chaos. But frankly, what is there besides Boom and ZDoom. There are a handful of Legacy WADs, most of them mediocre to bad with only one excellent one (Nimrod) and I can't find anything good for EDGE and Vavoom. For the vast majority of the rest ZDoom works fine with only a few having compatibility problems.

Since Randy has fixed all of the really annoying anomalies in ZDoom I am using this for nearly everything I play. Currently I see no need to keep another source port around, except Legacy for Nimrod, of course, but that's it.

Share this post


Link to post

I find it interesting that this exact same topic comes up in a thread every few months.

As a source port author, I can tell you that the goal of a unified, super-port will never be attained. There are several reasons for this:

1. Compatibility of vision. Some source ports have drastically different goals in their development. zdoom's aim, from my perspective, seems to be to become a strong, general 3D game engine that uses a lot of modern technology to go beyond the borders of DOOM. My own port's goal is different. In Eternity I want to enhance DOOM, but not go too far beyond. I work with what's there, and my main focus (although by no means exclusive) is on editing features. Some ports, like JDOOM, focus almost 100% on graphics, and others, like zdaemon and Skulltag, focus almost entirely on multiplayer. Its very difficult to meld together people and projects with different and sometimes opposing goals.

2. Ego. Most source port authors have a bit of ego, and even I may fall into this trap sometimes. You're doing what you want and what you think is cool, and you're not willing to compromise that vision to include those of others.

3. Practicality. In my Software Engineering class, we learned an important rule of thumb, 7 plus or minus 3 -- the approximate maximum number of people that can be on an optimally functioning team. If all of the source port authors in the DOOM community DID manage to come together and attempt to collaborate on a uber-port, it would be, with NO doubt in my mind, the most unstable, hacked-up, self-conflicting abomination ever created, simply due to difficulties in communication (let alone outright conflict -- see above point again :P).

4. Semantics. As was noted in the posts above, DOOM source ports have grown apart dramatically. If I want to reference some of Randy's code from zdoom and try using it in Eternity, I have to basically rewrite half of it myself in order to fit it into my own framework. Besides being in a different language now, zdoom's functionality is accomplished in very different ways, even where the end results are the same. So, it is not a matter of simply throwing together modules from different source ports and praying they work. Remember, they made the Therac-25 radiotherapy machine that way, and it fried a bunch of people to death...

So, there's my 4 reasons the "uber-port" is a pipe dream. I should say, in closing, that I DO wish that there could be more cooperation amongst the ports, especially when it comes to map format extensions. This almost became a reality with the JDS, but that group lacked both the reach and the true resolve to carry on with its functionality. Since then, the only efforts toward consolidation have been voluntary and isolated. I'm afraid its the best we're going to get.

Share this post


Link to post

The fact that almost every modern port has either inherited or incorporated Boom compatability could mean that something similar will happen again in the future, but it's unlikely.

Then again, there are at four current ports that have ZDoom features - ZDoom itself, ZDoomGL, ZDaemon, and Skulltag - and at least two more in the works.

Share this post


Link to post

Some of the BOOM feature extensions I've introduced in Eternity would be simple to add into other BOOM based ports, and probably even into zdoom with a little more work. prboom has adopted some of my features, including the HELPER, SPRITES, SOUNDS, and MUSIC blocks for BEX files. I'd LOVE to see more ports pick up those editing features to make them standard in some sense, but I'm not holding my breath :(

In the meanwhile, I have been adopting a few zdoom features too. Particle fountains use the same mapthings in both of our ports, and in fact, I've reserved the entire 9000 range of doomednum's for mapthings in Eternity to be for zdoom-style control things.

Share this post


Link to post

Note that the only people who think this idea is possible are the people who can't program. All people who can program, and program well know this idea is not at all possible. I know Zdoom's code base is now largely C++ and although this doesn't make it completely different from other ports, it does make a giant implementation nightmare.

Another problem is that every port has done things differently, and not because everyone is too self centered to do everything joe-doomer wants, but because in programming there are a thousand ways to do any one thing and none of them are right or wrong, just poor, good, better, best.

Any "Super port" would be a tangled mess of bad code which would most likely have all the crashing bugs of Legacy*Zdoom*Vavoom*EDGE and you would have tons of ugly feature conflicts, not to mention implementing all these features into the Hexen map format which would not only require copy-paste but translation as well which does nothing but cause problems.

In short, no one is programming the "super port" because it is impossible to do with cut and paste as so many people would like to believe. It would require more effort than it would be worth, and it would run like shit.

*steps off of soapbox*

Share this post


Link to post

I would really love to give port-creation a shot. It sounds like it would be quite rewarding (and i'd get to hopefully see all the things I've always wanted in a port made reality). The problem is I wont be able to for a while, since I will be taking Programming courses in college well over a year from now. Sounds very rad though.

Share this post


Link to post

nonsence. a super port is possible, but combining code isn't. for instance, all ports have autoaim, right? while I haven't done the reaserch, I can bet that each port has coding for it that is different from the other ports in one way or another. many of the ports also have gravity changing options and ingame consols. none are exactly the same in code, but they all have the same general purposes.

so, what am I getting at? this is it. someone should make this list... what the ultimate port would have in it. then you start a whole new sp from scratch (or maybe based off of boom or something "primitave" like that) without trying to splice the code of all the sps out there into one mass. I think that a Super Doom is very possible, but probably not in the future too soon.

Share this post


Link to post
frwl said:

nonsence. a super port is possible, but combining code isn't. for instance, all ports have autoaim, right? while I haven't done the reaserch, I can bet that each port has coding for it that is different from the other ports in one way or another. many of the ports also have gravity changing options and ingame consols. none are exactly the same in code, but they all have the same general purposes.

so, what am I getting at? this is it. someone should make this list... what the ultimate port would have in it. then you start a whole new sp from scratch (or maybe based off of boom or something "primitave" like that) without trying to splice the code of all the sps out there into one mass. I think that a Super Doom is very possible, but probably not in the future too soon.


No, it is not as easy as you think. There are the basic features that are easily implemented (autoaim is one of them) The big problem are the more advanced features, the biggest probably 3D-floors. Why do you think this is implemented in so few engines? And most of those have the renderer completely rewritten which makes them incompatible with many effects that were possible with the original software renderer (EDGE for example). I have looked through almost all sources of the various source ports and am therefore certain that too many features cannot be combined to work together. (Implementing them both but disallow usage of both in the same map is another matter but then we can keep it the way it is now)


The C++ issue mentioned above is, of course, utter nonsense. Converting the source to compile under C++ is a matter of a few days. I know this because I did this once with PrBoom to add a few features that were easier to do in C++. The conversion itself took 2 days! Of course this only included fixing the compiler errors but not converting any code into a more C++ friendly format. But it made the following changes so much easier that I really don't understand why most programmers stick to the old C-code...

Share this post


Link to post

wwo, another :ETS ACOMBINE ALL THE POTS TO MAKE ONE SUPIER PORT tjhrea. whaen will they end?

Share this post


Link to post

The entire reason in creating a port is because you want something different, everybody has a different vision. And I wouldn't ever try to combine multiple source ports, and I think any other coder would say the same. Plus there is no real way to "combine" source ports, you may be able get ideas from features, but all the rendering and structure types differ with all the ports out there. Which is why, I create my own ports ;)

Share this post


Link to post
Graf Zahl said:

The C++ issue mentioned above is, of course, utter nonsense. Converting the source to compile under C++ is a matter of a few days. I know this because I did this once with PrBoom to add a few features that were easier to do in C++. The conversion itself took 2 days! Of course this only included fixing the compiler errors but not converting any code into a more C++ friendly format. But it made the following changes so much easier that I really don't understand why most programmers stick to the old C-code...


Fixing compiler errors and using a few C++ features is one thing. Actually translating huge code change from a C method of programming to a C++ method is another. C++ is just the C language with a few minor changes and some major additions. The problem is that randy didn't just get Zdoom to compile under C++ he overhauled most of the code to USE the features of the language. Mobjs are classes now instead of structs for example.

Have you seen some of the differences between the C version of Zdoom's source and the C++ version of Zdoom's source? Like I said before it's not COMPLETELY different but it's enough of a change to make implementing major amounts of code from another port in Zdoom a pain. If were to try and implement Legacy's 3d floors into Zdoom (for example) I think you'll be pleasantly suprised at how big a difference there is between the two codebase.

Share this post


Link to post
SoM said:

Fixing compiler errors and using a few C++ features is one thing. Actually translating huge code change from a C method of programming to a C++ method is another. C++ is just the C language with a few minor changes and some major additions. The problem is that randy didn't just get Zdoom to compile under C++ he overhauled most of the code to USE the features of the language. Mobjs are classes now instead of structs for example.

Have you seen some of the differences between the C version of Zdoom's source and the C++ version of Zdoom's source? Like I said before it's not COMPLETELY different but it's enough of a change to make implementing major amounts of code from another port in Zdoom a pain. If were to try and implement Legacy's 3d floors into Zdoom (for example) I think you'll be pleasantly suprised at how big a difference there is between the two codebase.



I don't think the differences are as dramatic as you make them out.

Why do I know this? Simple. After converting PrBoom to C++ as I mentioned earlier I got carried away and started turning a lot of stuff into classes. I didn't go as far as Randy and used a separate class for every actor type but I converted almost the entire thinker mechanism. In 90% of the converted functions the only thing I had to change was removing the pointer to the object the function now belonged to. This could be done on a per function basis so I never risked once to break the code. The entire thing took 3 weeks (with max. 3 hours of work each day) and I never ran into a problem that stopped the program from working.
(Believe me, it really was worth the time because it makes maintenance of the code so much easier!)

The big problem when adding stuff from other source ports to ZDoom is the renderer. Although this part doesn't use much C++ specific stuff it has almost been completely rewritten. It is so different from the old code that porting any stuff is utterly futile (in both directions!)

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×