Does anyone here still use Doom Legacy?

With Legacy 2.0 in the works, I figured I'd reflect on this nice little port.

Sure, it doesn't have the modding capabilities of ZDoom or Skulltag, but it holds its own in the source port market, particularly with 2 player split screen (soon to support 4 players).

Just grab Oblige, some good co-op WADs (hopefully supports Plutonia 2), some DWANGO WADs, and you and a friend can either team up against the spawn of Hell or take turns shooting each other in the ass - on the same machine.

The split screen is what particularly drew me to this port. I wanted a way to blast Hell spawn with family and friends without having to use the internet (Skulltag and ZDaemon work for internet games, Legacy is best left for LAN).

Now I use Doom Legacy for my primary single player Dooming (even set up a classic control scheme: W/S for movement, A/D for turning, Q/E for strafing, CTRL to fire, SHIFT to run, SPACE to open doors, "[" / "]" / "|" for weapon cycling ("|" is for "Best weapon") I'll probably set up the same in Skulltag and ZDaemon.

So, it all builds up to this: Do you still like Doom Legacy?

ReMooD!!!

Legacy?

Not me. Though it was one of the first ports I used when getting back into Doom. However it quickly depreciated after I ran into it's limitations. Limitations such as crashing alot, weird audio, not having as much Vanilla support as PrBoom or enough mods to justify that lack of support like ZDoom (which mostly had that support and Boom). Nevermind the mess of menus.

Still, I liked the splitscreen. I really like the Doom-esque blood splats, sure ZDoom's are way better but inherently less classic feeling and that's my point. Also I really like the DOOM64 style HUD. I'm sure even I could code it for ZDoom but I'd also like to see it in PrBoom-Plus and the Eternity Engine for consistency and aesthetics. They could probably rework Eternity's graphical hud a bit fairly easily but eh I'm sure I'm just weird for wanting it.

Anyway you might want to check out ReMooD. I know I do from time to time, biggest thing I want from the project are better Vanilla support (CHECK), stability (CHECK) and better simple menus (CH-err, Maybe?) for instance, if there is a single profile then stop asking which one I want to use.

Maybe I've just grown picky and senile in my older age but I still wouldn't mind a phoenix like rise for Legacy 2.0 or ReMooD but Eternity still needs it's rightful time in the spotlight too and will hopefully see it soon.

Legacy 1.4 is far too buggy and unstable to be considered useful. So no, I'm not using it at all and inevitably I won't play maps that require it.

Regarding v2.0, it looks like nobody works on it so I don't see the current situation changing for the foreseeable future.

1.28 was the best verson. 1.32 was ok too, but I personally liked the versions with the cool water effects.

I'd use remood, but it has no networking at all, which was Legacy's only strongpoint. So, I've abandoned that port for the time being.

I don't seem to get the random crashes people are always complaining about, so I still use it quite a bit.

Sadly the pace of development is still pretty much a crawl, but we understand that the devs have pretty hectic work lives and don't always have the time to work on 2.0.

I'm thinking about trying to find a working version of Legacy so that I can play Phobia: The Age. I'd never use Legacy aside from that, for reasons already stated.

I think you probably need the latest version 1.42 (Birthday version) for Phobia. I can't say for sure though. I've not tried it with any other.

Doesn't it work in GZDoom? It was part of Graf's benchmarks.

I guess you can say that it sort of works in GZdoom. Last I checked anyway.

Gez said:

Doesn't it work in GZDoom? It was part of Graf's benchmarks.

Yes, if you like slow. Performance in Legacy with this map is amazingly fast compared to GZDoom with the same computer. Note that this is considering a computer from the time Phobia was released. I know it's playable now, but that wouldn't make it playable on that mid 00's computer. Inexcusable? Somewhat.

Slightly on topic, does anyone have any suggestions for other maps suitable for inclusion here?

Icerial 2 by Kaiser.

The shots of Nimrod aren't awesome. :p

Csonicgo said:

Yes, if you like slow. Performance in Legacy with this map is amazingly fast compared to GZDoom with the same computer. Note that this is considering a computer from the time Phobia was released. I know it's playable now, but that wouldn't make it playable on that mid 00's computer. Inexcusable? Somewhat.

It's slow because it uses a huge amount of small 3D floors. GZDoom is just not optimized for this sort of thing and the code is far too messy so I never had the motivation to change it, especially if it's only for one WAD that's officially unsupported.

The only way to address this would be to fully precalculate wall geometry but this single issue is really the only thing where it'd provide a speedup. I messed around with it but in all other situations it doesn't help one bit because the savings in not setting up the wall geometry each frame is easily outweighed by the increased CPU cache misses this will incur. I think this is one of the reasons why so many other GL ports break down performance-wise on large maps. They went in with the assumption that keeping this stuff precalculated is fastest by default but here this clearly is not the case.

If you take out the 3D-floor chains in the scene I used for benchmarking the performance will be more than adequate, btw.

DooMAD said:

I don't seem to get the random crashes people are always complaining about, so I still use it quite a bit.

Sadly the pace of development is still pretty much a crawl, but we understand that the devs have pretty hectic work lives and don't always have the time to work on 2.0.

Agreed, its worked on all the PCs I've had over the years.

I consider it dead, despite the less than snail pace development of Legacy 2.0, and have done for a few years now. I still tinker with mapping, despite not actively playing it, but largely stick with GzDoom now.

I wonder how many of the "bugs" people these days experience with Legacy is simply due to the march of technology. I wouldn't expect older software to nesscerilly work 100% with the latest hardware and software. Doom95's mouse issues are an example of this.

I think the Allegro library they used was a piece of shit. But that's only one thing. The engine itself is also buggy as hell if you know where to look.

Graf Zahl said:

The only way to address this would be to fully precalculate wall geometry but this single issue is really the only thing where it'd provide a speedup. I messed around with it but in all other situations it doesn't help one bit because the savings in not setting up the wall geometry each frame is easily outweighed by the increased CPU cache misses this will incur. I think this is one of the reasons why so many other GL ports break down performance-wise on large maps. They went in with the assumption that keeping this stuff precalculated is fastest by default but here this clearly is not the case.

I fail to see how the presence of a geometry caching scheme automatically means an increase in CPU cache misses. All this shows is that the approach you tried wasn't suitable.

DaniJ said:

I fail to see how the presence of a geometry caching scheme automatically means an increase in CPU cache misses. All this shows is that the approach you tried wasn't suitable.

Yeah, just adding a few fields to some data structures to handle the data needed for precalculation and I got 20% performance loss. It happened without adding any code so it could only be the cache.

I'll assume you simply augmented subsector and seg/sidedef (depending on your wall rendering strategy). If thats what you did then yeah, I can see why that would result in cache misses and imo, its too fine-grained to ever be efficient.

There is no reason to think that other approaches would suffer the same problem.

That may be but I just can't find anything that really helps in cases where not an extremely high number of 3D floors is involved.

The time for generating the rendering data is just not high enough compared to BSP traversal or actually passing the data to OpenGL.

Here's a benchmark of a really large map that renders a lot of linedefs:

Map map09: "hobb's end horror",
x = -2948.9402, y = -3467.5623, z = 681.0000, angle = 270.0110, pitch = 13.3594
Walls: 6421 (0 splits, 548 t-splits, 21043 vertices)
Flats: 2046 (11582 primitives, 60080 vertices)
Sprites: 150, Decals=0
W: Render=3.864, Split = 0.000, --->Setup=2.040, Clip=2.929
F: Render=1.107, Setup=0.580
S: Render=0.101, Setup=0.311
All=15.743, Render=7.224, Setup=7.311, BSP = 1.442, Portal=0.000, Finish=1.132
DLight - Walls: 0 processed, 0 rendered - Flats: 0 processed, 0 rendered
Missing textures: 0 upper, 7 lower, 0.008 ms
65 fps

The one value marked with an arrow is the only thing in here that would benefit from precalculated geometry and it's maybe 12% of the overall time required to render the entire scene - which can't even be saved fully. I'd be lucky if I got time savings of 1 ms out of this. And that's just not worth the hassle.

(Oh, and just in case you are interested: Doomsday manages 9 fps in the same scene on the same system.)

Graf Zahl said:

That may be but I just can't find anything that really helps in cases where not an extremely high number of 3D floors is involved.

The time for generating the rendering data is just not high enough compared to BSP traversal or actually passing the data to OpenGL.

If that is truly the case, with geometry generation being completed faster than the traversal of the BSP itself; then that is either a really impressive feat (seriously) or the BSP traversal is hamstrung by something else.

Oh, and just in case you are interested: Doomsday manages 9 fps in the same scene on the same system.

Thats understandable. Remember that the Doomsday renderer is essentially the same today as it was when it was first written a decade ago for Voodoo3-level hardware. Granted there have been many new features to embellish the world such as fake radiosity but the basic approach and core loops haven't changed.

DaniJ said:

If that is truly the case, with geometry generation being completed faster than the traversal of the BSP itself; then that is either a really impressive feat (seriously) or the BSP traversal is hamstrung by something else.

By what? It's a standard issue rendering loop that's nearly identical to the software renderer. The only major difference is the clipper which uses angles instead of display columns for precision reasons.

The time in my above post listed for BSP is just the RenderBSPNode code, nothing else. As soon as it starts processing a subsector other timers get started (like 'Clip' for walls which is also just standard code from the software renderer with only minor adjustments for the clipper.

DaniJ said:

Thats understandable. Remember that the Doomsday renderer is essentially the same today as it was when it was first written a decade ago for Voodoo3-level hardware. Granted there have been many new features to embellish the world such as fake radiosity but the basic approach and core loops haven't changed.

Yeah, the basics of GZDoom's renderer are approximately the same age... ;)

Graf Zahl said:

Yeah, the basics of GZDoom's renderer are approximately the same age... ;)

I don't see how you can possibly argue that given that you yourself have declared "renderer rewrite" in the GZDoom changelogs several times since the project's first release. Not to mention that you are using stuff like shaders and stencils that obviously weren't even thought of back then.

By comparison, the most "advanced" GL feature used by the Doomsday renderer is two texture units if available.

DaniJ said:

I don't see how you can possibly argue that given that you yourself have declared "renderer rewrite" in the GZDoom changelogs several times since the project's first release. Not to mention that you are using stuff like shaders and stencils that obviously weren't even thought of back then.

I said 'basics' - which includes all the relevant parts of this discussion. And that part of the renderer is basically still the same code I wrote 10 years ago (and the stencil buffer code is also already 8 years old so it hardly deserves being called 'advanced' by now.)

None of this advanced stuff has much of an impact on processing speed, neither positive nor negative. If I force GZDoom to switch off everything more modern than stencil buffers (which are only used for flooding texture gaps unless some advanced ZDoom features come into play) the speed is roughly the same as if I started it with all available options.

By comparison, the most "advanced" GL feature used by the Doomsday renderer is two texture units if available.

Ok, but that is not the reason for the weak performance on large maps. The one thing that really kills performance on large maps is the way the data is maintained. On large maps this time tends to increase to an amount that really makes a map unplayable.
I can't say much about how Doomsday handles it but I saw with ZDoomGL how badly handled geometry updates could totally break down performance.
It really was ironic: The engine had a supposedly 'neat' system to keep all map geometry in 'efficient' data structures but then ended up wasting several times as much time keeping it up to date than it would have cost to just recreate this stuff each frame.
Another thing I found out while analyzing this was that true frustum culling is something that isn't worth bothering in Doom. It just costs too much time and except for rarely occuring situations always takes far longer than just processing a bit of additional geometry.

I use to use Legacy til my old computer died and got a new computer which has windows Vista. Sadly As far as I know, Doom Legacy doesn't work on Vista :(

Graf Zahl said:

Ok, but that is not the reason for the weak performance on large maps. The one thing that really kills performance on large maps is the way the data is maintained. On large maps this time tends to increase to an amount that really makes a map unplayable.
I can't say much about how Doomsday handles it but I saw with ZDoomGL how badly handled geometry updates could totally break down performance.
It really was ironic: The engine had a supposedly 'neat' system to keep all map geometry in 'efficient' data structures but then ended up wasting several times as much time keeping it up to date than it would have cost to just recreate this stuff each frame.

Currently Doomsday opts to rebuild the geometry of the visible portions of the map every frame. A few specialized data structures exist for stuff like dynamic lights but the map geometry is rebuilt entirely.

I'm rather surprised to hear you say shaders haven't had a significant impact on performance though. What are you using them for?

Another thing I found out while analyzing this was that true frustum culling is something that isn't worth bothering in Doom. It just costs too much time and except for rarely occuring situations always takes far longer than just processing a bit of additional geometry.

On the left/right view plane I am inclined to agree what with efficient angle clipping.

DaniJ said:

I'm rather surprised to hear you say shaders haven't had a significant impact on performance though. What are you using them for?

On modern cards: everything except 2D graphics. The entire 3D rendering uses shaders on SM4 cards. On SM3 it's only selective for features that need them and on SM2 (where shaders are just too slow) they are only used for applying special colormaps (like the inverse invulnerability map) to camera textures.

But I'm using them for the features, not performance. The following features have shader implementations, the one marked with a (*) are implemented only as shaders:

- special colormaps
- warped textures
- brightmaps (*)
- texture glows (*)
- radial fog (*)
- brightening of the area near the player (*)

I also did a dynamic light implementation using shaders so that no multipass rendering is needed but surprisingly this is about the same speed as rendering each light in a separate pass on my GF 8600. Sometimes it's a bit faster, sometimes slower, depending on the amount of data that needs to be transferred.

JDoom is slow not because of dynamic lighting, radiosity, etc or because it rebuilds the geometry of the visible portions of the map every frame. JDoom is slow because code is not optimized. Not because the basics of renderer is 10 years old. PrBoom-Plus also "rebuilds the geometry every frame" and "the basics of renderer is also 10 years old", but I have 400+ fps at start on nuts.wad and 20 in jdoom (~20x), I have 100+ fps after awakening all monsters and 0.1-1 fps (100x) in jdoom with ALL FEATURES OFF. JDoom is 10x slower on hellcore2 map09, etc. Not 10%, not 50%, but 10x, 20x or 100x.

Yeah, it's possible to play some maps with JDoom!, but only some. Even Chocolade-Doom supports more wads than JDoom. There is no support for Boom, there is no support for common renderer tricks, so even vanilla maps can't be played properly. GZdoom was born, got gazillion features and reborn, but JDoom still in "beta6" infinite loop. And what are we waiting for? 1.9 declares no boom support and even less support for tricks or no support at all! What for? Please, explain.

entryway said:

JDoom is slow not because of dynamic lighting, radiosity, etc or because it rebuilds the geometry of the visible portions of the map every frame. JDoom is slow because code is not optimized.

You are correct and I fully agree.

Yeah, it's possible to play some maps with JDoom!, but only some. Even Chocolade-Doom supports more wads than JDoom. There is no support for Boom, there is no support for common renderer tricks, so even vanilla maps can't be played properly. GZdoom was born, got gazillion features and reborn, but JDoom still in "beta6" infinite loop. And what are we waiting for?

Doomsday is being completely rewritten from the ground up. A new architecture, emphasizing the use of plugins and a overall generality into a "real engine" rather than a "DOOM engine".

The course of development in the 1.9.x/2.0 series has seen us move to floating point math, integration of our own nodebuilder, a new core OO scripting system, internal map structure limits increased in excess of of those in any other port and currently we are in the process of switching to C++ and an OO unified client/server design throughout (i.e., single player games will be client/server too).

Not exactly insignificant changes, so you can appreciate this takes time.
Doomsday development Roadmap

1.9 declares no boom support and even less support for tricks or no support at all! What for? Please, explain.

This is because the methods used by Doomsday previously had a very low success rate and could result in just as many problems as it attempted to solve. So I removed pretty much all support for tricks. Now that we have our own internal nodebuilder and a new map representation support for tricks will return in a later release.

This thread sure did go offtopic with JDoom/GZDoom banter :)

I used to use Legacy until the main-now Newdoom site stopped being updated but havn't bothered to track their new site, so I just used a ZDoom derivative (Skulltag).