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

Doom Legacy 1.48.10

Recommended Posts

23 hours ago, wesleyjohnson said:

I have an old XP, and keep the win32 port compiling and running on that.

 

Please don't.  That's like programming against Linux 2.4 or FreeBSD 4.11.  You owe it to your windows users to compile on and test against a modern version of Windows.

 

https://www.microsoft.com/en-us/software-download/windows10

 

You don't really have to pay for or activate Windows anymore.  The only downside from not activating is that you can't customize your desktop and you sometimes get a message on the lower left corner of your screen.

 

image.png.24eaf0cc2d9692a615b63576c4c0e92f.png

 

Other than that, Windows 10 will continue working in perpetuity, and the Microsoft Police aren't going to be breaking down your door over unactivated Windows.

Share this post


Link to post

@AlexMax@dasho

Should be noted that @Gibbon just released a Doom Legacy build that plays nice on Windows 10:

 

https://github.com/atsb/source-port-builds/releases/download/1.0/doomlegacy-svn-r1620-win32-sdl-compat.zip

 

Some caveats:

  • It is set to OpenGL only. No more software.
  • Video modes are highly finnicky
  • When it does run, it actually looks pretty nice. Its like a high res chocolate doom with a nice colored lighting effect and the standard OGL features
  • 35 fps though.
  • BTSX runs but some of the ENDDOOM screens conflict with legacy.wad
  • Uses a custom SDL1.x to 2.x wrapper/translation layer

This version works well enough.

Share this post


Link to post
6 hours ago, drfrag said:

For me the official release runs on win10 as i stated earlier.

For me it crashes and runs badly on Windows 10 and 11.  Use Software mode (bad scaling) and then set Fullscreen.  Crashes immediately.

Share this post


Link to post
1 hour ago, Lol 6 said:

Runs fine for me when set in OpenGL mode, otherwise it crashes when doing what Gibbon wrote

Precisely why I did my version without any choice except OpenGL.  I guess folks just don't test it properly.  Anything less than OpenGL on modern Windows for this port is a complete disaster (unless you're rocking a 22 year old inferior XP).

Share this post


Link to post
3 hours ago, Gibbon said:

For me it crashes and runs badly on Windows 10 and 11.  Use Software mode (bad scaling) and then set Fullscreen.  Crashes immediately.

For me it doesn't crash. I already mentioned that performance isn't great and i doesn't support widescreen though. My card is an AMD Radeon R2.

Share this post


Link to post

Thank you for your information.

Yes, I think this should be a BUG report.  The bug system has the support for discussing this, tracking, and recording the results, ... and it sends you emails.

With your information, did find them in the lumps directory.   I must have looked in there 3 times, and just did not recognize them.

 

BSD is Berkley-Unix (as in the university),  slightly different than that commercial unix (which at one time we had to type  UN*X  to keep from informed by a team of lawyers of its copyrighted nature).

We have users with   FreeBSD, and NetBSD.

Share this post


Link to post

Have not gotten any BUG reports posted.  That does indicate the level of importance.

 

Tried to fix the MP3 playing  (phobiata).  SDL is not playing the MP3.  I do have the support libraries.

 

Have been adding SDL2 support.

Will maintain the current SDL1 support, for those machines that do not have SDL2.

The conversion-to-SDL2 document is optimistic, and incomplete.

It has taken weeks of slow progress.

 

The conversion doc said that the audio buffer is NOT zeroed, so we had to do that ourselves.

Following that advice resulted in losing the music, which later cost me many days of debugging to find why the music was not playing.

Had to undo that change, which means that the audio mixing is actually exactly the same as for SDL1.

This is due to DoomLegacy invoking the sound effect mixing as a callback function, after the music mixing.

It adds the sound effects, with the music already in the buffer.

I expect that many other Doom ports have the same mixing code.

 

SDL2 Keyboard support separates key presses and shifted-key (ASCII) text into separate events.

This doubles the keyboard workload, giving two events for most key down (but not all).

Must now have two keypress streams, as neither is complete.

Must change key press users to only use one key stream or the other.

As the SDL2 key encoding is different from SDL1 encoding for anything other than ASCII,

must now use several key press translation tables.

 

A SDL1 build currently still works better than an SDL2 build.

* DoomLegacy window blinks twice on startup.  This is already annoying.

* The music is going to Fluidsynth, and I cannot control it.

  With SDL1, it has gone to TiMidity, even when Fluidsynth is installed.

* The Fluidsynth volume levels are different.

Fluidsynth has some grand effects in its instruments, like the instrument changing its sound over several seconds of a note.

Does not seem appropriate for Doom music, and is distracting.

*  I prefer the sound of TiMidity.  It may be due to the instrument package installed (soundfont).  That is a project in itself, trying to compare all the instrument packages.

* Have not found an easy way to control which program plays the music.

* SDL2 code is not committed yet, as it is full of debugging.  Needs a couple weeks more grinding at it.

 

The SDL1 code is also getting some improvements.

There is a chance to improve the music looping feedback on Windows.

 

Edited by wesleyjohnson

Share this post


Link to post

I have a sourceforge so I’ll start doing bug reports when I begin the Windows debugging next week.

Share this post


Link to post
4 hours ago, wesleyjohnson said:

Have not gotten any BUG reports posted.  That does indicate the level of importance..

Or it means it works well enough for the time being? Or people know better?

 

I know on occasion you link to the bugtracker, perhaps it should be more often.

Share this post


Link to post
17 hours ago, wesleyjohnson said:

Have not gotten any BUG reports posted.  That does indicate the level of importance.

Tried to fix the MP3 playing  (phobiata).  SDL is not playing the MP3.  I do have the support libraries.

Sorry, got a bit overwhelmed with work, then got ill, then forgot. I just created one.

 

As a bonus I also made another bug report, since I finally managed to get 1.42 to work on Windows 7 (no small feat). Some (but not all) of the coronas in Phobia don't seem to spawn in the proper position anymore, see comparison screenshots inside the spoiler tag (the screenshots are also in the report).
 

Spoiler

 

In 1.42 they spawn inside their lamp-posts:

DL142.png.4ec46512c32ffb584e0659a787d9e4dc.png

 

In 1.48.10 they now spawn much higher:

DL14810.png.e226cab2609aa641fb6aa05326f98146.png

 

 

I'm not sure how specific this is to Phobia or if other older wads are affected. I ran a bit through Nimrod and everything seems fine, but the coronas there are also much more subtle. I'm also not sure how much fixing aesthetics for one older wad is a priority, but the report is there just in case.

Share this post


Link to post

Actually, I had fixed the positioning of the coronas.   They are supposed to be over the flame of the torches.  Walk around to the right and look at the torches and the flames at the pit.

To examine coronas, use the options->effects->light_effects->corona control, and switch them on and off.

You can also turn them brighter or bigger.

 

The coronas are supposed to be covering the flames.

Examine the corona for lamps in doom2 (map05 is good).

The table sprite_light (p_lights.c) places the corona for every torch type.

 

This is going to be a continuing problem, as when a wad replaces the torches, the brightest spot may have been moved.

Then the corona placement may be off for the replacement torches.

 

I have been considering ways to detect the torch flame, so the corona can be placed over it.  (Brightest pixel in the sprite?)

 

Probably will not work with this first room of phobiata.

Probably, the wad needs to be fixed, and those coronas moved down.

I may talked to the phobiata creator before about this (maybe).  Because, I have some memory that the answer was, they wanted them high, and leave them where they are because it looks more surreal.

 

Discuss ...

 

 

Edited by wesleyjohnson

Share this post


Link to post

Thanks for the information. I tested this out in phobiata.wad, in MAP01 and others, looking how the coronas were behaving. You're right, most of them look perfectly good, as far as I can tell the only ones that don't look right are those very specific ones in the screenshot I took. My best guess is something must've changed with the "brightest spot detection" code in Legacy at some point, but it only affects these because the torches don't have an obvious bright spot the way a flame sprite does, so the corona gets placed higher.

 

I did some digging in Doom Builder and these specific coronas are only used once in the entire wad, in this MAP01 starting room. I tried playing around with both corona.h and with the map's Fragglescript, I assumed OFFY does something to offsets but I could be wrong since nothing I changed no matter what values I set. Probably not a big deal honestly, especially since they're a one-time thing, and you're absolutely right they do look more surreal the way they are now XD

Still, if you or someone can tell me the attribute name for setcorona that controls a height offset I can try out various combinations to get it to look like the old Legacy and post my findings here.

Share this post


Link to post

DoomLegacy does not have brightest spot detection yet.  Just have tables, and they only work on doom and heretic torches.  The tables know  nothing about replacement torches.

Torch sprites from doom2 (or heretic) automatically get coronas, at the position appropriate for the doom2 original sprite (lookup in a table).

 

In phobiata, those map01 torches are yellow lamp (2028,  MT_MISC31, orig height=48, S_COLU, SPR_COLU), so they should have coronas.

The SPR_COLU has a light LT_COLUMN.

The y position from the table (where the corona is drawn) is  19, which is mid-level compared to other lamps.  A candle is 6, short torch is 14, large torch is 27, and a techlamp is 33.

However, the torch and thus the corona position can be modified by dehacked, and fragglescript.

Normally, that corona would end up being drawn 19 up from the base of the torch.

 

In phobiata, the colua0 sprite is BLANK, so the torch that is making the corona is not visible.

The top of the walkway is at -14 (it is a 3D floor).   The top of the posts are at 32.  The torch is sitting on top of the post.

Those lampposts are constructed of linedefs.

 

The fragglescript command setcorona can replace light entries or the whole table row for a light type, (see docs/fsfuncs.html).

The LT_COLUMN is id=15  (from r_defs.h).

 

Be aware that using fragglescript, they could have added another sprite at the position of the torch.

 

If you want to put the corona into the lamppost,  probably easiest to use setcorona to modify LT_COLUMN to y= -4.

Depending on exactly what the yellow lamp is sitting upon, it may require  y= 0, or y=1.

I would advise putting it back to 19 when exiting the levelmap.

 

Edited by wesleyjohnson

Share this post


Link to post

I finally got MP3 to work, using SDL2.  It seems that my SDL1 (a binary download) was built without MP3 support.

Anyone got a SDL1 with MP3 support built-in ??   I just want to know if that was systematic, or was it just something Slackware did.

 

 

Share this post


Link to post

Fascinating, I hadn't realized the lampposts were entirely linedefs, but kept wondering why the replacement sprite wouldn't properly show up when I open the map in SLADE!

 

I tried moving the offset for the lights (it should be COLUMN_L, unless I'm missing something), but no matter what I can't get them to move at all. I know that I'm looking at the right corona type, because I also found COLUMN_L as id=15 in things.h, and I can use the map's Fragglescript to change the LIGHT_COLOR and CORONA_COLOR of COLUMN_L, and it changes the colours of those lights in the map. But nothing will change the height at which they appear, even though the script already includes the line "setcorona(COLUMN_L, CORONA_OFFY, 0.0);". I wonder, is it possible there's a problem with 1.48 and CORONA_OFFY is not being properly executed? This would explain everything: the height is at 19 for the reason you explained, and the script sets it to zero to put it inside the lamppost, which works in 1.42, but for some reason isn't read properly in 1.48 and so the light spawns much higher.

 

Great news about SDL2 working with MP3. I don't know if I can help with SDL1, the only version I know I have is the one that comes with Doom Legacy.

Share this post


Link to post

I checked using the debugger and the y-offset does work.  I saw the yoffset was set to 0.

 

Setting values directly from the debugger, I found that -55 puts the corona inside the lamp shade.

They are coronas, not lights, so they get dim when you get too close to them.

You might want to try another light type.

 

Share this post


Link to post

DoomLegacy SVN 1624 has:

 

Support for MP3 and OGG.  This is hampered by my SDL 1.2 refusing to play MP3.

 

Support for SDL2 (a compile option selected using make_options).  It will also compile as before using SDL 1.2.

The SDL2 support is working for video and keyboard, but the sound is giving some strange problems.

At one time it would play MP3, but now SDL2 will not play any sounds at all.

I think my SDL sound system is slightly broken, as this happened only lately.

 

This notification is for those who might want download these and experience some of that cutting edge debugging experience that I am enjoying.

Of course, if it works for you, that would be interesting to me too.

Enjoy

 

Share this post


Link to post
3 hours ago, wesleyjohnson said:

DoomLegacy SVN 1624 has:

 

Support for MP3 and OGG.  This is hampered by my SDL 1.2 refusing to play MP3.

 

Support for SDL2 (a compile option selected using make_options) It will also compile as before using SDL 1.2.

Glad you're making some progress.

 

Anyways, there is an issue with MIDI mapping in the latest release of Doom Legacy.

 

Also, WAV lumps aren't always played at the right speed.

Edited by Nikku4211

Share this post


Link to post

@wesleyjohnson why don't simply use external libraries to decode various sound formats instead? there is drlibs, for example, with "dr_mp3.h" single-header decorer in the style of STB (that's what i'm using in k8vavoom to play mp3s).

Share this post


Link to post

The MIDI issue seems to be inconsistent device selection for playing some music.  That is exactly the problem I am experiencing now.  It seems to direct the MP3 off to some devices, and I get complaints from some of them, including the one that according to the the SDL_mixer docs should of taken over the  job of playing MP3 (was smpeg and now should be libmpg123).

It claims it cannot find the header.   I used the header to determine it was an MP3.

 

This morning the SDL sound was still down.  Even using old DoomLegacy binaries it was totally non-responsive.

Tried a different DoomLegacy config, and nothing changed.

Tried using another user account, and the SDL (at least the MUS part) is working over there.

Come back to my account, and the sound (MUS part) is working here too.

 

The MP3 still will not play.   A week ago the MP3 played fine using SDL2, every time I tested it.

 

I have no wish to involve another library.  I have to satisfy that library on way too many OS ports.

SDL should already be able to handle MP3 and OGG.  There are only a few wads that even use those.

I have looked at many of those other doom, to see how their SDL was initialized, and either it is very much the same, or totally obscured by a different coding style.

 

This is like I forgot to put a bolt in somewhere and a part of the suspension is flopping around loose.  Something like an uninitialized variable or SDL setting probably.

This is the same sound setup that I have been using for years.   The only thing that I have done to it is to start using MP3 and SDL2.

 

 

 

Edited by wesleyjohnson

Share this post


Link to post

Thank you for the bug reports, and especially the examples needed to debug the bugs.

If anyone should submit a bug report on this new SDL2 code, you MUST mention the SVN number.  I will probably bump to 1.48.11 for the current code, but that is not how debugging versions are identified.  We use the SVN number + patches, as that is always revised.

Otherwise I will assume that the bug occurs on the official distributed binary release.

The SVN number prints out at the top of the listing (as rev) when DoomLegacy starts,  example  "DoomLegacy 1.48.10 (rev 1624)".

It is also at the top of log.txt.

 

 

Share this post


Link to post

Found 1 problem:  cut and paste error.

For MP3, it was passing an uninitialized buffer meant for MUS to MIDI, instead of the MP3 data.  No wonder it could not play MP3.

There were several versions of the line I was testing, and I selected for the submit what I thought was the good one, previously tested, and did not notice the difference.

The real cause was that the transfer from testing code to final patch was not going smoothly, and I was having to diagnose new compile errors that were popping up.

This was caused by the MP3 code, being not being testable on SDL1, so the final versions of some fixes had to come from the SDL2 test code, where it actually worked.

--- Too-much-information --- 

 

Still need a way to steer midi to the device I want.

From reading the SDL2 code, it seems to use whatever loaded module it finds first, that handles that type of music.

We have no control of what order the loaded modules appear in that list.  They are detected at SDL2 mixer init, and apparantly even later if not preloaded.

 

 

Edited by wesleyjohnson

Share this post


Link to post
11 hours ago, wesleyjohnson said:

I have to satisfy that library on way too many OS ports

that's exactly why i am using STB and DR libs: they aren't "libraries" in the way we used to. just drop that file in your project, and that's it. they meant to be simply #include-d, no strings attached, no extra dependencies required. they aren't do their own file reading or sound output too, you just feed them with data, and get decoded samples in output buffer. which is, i believe, way more "bullet-proof" than to expect SDL to have all decoders included in each possible distro.

Share this post


Link to post

I downloaded a copy of the DR libs for reviewing and maybe future use.

However, the MP3 is working (going to commit that code tonight, maybe), and I have way too many things to work on already.

 

Current problem is the MIDI.  As long as I have Fluidsynth installed, the SDL2 mixer insists on using it instead of the TiMidity.  Fluidsynth has such weird instrument effects that it sounds like something is erratic or broken (but it plays it the same every time).  There seems to be some requirement from SDL2 that FluidSynth get its instrument package from a specific place.

The directory is there, there is *something* there, but not sure if it is an instrument package.  The requirement is lacking some important details, like actual file names.

Still investigating that.

 

(Update: In the SDL_mixer code, if the environment variable is not set, the default goes to where the instrument packages actually are on Linux

 and gets /usr/share/sounds/sf2/FluidR3_GM.sf2.   What this is going to do on Windows, I do not know).

 

 

It seems that the only way to get control, is to bypass SDL and route the Midi directly to ALSA.   No decoders are needed, it is just sending the data over there.

Would not need to do that if there just was some way to get SDL to use its TiMidity connection instead of the FluidSynth one.

I have looked into some other ports, to see what they may have done about this problem.  Even though it is somewhat similar to DoomLegacy code, it is like it went has gone through a foreign language translation from another coding style.   Cannot examine their possible solutions due to all the additional experiments they have mixed in.

Probably will spend the night reading more of the SDL_mixer code.

 

 

Edited by wesleyjohnson : new information

Share this post


Link to post

I don't know if this is helpful, since I'm on Windows 7 and not Linux, but for me SDL1 picks whichever MIDI device is set as default in the Windows registry keys. Initially this was the Windows softsynth, and when I changed the default device in the registry to an external (hardware) MIDI module SDL (and by extension Legacy) seamlessly started using this instead. This isn't unique to the SDL mixer that comes with Legacy, Eternity also started using the module when I set it to play through SDL. I don't know if things are different in SDL2 and/or Linux, but maybe if you can tell the system that Timidity should be the primary device (maybe through an ALSA config/parameter?) it'll work in the same way.

Share this post


Link to post

Thank you for that information.  I do not have much information on Windows 7 capabilities for selecting devices, or how SDL behaves in that respect.

At least that tells me that this should not be a problem with Windows.

 

I have an outstanding bug report that MIDI (on Windows 10) sometimes goes to Microsoft Synth, even thought the CoolSoft mapper is set to use a specific MIDI device.

This happens erratically from what I understand.

I should be able to expect that such a mapper on Windows would at least be consistent from day to day.

I do not know of anything that DoomLegacy could be doing that would affect the MIDI mapping, even though the report is that all these other Doom ports do not have the problem.

There might be an environment variable involved, as the SDL_mixer code sometimes checks for them, and there is one for external MIDI devices.

I could suspect that many of the Doom ports mentioned bypass the SDL MIDI routing.

 

It seems that SDL_mixer will autoload the Fluidsynth support, even if you do not select it at SDL_init.

If you did not have Fluidsynth at compile time, SDL_mixer has a copy in its source code.

 

Edited by wesleyjohnson

Share this post


Link to post

Latest DoomLegacy SVN has the patch for MP3  (I passed it the right buffer this time), and fixed re-playing the same MP3.

Bumped to Version 1.48.11  for code development.

Edited by wesleyjohnson

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
×