DoomLegacy 1.44 Alpha5 Release

The DoomLegacy 1.44 Alpha5 Release (SVN 1089) is at:
http://doomlegacy.sourceforge.net/

The source code is posted as well as some Linux binaries. Some other ports, like Win and X-Win, would be there too but our site manager has been preoccupied lately. At least the Source is there, so some users can compile it themselves, at least.

This is the last Alpha release before it gets released as Beta, (1.45).
It is about 90 patches since the Alpha4 release, some of which are significant.

New Features:

> Launcher is built into DoomLegacy. It is activated when the IWAD cannot be loaded, legacy.wad cannot be found, or if there are no switches on the command line.
> Corona drawing with sorted draw, with some menu options.
( OFF, SPRITE, DYN, AUTO )
> No secrets, no possible kills, or no items on a level, draws a dash instead of 0%.
> Monsters stuck on a door frame code, with menu to select (Vanilla, MBF, Boom)
> New menu sounds that are much less harsh than the pistol shot have been added to legacy.wad. Has a menu selection.
> Remove limits on flats.
> Makefile compilation system with an external control file (make_options).
> Change preferred directory name for savegames to ".doomlegacy" ( "doomlegacy" for win/dos ). Will also check for existing ".legacy" (legacy) directory. When not found, will create ".doomlegacy".
> Splash screen, finale, and menu screens are now centered in the monitor window.
> Add a -screendeg command line option, which is a generalization of -left and -right, to support surround monitor setups.
> Easier alternate button names for binding mouse buttons and joysticks.
> Error message screen now appears sooner, with more of the important error messages.

Bug Fixes (a few of the 46 listed in WhatsNew doc):
> Increased savegame buffer freespace to 64K to handle the large number of thinkers in hth2.wad (which needed 12K).
> Fix drawing of DeepWater, for several situations in ic2005.wad where textures are drawn pegged to mobile deepwater sectors.
> Restore the palette after the Heretic E2M8 ending pic is shown.
> Fix sound effects to cut off sounds such as the chainsaw. Finer control of stopping sound effects is provided.
> Fix Boom DeepWater colormap error for hardware renderer.
> Hardware drawn sprites occluded by transparent walls behind them.
> Applied patches from Alexey Dokuchaev to fix FreeBSD issues.
> Fixed free memory printout which was always printing "Free 0".
> Restore previous t_runscript and t_running commands so older wads that used them can bind them to keys. Chex newmaps scope works again.
> Create and Free Extra_Mapthing, used for FraggleScript created mobj that can respawn or can Nightmare respawn. Savegame now saves Extra_Mapthing as an optional section.
> Nightmare respawn modified to fix several bugs. Added better fix for nightmare respawn at (0,0) as used in prboom and eternity.
> Hardware draw of Boom 160 tagged translucent fixed.
> Fix updates of player viewheight to provide a slow rise and fall for changes to the cv_viewheight.
> Disable menu movement from the mouse for a short interval (about 4 seconds) after each key press.
> Check for a sound lump using plain name too, to find the amb sounds in hth2.wad, which were defaulting to pistol. Playing hth2.wad has the ambiance sounds now.
> Improved the software draw sprite ordering on 3d floors, where the sprite would be drawn under the floor. It does not cure a similar problem with railings, which are higher than dead sprites.
> Fix the demo playback so it will play our own 144 DL format correctly.
> Boom demo playback improved, removed a segfault condition and some incompatibilities. Added Boom stuckdoor code for demo playback. Still does not sync for very long.
> Boom Midi music lumps will now play when using older SDL library option.
> A central message function now consistently handles all messages, routing them to console, log file, and stderr text as directed by EMSG flags. Error, debug, verbose, and other special messges, use this facility.
> Search LEGACYWADDIR, default dir, and doomwaddir for legacy.wad.
> Linux-X11 Opengl library loading is fixed. It previously would fail loading and leave the user in software render mode.
> Hardware draw polygon vertexes are handled more cleanly. Some panels that were missed in polygon generation, are now drawn.


It looks like OS2 and Voodoo card support will be dropped due to lack of any response, and no one will admit they still run either.

Good job, man! It's nice to see Legacy getting some love. In the day, it was probably the most ambitious port, and, it still has some unique features.

I'm specifically interested in the sprite sorting - does it just shift things around a bit to improve some staged cases, while making others worse, or does it actually improve on the algorithm?

On the demo sync thing, if you're highly interested, I wrote a set of modules designed to be dropped into a semi-conformant C doom port that make a huge difference in tracking sync errors. It's just as helpful for net sync. I built it while working with Maes on Mocha Doom. With my first version, we got all the original demos running in sync. It's been a while since we did that, but I don't think he's released his new version yet.

So, again, if you're interested, I'll work with you on it. I just hate to see that toolset sit around and collect dust :) I actually have it IFDEFed into my main code base now.

Send me a PM if you're interested and willing to give it a try. I *know* Legacy has a good chance, as long as the code does not drastically deviate from Boom-style structure.

Anyway, keep up the good work!

Thanks, It is nice to hear from someone with something positive to say.

I think the DoomLegacy team has officially given up on demo sync, so it is not a high priority. I take a swipe at it, on passing, every now and then. If you post those tools on a share site, or somewhere, I will probably download them for future use. Thanks. It won't be soon because I have many untended business projects that I need to get back to.

No problem, you deserve it!

For the demo sync: Don't give up! What I am offering is complete email assistance in getting DoomLegacy to play the original demos in sync. Again, my motivation is to see my tools get used.

I wish I had a way to convince you of how easy it is to find the bugs, using my toolkit! My guess is that we have it playing the Doom II demos in 2 to 4 weeks of daily emails or so.

The toolkit compiles with your code (4 .c and .h files, with a sprinkling of IFDEFed one-liners in various specific places in your source), and does a runtime analysis of the demo, tic by tic, to a file. This makes a very interesting, easy-to-read, yet highly-compressed file. You zip the file, and send it to me, and I run my comparison tools, and tell you which DoomLegacy function is causing the first demo desync. Then you fix that function, and run another analysis. Rinse and repeat.

Once the first demo plays correctly, the others are probably close behind.

Again, I offer my assistance, but only if you are serious and motivated - I don't have time to waste.

Trust me, we can do it. My port started out as ZDoom 1.11 of all things. Then, I proceeded to make, literally, thousands of crazy changes, just playing around with the source. I really messed the source up! I should have started over, but I didn't. Eventually, I made ways to make all of my goofy changes configurable, and I started to get interested in demo sync. That's when the SyncDbg toolkit was born.

I eventually got rid of every demo sync bug, and then I got rid of every net sync bug. We play multi-hour coop sessions without any problems.

So, if you are serious about wanting demo sync/net sync, drop me a PM and we'll get started.

I still use Legacy regularly - Keep up the amazing work :)

Awesome to see Legacy get some love. My friends and I played this engine exclusively 10 years ago.

Btw kb1 I apologize if you mentioned it and it didn't register but what source port is it that you work on?

I use this port for split-screen multiplayer, a thing that other ports fail to make easily usable or even work. The only reproach I ever had was that I couldn't setup multi-gamepad support.

Keep up the good work! I wish you good progress in the development of this port.

axdoom, I reccomend you use XPadder for Doom Legacy splitscreen. It's very fun.

I seem to be having an issue with the latest version of Legacy, it never saves my config, meaning I always revert back to 1.42, the 'birthday edition'. Any idea why it reverts my config every time?

I also prefer the external launcher, makes setting the game up far easier.

There are some other glitches present as well, such as the engine crashing when splitscreen is enabled and a player goes underwater or walks accross a 3D bridge.

Mike.Reiner said:

Awesome to see Legacy get some love. My friends and I played this engine exclusively 10 years ago.

Btw kb1 I apologize if you mentioned it and it didn't register but what source port is it that you work on?

For lack of a better name, it's KBDoom - basically, a demo-aware, MBF level port, with customization via scripting. It's what I call a "home port", which means that I haven't released it yet :) Eventually I will.

Wesley, I sure was hoping you had decided to try - I logged in just to see :( Let's give it a shot, man! Work with me for a week, and see if what I told you is not 100% true: Legacy can get demo sync, I guarantee it! PM me an email address to send the 24kb zipped toolkit to (we'll need it to correspond anyway), or I can put it up somewhere semi-private (it's not ready for public consumption, cause it's kinda useless without my support).

I know you're busy right now (aren't we all??), so let me know when you get some time. It was the best thing I could do for my port, cause now my port *feels* like Doom - even the new stuff I added to the port feels more vanilla-like.

Maybe afterwards, I'll put up a page somewhere, generalizing the process, so others can benefit if need be. I wish I had had this resource when I was struggling with my port.

kb1: cannot give it time right now, as I spent way too much time on several Doom projects and have to work on some other stuff.
DoomLegacy has wandered significantly from the Boom code (like faintly recognizable similarity).

DoomKid92: Need to know which version and OS you are using.
There are several reasons why it might not save config.
1. permissions
2. quitting DoomLegacy other than by using the QUIT
3. Something the launcher is doing

There was a SplitScreen crash that was fixed. Have not had one since.
Need a specific version, OS, wad, and location to debug such a thing.
Have not had crashes with 3d bridges. That might be a incompatible wad, which I would also like to know about.

wesleyjohnson said:

kb1: cannot give it time right now, as I spent way too much time on several Doom projects and have to work on some other stuff.
DoomLegacy has wandered significantly from the Boom code (like faintly recognizable similarity).

I know, you told me you're busy - I can appreciate that. Again, if you're serious about it, we can do it when you've got some time. I don't check DW every day, and I don't always look at every post, so sending me a PM is best.
On the wandering: I took a very quick look at your latest source last night, and I didn't notice any major obstacles. It will take you a solid 2 to 4 hours to implement the toolkit, and fit it to your source. From that point, we'll do one bug at a time, at your leisure.
Let me know when you're ready, or, if you're just not interested, let me know that too, if you would. Either way, it's all good.

kb1 said:

Let's give it a shot, man! Work with me for a week, and see if what I told you is not 100% true: Legacy can get demo sync,

Ever tried this approach with ZDoom? I believe you'd be everybody's hero if you brought it back to demo sync. ;)

fabian said:

Ever tried this approach with ZDoom? I believe you'd be everybody's hero if you brought it back to demo sync. ;)

No way it'd work with the current ZDoom codebase; and if you want to do it with an old codebase it'd be pointless because Odamex already exists.

It could certainly be done - imagine taking PrBoom plus source, and adding it into ZDoom in bulk - yeah, it could work, but I'm sure that's not what you were thinking of :)

My process is iterative: your run the target port alongside known working source, until a game-world-level difference is detected. You then do what it takes to solve that discrepancy. Now, maybe it plays till Tic 5, and deviates. Then you go fix that issue. You are always directed to the specific tic, usually to the specific function, and likely to the specific mobj, in cases of monster AI issues.

Soon enough, you get through the first demo (which gives demo 2 a much better chance of just working :)

It could be done with ZDoom (correctly), with difficulty. My current tools assume that specific functions can be expected to do roughly what the equivalent vanilla (or Boom) function does. But, ZDoom has merged, split, and highly modified it's AI functions quite extensively, making it difficult to compare it's functionality to other ports.

However, as a temporary measure, you could probably add back vanilla wrapper functions, that call ZDoom's "smart functions" in a "known vanilla-like" way.

My original joke plan above is not totally unreasonable. One drastic, but reliable method would be to actually add back vanilla source, with functions prefixed with "debugsync_", like "debugsync_P_TryMove".

Then, you get *those* functions in sync, using my method. Finally, you start to move over to ZDoom's functions, one by one, correcting demo issues.

But, it may just not be worth it. With most source ports, the code needed for demo sync is quite minimal. But, for ZDoom, you may need to leave scores of "demosync_" functions in permanently, to coerce it into playing oldstyle demos. And, this may slow it down quite a bit, with all of the conditionals.

It's ambitious, anyway. I'd like to get a couple of more-vanilla ports under my belt first, before tackling that monster!

kb1 said:

But, it may just not be worth it. With most source ports, the code needed for demo sync is quite minimal. But, for ZDoom, you may need to leave scores of "demosync_" functions in permanently, to coerce it into playing oldstyle demos. And, this may slow it down quite a bit, with all of the conditionals.

Even then, you'd have no success. It's not only the AI that needs to be changed - this part is actually doable, albeit really tedious - but what will stop you cold is that ZDoom's thinker chain works completely differently - and depends on working differently.

You'd never be able to get the same thinker ordering as in the original game without causing massive problems.

Graf Zahl said:

Even then, you'd have no success. It's not only the AI that needs to be changed - this part is actually doable, albeit really tedious - but what will stop you cold is that ZDoom's thinker chain works completely differently - and depends on working differently.

You'd never be able to get the same thinker ordering as in the original game without causing massive problems.

Interesting. But, no, I wouldn't get "stopped cold" - too stubborn for that :)

It's doable, but again it falls into the "not worth it" category. Sounds like, in ZDoom, you'd have to conditionally switch to a more-vanilla thinker chain, for example, and somehow "glue it in" when an old demo is requested. I have no doubts that this would indeed cause major headaches. Another example is the sight-checking. And there's more where that came from.

Still, it *could* be done. But, I'm not interested in attempting it.

Now, there are those that might like to see some parts of ZDoom get reverted back permanently. Maybe there's an argument for going back to some older structures. Maybe the metric would be: "revert back that which is required to make the game play vanilla/Boom demos in sync." Each source port is guided by it's creator's own "philosophy". Who knows? ZDoom Classic, anyone?

Now, DoomLegacy is a much more realistic demo/net sync goal. Wesley, I'll keep bugging you about it every so often, unless you tell me you're really not interested. Say, every other month or so. No hard feelings either way.

kb1 said:

Now, there are those that might like to see some parts of ZDoom get reverted back permanently. Maybe there's an argument for going back to some older structures. Maybe the metric would be: "revert back that which is required to make the game play vanilla/Boom demos in sync." Each source port is guided by it's creator's own "philosophy". Who knows? ZDoom Classic, anyone?

I don't think so. Some of the more modern features depend on the altered thinker chain and would break horribly if that was changed.

So, attempting demo compatibility while retaining all newer features will cause some non-trivial issues.

Graf Zahl said:

I don't think so. Some of the more modern features depend on the altered thinker chain and would break horribly if that was changed.

So, attempting demo compatibility while retaining all newer features will cause some non-trivial issues.

Heh, what modern features do you need while watching a vanilla/Boom demo? :}

Are you seriously saying that you can't figure out how to get your port to conditionally store and traverse the original structures, and revert back once the demo is complete? Come on, man - you're a smart guy. I'm not saying that it would be elegant. Or trivial. But, it wouldn't be that bad, either.

Besides, what I was originally suggesting was that some people might just be ok with losing a few of the "more modern" features, if they gained vanilla+Boom demo sync. Naturally that idea deviates from ZDoom's direction, which is ok. But an ambitious developer could adopt such a philosophy, and could produce such a port. Of course it could be done.

Out of curiosity, what are some of the benefits that the altered thinker chain brings to ZDoom? And, what's an example of something that would break if it were changed? (Not arguing with you, seriously, I'm curious).

Wasn't this thread about Legacy?

Doom Legacy 1.44 Alpha1,2,3,4,5 Bug Warning: Quicksave has been writing outside the array it is supposed to be writing into. This corrupts some nearby variables, which manifests itself LATER as segfault and keyboard lockup.
This bug is in any 1.44 Alpha version that is compiled with the SAVEGAME99 code option.

The code in the subversion repository has been patched to eliminate this bug.

I advise to NOT USE QUICKSAVE until you get a later version.

It hits the next keyboard usage after doing a quicksave, but the saved game is correct. It appears that the worst that happens is that the program must be stopped and restarted from the quicksave savegame.
It appears to have hidden for so long because it does not hit vital variables, and only manifests if several quicksaves are done without an intervening game save.

Wesley Johnson, Doom Legacy Development Team.