Jump to content

FreeDoom vrs Legacy


Recommended Posts

I run Legacy on Linux, because it is the one that after months of rewriting I could get to run decently. I also tried ZDoom but have many problems with it. I ran it under FreeDos, but do not like the lack of controls that I have with Legacy.

To the real point of this post.

How much is FreeDoom going to support running on a Legacy port ???

I currently know of the following problems. Most of which I am trying
to patch Legacy to fix. But it is not clear if there is any give
from FreeDoom.

1. Level 13, underwater swim to a door that will not respond.
The level is using a second "Player 1 start position" to run through some linedef trips, acting as a timer to open the doors.
Legacy does not put anything on such a start position, so there is nothing there to trip the linedefs.
It would be so easy to just use a real monster, and extend the box
into another nearby box that also has monsters.
The difficult solution is to fix Legacy to have such zombie players
exist and be able to trip linedefs.


2. Many doors close too soon, while others have a reasonable delay.
I have submitted a patch to Legacy to have a door control, but it
affects all door delays. There is more than one with the problem.
I know, this could just be a bad setting with those levels.

3. Legacy allows jumping, which I would not be willing to play without. Some levels (Level 10 ?) have items that can be gotten by a jumper, but are more difficult to figure out without it. If the platforms were raised a slight amount, then they would out of reach of jumpers. Can we expect to fix FreeDoom levels so that ports (like Legacy) with jumping, do not defeat level puzzles ??


I cannot remember any more off the top of my head, I try to add more
later.

Share this post


Link to post

Freedoom's only target is Boom, compatibility with other ports depends on how compatible they are with Boom. Doom Legacy is outdated and not maintained, I would recommend using PrBoom instead.

1. Boom and compatibles are the target, not Legacy. Good luck with fixing Legacy, but Freedoom won't be incorporating hacks for all the engines that are not its target.

2. Specifics? Do these doors work properly with (Pr)Boom or is it a Doom Legacy specific problem? If the latter, see the above statement.

3. Boom doesn't support jumping so the levels aren't designed for it. Levels that require jumping to complete will not be accepted, although ones that remain compatible and beatable with regular Boom will of course be accepted. :)

Thanks for the feedback and I hope you'll enjoy working with Freedoom.

Share this post


Link to post
wesleyjohnson said:

I run Legacy on Linux, because it is the one that after months of rewriting I could get to run decently.

1. Level 13, underwater swim to a door that will not respond.
The level is using a second "Player 1 start position" to run through some linedef trips, acting as a timer to open the doors.

Legacy's lack of support for voodoo dolls is one of it's few failings that breaks a lot of wads.

3. Legacy allows jumping, which I would not be willing to play without.

EDGE supports jumping, Boom features and Linux - if you're willing to try yet another port.

Share this post


Link to post

wesleyjohnson said:
3. Legacy allows jumping, which I would not be willing to play without. Some levels (Level 10 ?) have items that can be gotten by a jumper, but are more difficult to figure out without it. If the platforms were raised a slight amount, then they would out of reach of jumpers. Can we expect to fix FreeDoom levels so that ports (like Legacy) with jumping, do not defeat level puzzles ??

Jumping heights aren't necessarily uniform between engines. From what I recall of Legacy versions I've used, for example, the player jumps more than in ZDoom. You can jump up to the ledge at the start of DOOM II while in ZDoom you can't. That place you mention may already work as you request in ZDoom or the like. Additionally, testing so that things work well for both jumpers and non-jumpers is a nightmare even without these differences and it limits what a map author can do compared to designing with one or the other behavior in mind. You always have an advantage while jumping so play is just not the same.

Share this post


Link to post
myk said:

From what I recall of Legacy versions I've used, for example, the player jumps more than in ZDoom.


No. It's the other way around. Legacy is the port with jumping where you jump the least. As for the start of Map01. IIRC, Legacy will allow you to jump up there, but only if you take a running jump from the stairs in the other side of the room. While Zdoom allows you to just jump straight up.

Don't have Doom installed on this computer currently though so I can't verify it right now.

Share this post


Link to post

Hmm, you're right. In fact, I just checked and it's indeed ZDoom that lets you jump onto that ledge easily. I remembered from back when I was a newb to source ports and jumped all over the place, even in maps that were not meant for it, that the jumping height had changed when I switched from Legacy to ZDoom, but actually: I then started jumping onto that ledge, not the other way around ;)

Share this post


Link to post

Tried ZDoom and I could not get it to jump, and I finally gave up as the controls were limited. I got the impression that ZDoom tries to maintain "exactly as original Doom" principals. I am beyond that into
"How can I improve the playability", which is where Legacy is going.

Legacy is still alive and have moved to SourceForge. Apparently it is undergoing rewrite into C++, so there is little support of the C code.
The code runs very well.

I have not successfully compiled any other Doom port under Linux. I fought with ZDoom for a while and gave up on it. Looking at the dates you would expect ZDoom to be more advanced, but Legacy has got much better controls and options. If ZDoom has got some of these features then it has hidden them too well, the console under Legacy is so good that the old "cheat codes" seem outdated.

It is helpful to know that FreeDoom is using Boom and nothing more.
So it is not tied to being a ZDoom only wad ?

If there are many wads using zombies then probably Legacy will have
to have code to deal with it, like everything else. What I wonder about is what standard do zombies come from ? Are zombies in Boom.
I also ask, is it a technique that FreeDoom allows as part of its standards. Is it really Boom with zombies, and what else ?

As for the jumping, well if ZDoom allows jumping, and FreeDoom advocates using ZDoom, then don't you have to deal with the problem in designing levels? It does not require much testing. If a level designer does not want to have the player jump up and grab something then put it up high enough that it is clearly out of reach. It does not break a level if some players find a shorter way to solve levels. I only ask this so as to get some idea of what the ground rules for level design are, not because it affects play that much.

One of my ideas it to introduce climbing. How to limit it is the question. I would have a control on the Legacy options that has, "no climbing", "climb if waist height", "climb if shoulder height", "climb if head height". I do not think this would ruin any game play, but just open up more ways to play existing wads. This is where my interest lies, improving the game !

As for the door delay. I have played Legacy with Doom1, DoomI, Heretic, and other wads that I have got my hands on. The door delays are quite reasonable in all those wads. Most of the door delays in FreeDoom are reasonable. But there are a two or three doors that are too fast for the difficult path to reach them, so bad that another post on this forum reads "it took about 300 tries". That is not fun, just tedious. I have written code in Legacy to make the game playable and restore the fun level. But I would hope to provoke you to set a standard that makes this wad playable by a wider group of people.

Share this post


Link to post
wesleyjohnson said:

I got the impression that ZDoom tries to maintain "exactly as original Doom" principals.

Before the inevitable flamewar over ZDoom starts, you should be aware that many forums users here are against ZDoom precisely because it is very different from original Doom. If you were after original Doom, you'd go with Chocolate Doom or at most PrBoom. :P

It is helpful to know that FreeDoom is using Boom and nothing more.
So it is not tied to being a ZDoom only wad ?

No, it's only targetted at Boom and compatibles. It should also be worth noting that ZDoom is not fully Boom compatible (and even if it were, the authors would make no attempt to have a "compatibility" mode to strip out newer features at runtime, it would be difficult to test a level's compatibility with the Freedoom guidelines).

If there are many wads using zombies then probably Legacy will have
to have code to deal with it, like everything else. What I wonder about is what standard do zombies come from ? Are zombies in Boom.
I also ask, is it a technique that FreeDoom allows as part of its standards. Is it really Boom with zombies, and what else ?

You mean voodoo deals? It was a 'feature' (actually a bug heavily exploited by custom WADs) of the original Doom engine and most source ports preserve it. Doom Legacy opted to not preserve this feature, and it broke many prior PWADs.

As for the jumping, well if ZDoom allows jumping, and FreeDoom advocates using ZDoom, then don't you have to deal with the problem in designing levels? It does not require much testing. If a level designer does not want to have the player jump up and grab something then put it up high enough that it is clearly out of reach. It does not break a level if some players find a shorter way to solve levels. I only ask this so as to get some idea of what the ground rules for level design are, not because it affects play that much.

The problem with designing levels with anti-jumping via platform heights is due to a simple fact that there has never been a standard "jumping height" in Doom (the original game didn't have it at all), so it's kind of hard to obstruct such a move without making the levels look grossly tall. Plutonia 2 worked around this with a ZDoom-specific setting to disable jumping, but I'm not sure this would be the best move to be honest.

Also about advocating ZDoom, I see how it certainly seemed that way, although the page was supposed to discourage it. As soon as Savannah spreads my new public key around their servers, I'll remove the bit with non-free (and Boom incompatible) engines. After that, only the first four ports will be listed (the two derived from Boom, the last one is a fork of Doomsday specifically designed to add Boom features...). It makes the page seem a bit small, but hey, it'll avoid confusion such as this :-)

One of my ideas it to introduce climbing. How to limit it is the question. I would have a control on the Legacy options that has, "no climbing", "climb if waist height", "climb if shoulder height", "climb if head height". I do not think this would ruin any game play, but just open up more ways to play existing wads. This is where my interest lies, improving the game !

Sounds good to me, although unfortunately as far as Freedoom is concerned, the Boom target is sticking so no levels that depend on that feature would be in this IWAD. You are, of course, free to make your engine and release PWADs designed for it!

As for the door delay. I have played Legacy with Doom1, DoomI, Heretic, and other wads that I have got my hands on. The door delays are quite reasonable in all those wads. Most of the door delays in FreeDoom are reasonable. But there are a two or three doors that are too fast for the difficult path to reach them, so bad that another post on this forum reads "it took about 300 tries". That is not fun, just tedious. I have written code in Legacy to make the game playable and restore the fun level. But I would hope to provoke you to set a standard that makes this wad playable by a wider group of people.

Need more info. What level(s) and does it, as I asked before, happen in (Pr)Boom? Testing Legacy with the commercial IWADs does absolutely nothing to answer my question, sorry.

Share this post


Link to post

wesleyjohnson said:
I got the impression that ZDoom tries to maintain "exactly as original Doom" principals.

No, that's what Chocolate Doom does. How could it have that purpose and yet allow jumping? ZDoom has tons of features that alter or can alter the game from where Doom leaves off. However, any robust engine (ZDoom included) has some optional backward-compatibility settings to ensure user-made levels won't break during play.

MikeRS said:
It should also be worth noting that ZDoom is not fully Boom compatible (and even if it were, the authors would make no attempt to have a "compatibility" mode to strip out newer features at runtime, it would be difficult to test a level's compatibility with the Freedoom guidelines).

I would say it is Boom compatible, just not in the technical or purist sense of PrBoom's (demo) compatibility. If I'm not mistaken, it'll run practically any Boom WAD except a few that use bizarre conveyor tricks or the like. It'd be kind of silly to include levels in Freedoom that break in engines that support every explicit Boom feature and are widely used. Such levels can always be fixed. If you want to be truly strict, only Boom, including perhaps PrBoom 2.02, is really Boom compatible. You do need to test all levels in one of these, because other ports many handle supposed Boom levels that can choke in Boom for some reason.

Plutonia 2 worked around this with a ZDoom-specific setting to disable jumping, but I'm not sure this would be the best move to be honest.

That wasn't really a workaround, we just placed it there mainly because it had been done in another WAD (CC3, I think) and since we were already including a MAPINFO lump for the music and level names. It is going to be removed in 1.1 because it terminates ZDaemon, anyhow.

Share this post


Link to post
wesleyjohnson said:

Legacy is still alive and have moved to SourceForge. Apparently it is undergoing rewrite into C++, so there is little support of the C code.

In the past year, there have been a total of two actual code changes committed to the Legacy Subversion repository. It certainly looks to me like this C++ rewrite isn't going to be finished any time soon.

In an ideal world, I'd like to just say "forget about Legacy altogether". It's a buggy, broken port and it doesn't have many users for that very reason.

However, I don't think we should be dogmatic in demanding that all ports MUST have 100% Boom support or that any port that doesn't behave EXACTLY as Boom does is not Boom compatible and should therefore be ignored. Freedoom ought to work properly in ZDoom, for example. If it doesn't then we can work around it. There's no reason why we can't work around minor issues for Legacy as well.

In the end I think it all comes down to whether anyone cares enough to fix it. I don't see why we can't have Legacy workarounds in the levels if people are willing to make the changes. The question is whether anyone cares enough to make those changes. Is there anyone who is willing to "fix up" the problems described in the original post so that the levels work under Legacy? If not, well, um, they're obviously not going to get fixed :-)

Share this post


Link to post
fraggle said:

In the end I think it all comes down to whether anyone cares enough to fix it. I don't see why we can't have Legacy workarounds in the levels if people are willing to make the changes. The question is whether anyone cares enough to make those changes. Is there anyone who is willing to "fix up" the problems described in the original post so that the levels work under Legacy? If not, well, um, they're obviously not going to get fixed :-)

Yeah, and after fixing it for Legacy don't forget to make sure that the map still works with the 503849058 other ports it worked with before.

Share this post


Link to post

Not completely on topic...

Why was Freedoom targeted at Boom and not Vanilla Doom?

I'm just wondering as I've never come across anything that explains why Boom was chosen over.

Share this post


Link to post
Gez said:

Boom features that ZDoom doesn't support are rare and rather obscure, like Boom TRANMAPs.

I'm not sure exactly how or why, but there also seems to be some sort of timing difference with voodoo dolls on conveyor belts in ZDoom, as well.

I don't know whether it's different conveyor belt behavior, different player movement behavior, different walkover-line behavior, or something else, but I found it nearly impossible to make spinning ceiling fans that worked in both Boom and ZDoom a few months ago -- the timing required for one would break it horribly in the other. ><

Share this post


Link to post

I have never understood what the deal is with the entire voodoo doll thing. There are two simple ways to fix it:

1. Restore the original player spawning functions. Why were they changed in the first place?

2. Put in a hack to explicitly spawn an object that at least acts like a voodoo doll at extra player starts during single player games, if this is for some reason more simple than the first option. The most important things that voodoo dolls can do is damage the normal player, and trigger linedef effects. Any object could be made to behave like this, even if it has nothing else in common with the classic voodoo doll.

Neither of these are hard. Either of these could be done in spare minutes. Why then has it been broken all these years, with vague promises of "it'll be fixed in the next version," which has never been and evidently never will be released? It's nonsense of the most classical form.

Share this post


Link to post
esselfortium said:

I'm not sure exactly how or why, but there also seems to be some sort of timing difference with voodoo dolls on conveyor belts in ZDoom, as well.


There's 2 issues:

1. ZDoom averages the scrolling speed across all touching sectors. This is compatibility optioned because it caused massive problems with Caverns of Darkness.

2. Some time later Randy added a fix for slow scrolling sectors. Unfortunately I caught this far too late to redo it properly. This is a really problematic change because it fundamentally alters how the scrollers work. It should have been compatibility optioned with the same setting as the first point.

Quasar said:

1. Restore the original player spawning functions. Why were they changed in the first place?


It had something to do with multiplayer spawning, if I remember correctly. AFAIK Legacy collects all player starts when parsing the map and only spawns them later, even in singleplayer. Of course the classic voodoo doll scenario with multiple starts for the same player only causes the first set of coordinates to be overwritten instead of spawning a voodoo doll.

Sadly this is a typical sign of port developers not thinking their changes through. It's not the only such change in Legacy (one that bothers me as much is that if you touch a damaging sector you get damaged immediately unlike in all other engines) and in ZDoom it has also happened on occasion (see the conveyor issue above) but I have tried to address the issues that were causing real problems, either by adding a compatibility option or a workaround that makes it work in a predictable fashion that does not break old maps.

Share this post


Link to post

Last night I tried prboom again. I had got it running but had not tried it much. It does not have free-look, and does not have jumping.
Because in prboom the mouse controls are fixed, I kept trying to aim at the monster (fingers have habits) and prboom would run me up into its arms. Not having free-look nor jumping, is like going from Quake back to Doom1.

I checked the door speeds using prboom. Same problem, but I discovered something. Using the mouse to move gives a higher speed than using the keyboard (forward key). It is very easy to set the mouse sensitivity to get some unreal speed. But those of us who use the keyboard forward and reverse are limited to normal walk and run. The walk and run speeds are not fast enough to get to those fast doors.

I also tried the "factory" level. This level has all those crates that just beg to be climbed upon, but I could not get up on them with prboom. With any jumping you simply get up on the crates, and can cross them easily. With prboom, you have to attack the control room first, open the far doors, and take a round about path.

Tried that switch that controls the silver lift. Using prboom was even worse than Legacy, and I could not even get near the thing in time. It simply took too long to steer around the crates. Gave up after 6 tries, it was easier to use the cheat.

Level13 is still broken using prboom. The complicated door that uses the zombie works under prboom, but that is the only improvement. It is still unsolvable. I ended up with a yellow key and nothing to use it on. At higher levels you end up with a red key (they are right on top of each other in the editor), but that just leads to a dead end
room that the player cannot get out of.

Share this post


Link to post

From what I have read, the zombies have been a consistent problem, partly because they are an accident of the original engine, and also because they are not part of any standard and every engine has different behavior.

As a professional programmer I have to tell you that using an undocumented "feature" usually leads to this same problem. The support software gets updated and the "feature" changes or get eliminated.
Now the person who used the "feature" wants the "feature" brought back because the old version had it, and the support staff want to update their software without keeping every old anachronism, and it becomes a fight-to-the-death.

I suspect the Legacy developers got rid of zombies because they were full of problems and I cannot disagree with them on this viewpoint. I am reluctant to reverse their decision and reintroduce something that was accidental, inconsistent, and a headache.
Wad developers who rely upon such "features" of some particular engine are asking for problems. I do not know of any original Doom level that uses zombies, and those levels are reported to work on Legacy, the ones that I have tried certainly do.


I only know of one zombie in FreeDoom and that could be eliminated with less trouble than it takes to argue about it.

It makes me wonder what the real reason is for wanting to hang on to this zombie use ??

Share this post


Link to post

Maybe they haven't been used much in Freedoom (yet?) but with conveyors voodoo dolls greatly expand what Boom can do, acting like a mechanic form of "scripting" which can be done in an intuitive manner by people familiar with DOOM mapping. Instead of using text to script certain events, you use map mechanics. Is it worth taking out because some port which even promises to include them in the future broke the effect? I would say that breaking voodoo doll behavior is one of the things that made Legacy much less popular than it once was. Voodoo dolls are an old and well known phenomenon (known since very early mapping in '94), and are even used in Final DOOM (in both Plutonia and Evilution).

wesleyjohnson said:
I suspect the Legacy developers got rid of zombies because they were full of problems and I cannot disagree with them on this viewpoint.

You do disagree with them, as they've stated they're putting voodoo dolls back in.

As a professional programmer I have to tell you that using an undocumented "feature" usually leads to this same problem. The support software gets updated and the "feature" changes or get eliminated.

As you'll see with time if you become more familiar with DOOM stuff online, it's quite documented, at least anywhere where people are familiar with WADs and source ports. Boom didn't remove or change voodoo doll behavior on purpose because it was useful (they would know, as the engine's coders were part of TeamTNT, and everyone who worked on Final DOOM was from TeamTNT).

Vermil said:
Why was Freedoom targeted at Boom and not Vanilla Doom?

I'm just wondering as I've never come across anything that explains why Boom was chosen over.

The was a recent thread that brought this up. Essentially, people chose Boom because it's generally widespread in engines and gets rid of Doom's hard-coded limitations, adding some handy extra features. Originally, PrBoom more or less inspired Freedoom (as free software, making a demand for a free IWAD), and it's essentially a port of the Boom code tree.

Share this post


Link to post
wesleyjohnson said:

As a professional programmer I have to tell you that using an undocumented "feature" usually leads to this same problem. The support software gets updated and the "feature" changes or get eliminated.
Now the person who used the "feature" wants the "feature" brought back because the old version had it, and the support staff want to update their software without keeping every old anachronism, and it becomes a fight-to-the-death.

There is no official documentation for anything with Doom. It's all undocumented :-)

Share this post


Link to post
wesleyjohnson said:

As a professional programmer I have to tell you that using an undocumented "feature" usually leads to this same problem. The support software gets updated and the "feature" changes or get eliminated.
Now the person who used the "feature" wants the "feature" brought back because the old version had it, and the support staff want to update their software without keeping every old anachronism, and it becomes a fight-to-the-death.



Welcome to the real world! Down here it's not all nice and clean. Mappers tend to (ab)use side effects and bugs and more often than not this will create problems for the developers.

Now, you can do this in two ways:

- try to remain as compatible as possible without compromising your engine
- let some maps be broken because you can't or don't want to bother with the problems.

It's a fine line and the decision what to do is not always easy. The voodoo dolls are a clear case though: It is pretty well defined how they need to act and nobody in the Doom community thinks that they are something that can be removed from a port without seriously damaging it (well, apparently for the old Legacy developers which, BTW, are long gone.)

Share this post


Link to post

A lot of things in Legacy can be explained by coders like Hurdler not being familiar with what went in to the map creation of Doom.

About the dolls though... I once asked him to get the Voodoo dolls back in. But he decided against that because he didn't know when they had been removed or how to reinstate them. Someone on the team also proclaimed that they were very problematic to keep in.

Share this post


Link to post
kristus said:

About the dolls though... I once asked him to get the Voodoo dolls back in. But he decided against that because he didn't know when they had been removed or how to reinstate them. Someone on the team also proclaimed that they were very problematic to keep in.



The team apparently had too many members that should better have kept their hands off the Doom source... :D

Share this post


Link to post
wesleyjohnson said:

I only know of one zombie in FreeDoom and that could be eliminated with less trouble than it takes to argue about it.

It makes me wonder what the real reason is for wanting to hang on to this zombie use ??

There's another in Map02 which raises a set of walkways in an outdoor nukeage pit when you press a switch. I suppose you took a running jump to clear those.

They're handy for implementing simple scripted events that would otherwise require a scripting language and limit the number of ports a map can be played on. Some of the functions performed using voodoo dolls could be done using monsters and generalized linedefs - for others they're indispensable.

Share this post


Link to post

One way to use FreeDoom with vanilla Doom engines is to use the Oblige/ObHack (my enhanced Oblige II) random map generator to make a megawad of FreeDoom levels. The levels generated by this program don't use any non-standard features, and should be playable even with ID's original Doom 2 engine.

The current Oblige 3 doesn't have FreeDoom support, but Oblige 0.97 and ObHack do have this support.

ObHack can be downloaded here:

http://samiam.org/slump/

- Sam

Share this post


Link to post

I might add that the same technique is still possible in Legacy. Only you have to replace the player with something else and give all the action lines a special flag (that I can't recall now)

Though it's still not possible to fix maps like Dystopia map04(?) w/o adding additional scripts.

Share this post


Link to post
kristus said:

I might add that the same technique is still possible in Legacy. Only you have to replace the player with something else and give all the action lines a special flag (that I can't recall now)

Though it's still not possible to fix maps like Dystopia map04(?) w/o adding additional scripts.

You can only use Boom generalized lines if you do this, though, as they can have the monster-activate flag set on them. With Doom's other specials, only a couple can be monster-activated, and they're pretty much all useless for voodooscripting with. For a lot of cases you could make it work using generalized lines, but anything that needs to affect, for example, lighting, can't be replaced.

Share this post


Link to post

What he meant is that Legacy has a little known line flag called 'alltrigger' which makes activation by anything possible for all linedef types.

Share this post


Link to post

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...