DoomLegacy 1.45.2 Release

Doom Legacy 1.45.2 has been released.

This fixes some bugs that I felt needed to be fixed sooner than later.
I recommend updating to this version.

One of the bugs left an extraneous character in the command buffer with each command. Three or more commands buffered would suffer from this random character between them. Wads that previously worked would suddenly fail because other bug fixes changed the random character.

Source and Linux binaries are ready. Win32 binaries are in the process of being posted.

Looks awesome, is there a changelog?

Great, downloading!

Hopefully this version fixed the OpenGL problem.

Well, OpenGL didn't apply the last time I used that port while I still had my XP.

There is a detailed changelog in the common download, logs/WDJlog.txt.

There are a few differences in rendering OpenGL from the software renderer. In this port the software renderer is a better implementation of Vanilla effects, even though OpenGL is required for some hardware render special effects (like corona).
The only known OpenGL render problems are with self-referencing sector
effects, and perhaps other Vanilla render tricks.

There may be other difficulties with OpenGL that depend on the GL library used and the SDL version used. I develop using Linux and only have Win98 for testing. Problems with newer Windows versions will require some user debugging and detailed bug reports to resolve.

Wesley I am willing to donate you a Vista-era laptop if it means you stop using Windows 98 already...it was a great OS but nobody uses it anymore, and its impractical to release a version without testing it on modern OSs. Especially concerning OpenGL.

I know I've offered support with this in the past but I've been so tied up and busy, but its the least I can do for you. It's not great, mind you, but it'll get the job done.

If I had a Vista-era laptop around, I would probably convert it to Linux. I abandoned Windows a long time ago and have no will to deal with any more of Microsoft's BS. Got one XP machine here, and now that I no longer have to get Microsoft updates, makes it easier on me. Microsoft updates have done more damage and wasted more of my time than any virus or worm (we are careful). The owner of the XP machine does not want Doom stuff on it, so I have to wait until they retire the machine. But I have put Linux in dual boot on it already, and I may get that user to switch to Linux, so I may not get an XP machine at all.

What the project needs is someone who is willing to debug on a recent Windows based machine, and that is not me.

This is better done by someone who is familiar with Windows based debugging and Windows based SDL and OpenGL, which I am not. I do not have Vista specific tools, have no experience with such tools, and am likely to make more Windows specific mistakes. It is excess overhead for me to acquire and learn all that for one session of debugging the OpenGL and SDL interface. I have no wish to become a Window's developer.

Edit: I have looked at other ports (like Edge) that I know have been done by Windows developers, but have not spotted anything significantly different in how they deal with SDL and OpenGL.
I really don't know what bugs I am even looking for, the reports are so lacking in details.

Hmm, the midi code is still broken (best demonstrated by freedoom's map01 music), some sound effects sound slowed down, and split screen is always horizontal no matter what the aspect ratio is. It doesn't support pillarboxing to 4:3 from widescreen ratios either.

Midi code broken: Not on my Win98 machine, and I cannot experience what you refer to on your machine. More details, and a decent bug report are needed.

Sound Effects slow down: Sounds like a Windows driver problem, or a game priority problem. Please investigate if you have any competing high priority services, or a low priority on DoomLegacy.

Splitscreen: DoomLegacy does not have wide screen adaptations yet. I worked on it but it could not be made ready for 1.45. The widescreen splitscreen ideas are interesting, but not DoomLegacy features.

OpenGL still not working. Unless I'm not doing some configuring right :/

OpenGL relies on SDL being installed, and OpenGL libraries being installed for your video card.
I have used DoomLegacy with the OpenGL renderer on SDL Linux 2.4 and SDL Linux 2.6, and X11 Linux 2.6, and SDL Win98.
Remember, DoomLegacy OpenGL has a separate DoomLegacy config file, so it can have settings maintained independently from the software renderer.

So windows binary never got released? It's not on SourceForge... :(

Has anyone tried building this on Mac?

I dont know if this still applies, I worked around the midi problem by converting the files from MUS to MIDI format with slade3.

This worked when I was using windows XP with the alpha3 build and I'm positive it will still work for this release along with later windows.

Hi Wesley, thanks for trying to keep Legacy alive. I have a number of small suggestions for things that I would like to discuss with you, but I'm not sure where is best. Email? Do you do IRC?

I think you should just take Chu's offer and stop testing anything Windows on an obsolete OS (98? Seriously?) to save some people the trouble of arguing about the SDL thing.

11-month bump, folks. This thread's old.

Oops, didn't notice the date.

But in all seriousness, wesley should stop using that piece of junk called Windows 98 for "Windows" testing.

3noneTwo said:

11-month bump, folks. This thread's old.

Correct, but newer discussions about the same topic stalled at the exact same point so it's actually still up-to-date.

I still have that computer Wesley... You could always dual boot and put XP on it!

Is it hard to set up a Windows 7 VM on Linux?

No. Especially since VirtualBox is packaged in all the major distros.

DoomLegacy is hosted on SourceForge, which handles bug reports and feature requests.
Please spread things out so individual items can be handled individually.
All the members get emails. We have members, I am just the only one editing code right now.

http://sourceforge.net/tracker/?group_id=2479&atid=102479

The major need is for programmers competent on one of these other ports to check-out and update the port specific code. I am already overloaded with multiple free code projects, and am limited in how much time I can spend on this. I am not going to get heavily involved with learning Windows programming.

I do not have any shortage of machines here. I do not have is an XP installation CD and cannot just stick it on any machine I want. I have recently be given a couple of laptops, an XP machine without a screen (and no CD-ROM so I cannot move the XP), and the other without a hard-drive. The estimated repairs costs for either of them exceed the value.

The Fall is where I am very busy trying to beat the snow season. Work on DoomLegacy will wait until the snow falls. I plan a December release. I have no shortage of things already planned for that release, like playing on a 9:16 monitor.

I have also been working on a large set of Doom extensions, but doubt that much will get done on testing those right now. And I do not feel like fighting with the conservatives right now. One of the extensions was a system to expand a few views for static objects.

wesleyjohnson said:

DoomLegacy is hosted on SourceForge, which handles bug reports and feature requests.
Please spread things out so individual items can be handled individually.
All the members get emails. We have members, I am just the only one editing code right now.

http://sourceforge.net/tracker/?group_id=2479&atid=102479

Thanks. Pretty much the first thing I was going to suggest is that SF is very unfriendly to contributors and is off-putting and it would be wise to consider migrating elsewhere. That's something I could help with. Github would be a very fine choice.

Another is the picture about which version of Legacy (the C version, or the C++ version, and which of the three source repos you have) are the "current" or canonical one needs to be clearer and better advertised around the place, not least the Legacy website.

The major need is for programmers competent on one of these other ports to check-out and update the port specific code. I am already overloaded with multiple free code projects, and am limited in how much time I can spend on this. I am not going to get heavily involved with learning Windows programming.

That's quite wise. (I personally can't help with win32 stuff much myself, but I could help with OS X.)

There is code for Mac (OS X) for both native graphics and for SDL.
The native code is old, and is not considered supported right now. I update it to keep it current to interface changes, but it has not been compiled for ages.

The Mac SDL port is the official supported port.
I was attempting to debug it with some else who had a Mac, but that arrangement fell apart (debugging by email). Any input on why that Mac SDL interface fails would be a help, short term or long term.
You can get the Subversion latest code from SourceForge.
You should look that over to see what you may be getting into.
First look into the make_options for Mac. It sets up the defines for the #ifdef.
Look in the sdl port directory and search for #ifdef for the MAC versions.
I cannot argue much about code that gets a specific port working, but changes that affect multiple ports usually run counter to some direction I am trying to take the code. Thanks for any contributions you can make.
I have gotten patch files for other ports, like FreeBSD, from Europe and Russia (I think).

Some of the other team members consider the C++ version to be the latest.
I stepped in to rescue the 1.42 branch because the C++ version (2.0) had stalled, and
the people who have worked on it have not finished some parts.

It has some significant differences that make it hard to transition to working on
that version.

wesleyjohnson said:

There is code for Mac (OS X) for both native graphics and for SDL.
The native code is old, and is not considered supported right now. I update it to keep it current to interface changes, but it has not been compiled for ages.

Thanks for the pointers. I would imagine that there is little point in the native port if the SDL one works. Might it be best to just remove it?

Some of the other team members consider the C++ version to be the latest.
I stepped in to rescue the 1.42 branch because the C++ version (2.0) had stalled, and
the people who have worked on it have not finished some parts.

I was personally pretty against the C++ port back when it was started; I'm not really surprised it stalled. I think it should be considered a failed experiment, and given that the C version in SVN is current, the current Git and CVS repositories archived and disabled. At least if you're staying on sourceforge. Presenting all three as active repos is pretty confusing to people browsing past on the SF website.

DoomLegacy 2.0 (C++) has Hexen and about 8 years work that has NOT been transfered to the DoomLegacy 1.x line.

The native ports have more direct hardware access than SDL. Some users may find
this attractive or necessary for their machine, for reasons I don't need to know. Someone wrote spend considerable time writing that port code, and somebody may want
to use it for their machine. I choose to NOT erase such work as long as there is
some slight possibility of it being useful.

The documentation and compile options steer the user to the SDL port for their machine.
It is a multi-port program. A few extra ports does not change that significantly.

Wesley, Im glad you are continuing to develop Legacy but please can you accept that laptop offer so we can use opengl on our windows PCs. Im champing at the bit to design some new Legacy maps (and improve some of my old ones) but I cant stand using the software renderer.

Discovered that a src Makefile has been missing from the SVN since spring.
This would seriously hamper compiling, unless you already had a Makefile from
a previous version. In the last updates the Makefile was split into a project Makefile, and one for compiling the src (the src Makefile).
My apologies to anyone who tried to compile DoomLegacy during the last few months.


Having a windows laptop would not make me a Windows programmer. I do not have the tools, nor the experience. I am already overloaded doing free software on Linux.
I am trying to get an XP laptop here working (it is missing a screen), but not for those reasons. The best I could do is move the MinGW to an XP platform and compile.
Improving the actual code requires someone who is familiar with programming Windows.
I cannot accept a working XP laptop if it is attached to some idea that I will use it to become a Windows programmer. The best I could do is eliminate the compile errors, test, and verify operation.

Same problem with the Mac.
Am trading an old Mac laptop for some flatscreen monitors because it is missing the harddrive, operating system, power-module, has a dead battery, and after fixing all that it would just have become an expensive Linux platform (it cannot run the latest mac OS anyway).

If you wish to truly be free from the Windows BS badguys you must forsake the Linux that is so similar to the Windows and become an appliance programmer and free the world from tyranny by porting Doom Legacy to your washing machine.