DoomLegacy 1.46.2

[BigDickBzzrak]

MR.ROCKET said:

I currently only make the Windows installer after Wesley releases a new build.

Only? I've read an old thread where Wesley argued with half of this forum about how Windows users expect every program to come with an installer and how SDL should be copied to c:\windows. The thread went for 6 pages or so! You're doing god's work man.

[Death Egg]

Jon said:

My honest opinion at the time, and it is the same now, is that the C++ rewrite is a mistake; and I think to some extent my feelings on the matter have born out. It should just be skipped, imho, and all efforts (and there's precious few people working on it anymore after all) put into the C version, which should be considered the canonical branch again.

It may be true this was likely the reason Legacy phased out, if so much work has already been done on the project, why let it all go to waste? It seemed to have some pretty cool features going for it. Maybe if it put itself out more, asked aound for programmers to help out finish it, it could get itself together and who knows, a couple years form now finally see an official release.

[Mr.Rocket]

bzzrak said:

Only? I've read an old thread where Wesley argued with half of this forum about how Windows users expect every program to come with an installer and how SDL should be copied to c:\windows. The thread went for 6 pages or so! You're doing god's work man.

Woah, I didn't realize that went on. Well glad I showed up when I did.
I suppose that ups me to at least 2 grains of sugar in the big cookie then. :)

RestlessRodent said:

Legacy 2 suffered from feature creep, they kept adding more and more features before they had a finished release. This ultimately lead to major burn out and at that point since most of the effort was on Doom Legacy 2, both ports pretty much died.

Perhaps this was the case back when before Wesley started working on Legacy1.x again.
However your comment tends to make me feel a little bad as it seems to work on pure assumption at the end stating that "both ports pretty much died" in a past tense manner. Well I don't think that was the case as for the most part it has to do with time in resources as well as encouragement. Which imo brakes down into:
Time being R/L, resources being the amount of people taking hand in the development of the project, and encouragement being the community or player base.
I guess this is also my assumption, but more of a positive one.
When in reality, for the past 5 years Wesley's been fixing bugs and adding small features to Legacy1. ~ While Legacy2 lay dormant for about the same amount of time.

While both versions hold a great amount of potential, it's just a matter of attention really. It doesn't have anything to do with the source port its self, as the source port will just sit there and wait for someone to work on it. At least until its a finished project. So from my point of view, you have to love what you do, the community has to love what you do, and that's what gives you encouragement.
~ as long as "time in resources" don't hold you back of course. :)

Aside from that, who's to say some programmer doesn't walk in utilizing the most advanced open source doom engine known to man adding most of the features and ideas from legacy 1 and 2, and calling it Doom Legacy 3.
That being said, a source port actually never dies, only its attention.




Cheers

[Death Egg]

So, if or when Legacy 2 comes out, will the developers of Legacy 1 move to it too? It seems like a weird decision to potentially develop two separate versions of the same port when one is clearly better.

[RestlessRodent]

MR.ROCKET said:

Perhaps this was the case back when before Wesley started working on Legacy1.x again.

When I started ReMooD (which is based on Doom Legacy), Doom Legacy at the time barely had any players. There were no releases for years and work on the actual source port was at a standstill. Legacy was pretty much untouched until Wesley picked it up again. I will add that I was mocked for basing my source port on Doom Legacy when I could have chosen PrBoom or ZDoom.

MR.ROCKET said:

Aside from that, who's to say some programmer doesn't walk in utilizing the most advanced open source doom engine known to man adding most of the features and ideas from legacy 1 and 2, and calling it Doom Legacy 3.
That being said, a source port actually never dies, only its attention.

At this point, that would be picking up one of the ZDoom family ports and adding a FraggleScript compiler and a few extra format parsers to one of them and then calling it Doom Legacy 3. The number of Doom Legacy 2 WADs that have been released can probably be counted on one hand. Since one of the ZDooms already has the equivalent features you may as well make your map for ZDoom. If you rely solely on features, you are not going to catch up or beat the ZDoom family any time soon.

[BigDickBzzrak]

Apparently this Ville guy read this thread and actually did some stuff on Legacy 2. If you're reading this, keep it up!

[Mr.Rocket]

Woah that's good to hear!
Ville is actually the primary programmer for Legacy 2!

Cheers

[VGA]

Is that a fork? I don't get it.

[Death Egg]

Very exciting stuff. I can't wait to try it out when it's released.

[Jon]

Death Egg said:

It may be true this was likely the reason Legacy phased out, if so much work has already been done on the project, why let it all go to waste? It seemed to have some pretty cool features going for it. Maybe if it put itself out more, asked aound for programmers to help out finish it, it could get itself together and who knows, a couple years form now finally see an official release.

How many interesting features are unique to the C++ branch? It might be less effort to port them back to the C one.

VGA said:

Is that a fork? I don't get it.

I think the uncertainty about which is the "real" branch is definitely a problem for Doom Legacy. One or the other should probably rename themselves. I'd go so far as to suggest that since the C++/v2 branch has never had a release, that's the one that should fork...

[Death Egg]

Jon said:

How many interesting features are unique to the C++ branch? It might be less effort to port them back to the C one.

Full Hexen support, for one. I wonder if the lead programmer would let others help with patching all the bugs and giving it a release, it's certainly been long enough for it to happen.

[Gez]

RestlessRodent said:

At this point, that would be picking up one of the ZDoom family ports and adding a FraggleScript compiler

ZDoom already supports FraggleScript!

[RestlessRodent]

Gez said:

ZDoom already supports FraggleScript!

I remember it being deprecated, I suppose it was never removed?

[Rachael]

In ZDoom terms, deprecation means "don't use this in a newer project" - nothing is ever actually removed unless it never hit an official release. Otherwise a lot of old mods would break.

[<inactive>Player Lin]

And if some maps/mods using that deprecated FraggleScript and found bugged in ZDooM/GZDooM. Should be report to get the maps/mods fixed unless the problem is unfixable. :P

[Graf Zahl]

If there is an obvious bug it should be reported, of course. If it is fixable it will get fixed, but never expect adjustment to a deprecated feature to suit a new project.

[Jon]

building this from source is a serious pain in the ass. A few references to README_compiling.txt which doesn't exist. A Makefile, and a CMakeFiles.txt, but the latter is not related to the former. cmake doesn't work, I guess that is abandoned but left in the source tree.

[Graf Zahl]

The source also throws out a shitload of warnings and needs a serious and thorough cleanup pass. Just to get it to compile with Visual Studio I had to disable several low level parts, some because they require GCC, some because something in there is messed up but seems to compile anyway on GCC.

And yes, the CMake project is close to worthless.

[Jon]

Hmm the SF project has all of CVS, SVN and Git enabled :>

A migration to Github would probably greatly improve people collaborating on this.

(and resolving which of 1.4xx versus 2.xx is really "doom legacy" going forward)

Increasingly wondering if I should leave this as nostalgia

[RjY]

Jon, FWIW I did this

svn co svn://svn.code.sf.net/p/doomlegacy/svn/legacy_one/trunk legacy

cd legacy

# if you type 'make' at this point it instructs you to
# choose an OS and suggested starting with OS=LINUX, so:

make OS=LINUX

# it then creates a 'make_options' file which you can edit
# if you want; I saw no need, and continued with:

make

It built an executable successfully, which when run opened a window with a rather cute green-on-black text console. Sadly I progressed no further because I seem to lack a legacy.wad. I guess that's the next thing to find.

This was on debian sid with at least libsdl1.2-dev and libsdl-mixer1.2-dev packages installed.

----

Edit: Have a build log. http://sprunge.us/LaZY Humorous URL :)

[Graf Zahl]

RjY said:

Jon, FWIW I did this

svn co svn://svn.code.sf.net/p/doomlegacy/svn/legacy_one/trunk legacy

cd legacy

# if you type 'make' at this point it instructs you to
# choose an OS and suggested starting with OS=LINUX, so:

make OS=LINUX

# it then creates a 'make_options' file which you can edit
# if you want; I saw no need, and continued with:

make

It built an executable successfully,

Well, obviously it does, considering it's being developed on Linux and there's binaries.

But it doesn't change anything about the source being a MESS with a capital everything. I wonder how many warnings it creates - but from what I see in Visual Studio some seem serious.

[fabian]

Been there, done that:

https://www.doomworld.com/vb/post/1352901

[Death Egg]

Jon said:

Hmm the SF project has all of CVS, SVN and Git enabled :>

A migration to Github would probably greatly improve people collaborating on this.

If anything gets people working on this again I'm all for it.

[Graf Zahl]

What Legacy needs to get people involved is to make it compile on Windows again without jumping through hoops. But that's a gargantuan task because far too much of this code has never been tested on anything but GCC, and probably not with all the latest language features active.

Git would definitely be a plus because it'd at least allow to fix all the warnings file by file and PR the changes.

[Jon]

RjY said:

Jon, FWIW I did this

Thanks, I was attempting to build on OSX which is probably doomed from the start.

I dug out my old Legacy special effects PWAD (called "smallfun") and tried it with the latest legacy (linux binaries rather than attempting a source build). What had motivated me somewhat to look at legacy again was getting these old things cleaned up and released. However literally none of the special effects in the PWAD work anymore. So much for that! Maybe one day I will work out exactly which versions of Legacy my PWAD would function with; but for now I can't be bothered. I put Smallfun up at https://jmtd.net/doom/ (which I spent a little time revamping), probably won't bother uploading to /idgames since I can't explain what engine/version would actually play it.

[Graf Zahl]

That level uses the water hack if I am not mistaken. That had already been removed from the engine when I first used it back in 2002. If I am not mistaken that would require Legacy 1.28 which is not easy to get these days.

[Jon]

Graf Zahl said:

That level uses the water hack if I am not mistaken. That had already been removed from the engine when I first used it back in 2002. If I am not mistaken that would require Legacy 1.28 which is not easy to get these days.

It has the water hack in it (the negative-tag thing) but not for anything physically important. There are a few transparent lines of various types (predating the boom support) and I think those linedef tags got overridden with boom meanings; there were also some behaviours which rely on the "dead lost soul" thing being redefined (via DEHACKED) to have a larger radius and have "physicality" and used as invisible stepping stones (the bridge hack that I allude to in the text file, originally discovered, I think, by Gokuma). I'm not sure why they would have broken.

I think that invisible bridge thing might work in some other ports that have optional z-height clipping checks, like Crispy (and I guess zdoom) but I haven't tried recently.

[wesleyjohnson]

I have not been paying attention lately...

To clear some stuff up:

The compile is clean for Linux GCC 4.x, all warnings were resolved years ago.
I am getting Linux 4.4 up (slowly as there is a ton of stuff to port over),
which has GCC 5.x, and will see what that mucks up now.

I do not have any MS compilers, so if anyone wants it to compile clean on a
MS compiler, they will have to contribute some information (bug reports please).
The XP machine (intermittantly assembled, when I don't need the table for something else) only has MinGW compilers, and I do not trust the direct draw compiles.

Have contributers for BSD, and now Mac PPC. Fixes for big-endian on a Power-PC
are in the works.

I wish someone would compile it for OS2 and let me know what errors occurred and what fixes were made, even if they do not get it running. Then I can fix
the code base for OS2, which someone else can use to get further.

This state of work on various ports explains much about Legacy 2.0.
Legacy 2.0 simplified to the SDL port only, reorganized the files.
They added hexen. Mostly it is now SmiteMeisters project.

I work on 1.4x mainly because I can work without stepping on anyone's toes.
The moment I start working on 2.0, I would have to be in constant negotiation
with SmiteMeister.
My working machines are off-the-internet, so the turn around in a conversation is
measured in days. It is just easier to work on an isolated branch.
SmiteMeister would like to get work on Legacy 2.0 started again, but that is not
going to kill 1.4x because the 1.4x branch serves some users that 2.0 does not.
There is going to be a considerable time, maybe infinite, that DoomLegacy 1.4x
lives on while Legacy 2.0 becomes the main release for those using mainstream OS and
installations. That first requires that 1.4x get to the point where it is stable enough to not require giving it constant attention. Unfortunately, it is where I like to
experiment, and I have a whole new set of changes I still want to make, and some
new experimental stuff (extensions) to work on.

Somehow trying to combine them would likely introduce more bugs than solve problems.
The time in patching or maintaining is insignificant compared to the time spent
trying to discover the cause of reported bugs. If the reported symptoms happened on my machines it would be easier.

[Graf Zahl]

wesleyjohnson said:

I do not have any MS compilers, so if anyone wants it to compile clean on a
MS compiler, they will have to contribute some information (bug reports please).
The XP machine (intermittantly assembled, when I don't need the table for something else) only has MinGW compilers, and I do not trust the direct draw compiles.

The main blocking issue is that parts of the code use CRT functions that do not exist on MSVC. I got it to compile once, but I had to virtually disable the entire network code and a few other pieces to get it to work.

Not knowing the code base well enough it's stuff I wouldn't want to touch for the fear of breaking it.

[Jon]

wesleyjohnson said:

That first requires that 1.4x get to the point where it is stable enough to not require giving it constant attention. Unfortunately, it is where I like to
experiment, and I have a whole new set of changes I still want to make, and some
new experimental stuff (extensions) to work on.

Not to sound facetious but, you've heard of branches in version control, right? You don't seriously expect to do bug clean up and experimental feature development in the same branch at the same time?