DoomLegacy 1.48.14

Have committed the latest release of DoomLegacy, 1.48.14.

[ OLD: Binaries will be released, I don't know when, depending upon when the other people involved get around to that during this busy holiday season.

I have already reminded them about making the 64 bit binaries too. ]

[ EDIT: binaries are up at SourceForge

DoomLegacy 1.48.14 downloads at SourceForge

]

 

SourceForge-DoomLegacy

 

From the whatsnew.

 

1.48.14 SVN1657 (2023-11-30)

 

FEATURES 1.48.14

 

* UMAPINFO, derived from umapinfo-lib (GPL) written by Michael Bäuerle, who has allowed us to use and modify it in DoomLegacy (FR_0100). In DoomLegacy the original library code got heavily modified, eliminating use of FLEX and YACC, removing internal structure hiding, and making it embedded in DoomLegacy. Errors and messages were rewritten to attach to DoomLegacy error reporting.

 

* Add viewfit control. This allows a wider monitor to be used with drawing at correct aspect ratio.

auto: auto select based on actual screen size.

stretch: stretch to fit screen.

fit width: fit to screen width, scale to correct aspect ratio.

fit height: fit to screen height, scale to correct aspect ratio.

 

BUG FIXES 1.48.14

 

* In Pagodia.wad, Map06, the hanging vine texture had visual artifacts. (AUR008, texture #624, lump 132961). Due to some of the patch columns being totally empty, some of the columns of the generated texture had the 0xFF termination, in the wrong place. Fixes bug 687.

 

* In Lost Civilization Map04, the arch texture ARC1ABRN was rendered with black holes. The wad uses it on a wall and as a masked texture, next to each other. These two uses generate incompatible texture formats.

The use on a wall had texture generation using the TM_picture format. The masked use requires a TM_masked compatible texture format. To fix this, gave the masked texture draw the capability to generate an extra texture_render holding a TD_2s_ready texture.

 

* The MIDI output included some padding of Track 0, that caused the Win10 and Win11 MIDI player to delay the track and change it to a piano. Do not know why these were in the MIDI output. The Track 0 padding has been disabled, and may be removed entirely (eventually). The Program_Change inclusion is now enabled by control variable "midi_create_program", which is default 0. The midi compression is enabled by control variable "midi_compress", which is default 1. These are not in any menu, can be changed by console. This fixes bug 0674.

 

* Add JOYSTICK_SUPPORT compile-time option, so that joystick code can be disabled. This was necessary due to some port situations not having joystick hardware.

 

* Steven Newbury has been trying to compile for DOS. These are changes based on a something he summitted. I suspect this may not be complete. It covers some network problems with DOS. Within djgppdos, there are DOS sound fixes and many other fixes to bring the DOS port up to date with the interface.

 

* Fixing complaints from gcc 11.2. Also snprintf does not honor string max field size. Must copy possibly long strings to some shorter buffer first. The code_size seems to have been reduced by 56K, perhaps due to new compiler.

 

* Fix error from w104_23. When BOB_MOM code was made a standard feature, one of the compile tests was missed. Removing the BOB_MOM define, made some of the old code active again. This may have had some obscure effect upon when the weapon bobbing stops. Have removed that old code. Some other cleanup, ptr declares.

 

* Disabled a RANGECHECK in wi_stuff as many wads violate those assumptions. Fixed many other typo and ptr declares encountered while working on UMAPINFO.

Edited December 30, 2023 by wesleyjohnson : Update

I wish to thank those that contributed to the project with debugging information.

Many of the bugs fixed would not be found without them.  As I do not run Win10 or Win11 at all,

all bugs on those ports are dependent upon someone sending me detailed information and debug logs.

 

This is not everybody who has contributed.  These are the ones that I could find in the notes that I could actually find at this time.

But, Thanks to everyone, even those that did not get mentioned.  I know I must have missed somebody.

 

Michael Bäuerle : UMAPINFO, DeePsea tall patches, and reporting bugs in advanced wads.

 

latern424: MIDI on Win10 and Win11.  He sent a detailed report and ran a special instrumented version of DoomLegacy that finally diagnosed what was happening.

 

Adam Stylinski: Network packet analysis, and numerous detailed reports.

 

Steven Newbury: compiling on DOS

 

Mr. Rocket: who is always available for answering Windows questions, and testing things

 

Hey, @wesleyjohnson

 

This looks super exciting... congratulations. I am a user of 1.40 for DOS (mainly for Heretic), does the above mean there are DOS/Win9x compatible builds in the wild which have UMAPINFO support?

 

Anyway, appreciate the "official" binaries will be done when they are done, should the SF page be checked for downloads then?

No DOS from me right now as my DOS system is down.

 

I installed the latest Linux and have switched to it, and it may be a year before I have everything working again, if I ever get that far.

The DOS testing was being done by someone else, and we got as far as my fixing all the problems that he had found.

There is a fair chance that if you have DOS and a compiler that you may be able to compile Doom Legacy.

I had not achieved getting my compiler on FreeDOS to work.

Depending on your memory available you can enable and disable options in DoomLegacy.  There is not only the make_options, but also the doomdef.h file that can be customized.

 

UMAPINFO should work on DOS perfectly fine.

It also got support for DeepSea patches and some other modern blockmap stuff, so you can play Lost Civilization and some other modern wads.

 

There may be others who have a site where they post Doom Legacy binaries for additional systems.  I never know how long these things last, nor can I seem to keep track of them.

 

I have made contact and sent the binaries off to the team member with official access to the SourceForge account.

He did say that he can make the 64 bit binaries so they may get done this time.

We will have Linux SDL, Linux X11, and Windows SDL binaries.

It may compile for DOS and MAC too, and BSD and other unix-like.

 

The bug fixes in this version may be few, but they are notable, especially for Windows 11 users.  We finally got the music fixed on Windows 11.

 

The binaries are available at SourceForge.

 

DoomLegacy 1.48.14 downloads at SourceForge

Hi, I've downloaded the new 1.48.14 version from SF.net.

But when I run the program it says its 1.48.12 (rev.1642) :\

Then likely he messed up the packages, or that release script.  That would not be possible otherwise.  I will have to contact him.

He bumped the SVN to 1663 and I assumed he recompiled.  The Windows binary on SourceForge is NOT the one I sent to him.

It will take a while to track this back as the only Windows I have is the old XP system.

I get 1.48.14 on the Linux SDL1 version, so it is correct in the sources.

 

We have a script that supposedly was to automate the release process.  Somehow it has been grabbing the wrong files.

I have sent him another tar of the correct files, and this time I bypassed the script and did it by hand.

We hope to have the correct 1.48.14 Windows binary up on SourceForge soon.

 

SourceForge will not let me fix the problem directly.  I tried.

 

Update: The SourceForge files are being updated.

The script got the Linux download files too.  One has 1.48.10 in it.  I still do not know how it did that.

 

Any 1.48.14 downloads from before today cannot be trusted,  download them again after tomorrow  Jan 1.

It is easy to verify which version you have gotten, as the very first line printed out by Doom Legacy has the version number.

 

Update:  The bad files have been taken down.

The 1.48.14 windows binary is up on Source Forge.  I have verified that it matches the 1.48.14 windows binary that I made.

 

Edited December 31, 2023 by wesleyjohnson

The correct binaries are now up at SourceForge.

I have checked the downloads, and they appear to be the correct ones.

I played SDL1 for a while to verify that it was 1.48.14, and checked the SDL2 identify, and compared the downloaded files to the originals.

Sorry for the confusion.

DoomLegacy 1.48.14 downloads at SourceForge

 

The Release script will be dealt with.

Botmatch in FreeDM works great. Thank you. A real gift for the New Year.
I saw on the site that support for MD2 models is expected, is it just decorations on the map or also the player model and monsters?

There is extensive MD2 model code.  I think the MD2 applies to the players, and is only in OpenGL.  I have not had a model, or time from all the other debugging, to test it.

As I prefer the 24 bit draw, I have not been provoked to explore or verify that it still works.  At least I cannot remember doing so.   I do remember going through the code for some reason, some 10 years ago.

It has been there since before 1.44, or when I started with it some 20 years ago.

 

I have tested the skins, and that works, and is weird enough.  Dress your bots up as Bond, or some other weirdness.

You can find skin packs in the DW wad repository.

 

What is that picture you put up.  That does not look to be from Doom Legacy ?  Unless someone has been making very strange wads again.

 

 

3 hours ago, wesleyjohnson said:

That does not look to be from Doom Legacy ?  Unless someone has been making very strange wads again.

Even if the models only exist as decorations for the maps, it is very interesting. Unfortunately I didn't find any information on how to use this if I want to add new things.

I also wanted to add that yesterday I launched multiplayer between Win 10 and Win XP. It works. It works even if version ...14 is running on Win 10, and version ...12 on XP.
I was pleasantly surprised to find that downloading the necessary pwads is supported.

Screenshots, the one site page I never visit.

How did he have a screenshot, if it was coming soon. ???

 

I have not quite figured how to use MD2 either, but I suspect that it is on the command line.

 

Spent 10 hours today rewriting that release script.  Most of that was in manuals trying to make a directory search that would find the correct directory using some keywords, or either getting BASH to deal with multiple results.  I got it sorted out now.

 

Found that the soft-links it uses were all pointing to old directories.  That is in spite of my setting those soft-links to 1.48.14 directories, and I remember doing that several times.  That soft-link command usually gives me problems.  The rewrite of the release script does not require the user to change soft-links anymore, so fewer possible errors now.

 

Do not recommend multiplayer with older versions.  There were too many fixes to stop multiplayer from kicking players, and you should have all clients use 1.48.12 at least.   Multiplayer was not changed in 1.48.14, so the net compatibility is the same as 1.48.12.  There is a net version that is sent between server and client, to prevent using incompatible clients.

Edited January 3 by wesleyjohnson

I saw another of those claims that Doom Legacy is only partially Boom compatible.

If I knew of anything from Boom that Doom Legacy did not do I would have fixed it already.

So, the question is, what is this partial Boom compatibility about?

I would like to see something specific, like "it does not do Boom xxx", and then I could address that.

Please be specific.  Remember that when MBF compatibility was being worked, there were other fixes  from PrBoom that got done.

 

I found that the  1.48.12 x11 binaries were actually 1.48.10 x11 binaries.  More fallout from the release script.

A new package has been prepared (by hand) and is on it way.

 

1 hour ago, wesleyjohnson said:

I saw another of those claims that Doom Legacy is only partially Boom compatible.

I didn't write this. I just recently learned about deh and bex and started experimenting with these text patches. I tried this modification for the rocket launcher and found that in Legacy it doesn’t work very well with the mbfonly.deh patch: after a short time the game crashes and freezes (tested only for Win 10).

In addition, the possibility of adding a railgun attack is very interesting. Here in this link the lines after Code pointer 86 are indicated in the "Player Weapon Codepointers" table: "NA | Player fires Railgun centrally (Zdoom) | FireRailgun". I saw that this was added to odamex and watched how it works: https://media.mas.to/masto-public/media_attachments/files/111/652/620/030/980/283/original/b6bbfc3107458e97.mp4 
Is it possible to expect this to be added to Legacy?

If it is a true Boom feature, then I would fix Doom Legacy to include the feature.

If it is a misuse of some implementation of Boom, then I cannot promise anything.

 

I thought I have had used the 40mm grenade launcher deh before.  There may be another one.

Downloaded that version, and it does cause a segfault.   Thank you, I can work on that.

 

I saved the code pointers table, and will look at that later.  I am working on another project right at the moment and that has priority right now.

However, am not likely to adopt a ZDoom feature unless there is desirable wad that we could actually play.  We cannot play ZDoom wads.

 

 

The grenade launcher, DH-GREN.zip

Unzip the file and you will find multiple files within.  Just letting DoomLegacy load the zipped file and autoloading ALL the files does not work well.

I had best success with selecting one of the DEH, not loading both.

> doomlegacy -game doom2 -file DT-GREN.WAD MBFONLY.DEH

Watch out for the grenade bouncing back at you.

 

I experienced a lockup twice, which is due to a thing getting on a list linked to itself.  That is weird and I have not tracked down how it is happening.

It gets caught in a tight loop, looking at the same thing repeatedly.  I have not seen this happen in any other testing.

When it does happen, the only thing that can be done is to get to another console and kill the process.

 

The other DEH file, does not bounce the grenades.

>> doomlegacy -game doom2 -file DT-GREN.WAD DT-GREN.DEH

The grenades have a short distance and are as much a danger to the player as to the monsters.

However, I did not experience the lockup.  This leads me to believe that it may limited to something in some MBF bouncy function, or how it got used.

Edited January 6 by wesleyjohnson

Later I found a couple of good weapon mods for mbf21: 

and

Both don't work in Legacy

I don't believe Doom Legacy claims to support MBF21, but correct me if I am wrong.

You considering making a flatpak, AppImage, or portable installation for Doom Legacy? I am a very casual user of Linux and do not like messing with the terminal. It could help the source port reach a larger audience.

At least the 1.48.12 binary ran on my computer with Ubuntu without any hassle. 1.48.14 did not start only because, I think, the kernel is old.

This system which was used for building has been recently upgraded to Linux 5.15.117, and compiler gcc 11.2.

As it still uses glibc 2.33, it should be compatible with other ports that use the same.  It may be dlopen or the zip libs.

You could build it yourself on your platform, as it compiles with only gcc, (or clang), and make, which every Linux dist ought to have.

 

MBF21 is a newer spec, and requires some additional DEH support that is not in Doom Legacy 1.48.14.

It is something that I will have to look into.

 

As I have not used flatpak or AppImage, or had a need to, they are not yet something that I could produce.

Adding an additional distribution file is something that I would have to discuss with the higher levels of the team.

 

The DT-GREN issue has been debugged and is due to an old latent bug from Boom.  MBF changed the blockmap unlink function in a way that hides the bug.  It requires an unusual missile thing created using DeHacked to trigger the bug.

Using the file MBFONLY.DEH will trigger the bug by creating a missile that gets entered in the blockmap.

I have a patch in progress for Doom Legacy.

 

On 1/9/2024 at 12:32 PM, wesleyjohnson said:

MBF21 is a newer spec, and requires some additional DEH support that is not in Doom Legacy 1.48.14.

It is something that I will have to look into.

Yes, I'm sorry, it took me a while to realize that MBF and MBF21 are different concepts

On 1/7/2024 at 9:30 PM, camper said:

At least the 1.48.12 binary ran on my computer with Ubuntu without any hassle. 1.48.14 did not start only because, I think, the kernel is old.

1.48.14 works in Ubuntu 17.10, checked the launch of the binary (linux3.2_64_sdl1)

___

 

I would like to ask. If there is support for 3D floors, are there plans to expand the map creation functions? If so, which ones?

Is there a command to keep Bots from killing MBF Dog helpers?

If not, there needs to be, heh.