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

Is there room for Yet Another Source Port? The possibility of DoomXL.

Recommended Posts

With DarkXL back on the path to beta, the idea has come up about doing a DoomXL. So the question is, is there room for yet another source port - or is the "market" saturated at this point?

So why do another source port to begin with? Well this wouldn't be a standard port. Once DarkXL reaches beta, the idea would be to rewrite Doom to use the DarkXL engine - while making any modifications necessary to fully support Doom properly of course. This would mean that I couldn't use the source as-is, requiring more work to get running then a standard source port I think, but I think it would have several advantages:

* Overlapping sector support.
* Portal-like effects, using adjoins and overlapping sectors.
* Second sector heights and 3D models - allowing for simple bridges and platforms.
* Fully dynamic, animated sector geometry. Things like rotating doors, moving platforms, even script controlled sector or sub-sector movement.
* No glBSP or equivalent programs needed.
* Sector connections can change dynamically, allowing things like elevators that connect different floors together.
* DarkXL extended features such as dual adjoins and top and bottom adjoins - allowing for things like 3D bridges made of sector geometry and true deep water.
* Floor and ceiling slopes.
* Heightmaps within sectors.
* Extended features such as dynamic lighting, bloom and reflections.
* Fully scripted logics - meaning mods could alter monster behavior, what pickups do and other effects just by modifying script files.
* Built in level editor, like DarkXL will have.
* And more. :)

These features would be inherited from DarkXL, even before I add anything new.

So it'd still be a sector engine, but it would push the limits and allow for simple to use 3D effects. No more hard to use 3D bridges that don't quite act like normal geometry or special case portals. Any sector connection can be a portal and many geometry restrictions are lifted.

So what do you guys think? Do you think there's room for another source port?

Share this post


Link to post

I believe the one thing that has not been done yet is a pure Java port of Doom that will be executable in either desktop or applet mode, without needing OS-specific extensions. The closest thing to a browser-embedded Doom is as of now Flash Doom, which however "cheats" by using Alchemy to pull the original C code in, I don't know how cross platform is that.

Also, a pure Java MIDP (in poor words, Java games) version of Doom. But I mean D-O-O-M, with IWADs and all, and not some random-ass maze game. An no fucking Symbian, Android or iPhone, thank you.

Share this post


Link to post
Sergeant_Mark_IV said:

No DECORATE support? Then, it fails IMO.

Hmm, I don't think I said that I'd refuse to support DECORATE or other standards. However support would have to be added in since the list I gave was the set of features I'd get just for using (or starting with) my DarkXL engine and not meant to suggest that they would be the only features supported. If you are trying to say that certain standards must be supported in order to make a source port worth using, then that is good information to hear. Fortunately I'm just testing the waters, so nothing has failed yet. :)

Maes said:

I believe the one thing that has not been done yet is a pure Java port of Doom that will be executable in either desktop or applet mode, without needing OS-specific extensions. The closest thing to a browser-embedded Doom is as of now Flash Doom, which however "cheats" by using Alchemy to pull the original C code in, I don't know how cross platform is that.

Also, a pure Java MIDP (in poor words, Java games) version of Doom. But I mean D-O-O-M, with IWADs and all, and not some random-ass maze game. An no fucking Symbian, Android or iPhone, thank you.

Sorry, I have no plans for working on a Java or Flash port of Doom. Thanks for the suggestion though. :)

Share this post


Link to post

Room, perhaps, but you may find some obstacles.

DOOM add-on design is very rich but not seldom relies on unforeseen quirks of the engine or hacky level design to produce new effects. You'll need extra effort to get many of these working if you start off from a different code base. If they don't work, many add-ons, even rather popular ones, won't function well.

Many players also value the classic feel of the DOOM engine and might be put off by an engine that does more or less the same as existing ones but doesn't have the original base.

Also, editing for your engine will be somewhat different, making the acquired skills of long-time designers less applicable, as they'd have to learn an array of new ways to implement stuff.

This community is also very open source and sharing oriented. Practically any engine, even the ones not under the GPL, has its source released regularly, excepting two of the online ones (which is a controversial topic and they adduce security concerns.)

Share this post


Link to post

Okay man.
The ability of making new monsters, players, weapons, driveable vehicles, items, and everything else in a simple and easy way like decorate is just unreplaceable. Unfortunely, ZDoom and Skulltag are the only ones that gives a full support to it. If you could make one with everything you said, plus DECORATE, it would really kick ass.

Also, do you mind making particle and flare systems like Doomsday?

Share this post


Link to post

Hm. I think this would end up feeling a bit less like Doom and more like a Doom TC of a BUILD engine game. That said, I'd love to see a Doom port capable of hardware rendering AND complex linked portals, but BUILD's portals have their own restrictions. Could your engine do this, for example?

Share this post


Link to post
Creaphis said:

Hm. I think this would end up feeling a bit less like Doom and more like a Doom TC of a BUILD engine game. That said, I'd love to see a Doom port capable of hardware rendering AND complex linked portals, but BUILD's portals have their own restrictions. Could your engine do this, for example?

Yes, with multiple adjoins I don't see anything in those screenshots that isn't possible.

As for feeling like a TC, I don't think that would be an issue. What I'm talking about is starting with the DarkXL engine but modifying it to incorporate Doom physics, controls and so on. While I can't use the source directly, I can use the original algorithms. Remember that I've been doing DarkXL with no original source code at all, so I'm pretty confident with my ability to get the look and feel down when there is full source code to reference and use when appropriate.

Sergeant_Mark_IV said:

Okay man.
The ability of making new monsters, players, weapons, driveable vehicles, items, and everything else in a simple and easy way like decorate is just unreplaceable. Unfortunely, ZDoom and Skulltag are the only ones that gives a full support to it. If you could make one with everything you said, plus DECORATE, it would really kick ass.

Also, do you mind making particle and flare systems like Doomsday?

No problem. All the things you've mentioned are already possible in DarkXL (or will be possible by beta) using the scripting. However supporting a standard system, such as DECORATE, that supplements the scripting system is certainly doable if it helps.

Also supporting flares and particles systems are certainly possible as well. With bloom, flares aren't as necessary though. Anyway there is plenty of additional graphical candy that can be added, but like DarkXL the features can be toggled on or off depending on what you like.

myk:
DOOM add-on design is very rich but not seldom relies on unforeseen quirks of the engine or hacky level design to produce new effects. You'll need extra effort to get many of these working if you start off from a different code base. If they don't work, many add-ons, even rather popular ones, won't function well.

Like DarkXL, the goal would be to support as many existing mods as possible. What good is a source port when only the simplest mods and vanilla levels work?

myk:
Many players also value the classic feel of the DOOM engine and might be put off by an engine that does more or less the same as existing ones but doesn't have the original base.

This is my biggest concern. Will this source port seem different enough to bother with? Will people be even willing to try a new source port when they are used to DoomsDay or ZDoom? As I stated before, I'm confident in the look and feel department - it will feel like Doom - but that's not necessarily enough on it's own.

myk:
Also, editing for your engine will be somewhat different, making the acquired skills of long-time designers less applicable, as they'd have to learn an array of new ways to implement stuff.

If the engine supports mods properly (as mentioned above, it needs to), then people don't have to use the in-engine editor. However, obviously to use the features properly they should. Fortunately you are still editing sectors in a fashion similar to Doom Builder and other popular editors, just with support for more or different features and editing tweaks. It may have features that they don't have - or they may work a little differently - but its the same ideas.

myk:
This community is also very open source and sharing oriented. Practically any engine, even the ones not under the GPL, has its source released regularly, excepting two of the online ones (which is a controversial topic and they adduce security concerns.

The DarkXL source will be released at some point and so will DoomXL if I decide to do it.


Finally thanks, everyone, for your comments. You guys are helping me to decide how to proceed - or if to proceed. Anyway feel free to post more comments, I have a while to plan and decide what to do. If DoomXL becomes a reality, I still have several weeks to plan since DarkXL needs to be at beta first. :)

Share this post


Link to post

If a DoomXL gets made, I will certainly give it a look. I personally would like it to have a good scripting language a la Decorate, but I'm not going to pressure you for it.

(Random side note and probably a total pipe dream: Decorate or similar for DarkXL? That'd be cool too.)

Share this post


Link to post

lucius said:
The DarkXL source will be released at some point and so will DoomXL if I decide to do it.

I see what it says on your DarkXL FAQ, but people won't like that unless you do your work real quick (which seems impossible) and release the code relatively soon. Otherwise, the promise of a future release notwithstanding, all the other programmers and port fans will see you adding stuff to your port, feeding on their shared ideas and community work of years like a leech without offering your work on an equal basis. They won't be able to see the source, so they won't know whether you're stealing code or deriving it and, arguably, copyright derivation is not just a matter of copy-pasting literally.

Share this post


Link to post
Sergeant_Mark_IV said:

Okay man.
The ability of making new monsters, players, weapons, driveable vehicles, items, and everything else in a simple and easy way like decorate is just unreplaceable. Unfortunely, ZDoom and Skulltag are the only ones that gives a full support to it. If you could make one with everything you said, plus DECORATE, it would really kick ass.

Right, because ZDoom is surely the only port that's ever implemented the ability to modify or define new monsters or weapons, ever.

Shut up.

Share this post


Link to post
lucius said:

Hmm, I don't think I said that I'd refuse to support DECORATE or other standards.

DECORATE isn't exactly a standard, it's ZDoom's native actor definition language. It's quite popular because it's simple yet powerful. Also it has the advantage of being shared by two ports derived from ZDoom, the OpenGL port GZDoom and the multiplayer-centric port Skulltag.

Some other ports have their own content definition language (EDGE, Doomsday, Eternity, Remood, all have their own thing). But in my opinion, none of them are as straightforward to use to define actors as DECORATE. (And I'm not the only one thinking that, since Janis Legzdinsh implemented support for it in Vavoom and Quasar is working on adding support for DECORATE-style syntax in Eternity's definition files.)

That said, for a long time, the only way to change content in Doom mods was through the use of a tool called DeHackEd which overwrote identified sections of doom.exe to change values. Since there are many versions of the exe, the dehacked patches are text files which are interpreted by dehacked and applied as appropriate to the exe. Then Boom, one of the earliest source ports, added support for loading interpreting dehacked patches directly, so that they could still be used with this new engine. Since then, support for dehacked patches is considered a necessity. This one is an absolute standard now. Not the most practical, as can be understood given its origins, but at least it's not a moving target anymore.

Sergeant_Mark_IV said:

Unfortunely, ZDoom and Skulltag are the only ones that gives a full support to it.

You're forgetting GZDoom and Vavoom. (And ScoreDoom, heh.)

myk said:

DOOM add-on design is very rich but not seldom relies on unforeseen quirks of the engine or hacky level design to produce new effects.

And not just level design. Sure, detecting all the hacks used in a level (self-referencing sectors, deep water effects, etc.) and emulating it in a renderer is a big hassle; but it isn't the only one. There are plenty of glitches in the physics and movement code as well. Some maps can simply not be played if a bug is not present. To give an idea, this file is used by ZDoom to determine automatically appropriate compatibility settings to apply to known troublesome levels, as identified by their MD5 sum.

And let's not even talk about trying to shoehorn demo compatibility in an engine that's not even based on the original.

lucius said:

Remember that I've been doing DarkXL with no original source code at all, so I'm pretty confident with my ability to get the look and feel down when there is full source code to reference and use when appropriate.


But the Doom community is full of nitpickers who are extremely well acquainted with the slightest elements of Doom look and feel. Once there was a bug report on the ZDoom forums because items dropped by dying monsters were tossed a bit farther than normally.

Share this post


Link to post

Well DECORATE is probably worth implementing, especially if more ports decide to implement it - like Eternity as you mentioned Gez. Dehacked patches would also be necessary, but as you said it's a fixed standard so should be doable.

Gez said:

And not just level design. Sure, detecting all the hacks used in a level (self-referencing sectors, deep water effects, etc.) and emulating it in a renderer is a big hassle; but it isn't the only one. There are plenty of glitches in the physics and movement code as well. Some maps can simply not be played if a bug is not present. To give an idea, this file is used by ZDoom to determine automatically appropriate compatibility settings to apply to known troublesome levels, as identified by their MD5 sum.

And let's not even talk about trying to shoehorn demo compatibility in an engine that's not even based on the original.

[/B]These are probably the biggest challenges, I agree. But with original source code available for reference, they are surmountable.

Gez said:

But the Doom community is full of nitpickers who are extremely well acquainted with the slightest elements of Doom look and feel. Once there was a bug report on the ZDoom forums because items dropped by dying monsters were tossed a bit farther than normally.

[/B]
*I have to make sure to use the same algorithms for physics, movement, monster AI and so on.
*Heavy initial testing must be done with vanilla levels. Make sure the gameplay, physics, demo playback, etc. works properly on the vanilla levels before moving on to user levels.

While everything mentioned here are challenges - it can be dealt with. In my mind, the question isn't "can it be done" - I've looked at Doom and Quake source code before, I can work with it and figure out how things are working - but "should it be done." Are the features I mentioned before compelling enough that, assuming the experience is authentic and the look and feel is maintained (including things like how items drop and monster behaviors), would people be interested in another port?

Just to be clear, I wouldn't ignore the source code - I'll use/incorporate what's appropriate and use the rest as reference. Core elements like movement, collision, physics, monster AI, weapon behaviors, demo playback and so on are critical and would be treated with care.

Anyway if I decide to proceed, the first thing I'd do - before worrying about deHacked patches, DECORATE, level editing, new features and so on - is to get the original Doom (and Doom II) working under the new engine. Then let people nitpick it to death and make sure the look, feel and gameplay are solid and authentic before moving on. If, before moving on, the game doesn't look and feel at least as authentic as GZDoom or JDoom then there'd be no point.

Anyway, thanks for pointing out the challenges, it is good to be realistic about what issues will come up. :) If anyone wants to point out additional challenges and concerns, that's cool - it'll make sure these things are on my radar.

However, the more important thing to me is my original question. Given the features I mentioned (plus additional smaller features can be added later like particles), would people be interested in another Doom port? Thanks, everyone who commented - I appreciate it.

Share this post


Link to post
myk said:

I see what it says on your DarkXL FAQ, but people won't like that unless you do your work real quick (which seems impossible) and release the code relatively soon. Otherwise, the promise of a future release notwithstanding, all the other programmers and port fans will see you adding stuff to your port, feeding on their shared ideas and community work of years like a leech without offering your work on an equal basis. They won't be able to see the source, so they won't know whether you're stealing code or deriving it and, arguably, copyright derivation is not just a matter of copy-pasting literally.

I see your point. Once the DarkXL beta is out, I plan on releasing the DarkXL source code. I'll just have to make sure that DoomXL is open from the beginning - I still planning on doing the work myself, I like to work alone on code. However it will prove that I'm not just copying and pasting from the hard work of others - well other then the original Doom sources of course. :) It will also allow sharing, so if I do use any code from another port - with permission of course - it will be obvious as well. And with as many Doom ports as there are, forking isn't a very big issue in this environment either.

Share this post


Link to post
lucius said:

Well DECORATE is probably worth implementing, especially if more ports decide to implement it - like Eternity as you mentioned Gez.

(Like Vavoom, rather. Eternity decided to adopt just the syntax, not the language itself.)

lucius said:

However, the more important thing to me is my original question. Given the features I mentioned (plus additional smaller features can be added later like particles), would people be interested in another Doom port? Thanks, everyone who commented - I appreciate it.

There is a niche available for working portals in a hardware-accelerated port. The portals in ZDoom and derivative are severely limited, and those in Eternity are much better but there's no OpenGL offshoot of Eternity.

Share this post


Link to post

Honestly since the port isn't a offshoot of ZDoom it isn't really worth adding full-on decorate support. The syntax could be usable but at the same time it might be worth adding in your own action functions, flags, other features, whatever, so you don't have to be tied to ZDoom and end up doing anything you want to do. If you were to do this, it probably wouldn't be the best idea to just name your language DECORATE though, since it'd make it sound like your scripts would be compatible with ZDoom and so on.

When it comes to this stuff though the scripting (aside from mabye a ACS-like thing) doesn't really interest me. What's more interesting to me are the mapping features.

Also:

No DECORATE support? Then, it fails IMO.


This is the worst reason I've ever seen for something failing.

Share this post


Link to post

Good points. DarkXL already has it's own scripting system - so I'll have to give careful thought as to how DECORATE fits in. The end result, though, will be all the power that DECORATE affords. But you are correct in that there is no reason to couple DoomXL with ZDoom.

Share this post


Link to post
Gez said:

There is a niche available for working portals in a hardware-accelerated port. The portals in ZDoom and derivative are severely limited, and those in Eternity are much better but there's no OpenGL offshoot of Eternity.


This is what interests me the most. I'd much sooner have this than another port playing catch-up with ZDoom's scripting capabilities. Chances are some other people will be interested by this too. But, lucius, the answer to "Is it worth it?" depends on how large a "market share" you'll need to retain your motivation to work on this. I can tell you now that it'll be a very small percentage of all Doomers, simply because most Doomers have been using the same ports for years and can become quite entrenched in their habits.

Share this post


Link to post
esselfortium said:

Right, because ZDoom is surely the only port that's ever implemented the ability to modify or define new monsters or weapons, ever.

Shut up.


GZDoom and Skulltag are based on ZDoom if that helps.

Share this post


Link to post

I've let "market share" concerns drop from my mind in large part as work on EE has continued through the years. When people enjoy it, I like that, but my motivations for working on it remain primarily intrinsic. EE is my port first. If you can have that attitude, then your project can prosper even if it is overshadowed by existing entrenched ports in terms of popularity.

Another avenue that is currently still unexplored in DOOM is the ability to specify and modify the game code in form of scripts rather than having it implemented inside the executable. In Eternity we are looking toward ECMAScript to provide an equivalent level of power, but we have not yet actually started the work on integration of the SpiderMonkey interpreter, since there are so many other things in the way right now.

If your engine already has this capability, then IMO you are a leg up on everybody else in a very important area.

Share this post


Link to post

Thanks for the responses everyone. I think that there are certain key areas where this port will do things that others don't (or only partially) - and some of those things are important to some people. I'm ok if DoomXL isn't as popular as most of the others as long as there is a group that is interested and that it is considered a good port. I don't expect this to be the next ZDoom or Doomsday - it's just too late to the game for that. (Not impossible but highly unlikely)

Anyway it seems the port would be worthwhile, as long as I handle certain things very carefully (gameplay, look and feel, demo playback, etc.). So expect to hear more about DoomXL in the future, once DarkXL reaches beta. :)

If you have any additional comments, suggestions or questions feel free to post them.

Share this post


Link to post
lucius said:

demo playback


Attaining compatibility with demos recorded with other engines will basically be impossible. However, if demos recorded with DoomXL could be played back at least with the same version of DoomXL, that's par for the course.

Share this post


Link to post
Gez said:

The portals in ZDoom and derivative are severely limited, and those in Eternity are much better but there's no OpenGL offshoot of Eternity.


It should be noted that GZDoom's portals don't suffer from the most crippling of ZDoom's limitations and with recent improvements it's even capable of handling rf_kerkr.wad which is one of the 2 released Eternity maps that are using portals. The other one (ogro.wad) doesn't fully work yet because I haven't coded support for Eternity's horizon portals (yet.) Personally, I find Eternity's horizon implementation quite clumsy compared to ZDoom's much more simple and straightforward method but technically I see no reason not to add it if it means being able to render this map as intended

Share this post


Link to post

Whilst I think that there is still room for another source port I have to ask why you want to begin from scratch. There are too few talented developers in the DOOM community and they are spread extremely thinly over nearly a dozen existing ports. Why not join an established project with compatible goals?

Share this post


Link to post

Making DoomXL implies porting Doom features to the codebase he developed for DarkXL and DaggerXL. Joining an existing project implies dropping that. So I understand his choice.

Speaking of these two other projects, they are more useful in my opinion than a new Doom port. There are plenty of means to play Doom on modern hardware, running the gamut from "practically exactly the same thing, bugs included" to "now enhanced with a lot of fancy new features". Games like Dark Forces or Daggerfall don't have that luxury. And there are many other worthy contenders who'd need some reverse engineering love; I'd love to be able to play an underrated gem like Shadowcaster without getting a DOS4/GW TRANSFER STACK OVERFLOW every five minutes (it's even worse on DOSBox than it was back in the days, though at least rebooting the PC is no longer necessary).

Share this post


Link to post

As a former source port coder, my advice is to ask yourself (as soul-searchingly as possible) this question:

Do you actually like playing DOOM? Really really like it? Enough to spend thousands of hours working on your own port, the constant testing and fixing bugs, and dealing with people's criticisms and endless feature requests?

If you love DOOM and will enjoy lucius-ifying it, then go for it, the result will be good source port and other people will appreciate it. Otherwise I doubt you could produce something truly worthwhile. Your heart's gotta be in it I think.

Share this post


Link to post

Decide on a philosophy and direction behind the project - what are you trying to achieve, and how is it fundamentally different from existing source ports? I don't just mean "it's like ZDoom but it has all these cool features as well!" - try to get a deeper direction for what the purpose of the port is. There are already a lot of source ports, and people have their favorites. Unless you make something that is distinctive and obviously different from existing ports, nobody will care.

No DECORATE support? Then, it fails IMO.

Expect reactions like this. There are a million features that people will want you to add, a lot of them are difficult and time consuming to implement. One of the reasons I decided to embark on writing Chocolate Doom was that I had decided on a direction for the project which allowed me to reject almost all feature requests (and it's still a problem).

Don't expect to get lots of users overnight. Don't base your motivations on how many users you're expecting to get. Write it because you enjoy programming and you find what you're doing interesting.

Release your source code.

Share this post


Link to post
andrewj said:

As a former source port coder, my advice is to ask yourself (as soul-searchingly as possible) this question:

Do you actually like playing DOOM? Really really like it? Enough to spend thousands of hours working on your own port, the constant testing and fixing bugs, and dealing with people's criticisms and endless feature requests?



That's one thing. I believe that another necessary requirement is that any port author needs intimate knowledge of how things really work in Doom. Without a fundamental understanding of Doom's quirky physics I think any attempt to do a port is doomed to fail.

Also, reading the feature list gives me the impression that much of this won't fly while keeping the original game logic in place.

However, doing Doom with a better physics engine will sure alienate a vast majority of its players, even those who use some more 'advanced' engines which don't slavishly adhere to each minute detail of how Doom works.

Just do a search for 'Vavoom' and I'm sure you'll find some interesting discussions about this.

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
×