Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
Sign in to follow this  
Zed

Source Ports' Limits

Recommended Posts

Hi there, it's me again.

I was wondering, what are the limits of the various ports? Let me explain.

For example, EDGE has (according to the Doom Wiki) "Support for up to 64 defined weapons at once". ZDoom has "Support for most of Boom's editing features". Etc.

The question is: EDGE, for example, can support more than 64 weapons? Maybe 128? 256? What's the limit? ZDoom can support "most" Boom features. Will it ever support, for example, demos recorded in other source ports, like, for example, Legacy? Is there any source port out there that can support "Full 3D", like in "modern" engines/games?

Now, I understand that most source ports have some very specific features in mind, which may or may not be compatible with future development/compatibility, so they might not be able to do some specific tasks they were not meant for in the first place. For example, I don't expect PrBoom to support Decorate, or Chocolate Doom to support jumping or freelook, that's why I don't include them, but I'm aware that this features are present in EDGE and ZDoom, even though they aren't meant to reproduce the "vanilla experience", but can do it.

I hope I explained this properly.

Thanks and good day.

Share this post


Link to post
Zed said:

ZDoom can support "most" Boom features.


It's 'most', because ZDoom does not descent from Boom and therefore a few things are implemented differently. The most obvious example is the TRANMAP lump. From a technical point this feature is more or less a hack which seriously interferes with genuine translucency and it's inherently limited to paletted rendering.

Zed said:

Will it ever support, for example, demos recorded in other source ports, like, for example, Legacy?


No, never.
For demo compatibility the engine must behave EXACTLY the same to produce the same results. This puts some serious limitations on what things can be done and how they can be done. And since there's other ports specializing in demo playback ZDoom decided early that demo playback was not important enough.

Share this post


Link to post

Thanks for your reply.

I understand what you say, and I agree. But I think I didn't asked the question properly.

I'm not talking about what can ZDoom/Legacy/EDGE can or cannot do, I'm talking about what are the "limits" of each source port. You answered a part of that question: ZDoom is not meant to be compatible with demos recorded in other source ports, for example. But I was referring to something a little different.

ZDoom, EDGE, PrBoom+, etc, are constantly evolving, adding new features, improving the "Doom experience" overall. Will that ever stop? Will the source ports reach a limit on what can be done, and focus instead on how to do it better, or will there be a "final" version of ZDoom, for example?

EDIT: Now that I read my post again, I want to clear something up. What I want to know is, basically, what can be done with each port. For example, I've seen some amazing things like RTC-3057 for ZDoom, or some mods for EDGE (sorry, can't remember names). What more can we expect in the future?

Share this post


Link to post
Zed said:

ZDoom, EDGE, PrBoom+, etc, are constantly evolving, adding new features, improving the "Doom experience" overall. Will that ever stop? Will the source ports reach a limit on what can be done, and focus instead on how to do it better, or will there be a "final" version of ZDoom, for example?



Ports will constantly evolve, as you said. As long as there's someone to work on the code there won't be a final version.

As for what to expect, nobody can say. It entirely depends on poeple's creativity.

Share this post


Link to post

The DoomLegacy 1.44 versions have several changes that push the limits.
- Sprite draw limiter, to play wads with more sprites than can be drawn on your hardware.
- Better Fog linedefs, for foggy wads. These are enhancements to the Legacy Fog linedef, adding more encoded fields in the texture names.
- New Legacy demo header format. Incompatible with anything else, but records the actual recording settings more accurately.

I want to add things like:
- Crawl
- Climb
- Lob bomb (grenade)

Maybe an easier way to place objects on 3d floors (without inventing a wad contraption) or having to add them with fragglescript.
Something like specifying which floor the object is upon (1..8).

At the moment I still have a few bugs to kill, but am getting close to a new major release (1.45).

Share this post


Link to post

Asking for what limits ports got is a useless question unless it is more specific. "Like what is the limits of <feature> in <port>?"

Asking a too open ended question like what are the limits of all the ports just makes for a infinitely long list. Which is why people ask what something can do, rather than what it can't.

Share this post


Link to post
Zed said:

What I want to know is, basically, what can be done with each port. For example, I've seen some amazing things like RTC-3057 for ZDoom, or some mods for EDGE (sorry, can't remember names). What more can we expect in the future?

A lot of craziness.

RTC-3057 is an old mod. If you want more recent examples of what ZDoom can do, we've got the ZDCMP2. But also Virus, Urban Brawl, anything from Lil White Mouse or from DOOMERO-21, just to get a look at how far it can go. (Okay, several of these examples require GZDoom since they use models instead of sprites, and in LWM's case, they may rely on vertical angles higher than what the software renderer allows. The game logic, though, is still purely based on ZDoom features.)

Which doesn't mean that you cannot also create ZDoom mods with classic gameplay of course. But it's possible to make it seem like Half-Life or Quake.

Share this post


Link to post
wesleyjohnson said:

Hey Gez ... Any chance that DoomLegacy could be upgraded from "generally considered dead" on that zdoom/wiki.

DoomLegacy development team.


Sure. Sorry about that, it was written a few months before you effectively resurrected it.

Share this post


Link to post
kristus said:

Asking for what limits ports got is a useless question unless it is more specific. "Like what is the limits of <feature> in <port>?"

Asking a too open ended question like what are the limits of all the ports just makes for a infinitely long list. Which is why people ask what something can do, rather than what it can't.


You are right, it seems that after a couple of tries I haven't been able to ask it properly. I apologize.

Using your example question as a base, I think I could ask something like:

-What are the limits of 3D floors, for example, in ZDoom? Can they be recreated without using silent teleporters? Are real floor over floor possible in ZDoom or EDGE? For example, if I want to recreate a real 10-floor building without teleporters, can it be done?

-Will PrBoom+ be able to play ZDoom or Legacy demos in, say, 10 years? Can it be implemented? Is it difficult, extremely difficult, or impossible?

-Is it possible, for example, to create some sort of "Universal Source Port" that can recreate most, if not all, the features present in the more advanced source ports? For example, a combination of ZDoom and Legacy, or PrBoom+ and 3DGE?

I hope I finally explained this properly. I apologize if this sounds dumb/pointless.

Gez said:

But it's possible to make it seem like Half-Life or Quake.


OK, so it's possible to make them look like HL or Quake, but can they be made to act like them? For example, if I understand correctly, the first versions of ZDoom didn't have Hexen support. Now they have it. Will future versions of ZDoom be able to support "Quake clones"?

Again, thanks for your replies.

Share this post


Link to post
Zed said:

-What are the limits of 3D floors, for example, in ZDoom? Can they be recreated without using silent teleporters? Are real floor over floor possible in ZDoom or EDGE? For example, if I want to recreate a real 10-floor building without teleporters, can it be done?


ZDoom can have "real" 3D floors, without any teleport trick. Several are prominently displayed in ZDCMP2.

The only limitation is that they can only have flat surfaces -- no sloped 3D floors in ZDoom. GZDoom, however, allows sloped 3D floors (but they're a bother to set up).

Zed said:

-Will PrBoom+ be able to play ZDoom or Legacy demos in, say, 10 years? Can it be implemented? Is it difficult, extremely difficult, or impossible?

One never knows what the future holds, but nope. It'd require a dramatic shift in design goals.

It can be implemented (anything's possible after all) and the level of difficulty would mostly depend on how much of PrBoom+'s current goals you are willing to sacrifice.

Zed said:

-Is it possible, for example, to create some sort of "Universal Source Port" that can recreate most, if not all, the features present in the more advanced source ports? For example, a combination of ZDoom and Legacy, or PrBoom+ and 3DGE?

Technically, yes, but it would be a real nightmare to code and maintain.

Zed said:

OK, so it's possible to make them look like HL or Quake, but can they be made to act like them? For example, if I understand correctly, the first versions of ZDoom didn't have Hexen support. Now they have it. Will future versions of ZDoom be able to support "Quake clones"?

No. ZDoom as it is now presumably supports all the vintage games it is ever going to support. Only possible additions would be some console ports, e.g. the dormant Doom64 branch.
Chex Quest, Hacx, Heretic, Hexen, and Strife all stayed remarkably close to the original Doom engine. Adding support for non-Doom engine games (Build, Quake, whatever) would be too much work. There's a lot of little tiny details that would hinder extending the port towards other game engines, going from needlessly redundant systems to incompatible underlying architecture.

Share this post


Link to post

Yeah, this concept is a serious hassle. I've often thought of ways I could combine say, flat warping code or a decent sound backend from one port to another - it's a different ballgame once you start going down that dark path. It's best to either code it yourself or not at all.

And 3DGE has good BOOM compatibility, if that's what you're going for. If it's the smoother framerate of PrBoom that you mean, I've been working on a solution for quite some time and I'm hoping I can gather people to test that out soon.

Oh, and 3DGE has real true 3D floors, which means you don't have to use teleports or any of that nonsense. Not sure how Zdoom/etc does it, but EDGE has been able to do it for quite some time - I believe it had dominance for awhile in that area. You spawn objects on those surfaces with RTS, if I remember right. So you can have a true 3D stairway, spawn a monster on the top, and it'll walk down (or up) if it chooses.

Share this post


Link to post
Chu said:

It's best to either code it yourself or not at all.




Now, as an experienced developer I have to srongly disagree with this. This is called NIH-syndrome (Not Invented Here) and in general is one of the worst problems in software development, that people think they have to cook up their own solution for a problem, even if it has already been solved.

Chu said:

Oh, and 3DGE has real true 3D floors, which means you don't have to use teleports or any of that nonsense. Not sure how Zdoom/etc does it, but EDGE has been able to do it for quite some time - I believe it had dominance for awhile in that area. You spawn objects on those surfaces with RTS, if I remember right. So you can have a true 3D stairway, spawn a monster on the top, and it'll walk down (or up) if it chooses.


ZDoom does have true 3D floors, even with the software renderer. I don't think that EDGE had 'dominance' ever. If one port popularized them it was clearly Legacy.
As for spawning stuff on them ZDoom doesn't need to resort to hacks because the map formats suppport z-coordinates natively.

Share this post


Link to post

One limit with 3D floors that crops up every now and again is that, for good reasons, they can't be made or destroyed during gameplay.

For example, you can't easily make a magical bridge that fades away and becomes non-solid while the player is standing on it. There are work arounds - 3D floors can be moved up and down (including below the real floor or above the real ceiling to hide them) but they cannot be created or destroyed.

For most needs, the ability to move the floor is fine but, as I said, every now and again someone wants to create/destroy one during play and sometimes the work-arounds don't do quite what was being looked for.

Share this post


Link to post
Graf Zahl said:

Now, as an experienced developer I have to srongly disagree with this. This is called NIH-syndrome (Not Invented Here) and in general is one of the worst problems in software development, that people think they have to cook up their own solution for a problem, even if it has already been solved.

Problem I usually find is that other peoples' implementations, even if derived from an external source, have been heavily modified to rely on their own dependencies.

An example that should be close to home for you would be ZDoom's integration with Timidity. Nobody else can use that code because it's been heavily altered to depend on FString, DObject features, and countless other dependencies of the ZDoom codebase. I mention this because it was a bitter disappointment to me when I checked out the code with the faint hope that it could be used in Eternity.

Identifying and replacing all of those calls with ones of my own would end up being more work - and more difficult work - than starting from scratch with the original library. Unfortunately that also gains me none of the bug fixes or enhancements that the ZDoom-dependent codebase has.

My point is ultimately that often, when it's "not invented here," it simply doesn't work here either.

Share this post


Link to post
Quasar said:

My point is ultimately that often, when it's "not invented here," it simply doesn't work here either.


That's an entirely different matter.

But the Timidity code shouldn't be too hard to (un)fix.
The use of FString in a few spots is questionable but the code has to integrate somehow with the rest of the engine but this is a handful of spots at most.

The biggest change was the code to load the config file. That's to allow loading from a WAD or PK3 file.

I had to do porting jobs at work that were far, far worse but the impression has always been that even a work intensive port of existing code (provided that said code is in a readable state, of course) is always a quicker job than writing it from scratch.

I even was able to reuse a sizable chunk of ZDoom's lower level code in a project at work recently, saving me weeks of tedious work. Sure, it cost me a few days to make the adjustment but it still was preferable to writing all that stuff myself.

Share this post


Link to post

As to the question, play demos from each others ports, ha ha ha ...
The only demo format seriously considered by a port is Boom demo.
The problem is that demos do not record anything except the player input, and every monster action depends upon the engine behaving .. EXACTLY .. IDENTICALLY .. to the previous execution, as generated from RANDOM NUMBERS. Port engines have differences, and the most innocent of changes will throw the replay off, causing demo sync problems, especially in re-creating those same exact RANDOM NUMBERS. DoomLegacy developers gave up the effort so support demos long ago, and I only recently got it to play it own demos again.


DoomLegacy has got 3D floors, 3D transparent water, and 3D fog now (and foggy water). These can be completely visible, with the floor edges exposed, and with 3D stairs.

Have not got much commentary back on the fog yet. The only wad to use it yet are my test wads, and those are designed to expose rough edges in the implementation. The fog effect rendering can later be improved with better algorithms and CPU power, so there are multiple fog settings that are based on intended use.

TRICK: If you create a pillar under objects, then retract the pillar before the player comes into viewing range, you can place objects on any 3D floor without using script.

The ports are notorious for borrowing each others code. But most of the borrowed functions rarely survive long intact. Then again (IMO), Chu was not talking about borrowing a function, but a whole feature that crosses several sections of the code. Much more difficult to integrate.

Share this post


Link to post
wesleyjohnson said:

The ports are notorious for borrowing each others code. But most of the borrowed functions rarely survive long intact. Then again (IMO), Chu was not talking about borrowing a function, but a whole feature that crosses several sections of the code. Much more difficult to integrate.


Yes, this- sorry I wasn't making myself clear earlier. It just doesn't work - the big things, mostly when crossing the rendering or script code. In that respect, it's much easier to do it from scratch. You can reference the code, sure, but borrowing is out of the question. Took me a long time to figure that one out when I first started doing this stuff, I learned the hard way for sure. ;-)

It's funny, but I've found a few functions that are nearly the same in both DoomLegacy and EDGE (some comments also remain unchanged). It's for this reason (another being lineage) that I mostly reference Legacy rather than ZDoom when it comes to feature implementation. Zdoom, like Quasar said, has too many dependencies to all sorts of other stuff that make it near impossible for me to follow. In all fairness though, so does EDGE.

@Graf: I wasn't aware ZDoom's 3DFloors were that advanced, I was somehow thinking that they were using some sort of software hack like Duke3d. It's been awhile since I've checked out ZDoom code (I took today to do just that), so that's my bad. We also have to remember that EDGE has had 3D Floors since, what, 1.24 (DosDOOM 0.65?). It's my understanding ZDoom and kin didn't adopt them until recently. I was also aware of DoomLegacy's implementation, I just forgot to mention it.

@Quasar: It might be worth for you to check out EDGE's Timidity code.

@Enjay: I think you can "destroy" 3d floors in 3DGE with scripts - I'll have to double check. Might be hackey though, but I'm certain we did it with Hypertension.

Share this post


Link to post
Chu said:

It's my understanding ZDoom and kin didn't adopt them until recently. I was also aware of DoomLegacy's implementation, I just forgot to mention it.


Correct - but it was because it required someone to come up with the right idea how to render them. All the 3D physics code has been available in GZDoom since 2005 (which was mostly written between 2000 and 2003 but not released until much later)


One note about 'destroying' 3D floors.
Seriously, what's the point? From a map's perspective there's no real difference between removing a 3D floor from the map data and (instantly) moving it to a position where it becomes invisible and out of reach. But keeping it around removes a significant amount of burden from the savegame code because the 3D floor data can be considered map-static and therefore does not need to be written out and read back in. It takes all the needed info directly from the model sectors which are processed normally like all other sectors.

Share this post


Link to post
Graf Zahl said:

One note about 'destroying' 3D floors.
Seriously, what's the point? From a map's perspective there's no real difference between removing a 3D floor from the map data and (instantly) moving it to a position where it becomes invisible and out of reach. But keeping it around removes a significant amount of burden from the savegame code because the 3D floor data can be considered map-static and therefore does not need to be written out and read back in. It takes all the needed info directly from the model sectors which are processed normally like all other sectors.


To be clear, I wasn't complaining. It's never even been a problem for me but I have seen others who wanted to do it.

IIRC, the last time I saw someone asking about it was when they wanted to make a floor fade out and at some point become non-solid and be able to fade back in again (like a pulsing magical bridge or something). I know that can be done by instantly moving the original floor away and replacing it with a series of increasingly translucent floors, and then reverse the process for the fade-in.

The "problems" I anticipate with this is that, unless you use a lot of floors, the fade-out/in would happen in obvious steps rather than being smooth. Perhaps more seriously, I'm not sure how any objects (enemy corpses, living enemies, pickups, whatever) on the floors would behave. However, I guess at some point the floor would move the items and perhaps do so inappropriately (e.g. if a solid floor had been moved below the real floor, the items on it would fall to the ground (fair enough) but when the solid 3D floor came back up, would it also raise the items that had fallen back to the height of the 3D floor? or if insta-moving the floor up, it gets stuck below the ceiling because it is carrying items?).

However, unless it's something that is easy to add and be efficient (and I know it isn't) to me it's a reasonably specialised requirement with a semi-functional work around that can be tailored to work pretty well and is simply something out-with the intended scope of the 3D floors.

Share this post


Link to post

Even without changing their solid/non-solid nature, being able to change the alpha at runtime would be useful.

Share this post


Link to post
Zed said:

The question is: EDGE, for example, can support more than 64 weapons? Maybe 128? 256? What's the limit?

Is there any source port out there that can support "Full 3D", like in "modern" engines/games?


I can answer these questions from a EDGE-centric perspective as I'm slowly beginning to know the port quite intimately.

EDGE does indeed support "3D" in the sense that things have a Z-value and can be climbed/walked under and there seems to be no limit to how many extrafloors can be stacked. However, slopes are purely decorative (and the collision works as the non-sloped sector would, flat) and can't be used in conjunction with extrafloors. It's a kinda hack done from the mapping perspective, so I don't think it's "full" at all.

As for weapons, although there appears to be no specified limit to how many can be defined (I'm referring to some old DDF documentation as reference here though), you are limited to only 16 ammo types. Although these since these ammo types could be used 'invisibly' as variables for scripts (since RTS doesn't appear to have variables of its own), this number may be less depending on how advanced your scripting is.

As an aside, in my own original game (SLaVE) I'm using an ammo-counter for arcade-style scoring. Neat.

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
Sign in to follow this  
×