DoomLegacy 1.48.12 Release

[wesleyjohnson]

DoomLegacy 1.48.12 (SVN 1642) has been released.

Those who compile their own can get the latest at SourceForge SVN 1643.

Our packages and binaries will be forthcoming, once I can revive other members of the DoomLegacy team back to life.

(Edit: DoomLegacy 32 bit binaries are now available:  DoomLegacy 1.48.12  )

 

 

 

FEATURES 1.48.12

 

• Added SDL2 support, as a compile option.

This provides video, sound, and keyboard alterations for the SDL2 library calls.
The source code still supports SDL1.  This supports target machines that are not supported by SDL2.
At this point, for some things like MIDI music, we have not yet found optimal SDL2 solutions, so SDL1 is still considered the primary port.

 

• Added a control to select music type, with an automatic mode.

Added automatic music type selection and playing.

This works better with SDL1 than SDL2.
SDL2 will always use Fluidsynth for MIDI.  It even builds a copy of Fluidsynth into SDL2.
 

 

• Added controls to adjust monster health, health pickup, armor pickup, and ammo pickup.

This allows adjusting play of an overly difficult map such as one with multiple cyberdemons, such as when you have only three players on your coop team and one is a newbie, or just adjusting a map weak in ammo.
The user can also increase difficulty when feeling cocky.


BUG FIXES 1.48.12

• Mingw32 does not have strcasestr.

  Had to write one for Mingw32 and Watcom.

 

• Fixed a segfault in biowar.wad Map08 with OpenGL.

It would segfault when a texture being drawn in cache, had one patch extending lower than the texture bottom.
The cache write now tests against the cache limits, and not the source.

 

• Fixed X11 musserver quitting whenever trying any device other than TiMidity.

Made the FluidSynth MIDI detection work.
Included the DEBUG options.
Fixed a HAVE_ZLIB test that would error when compiling for X11.

 

• Fixed where Player picks up clip when already has full ammo.

A bug was introduced in patch w105_22_playermsg, svn 1225.
This resulted in the clip being used up, even when the player already has max ammo.

 

• Rewrote the flat animation, to load all flats of an animation.

A long time ago the flats were optimized by only loading the flats that appeared in the level map.
This is incompatible with flat animation, as the animation requires flats that may not have appeared otherwise.  This results in the animation not working for some flats that should be animated (doom2 map17).
Updates the flat animation again when levelflats has moved during the update.
Removed the old animation code that checked all flats in the wad.

 

• Fix the existing MIDI, MP3, and OGG music playing.

Fix MP3 music playing, so that it does not try to play it as MUS.
Detect the music type upon replay too.

 

• VISPLANE_DYNAMIC_COVER.

Replaced arrays of [MAXVIDWIDTH] in visplane with dynamically allocated arrays of the current video width.
This reduces each visplane from 6464 bytes to 3268 bytes.
This will allow MAXVIDWIDTH to be increased, to allow larger screen sizes, without affecting the memory usage for everybody.

 

• Transition to new software renderer, to fix sprites that are drawn in conflict with 3d floors.

Removed drawnodes code.
Sprites could not be sorted into the drawnodes to satisfy all the conflicts that occur.
Instead of trying to save all the sprite conflicts in one sprite structure (like a drawnode), the sprite is split and clipped until all parts of it have been drawn (or masked),

 

• Replaced openings code (from PrBoom) with pool16 code.

The pool16 does not have to adjust existing pointers when expanding the pool.

 

• Fix to sprite draw, so that flipped sprites drawing is independent of the sprite x1 position.

This fixes draw errors of some flipped sprites.

 

• Fixed the OpenGL dynamic lights, where wall textures would distort when a fireball or rocket would pass by.

This affected walls under a 3d floor, when it experienced a dynamic light.

 

• Fixed a zip seek error that only affected some zip files.

Opening a zip archive when there already was a zip file open, required that the zip file be closed, or its file position will be different than our recorded position.
This fixes bug when loading cyberarena3.zip.

 

• Protect against NULL line ptr in some light functions.

This mitigates a segfault in cyberarena3.zip, that was not reproducible.

 

• Fixed compile errors in dynamic load of zlib, and libzip.

Detect version of libzip from header file.
Removed version of libzip from make_options.

 

• Add SDL_DIR to the compile make_options.

Compile on win/mingw32 cannot reliabily find SDL/include otherwise, and it is better than having end users editing the Makefile.

SDL installs with sdl-config are not affected, and most users do not need to specify it.

 

• Fixed the new SDL sound code compiling with SDL Mixer versions.

It adapts the code for SDL Mixer 1.2.8, SDL Mixer 1.2.10, SDL Mixer 1.2.12, and SDL2 Mixer.  This is detected at compile.

 

The SDL Mixer 1.2.8 does NOT have MIX_INIT, but the SDL Mixer 1.2.10 does, and SDL2 does too.  The MIX_INIT provides some device detection and reporting to the user what was found.

Still supports compiling for SDL Mixer older than 1.2.8, but those do not have RWOPS, and thus music playing with that Mixer will then use the hard-drive.
This is detected and determined at compile-time, and running with a newer SDL Mixer will not affect that compile decision.

The user must have a compatible SDL Mixer installed (same or better).
Newer SDL installs have bug fixes (especially on win), and may be customized to the users machine, so this is up to the user.

 

• Changes to support compiling on Mac OS X (Darwin).

Uses App folder.
Based on support from Gibbon.

 

Edited December 21, 2022 by wesleyjohnson
Update

[wesleyjohnson]

DoomLegacy very much supports compiling by the end user for the user preferences and libraries.

 

Plan to add support for dynamic detection of the SDL Mixer library, and run-time adaptation to the run-time SDL Mixer library detected.

This would make it much easier to create a general binary distribution that has all the features.

The Win32 binary is currently created on a WinXP, which limits it only use features available in SDL Mixer 1.2.8.

That is my machine for testing that the code still does work for SDL Mixer 1.2.8.

 

[wesleyjohnson]

Does anyone have machines for which they need (or just find it better) to run older versions of SDL 1.2.

I have an XP machine that uses SDL_Mixer 1.2.8, which is missing some functions that SDL_Mixer 1.2.12 has.

This is not a popularity poll, so I am not counting responses about the latest windows, nor wanting to hear about how EVERYONE some person knows is limited to only using certain  versions.  If you know anything about how old Doom is, and how old some of the machines that people try to run it on, how old the SDL Mixer 1.2.8 library is, has no importance what-so-ever in this.

 

Complete silence is not going to mean that I am going to rip-out any support code.  It just means that I will have to do alot more research and testing to see what hardware and OS are limited to only running these older versions, before I even consider doing anything of the sort.

 

 

 

[DosFreak]

I don't have any preferences of using old versions of SDL 1.2 or SDL_Mixer just for using them. I can speak only for OS compatibility.

Also you may want to post at vogons.org and/or vcfed since there are a lot of users with old hardware and operating systems there.

As far as SDL 1.2.15 I've run it on a minimum of NT 3.51 as long as I recompiled SDL1.2 without fullscreen and OGL support. 

Not aware of any reasons to run older versions of SDL 1.2 for performance reasons.

 

The following is the list of ports that use SDL_Mixer and the minimum OS they run on.

From the below using SDL_mixer v1.2.12 doesn't appear to break OS compatibility but as always would need to be tested thoroughly.

 

The following require XP minimum:
Odamex 0.7.0  uses SDL_mixer v1.2.12
Doom Retro v4.6.2 uses SDL2_mixer.dll v2.6.2.0
Internation Doom v6.0.1 uses SDL2_mixer.dll v2.6.1.0
Woof! v8.0.0 uses SDL2_mixer.dll v2.0.4.0
Nugget Doom v1.7.0 uses SDL2_mixer.dll v2.0.4.0
Eternity v4.0.3.00 pre 819 uses SDL2_mixer.dll 2.0.4.0
Doomsday v1.15.8 uses SDL2_mixer v2.0.0.0
Chocolate Doom  20221015 uses SDL2_mixer v2.0.4.0
Crispy Doom 20221015 uses SDL2_mixer v2.0.4.0
Rude 3.1.0pre11 uses SDL2_mixer v2.0.4.0
DSDADoom v0.24.3 uses SDL2_mixer v2.0.4.0
prboom+ v2.5.1.7um uses SDL2_mixer v2.0.1.0

 

The following require NT4 minimum:
prboom+ 2.5.1.4.test-win95 uses SDL_mixer v1.2.12.0

 

The following require 2000 minimum:
Doomsday v1.9.0 beta 6.2 SDL_mixer v1.2.7.0

 

The following work on 98SE-ME-NT4

Doom Legacy v1.48.10 uses SDL_mixer v1.2.11.0

The following work on 98S-ME

PrBoom+ v2.5.1.4 uses SDL_mixer v1.2.12.0

 

The following work on 95-98SE-ME-NT4:

Eternity v3.40.37 uses SDL_mixer v1.2.11.0
Chocolate Doom v2.3.0 uses SDL_mixer v1.2.12.0
Crispy Doom v3.2 uses SDL_mixer v1.2.12.0
Rude v2.5.0c uses SDL_mixer v1.2.12.0
 

Edited December 12, 2022 by DosFreak

[wesleyjohnson]

Thank you for your extensive listing.

It looks like Doomsday uses an older SDL_Mixer (1.2.7.0) than DoomLegacy does, but requires minimum Win 2000.

Most ports just used the latest SDL available when they were working on it.

 

That those last 4 are using 1.2.11 and still work on Win95 is useful information.

 

I may just look at vogons etc, just to see what old hardware people are still running, and what they are doing with it.

 

For some reason, DoomLegacy has significant numbers of users that download the old versions.

I may keep one old hardware compatible version around, just to see how many people download it.

Then I would only need to have the run-time version detection handle 1.2.10 and up.

It depends upon how much code is actually saved, so if it does not save much, it might just be moot.

Not saving much to rip out code that is already there and tested.

Edited December 13, 2022 by wesleyjohnson

[taufan99]

@wesleyjohnson I should thank you for all the effort in keeping Doom Legacy usable on older systems/hardware. As someone who frequently browses the topic of modern use of old systems, it's always fascinating to see new stuff serviceably run on older systems like this one.

[wesleyjohnson]

The DoomLegacy 32 bit binaries are up at SourceForge.  Do not know when the 64 bit binaries will arrive, as those are built by members who run 64 bit.

There is also source code.

Do not forget to download the common package.

 

DoomLegacy 1.48.12

 

 

SourceForge has mangled the README file in the display.  The copy in the download formats correctly with any other reading tool.

 

DoomLegacy will compile for many other customizations, but I do not have the machines needed, and other excuses..  We provide what we think would be the most useful binaries.

 

Edited December 21, 2022 by wesleyjohnson

[wesleyjohnson]

I was interested in whether people would flock to SDL2, just because it was newer, or most would stay with SDL1 because they had that on their hardware.

In the Linux users, we have  SDL 1, leading over SDL 2, by one download, with X11 download trailing those by one download.

 

Many people are forgetting to download the common download (according to the download stats).

Some people may be using the old Common download from the previous version, which probably works, but does not give them the new docs.

Flightgear and a large number of games do the same thing, this is not a new concept.

 

Tis the year end season, so the 64 bit downloads may not show up for a while.  I have heard from those members, so they are alive.

 

[wesleyjohnson]

Thank you old systems users, and the users of old systems, for your support and interest.

Exploration of sites like vogons, does not reveal much of any pattern.  It seems to mostly users wanting to get such and such running on some old hardware.

Keeping the DoomLegacy software configurable seems to be the best I could do.  Some more auto detection would not hurt.

 

 

[wesleyjohnson]

Some of the users on this forum not want to wait for this to reach an official release.  It is committed to the SVN source.

 

SVN 1648

Have fixed a long standing problem with Windows MIDI.

For some reason, which I could only conjecture about, one of the MIDI tracks had been padded out with 33 zeros.

Timidity, Fluidsynth, Win32 MIDI, and probably every other MIDI, has ignored these.

The rationale for having done this has probably gone away with DOS and early Windows, so I have disabled them.

The report from some Windows 10 and Windows 11 users is that this fixes the MIDI music problem where one MIDI track changes to a piano.

 

It was also sending a Program_Change command with a blank title string.  This has been made optional, default disabled.

 

* LOG

Fix to Bug 0674 Midi track playing late.
The MIDI put out 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_compression", which is default 1.
 

Thanks to lantern424 for providing sufficient information and testing to identify the nature of this problem.

Thanks to lantern424 for testing on Windows 10, and MrRocket for testing on Windows 11.

Edited February 23, 2023 by wesleyjohnson

[Mr.Rocket]

On 12/23/2022 at 11:23 PM, wesleyjohnson said:

Many people are forgetting to download the common download (according to the download stats).

Why not include the common download with the binary package?

All the old versions were distributed like this, why is it different now?

[RonLivingston]

Doom legacy, I haven't seen that in a while

[camper]

Hello. Quite a long time ago (I think it was in 2012 or a little later) I installed Doom Legacy (DL) on a work Pentium 2 computer with Windows 98. I used DL as a test program to check the operation of the equipment and warm up specialized controller boards before starting work (it automatically demo game was running, lol).

Now I've noticed DooM Legacy as a port that has some unique features, most notably split-screen multiplayer on one computer.

I know that version 1.48.14 has already been released, but it is not yet available for Windows on Sourceforge. I'm currently trying 1.48.12.

I would like to take a closer look at this port, especially since I have now become interested in modding using deh.

I'm currently trying different deh patches, for example this one: https://github.com/fragglet/mbf/blob/master/examples/grenade.deh

And I'm very excited about how it's working. However, I noticed that the odamex style railgun attack functionality is not available. This is a tragic, because in multiplayer the railgun became the de facto standard after skulltag/zandronum came out.

When the binaries for version 1.48.14 appear, I would be glad to try it on Windows 10.

[Edward850]

9 hours ago, camper said:

Now I've noticed DooM Legacy as a port that has some unique features, most notably split-screen multiplayer on one computer.

Not all that unique nowadays.

[camper]

I checked now. The port works under Win XP and multiplayer works. The local network server started on a PC with Win 10. Nowadays support for Win XP is becoming rare and this is valuable.