Doom Legacy 1.47.2 Release

I see, sorry for making assumptions back there. However, upon further testing, there's definitely something weird going on with the enemies movement, they come at you walking sideways/backwards a lot of times.

The sideways walking annoys me too.  This walking weirdness started when the MBF movement code was added.

From my tests, it seems to be dependent upon the MBF monster avoid hazard option.  Turn that off.

Have not yet tracked down the exact code segment that allows backward movement.

Need to put on my list to add another option that fixes MBF movement weirdness.

This is where someone could say:

Yes, the monsters walk weird in MBF.

Or, NO, the monsters don't walk weird in MBF, you must have got the code wrong.

Might be useful, this is a back burner issue right now.

Been working on:

Config files:

New code (testing) has a separate additional config file for each drawmode.

When the drawmode is changed, the config file for that drawmode is loaded  as a drawmode config file.

The drawmode config file is optional, and only has selected settings, like gamma.

Any setting from the drawmode config file overrides the main config file settings, (Push down storage).

The system tracks which config file a setting came from, and will write it back to that config file.

The menus allow adding and removing a setting to/from the drawmode config file.

Adding Corona draws to software rendering:

  Native draw looks nice.  Even got something horrible looking that renders in 8bit palette mode (poor alpha drawing support).

  Found out what happens when the terminating 0xFF of a patch column gets overwritten.  Rendering continues into all the following column data, until it finds an 0xFF.

  Playing Phobiata using native drawmode is much faster than using OpenGL.  With the software rendered coronas, you can now see the fireflies and other fragglescript created lights.

Changing game from the menu:

  Stalled due to difficulty backing out of some of the data modifications made for particular games.

Added some new corona types.  The corona around torches now flickers.

Added some new DrawAlpha draw modes, to better draw coronas in software draw.

They will likely get used for fog draw too.

This even works in 8 bit palette mode, due to having support for doing RGB color math,

and converting back to a palette color using a 12 bit RGB to palette lookup.  It is tolerable now.

But the best play mode is now NATIVE.  Although OPENGL has dynamic lights, it is slow on my machine.

Thinking about the next release, 1.47.4.

That means I will need to update the docs for these new corona types and modes.

Been wanting to try Doom Legacy but both times I've downloaded it, it absolutely refuses to launch whether its with the launcher it comes with or doing it through ZDL like I do with Doom Retro, PrBoom, Crispy, etc. Was looking through some of the posts about the launcher and I don't believe I'm getting the error message, or maybe I am but not seeing it. It will look like its going to launch, then nothing:(

From the "Launcher" comment, I am going to assume it is some version of Windows.

I also assume it is 1.47.2, as that is the latest version.

Make sure to read the docs.  All the setup instructions for various platforms are all in there.

Also you need two download files.  The executable download, and the support files download.  Put them both in the same directory.

Give doomlegacy its own directory.  Do not put them in your home directory, access to home has been restricted for security reasons.

You also need a wad file, like doom2.wad.

The way to do it when you have problems is to get a console, and type in the executable name, along with parameters.

First, cd to the executable directory, because that eliminates alot of possible problems.

On Windows, output and error messages are shoved into the files  stderr and stdout in the executable directory.  Windows will not output them to the console like Linux does.

I suggest first to test that it runs at all.

>> doomlegacy --help

To get to the built-in launcher, give it no parameters

>> doomlegacy

Then test what graphics you may ask for

>>  doomlegacy -game doom2

or

>> doomlegacy -native

and only later

>> doomlegacy -opengl

I just wanted to say that when I run Legacy through ZDL, I have to add the -opengl parameter to "always add these parameters". Why not add this to in-game option where you can switch renderer from software to opengl (and vice versa), then restart, and the render parameter will save to settings. This is done in modern source ports.

6 hours ago, wesleyjohnson said:

From the "Launcher" comment, I am going to assume it is some version of Windows.

I also assume it is 1.47.2, as that is the latest version.

 

Make sure to read the docs.  All the setup instructions for various platforms are all in there.

Also you need two download files.  The executable download, and the support files download.  Put them both in the same directory.

Give doomlegacy its own directory.  Do not put them in your home directory, access to home has been restricted for security reasons.

You also need a wad file, like doom2.wad.

 

You would be correct on the 1st 2 assumpltions, thank you for help. I see the problem now, I had only downloaded the EXE, not the support files lol. Looking forward to giving this another shot, appreciate your help wesleyjohnson:)

Edit: I found the problem, the readme said not to put Legacy in your HOME directory so all I did was move the folder to Documents and its working perfectly now. eally love how well this plays and its so much like I remember when I was a kid playing Doom 2 and Final Doom all the time in '96 lol. Thanks again!

DoomLegacy 1.47.3 can change the drawmode in the menu, and does save it in the config file.

Read back from the top of this topic.

DoomLegacy should go in its own directory.

During multi-player sessions, if your DoomLegacy is the server, it allows other DoomLegacy to download your wad files.  There are some security measures taken so this feature cannot be used to search your computer.  One of those is to block file searches to the HOME directory.  If it cannot load legacy.wad (to get support graphics) it will give you error message and quit, which on Windows just looks like quit because all the error messages written to stderr just end up in the stderr file.

I can confirm that setting the MBF (monster avoid hazard) to Off, does indeed fix the issue where the monsters would otherwise walk sideways on sight, if turned On.

Has this been fixed in the new yet to be released 1.47.3?

The flickering coronas sounds pretty neat. I'm hoping they will flicker at random times and not based on sprite animation frame time.

I can't wait to try out the new version!

When do you think it might be ready for release? 

Thanks

What I would like to know is if anyone who has used MBF seen this sideways walking.  I want to know if it is an MBF bug, or a bug in my implementing of MBF code.

I currently cannot test MBF directly.

If the patches that I am working on currently would work, I would like to make the release of 1.47.4 before Aug 2019.   As that is not going to happen, then as soon as I

give up on them, and just release what I got.

I am working extending the short skies up to 240 height, so that we never have to stretch a sky.  So far the mechanics are finally working.  Some very old hacks in the texture code were unmaintainable, and I am revising that coding first.   The extended skies are starting to look tolerable, if you don't stare directly at them.  I keep breaking the starry night skies.

The starry night skies extend the best of all, sometimes.  Will put in a select switch, so users can select which sky treatment works best for a wad.  This involves way too much testing, which makes this coding take an enormous amount of time.

Hi Wesley,

I've recently had a look at the SVN log and I must say wow you've been busy!

But I haven't heard much lately so I thought I'd ask how things are going over there?

Cheers, looking forward to the next release! 

Got a little fix that reduces the sideways walking.  It was the one difference from MBF that I could find, and still does not look it should do anything.

The hang-up lately is that I am working on Sky extension, so as to not need to stretch any skies.  The problem is that the my code is so fragile that every change causes an extensive debugging session.   I am now on my third attempt, after having disabled two previous attempts.   All the support for this is done, it is just the generation of the sky details that does not behave reasonably.  Just started another reorganization of that code, to deal with three possible sources of conflict in what is drawn for the sky.  Of course, now it is refusing to draw anything but the background and a few scraggles.

Have a selection item for skies, one of which extends with a starry sky.  It generates a star field above the wad sky, with some extension of areas the sky.

That looks rather like a starry night above the distant hills.  I only have to break up that straight line some.

Might let the starry sky dip down into the wad sky background.

I have about three works in progress that I wanted to get into the next release too, but I want to get past the skies problem first.

So, it looks like late Sept. at best.

The Sky code has been made tolerable, for now.

Some other bug reports have surfaced and are being fixed too.

If it affects the network interface or version, I am fixing it now for 1.48.

I would have released 1.48 last month (ahhaaa, that was OCT), but...

There have been a few small improvements made in bots vrs network play, and that broke the network code somewhere.

Now, I am having to do the deep dive into all things network, and finally fix the kludges.

The new fixes are not necessarily all giving immediate good results, but I hope this eventually makes the network behavior more

predictable.

On 3/25/2019 at 7:38 PM, DANZA said:

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.

This!! +1

Back in the day Legacy was my port of choice because it had a convenient built-in launcher and because it looked/felt the most similar to what I remembered playing in the DOS version and in Doom95. Could also play Heretic on it fine.

I tried to play it recently, but there were some issues with music/graphics, I don't remember what it was specifically. I still have to try the Linux version.

How could these modern operating systems fuck up such a simple thing like MIDI playback? It was the most simplest thing back in the day that was a given that would come with every system. Nowadays, you have to install it and look for the soundfonts/instruments yourself. How boring, modern computing HaHaHa  And it's something that don't have a proper excuse, because it takes kilobytes of storage, it's not like it takes hundreds of megs on disk. Wow...

I would have had 1.48 released by now, but the network code got broke somewhere, some time.

At first, it would kick player2 when bots were added.  The repair system would fail to fix anything, so it would try 7 times and give up.

With the latest fixes, it hangs when the network player tries to join the game.

The more I look at the network code, the more inconsistencies I find.  When I try to fix them, it gets worse.

This is going to be a major rewrite of all parts of the network code, just to eliminate the kludges.

The savegame download code has had a race condition that I am going to eliminate.

I have not even tested in the last week because I can see so many problems already, just by inspection.

The new network code will have some decent state maintenance so that some checking can be done.

There will be some new network controls.

This is just an update, that a release of 1.48 is still ongoing, and may happen any month now.

And three months later, I am still working on the network code.

My aim was to make it more robust by making the network code more straight-forward.

Instead, I am exposing how fragile it all is.

Have finally found the problem that has been holding me up for that last two months.  Have not got a workable fix yet, but I found the problem.

The compiler is padding my network packet structures to align some of the types.

This is compounded by the fact that the other machine I use for testing network, has a different compiler than my main machine.

They apparantly do not agree on everything.

You might think that packing the structures would be the obvious answer.

There are signs that packing has been used, and then disabled again.

I tried packing some structures, and that made packets look like gibberish to the other machine.

The two machines are both x86, but have different compilers because one is a windows machine.

Clearly, there are some serious problems with using packed structures.

Well, we aim to be compatible with multiple platforms, and I want those platforms to be able to play network games together.

I am only working with two compilers, and the attribute for packing used by GCC, is apparently ignored by Mingw32.

That leaves the pragma pack, which being a pragma, can be ignored by the compiler.

In addition, for some platforms there are lingering doubts that they can perform unaligned accesses at all (like SPARC).

Really, using structures at all to form network packets is questionable.   They make it easy to access the fields,

but also are easy to violate the compiler expectations, producing misplaced accesses.  If both machines misplace the

write and read the same, it may even work.  Or, as in one bug, when a command with a map name was the last command,

(and this happened only when this message was the last command in the packet) it would get a different character in

place of the terminating 0 of a string, producing a map name that the client did not understand.  The string was out of position

and the packet length was calculated, so the last char did not get transmitted with the packet.

SO..

I am trying the approach of manually aligning every network packet structure, so there are no more surprises.

I have created  two types for 16 and 32 bit values, that are byte arrays that have read and write functions.

They can be unaligned in the packet, and it solves the endian problem too. 

They can be used with packet structures that cannot be aligned, such as optional sections, and repeated sections.

I have got back to the point where my client machine can connect to the server again.  Now, to just chase down some lingering anomalies.