Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
wesleyjohnson

Doom Legacy 1.47.2 Release

Recommended Posts

5 hours ago, wesleyjohnson said:

Targa format

What does the Targa format offer to us users? Can you explain it? (I've read it's article on Wikipedia but I'm not a tech-minded person.)

Congratulations on the release, by the way. :)

Share this post


Link to post

Just wonder, will this update fix midi stuttering on Windows?

BTW Legacy runs smooth on my second Linux laptop.

Share this post


Link to post

Targa format is much newer than the PCX format that was previously used.  PCX format was from DOS.  It was hard to find a viewer that would support it.

Targa format is supported on Linux, and seems to be supported on the Windows that I tested.

The difference is that now you will get a picture in a file format that you can view.

The screenshot file may be viewable just by double clicking on it (system dependent).

 

Some of the music support in DoomLegacy has been rewritten, and gone over  thoroughly.  This will mostly benefit Linux X11 users, as that is where

problems were found.  Some changes have been made.  In spite of repeatedly looking for something in the midi playing that could affect Windows

and not Linux, nothing has been found.

 

There have been reports of midi problems on Windows, but I could not get most of them to happen on my test machine.

It has been reported that updating your SDL to the latest version will fix some music problems.

Some of the music problems are due to the poor midi instruments on the default Windows midi player.  I have heard this happen on my test machine.

Some instruments are missing entirely, making the music silent when those are used.

Some of the Doom2 music uses those instruments, there is one long passage of piano that gets very very faint on Windows.

You can update your music instruments, or replace your midi player entirely.

I am a Linux user, which limits my ability to diagnose and fix problems outside of DoomLegacy (such as in the Windows system and its midi support).

 

Share this post


Link to post

I have noticed that there are a large number of downloads of DoomLegacy Version 1.40.  This version is from 2002.

If anyone has a link to DoomLegacy Version 1.40 somewhere, could they please update it.

I have found one link to Version 1.41 at freshmeat freecode, but that site seems to be no longer updating, and at least has a warning that it may be stale.

 

Edit: It is the macosx version they are downloading, at a rate of 65 downloads a week.

 

 

Edited by wesleyjohnson

Share this post


Link to post
3 hours ago, wesleyjohnson said:

Targa format is much newer than the PCX format that was previously used.  PCX format was from DOS.  It was hard to find a viewer that would support it.

Targa format is supported on Linux, and seems to be supported on the Windows that I tested.

What about the PNG format? I heard PNGs are easier to post on the web.

Share this post


Link to post

Limited time, too many things need doing.  Targa can be written without using a support library.   Sure, PNG is nice on that end, but any kind of compression requires a support library.

I would have to find a PNG support library on 5 different operating systems.  Limited time, too many things need doing.

 

Share this post


Link to post
17 hours ago, wesleyjohnson said:

Limited time, too many things need doing.

Take your time, don't stress yourself. :)

Share this post


Link to post

TODO LIST:

Fix some draw anomolies (thin lines, unstable render of close linedefs, unstable sprite ordering relative to overlapping flats).

Allow switching between draw modes, and OpenGL, from the menu.

Reading wads in zip format.

Fix short skies so they can be used with the mouse-look.

Add some more enhancements that give more game interaction.

More monster types with special engine interactions (robot, controller boss).

Add some vermin with appropriate behaviors.

More special locks, keys, and devices.

Some basic combining linedef that allow more complicated sequential actions (without having to use a voodoo doll).

Some level tuning linedef.

More weapons, with player choosing which weapons they can carry.

Some enhanced texture generation.

More door options.

Crouching, crawl.

 

 

 

Share this post


Link to post

The Windows binary is up on SourceForge.

The Windows binary still includes the old Launcher, which works for some people and not others.

 

The problem is that for the old XP (the Windows I have, used for testing), the Launcher fails to write the settings in the doomargs.tmp file.

If this is a new install, doomlegacy will then give an error message about "doomargs.tmp file not found".

If it was run previously, it will reuse the existing doomargs.tmp file, with whatever doomlegacy settings that were in it.

 

 

For those that are interested, bits of some ongoing conversation.

----

About the message "Response file doomargs.tmp not found"

 

From my experiments, if you get that error then the Launcher is not writing the doomargs.tmp file. That means that the settings from the Launcher will NOT be getting to doomlegacy.
If you set the file by hand, then doomlegacy will only ever get what you put by hand into the doomargs.tmp file.

If you are getting the doomargs.tmp not found error, you should abandon the old external Launcher and start doomlegacy directly from a shortcut.
You can edit the shortcut, have one that starts doomlegacy with "-opengl" for example.
I recommend starting doomlegacy without any command line arguments, so that it starts the built-in launcher, which is not as pretty as the old external Launcher, but is functional.
It also handles the new settings that the old external Launcher does not know about.
However, you have to read docs/legacy.html command line switches to use it.

 

----

It could also be dependent upon how the Launcher is started.

I have been doing a "cd" to the Legacy directory and trying to start the Launcher from a File Manager.

Maybe it only works if it is started from a desktop shortcut.  I passed on installing that, and that may be the problem.

Putting a doomargs.tmp file in the binaries directory makes the error message go away, but the Launcher is useless because none of the settings get through to doomlegacy.

It is not writing a new doomargs.tmp file when you change the settings.
 

----

If you are going to test the Launcher, you MUST use different settings for each test.  Otherwise you will not be able to identify when it fails.
Once you have a doomargs.tmp file present, then a Launcher failure will only fail to write a new one (with the new settings), and the Launcher
will simply reuse the old one.

You must test with different settings each time, so that it is obvious when it has failed to write the new settings to the file.
The simplest seems to be changing the game from  UltDoom to Doom2 to TNT, etc. as that will be obvious when it starts up in

the game mode from a previous session.

----

 

I may have to drag the old Win98 machine out and test the old Launcher on that.  But would that even be relevant anymore ..

 

----

This discussion has been about the old Launcher that is included with the Windows binary download.

DoomLegacy itself is running fine.

On my XP test machine (and only on the XP machine), it seems that the sfx sound has low volume, and the music is lounder.

For those who have problems with the old Launcher,  you need to abandon using that Launcher, and start DoomLegacy by other means.

 

 

 

 

Edited by wesleyjohnson

Share this post


Link to post

For anyone who might be trying to use the old Launcher that is included with the DoomLegacy Windows binary.

If you get the "doomargs.tmp file not found" message:

 

The old Launcher is putting the doomargs.tmp file in the directory where it finds the IWAD.

I don't know why it does this, as it makes no sense.

I assume it then passes a command line string to doomlegacy that does not mention any directory for the doomargs.tmp file.

This is a bug in the Launcher, it is not consistent in the location of the doomargs.tmp file.

It did this for an absolute IWAD path
  C:\doomwads\doom2.wad
It did this for a relative IWAD path
  doomwads\doom2.wad
 

I do not want to copy my entire doomwads directory into every install of doomlegacy.  Trying to use shortcuts did not work, in either direction (on an XP).

A file indirect of doomargs in every directory that has an IWAD might make it write the doomargs file where it is supposed to (but apparently not available on an XP).
 

There are other Launcher programs out there, but  don't know how compatible they are with DoomLegacy.

This one is not that compatible as it is.

 

KB1 is looking at the Launcher source code.  As he programs for Windows, at least he might have a chance of figuring out what is going on.

MrRocket reports that it works for him.  You just have to have the wads in the directory with the doomlegacy binary.  That may turn out to be literal and a requirement for using the old Launcher.

 

If you have wads in other directories there are two ways to start DoomLegacy.

1. Use a command line console box, type in command lines.  Faster.

2. Start doomlegacy without any command line switches so it goes to the built-in launcher.  Provides some lines to fill in and a game control.

 


 

Share this post


Link to post
On 8/18/2018 at 5:18 PM, wesleyjohnson said:

KB1 is looking at the Launcher source code.  As he programs for Windows, at least he might have a chance of figuring out what is going on.

MrRocket reports that it works for him.  You just have to have the wads in the directory with the doomlegacy binary.  That may turn out to be literal and a requirement for using the old Launcher.

 

If you have wads in other directories there are two ways to start DoomLegacy.

1. Use a command line console box, type in command lines.  Faster.

2. Start doomlegacy without any command line switches so it goes to the built-in launcher.  Provides some lines to fill in and a game control.

It can be fixed. But the version of the source code (1.3) on SourceForge is older than the version of the compiled launcher installed by the setup program (1.42). So if MrRocket can publish the latest source, I'll see what I can do.

Share this post


Link to post

Nice to see the project is still active.  I'm not sure who is responsible for the sourceforge website, but there are a few links in the left navbar that need updating or removing.  It still points to the NewDoom forums.  Those have been gone for a while now, heh. 

 

I'm currently attempting to pester freenode staff so we can tidy up the #legacy IRC channel a bit.  Seemingly, no one has ops for it anymore.  That still points to NewDoom too, but no one can change the message.  

 

//EDIT:  @wesleyjohnson Seems Freenode want authorisation from someone more senior in the project, I've sent you a PM about it.

Edited by DooMAD

Share this post


Link to post

Are there plans to move this to Github eventually? Seems most Doom source ports use it and I imagine you could get more contributors that way.

Share this post


Link to post

Again, about the old Launcher included in the windows binary ...

In the game page, If you do not use any path names when specifying the IWAD ( i.e. doom2.wad ) then the Launcher does not put the doomargs in the wrong directory.

The only requirement is that the IWAD files must be in one of the directories that DoomLegacy searches, such as /games/doomwads.

So, just specify doom2.wad, let DoomLegacy find it by searching directories, then the Launcher works much better.

 

 

Share this post


Link to post

The Newdoom forum did have the old discussions.  The link seems dead now.  I have notified the site master.

 

No plans to move to GitHub.  I doubt that is much of an issue.  Subversion is working just fine for this project.

The real problem is that so many people want to start their own port, so they can experiment and add features of their own choosing.

 

Share this post


Link to post
On 8/3/2018 at 6:17 PM, wesleyjohnson said:

Limited time, too many things need doing.  Targa can be written without using a support library.   Sure, PNG is nice on that end, but any kind of compression requires a support library.

I would have to find a PNG support library on 5 different operating systems.  Limited time, too many things need doing.

 

For your information, there are usually two ways that people usually go about adding PNG support to their project.

 

The first way that 99% of people do is using libpng, or some wrapper around it.  It is the 9,000 lb gorilla of PNG support libraries.  On Linux, you link against system libpng.  On Windows and MacOS, or other platforms where libpng can't be found, you build libpng and its dependency zlib as part of the build process, and either statically or dynamically link them into your software.

 

The second way is if you don't want the hassle of setting up your build system and are fine with a reduced feature-set.  There are a popular series of single-header libraries out there called "stb" that have modules that allow you to read and write a variety of image formats.  You include them in your project and there is no step 2.  They can be found here for the reader and here for the writer.

Share this post


Link to post

Yep, that is just about what you have to do to use PNG.  There are other reasons why I will have to do that eventually, and the most compelling is to support wads that have PNG textures.  There is some advantage to using PNG for textures, it reduces the wad size (ok,some people still care about that).

When that time comes I will probably include PNG as a screenshot format.

Up until then, I cannot see screenshots as a strong enough reason to deal with PNG right yet.  Mostly because of that need to deal with this for so many operating systems.  For the few screenshots that people take, they can convert them to PNG or any other format they want using more any paint program.

I got lots of other plans for improving actual play that feel more important right now.   And, right now, I have to get some income oriented work done.

 

 

Thanks, I saved the STB project README for future reference.

 

 

Share this post


Link to post
On 7/26/2018 at 2:26 AM, wesleyjohnson said:

- DoomLegacy 1.47.2 has some changes to the netgame and thus is NOT netgame compatible with previous versions.

  Some of those changes involve security fixes, and preventing kicking players.

  Netgame sites: Please review the changes so you can update to use Version 1.47.2.

 

 

Ah, perhaps this is why I can't get xiO_'s #Legacy Doom Launcher mIRC script working with this 1.47.2 version.  #LDL works with 1.42 and 1.44, but causes an instant crash with this latest one.  1.47.2 works fine with the included standard Legacy launcher, though, so I'm not sure how to go about updating the #LDL mIRC script to make it compatible with this version.

 

//EDIT:  Exl fixed it.  It was nothing to do with what I thought it was, heh.  The above link is updated with the working version.  

[20:38] <+Exl> ok, it doesnt seem to like it passing arguments as a file through @

 

Edited by DooMAD : Cheers, Exl :)

Share this post


Link to post

Ah good to hear about xiO_'s Legacy Launcher for mIRC! 

That brings me back.. Cheers DooMAD! :)

 

@kb1, sorry I'v been a bit out of the loop lately, but that's exactly the only source version I had also, 1.3.

 

The 1.42 version of the launcher was inherited from a previous version of Doom Legacy, I think it was the birthday version 1.40?

It worked fine for me on Windows 10 and slightly older versions of Windows, which is why I included it with the installer.

I have no idea where the 1.42 launcher source is.

 

1.3 on the other hand, didn't work properly. There was an issue loading external files/pwads, (Single Map) where the loading would show gibberish and write it like that in its launcher config also. Not sure why, and it did this from direct download and/or after compiling from source.

Aside from the pwad/deh loading, 1.3 seemed to work, but I didn't plan to distribute it like that heh, which is why the 1.4 version went into the installer. 

So yeah, I've only had a look at the 1.3 source, but set it to the side and started working on something else.

Maybe you can figure out what's up with the 1.3 version source?

~ hopefully it's not a French translation somewhere causing it, hah. 

 

Thanks, and sorry again for the late reply. 

 

 

 

Edited by Mr.Rocket

Share this post


Link to post
On 11/24/2018 at 12:00 AM, Mr.Rocket said:

Ah good to hear about xiO_'s Legacy Launcher for mIRC! 

That brings me back.. Cheers DooMAD! :)

 

I might be free for a game on Monday or Tuesday if you're feeling nostalgic and fancied venturing back to the dark and dingy realm of IRC?  I'm probably rusty as hell, though, heh.

Share this post


Link to post
On 11/23/2018 at 7:00 PM, Mr.Rocket said:

 

@kb1, sorry I'v been a bit out of the loop lately, but that's exactly the only source version I had also, 1.3.

 

The 1.42 version of the launcher was inherited from a previous version of Doom Legacy, I think it was the birthday version 1.40?

It worked fine for me on Windows 10 and slightly older versions of Windows, which is why I included it with the installer.

I have no idea where the 1.42 launcher source is.

 

1.3 on the other hand, didn't work properly. There was an issue loading external files/pwads, (Single Map) where the loading would show gibberish and write it like that in its launcher config also. Not sure why, and it did this from direct download and/or after compiling from source.

Aside from the pwad/deh loading, 1.3 seemed to work, but I didn't plan to distribute it like that heh, which is why the 1.4 version went into the installer. 

So yeah, I've only had a look at the 1.3 source, but set it to the side and started working on something else.

Maybe you can figure out what's up with the 1.3 version source?

~ hopefully it's not a French translation somewhere causing it, hah.

Thanks for the detailed reply. No problem with the delay - I have the same issue these days!

I'll see if I can't fix the SP external file/pwad bug and the current path issue. I'll also try to test each option a bit, and do a bit of regression testing against the 1.42 version, to try to catch any other changes.

 

Finally, I'm bumping it to 2.0, and adding the build date somewhere! I loathe unreliable version numbers! No new features, for now, though - I was just trying to give Wesley a hand on a simple fix. Thanks again.

Share this post


Link to post

I am also working on bringing as many of the command line controls into the menu system as I can.

Right now I am changing the config file system to allow more flexibility.

It will allow loading a common config file, a drawmode (OpenGL) config file, and a user specified config file, and it will remember which config file each control variable came from so it can save them to the correct config file at shutdown.  The user can edit the config files to select which settings are unique to a drawmode or specific situation.

This will fix the problem with having to define all the control keys again when switching to OpenGL.  The OpenGL config file will only have those entries that the user wants to change for OpenGL.  The config loading system will remember which those were.

 

I have not quite got the drawmode to change from the menu yet, partly due to OpenGL having its own separate config file.

 

 

Share this post


Link to post
On ‎11‎/‎27‎/‎2018 at 6:25 PM, wesleyjohnson said:

I am also working on bringing as many of the command line controls into the menu system as I can.

Right now I am changing the config file system to allow more flexibility.

It will allow loading a common config file, a drawmode (OpenGL) config file, and a user specified config file, and it will remember which config file each control variable came from so it can save them to the correct config file at shutdown.  The user can edit the config files to select which settings are unique to a drawmode or specific situation.

This will fix the problem with having to define all the control keys again when switching to OpenGL.  The OpenGL config file will only have those entries that the user wants to change for OpenGL.  The config loading system will remember which those were.

 

I have not quite got the drawmode to change from the menu yet, partly due to OpenGL having its own separate config file.

 

 

 

Hi Wesley,

Just curious as to why Legacy only has support for SDL and not SDL2?

I've noticed that other source engines that support SDL, use SDL2.

Besides being newer, is there a benefit?

Sense you're working on the above, would it be time to look into a newer SDL version?

 

 

Share this post


Link to post

It was written for SDL.  As SDL is not yet broken, there is no good reason to go through all the work and testing to change to SDL2.

I just do not have infinite time to do everything, so to do SDL2 I would have to stop work on something else.

 

Share this post


Link to post

The SVN repository DoomLegacy (SVN 1426), Version 1.47.3 (non-release version). has a new feature that allows the user to switch between draw8 (palette), native software rendering, and OpenGL rendering using an options menu.  I mention this in the hope that if users are going to find bugs in this, that it get reported to the SourceForge DoomLegacy bug tracker while I still remember how it all works.  Doom (and DoomLegacy) was designed to take command line settings and totally commit itself to those settings one they were acted upon.  It has taken over a year of putting in the missing code to track and release all those graphics.  Backing out of OpenGL rendering was somewhat more difficult than software rendering due to some of the strange hacks that were used in the graphics caching.  With all those changes there are plenty of places where it could break.

 

The video driver model has been changed.  Previously, the pertinent command line switches would be given to the video driver and it would then find some video modes and set the rendering mode.  Failure would be terminal, with DoomLegacy aborting.

The new interface model has three parts.  The driver provides a startup video mode at program start, to provide some way to report error messages.

Most of the command line switches are now processed by common video mode switch code.

The video driver has a query function that will report if it can find viable video modes for the query parameters presented.

This way the command video mode switch code can query about alternatives (such as 15 bit and 16 bit draw modes) before trying to switch

the video drivers, video card, and the rendering engine settings to those settings.  Switching the rendering engine is the most complicated, as it can

involve dumping all the graphics and reloading using a different patch caching system (due to OpenGL and the other hardware rendering systems, using totally incompatible graphics caching).

I can not see any reason why this should not work for all the various video cards out there (that I don't have), but I won't invest money or reputation that something won't come up.

 

Reports from those who like to be early testers, would be appreciated.

 

I am also working on changing the game from the options menu.

Changing from Doom2 to Heretic for example.  Same kind of problems, such as backing out of changes to the info database.

 

Changes to the config file system are on hold due to problems with the new config system repeatedly losing video config settings.

The current system has a separate config file for opengl, which totally replaces the normal config file.

I have gotten tired of having to duplicate the entire options setup when using OpenGL and its separate opengl config file.  However, OpenGL

needs to store different video settings like gamma.   I don't think just a separate opengl gamma would suffice.

 

The new config system would have one master config file, and secondary overlay config files that would change selected settings.

For instance there could be an opengl config file that would only change video settings, and would not need to have key bindings.

Saving the config files and automatically changing config files when the rendermode changes has become the problem.

This is a bit of a guessing game as to what would be really useful for the end user, and how many config file changes are needed.

I expect that most users use only one graphics mode and would be happy with one config file.  But there are always users with

multiple setups, cards, monitors, and who-knows-what, that exercises the config file capabilities the most.

 

 

 

Edited by wesleyjohnson

Share this post


Link to post
Posted (edited)

Did something change in the sound code? The old 2004 version I have can play the Perkristian HD sounds and even a Doom 4 sounds wad I made just fine, but the latest version plays them in slow motion and super quiet. Regular sound volume (no mods) its also low.

EDIT: It seems it was caused by the move from FMOD to SDL since version 1.45. The online documentation says one can compile the program with FMOD, but doing that escapes my abilities. An optional download would be really appreciated as the difference is quite drastic.

Also a on and off toggle for the new sprite rotations would be a good idea. With the extra rotations sometimes looks like the monsters are walking towards you sideways, which is kinda funny.

And thank you for your work, Legacy is always on my Doom folder because It's one of the only source ports with quality splitscreen. Makes me really happy to see it still being developed.

Edited by DANZA

Share this post


Link to post
Posted (edited)

It has been SDL sound the whole time I have worked on it.  I have not gotten the FMOD option to compile being that I cannot get a FMOD package working on my Linux.

The SDL sound code gets edited just about every year, so there is no way to identify any specific patch as a problem with your sound wad.

If this is on Windows, then that is another problem.  The Windows MIDI playing is suspect, known to play some instruments quietly.   There is a problem with the built-in MIDI sound fonts

shipped with Windows.  There is also the problem with sound volume controls on Windows,

 

The 16 sprite rotations are not used unless you have a WAD with some 16 rotation sprites.

I will test to make sure nothing got damaged in the regular sprite code.

 

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×