Doom Legacy issues

[Ladna]

Visual C is a pretty shitty C compiler. Unless you're using the latest dev releases, it doesn't even support C99, which is 16 years old.

[Graf Zahl]

Ladna said:

Visual C is a pretty shitty C compiler. Unless you're using the latest dev releases, it doesn't even support C99, which is 16 years old.

I AM using the latest dev release. Legacy doesn't use C99 anyway.

And I'm pretty sure that most of the problems - aside from badly named system #defines is that it's not standard compliant.

Normally when using some GCC code it will take a bit to sort out a handful of errors due to naming differences. This drowns the output window in error upon error upon error.

[fabian]

Graf Zahl said:

Well, no chance here, it takes great skill to write plain C code that only works with one compiler. The team that produced this certainly managed.

Don't be that hard. It's actually quite easy to throw in some POSIX-isms like basename()/dirname() or some GNU-isms like __attribute__ or something. It's just as easy the other way round by using itoa() or whatever. So, being standards compliant heavily relies on what you call "standard".

[Graf Zahl]

That's not the kind of errors I get.

The worst one is that it complains about the function pointer definitions for CVARs about incompatible parameter lists. Most of the errors look like dependencies on old compiler behavior, not some inadvertent Unix-isms.

In the end it's nearly typical code that gets created if the developers use precisely one compiler and never test it with anything else.

As someone who needs to write cross-platform code at work the traps this ran into are just inexplicable. There days it rarely happens to me that some code only compiles on one system but not the other.

[LexiMax]

Ladna said:

Visual C is a pretty shitty C compiler. Unless you're using the latest dev releases, it doesn't even support C99, which is 16 years old.

Unless something changed super-recently, it still doesn't support C99 features that didn't make it over to C++, just C99 libraries.

[Ladna]

I *think* something did change super recently:

http://blogs.msdn.com/b/vcblog/archive/2014/06/18/crt-features-fixes-and-breaking-changes-in-visual-studio-14-ctp1.aspx

There are still some stupid problems, but the biggest ones (no snprintf/vsnprintf) are fixed.

And yeah to fabian's point, the C standard library doesn't cover a lot. As soon as you venture into POSIX, you're basically boned. People hate GLib, but really, almost everyone should be using it. I could argue for breaking it up (there's no real reason your data structures should be in the same library as your threading, file system abstractions, and Unicode handling...), but whatever.

[wesleyjohnson]

Have been working on all aspects of the Makefile, install, and DoomLegacy environment.

Every single aspect of DOS/Windows (DOS5, FreeDOS, DosBox, Win98, and WinXP to be exact), of writing BATCH files, which commands work for install, and compiling, has been a continuous day by day hell of incompatibilities.
DosBox does not seem to be able to run most batch file commands.
My FreeDOS is crippled since I installed a DVD drive on that machine.
Was able to test a batch file on a WinXP, but that is all (no compile, no DoomLegacy debugging).

Currently SDL compiles using MinGW on my Win98 system produces bad binaries. I upgraded SDL on the Win98 system and it compiles bad now. Been trying every variation of SDL libraries and location to diagnose the problem.

It also does it for older versions of DoomLegacy source that is still
on that machine, so it must be the SDL installation. Must be one of those Windows DLL Hell problems.

Have not figured out the libraries needed for linking.
It seems to REQUIRE Ar-format static libraries for MinGW to link (SDLMain.a). Then there are the runtime SDL.dll Windows library in a separate download.
No instructions so all I can do is guess and experiment.
I expect that MinGW is trying to be unix compiler using Ar stuck into a Windows machine, but it needs to produce code for running on Windows using Windows SDL.dll.

I finally got rid of the strange colors in the palette (reinstalled SDL lib). Still have a problem where cannot exit the program, it hangs at that point.

Going to try some MSYS, to see if that can help with the SDL install
on the Win98.

I only read this thread to see if there is any information that could be of use. The demands that I become a Win7 programmer will be ignored. I skip over any post that even touches that issue.

[Edward850]

wesleyjohnson said:

The demands that I become a Win7 programmer will be ignored. I skip over any post that even touches that issue.

You don't understand Windows at all, do you?

wesleyjohnson said:

so it must be the SDL installation. Must be one of those Windows DLL Hell problems.

Or anything anybody has been saying in this thread.

[<inactive>Player Lin]

Edward850 said:

You don't understand Windows at all, do you?

Totally lost hope about we'll have a proper Windows version of DooM Legacy. :(

[Graf Zahl]

wesleyjohnson said:

It also does it for older versions of DoomLegacy source that is still
on that machine, so it must be the SDL installation. Must be one of those Windows DLL Hell problems.

Must be from stabbing yourself in the back by NOT READING what other people told you and stubbornly instisting of doing something stupid (like trying to *INSTALL* SDL), huh?

Why do you even try to compile it? It should be fully sufficient to use the prebuild DLL and import library?
I don't use MinGW but this download seems to be all you need (provided that you do not try to shoot yourself in the foot by trying to INSTALL SDL...)

wesleyjohnson said:

Going to try some MSYS, to see if that can help with the SDL install

Again: You do not INSTALL SDL so this problem is entrirely of your own doing!

wesleyjohnson said:

I only read this thread to see if there is any information that could be of use. The demands that I become a Win7 programmer will be ignored. I skip over any post that even touches that issue.

We all figured that there's no hope to be found here.
Legacy has been the laughingstock of source ports for 15 years, constantly being sabotaged by incompetent devs who where unable to get their priorities straight.
But you certainly take the cake here. Your predecessors were simply mediocre developers incapable of staightening out their project - but a dev who seems to be unwilling to create something usable - that's a first.

As for 'usable' information - there's more than enough here - you just tend to ignore it and just focus on the UNUSABLE, thus worsening your situation ever more.

playerlin:

Totally lost hope about we'll have a proper Windows version of DooM Legacy. :(

Fully agreed.

[Sandstormer]

playerlin said:

Totally lost hope about we'll have a proper Windows version of DooM Legacy. :(

ReMood seems to be the closest that we'll get.

[Ladna]

I hate to keep this thread going... but evidently not enough.

It's pretty hilarious how rustled Graf Zahl is getting about having to drag/drop 8 files from 2 folders into 1. While it is silly and 100% unnecessary, it's also really simple to do. And really, who gives a shit anyway.

What bothers me is you're making this out to be something that's wildly difficult to do. You don't need to write any BATCH files. I have no idea why the fuck you would load up DosBox. I have no idea why you would try and load up FreeDOS. What is the point of any of that?

Don't ever load up Windows. Install MinGW-w64 on your Linux machine and cross-compile Windows binaries. It's GCC, so you won't have any (severe) problems. If you really give a fuck, you can statically link SDL and SDL_mixer. If you're confused about any of that, have a look at the D2K or Eternity Engine client-server branch repositories on GitHub. It's all there.

I'm cross-compiling D2K binaries for Windows on Arch Linux as we speak. It's beyond me why any serious Linux dev would have even the slightest problem with this (unless, like D2K, you're using GObject Introspection... then whoa I'll buy you a drink and cry together with you).

Goddamn. This is almost as bad as Maes trying to defend CVS. Spend like 30 minutes googling FFS. Think of Graf Zahl's health.

[VGA]

Ladna said:

It's pretty hilarious how rustled Graf Zahl is getting about having to drag/drop 8 files from 2 folders into 1. While it is silly and 100% unnecessary, it's also really simple to do.

Well you answered your own question, it's stupid and unnecessary. Some users *will* get stumped right there. And why are you singling out GZ, other people are annoyed, I as well.

And really, who gives a shit anyway.

... the users, supposedly.

[Ladna]

It's annoying, and if people are annoyed they'll say so. But I can point at a very slight annoyance and say it's very slight. And I can ridicule people who blow it out of proportion. Everyone can use some ridicule once in a while, including me.

I'm singling out Graf Zahl because, while others have expressed annoyance, he's like 2 seconds from exploding. It's funny and I said so.

Honestly I just think it's crazy that there's 4 pages (mostly) dedicated to freaking out about copying 8 files. I mean wow.

[jmickle66666666]

it's mainly frustration at wesleyjohnson's seeming inability to read

[VGA]

Ladna said:

Honestly I just think it's crazy that there's 4 pages (mostly) dedicated to freaking out about copying 8 files. I mean wow.

That's a testament to wesley's inability to untie the knot of false assumptions about how SDL and Windows work. Also he is an anti-Windows jihadist apparently :-D

No hard feelings of course, he is a fellow doomer after all, I hope he doesn't regards these opinions as personal attacks. It's just that if you're distributing problematic and unworkable binaries for the most popular OS, you should test them a little. On a VM or some box with Windows 7, which is the golden standard now. That doesn't make you a Win7 programmer.

[chungy]

Honestly, Wesley's best course of action at this point is to just discontinue providing Windows binaries. He's made it abundantly clear that he has no intention of making usable ones. (Or as a compromise, a strong disclaimer that they won't work on anything except Windows 9x.)

[Doomkid]

Sandstormer said:

ReMood seems to be the closest that we'll get.

Legacy 1.42 is more stable, unless GhostlyDeath has continued ReMood development in the last few years and I haven't noticed.. If he has, that would be swell.

I too was looking forward to a stable and improved Legacy for Win7 and up, namely due to that fact that I play splitscreen from time to time when friends come around. There are a few simple tricks to get 1.42 working great, and sometimes it works fine right out of the box. I'm very greatful for compatibility mode!

[ReFracture]

Doomkid said:

I too was looking forward to a stable and improved Legacy for Win7 and up, namely due to that fact that I play splitscreen from time to time when friends come around

I played so much Legacy split screen.. memories. It even supported it online.

Played with my friend locally using splitscreen online with other people on Doom Connector. It was the only game in town for accomplishing that.

[Graf Zahl]

Ladna said:

Honestly I just think it's crazy that there's 4 pages (mostly) dedicated to freaking out about copying 8 files. I mean wow.

No, there's 8 pages, plus an 11 month history of a developer who not only refuses to listen to advice from people who should know better but also seems to be hell-bent on NOT testing his product on the system it'll be most used on.

For the record, the current Legacy version not only needs some files to be copied (which will indeed be too much to ask for of an inexperienced user who would expect to copy the product to their HD and be able to start it out of the box.)
No, it's far worse. Due to only being tested on the very much obsolete Windows 98 the code contains things that just do not work right anymore on modern systems. For example, it doesn't even start the game on my system, giving NO ERROR MESSAGE on the screen, the only info I get is some cryptic and mostly useless message in stderr.txt that there was a problem initializing the video.

And to top it off, the user is greeted with a fucking ugly start screen where some basic things can be set. Aside from being a visual mess the error messages one gets when improperly setting things up can be more confusing that the screen itself.

And then have a developer who shows a complete unwillingness to listen to the (inevitably) negative feedback and acknowledge the problems and instead continues to babble about 'installing' SDL or some nonsense of not willing to even TEST his product on the most used operating system and you got a major problem.

Do you really expect that I can respect such an attitude?
Sorry, but it clearly takes another hardcore Linux zealot to see some sense in there...


Re. Remood:

The last time I checked it out, it at least started up, unlike the latest Legacy. But AFAIK it has removed OpenGL support, mutilated the main menu and in general was pretty much unstable and prone to random crashes. It was certainly not a good experience.

[Sandstormer]

Doomkid said:

Legacy 1.42 is more stable, unless GhostlyDeath has continued ReMood development in the last few years and I haven't noticed.. If he has, that would be swell.

1.42 doesn't work on my current system. Every time that I try to launch it on an older system, it keeps telling me that I'm missing .DLL files and I don't think that it is worth the hassle to hunt down .DLL files when I can use other sourceports that actually include the necessary .DLL Files in the download.

I'm not sure what ReMood's story is these days. I only mentioned it because it at least starts up properly. It's buggy, the menu system is a royal clusterfuck, and it doesn't even have an autorun CVAR. Lots of work needs to be done on it, but at least it is playable. Not very pleasant, but playable. It would be nice if Wesly updated Legacy for Windows, but I don't see that happening despite the willingness of the other sourceport authors to offer a helping hand or three.

[Jon]

chungy said:

Honestly, Wesley's best course of action at this point is to just discontinue providing Windows binaries. He's made it abundantly clear that he has no intention of making usable ones. (Or as a compromise, a strong disclaimer that they won't work on anything except Windows 9x.)

Yes this is exactly what he should do. Anyone who wants a working Windows build should roll their sleeves up to prepare and test them rather than whining. I guess when he decided to provide win32 builds in any form, he underestimated just how entitled the masses are.

[chungy]

I think Windows users are justifiably entitled to expect a Windows program to behave by the conventions of their platform. Or to expect that the developer doesn't recommend insane and dangerous things like modifying the operating system directories.

Pretend it's Linux, and Wesley is only providing a shell script that requires you to run it under "sudo" to operate. It would do such nice things as install his own pre-compiled libSDL-1.2.so.0 into /lib, overwriting an existing one if it's there, maybe it'll even think that /lib as a symlink (as is normal on Fedora and Arch) is an error and helpfully correct that for you by deleting and doing "mkdir /lib" before copying that file there. Then it'll just install Doom Legacy into $HOME/bin/Legacy and modify your $HOME/.bashrc to include it in your PATH.

That's pretty much the equivalent of what Wesley thinks is appropriate for Windows.

[Graf Zahl]

Jon said:

Yes this is exactly what he should do. Anyone who wants a working Windows build should roll their sleeves up to prepare and test them rather than whining.

I think one should at the very least be entitled to a distribution that actually WORKS! And a developer who performs some checks that it does.

If that can't be done, it's indeed the best course of action to not bother.

But all that doesn't excuse that any feedback gets persistently ignored instead of being worked into the project.

The big problem with Legacy, though, is that the source is barely cross-platform compatible, it's a nightmare to even get working on Windows in a way that allows running some tests with it - making external help quite unlikely to come.

[Sandstormer]

I didn't know that expecting a dev to maintain a properly working and up to date version of their own release for a specified platform actually constituted a form of entitlement. If he doesn't feel like doing that then he should definitely drop all support for Windows and focus exclusively on Linux. Then he doesn't have to worry about any "Whining", and the part of the community that uses Windows will just put Legacy in the rear view mirror and focus on sourceports that are actually viable on their platform of choice. If he is going to make Legacy available on Windows then he should do it properly. otherwise, he should just save himself the trouble and only release on Linux.

[Graf Zahl]

For anyone interested:

I just managed to get it to compile on Visual Studio, but the amount of changes was quite significant. I had to disable some stuff because it required some Unix-y data structures, most importantly this was file searching.

Other problems here:

- the angle_t math makes some bad assumptions about signed/unsigned math and was throwing an endless list of errors. I merely changed these places so that they compiled but they will definitely require some very careful reviewing because lots of it assumes that angle_t is signed even though it is defined as an unsigned type.

- the file hw_sym_sdl.c had some very strange definition problems with OpenGL that I had to hack around to get it to compile.

- include conflicts with winsock and winsock2 which I couldn't track down. I had to remove the winsock2 includes to make it compile, no idea if that affects usability of the network.

- and the biggest show stopper, this was what prevented it from running on my system:

Legacy tries very forcefully to create an 8-bit screen surface. The only problem is: SDL refuses to do this on my system! It's completely impossible to switch to an 8 bit mode. I had to change several places in the startup code that forcefully set the engine to 8 bits. But after finally managing to do this and start with a 32 bit surface, behold: Both software renderer and OpenGL are working! The only thing that doesn't work is music because I skipped SDL Mixer.

The bottom line is: The Windows problem is definitely solvable, it's all merely the result of mucking up the startup code to make it work on some badly configured system. Ugh...

[Sandstormer]

That's awesome, Graf! I hope that this leads to a more stable Windows release at some point, as you've shown that it can definitely be done!

[Graf Zahl]

Have some fun:

http://www62.zippyshare.com/v/QqZh71nr/file.html

This contains both binary and source, plus a Visual Studio 2013 project.

Known issues:

- no music
- some stuff with file paths has been disabled
- no XP support, requires Vista or later.
- source is not yet fully cleaned up.
- project may not compile on other systems without adjusting some paths in the compile configuration.

[Sandstormer]

Wow, this is so cool, Graf! Is there anything that you can't program?

[kb1]

Graf Zahl said:

For anyone interested:

I just managed to get it to compile on Visual Studio...

Yep, good job Graf!

At this stage, I, have some suggestions for wesleyjohnson:

1. Articulate a mission statement, and place it before a "Features" link on your website. Include your high-level philosophies on software design, as well as your low-level requirements, like variable naming conventions, comment writing, indent preferences, etc.

This document is built in preparation and support for the next suggestion:

2. It may be time to look for, request, and recruit a junior partner developer, with Windows tools and OS, who will work with you on cross-platform support.

3. Before doing any more bug fixes, or adding features, get the following completed:

a. Cross-platform support, at least Linux and Windows. SDL will ease this. i_system interface stuff, big endian, support for 64-bit compile and/or explicit int sizes, etc. Render to internal 8-bit, blit to SDL surface (32-bit). 8-bit video cards are gone, unfortunately. Get it to compile for all target architectures.

b. Conceptually separate config stuff from binary install. In other words, the program and support data should be common to all installs, so make that a unit. Then, if you want to have different configs (vanilla deathmatch+software vs. full-blown GL, etc), do that separately, using a simple config swap batch file, or something.

c. Build tested installs for each architecture.

d. Update your web page with links to binary installs for each OS, and add additional source links. Each should have a SMALL readme on how to get started, but that readme should not be mandatory.

That's it. Working in that order will promote a lot of benefits:
* Cross-platform support
* More users = more testing = more bug reports
* More accessible to developers = source forks = backwards-compatible bug fixes
* More hardware support from better SDL implementation
* Install isolated from config = up & running out-of-the-box, known-working setup, with more config flexibility.
* Junior partner cross-OS dev = easy-for-you cross-OS support, 2nd pair of eyes on the source
* Eventually, junior dev might become master dev, and add some nice features.

I wrote those suggestions, because I sincerely wish for the best, for you, and for the port. "Legacy" actually has a huge legacy - no reason that cannot continue. It would be a crying shame for Legacy to lose Windows support - I will not believe it has come to that.
Good luck.