Doom Legacy issues

[VGA]

Well, I try ALL ports to form an opinion, for example I just tried Doom Legacy. After putting the libraries in the same folder as the executable so it doesn't crash, it complained about missing legacy.wad. So I discovered I had to download an extra package which contained it. But then it still complained about missing legacy.wad. It continues with ESC, so I ignored it.

Then it seems it wants me to type in the full path to my IWADS. OK, but the SHIFT keys count as "downwards arrow" so I am unable to do that. So I give up and if someone asks me for my opinion about that port I will say with a clear conscience "on windows at least, it's buggy as hell"

I think that's fair.

EDIT: This test was on my Vista laptop.

[Coraline]

That is not entirely wesley's fault because Doom Legacy is not tested under any modern version of Windows since he does all of his work under Linux.

Conversely, for 3DGE I do all of my testing and developing under Windows, and I have other people to port/test the code to 32/64bit-Linux, etc. But I would not notice a problem under Linux otherwise.

I can safely say I've gotten Doom Legacy to run on a Windows 7 machine with no problems. ^_^

[Edward850]

Chu said:

That is not entirely wesley's fault because Doom Legacy is not tested under any modern version of Windows since he does all of his work under Linux.

One would expect that if you provide a port for a platform, you actually test that platform. Especially if the majority of your userbase is going to be on said platform.

[DaniJ]

VGA said:

I just tried Doom Legacy... ...it seems it wants me to type in the full path to my IWADS. OK, but the SHIFT keys count as "downwards arrow" so I am unable to do that.

...on my Vista laptop.

The Doom Legacy file system is case sensitive nowadays? It didn't used to be that way and on a Windows platform it should be mostly irrelevant even if it is. Did you try it? (disclaimer: I haven't used this port in a very long time)

[Coraline]

Are you starting Legacy with the launcher or just the executable? I haven't used the launcher in YEARS but with the base exe everything works just fine.

[VGA]

There is only one exe that is also a launcher, it doesn't have a gui (no file picker, you got to type in full paths)

[ReFracture]

The launcher is absent with 1.45 it seems.

My problem with Legacy right now is the midis seem to be missing multiple instruments and the SSG reload sound is playing back at the wrong speed.

[wesleyjohnson]

Doom Legacy does not require that wads be in the executable directory, it searches directories as described in the instructions (docs).
It uses the DOOMWADDIR that other ports use.

The binary is now distributed separately from the common, to reduce the redundant work with every release. Many other projects do the same exact thing with their downloads. I think this is explained in multiple place, including a README at the download site.

I test windows code with Win98. I do not know how they could have mangled windows so bad with more recent versions to get the behavior that VGA describes. I expect that he is totally ignoring the docs files.

Doom Legacy will still work with most launchers. Old command switch behaviors have been preserved (as much as possible), but have been enchanced in a few places. It you launch it from a mouse click, it will notice that there are no command line parameters and will bring up a launcher window.

I do not understand the problem some people have with entering file names. I have never used a full path name, ever.
All names are submitted to the OS as relative file names.
What could screw things up is setting up Windows to change to some strange directory during execution. I can do nothing about users setting up strange Windows shortcuts. I cannot warn users of what the problem is because I do not get it on Win98, and the Windows 7/8 users who complain do not diagnose the problem nor discover a solution.

What is notable is that Doom Legacy will totally ignore file names on the command line that are not part of a switch. There will be no error message. It will totally ignore a mangled switch name.
Garbage on the command line will be totally ignored.

Example: -game doom2 -f mywork.wad
This will ignore mywork.wad as the switch -f is not recognized.

Example: -game doom2 -file mywork.wad
This will look for mywork.wad in several places, including DOOMWADDIR, and an OS dependent default directory.

Shift keys as downarrows ??? What did Vista do, change the keyboard code mapping ???

However, I note that Chu seems to have better results than others do, and I wonder what must be different.

Someone has to compile Doom Legacy from source on a recent Windows to see if the executable is significantly different than the version I compiled using MinGW on a Win98 machine. The SDL used for the compile of the precompiled Windows binary, is an older SDL version.
Users can install a newer version of SDL, which may fix problems or give better performance on their OS. This may require compiling from source, because the older version of SDL did not have a working RWOPS sound interface, so a work-around is used in the code (same as prboom).

The code is heavily conditional on Machine and OS, and even SDL version. The precompiled binaries are fine for the users that can use them, but if you cannot, then it will need to be compiled from the source code download.

All sound goes through SDL (if you are using a precompiled binary). Sound problems such as described would have to be problems with SDL.
Doom Legacy uses the SDL that the user has installed, trusting that the user has dealt with OS dependency issues. If the user has not resolved any OS dependency issues, they will still be present. The user may be misled by other projects that supply a SDL library built-in to their project, as that can be executing a different SDL library than Doom Legacy.

I have never figured out the midi music complaints. For a while I had trouble with the built-in MIDI in the boom demo wad, then resolved it as something trivial (which I do not remember, but I think it was the separate OS volume control for MIDI).
I have heard it play that MIDI.

[Graf Zahl]

wesleyjohnson said:

I test windows code with Win98.

In other words: You do not test your code on Windows as it exists today at all!

And that's probably the only reason why your program has problems. A lot has changed in the last 17 years and even though Windows has maintained a remarkable level of backwards compatibility, it's no longer the same.

I just tried to test it myself, trying to act like some average computer user with limited technical knowledge.

- downloaded the Win32 binaries and the common files.
- copied everything as-is to a directory on my HD
- started it (without IWAD present.)

Result: of course it did not work because you still insist on keeping the DLLs in subdirectories, requiring some action on the end user's behalf. I already told you a few months ago that this is stupid and not what Windows users expect. That's Fail #1.

- fortunately I already knew of this issue so obviously I copied the files around, started it again.

Message: 'legacy.wad' not found. Huh??? Legacy.wad was present but the IWAD wasn't (because I already expected what the problem here was, namely an incorrect error message for missing IWADs.) (fail #2)
So I copied Doom2.wad into the directory.

Upon start I got some fucking ugly text menu that was hard to comprehend even for an experienced user like me. So after mucking around with it a bit I eventually hit 'continue' - and the game terminated without any further message. (fail #3)

So to sum this all up:
Your product is a complete and utter mess, it's unusable, its setup process is undecipherable for the average computer user and it doesn't even seem to work.

I always had issues with Legacy but this version takes the cake for the most useless Doom port I ever encountered. You let the user run into so many walls that most of them will certainly delete that POS long before they see the in-game menu for the first time.

Ugh...

EDIT:

Postscript:

I noticed a little file called 'stderr.txt' after writing this response, so I had a look at it:

Draw 8bpp using palette, SDL must convert to 8 bpp video modes
No usable fullscreen video modes.

Which proves my first statement that your tests on Windows 98 are completely and utterly worthless because they do not represent the state of modern Windows even remotely.

I'm sorry but this entire thing is just ridiculously pathetic.

[ReFracture]

Forcibly playing back the SSG's 22050 sampled audio at 11025 is why it sounds wrong, and this isn't really a fault of SDL as pretty much every other SDL engine I've ever used lacks this characteristic, or at the very least if it is an issue with SDL the developers work around it. It's more often the engine forcibly playing back every sound at 11025, even if the sound isn't 11025.

[fabian]

wesleyjohnson said:

[...] it will need to be compiled from the source code download.

OK, so I tried this on a computer on which I regularly build Chocolate Doom/Crispy Doom/Doom Retro and PrBoom+, i.e. it has recent versions of all SDL, GL and whatever headers and libraries installed. The Operating system is a 64-bit Debian GNU/Linux testing/unstable.

I downloaded doomlegacy_1.45_beta1_source.tar.bz2 from the Sourceforge project site and extracted it into a temporary directory. In the source directory there is a README.txt refering me to src/Makefile, nice. So, I do "cd src; make" but it stops with an error message and tells me I have to edit a file called ../make_options and set my "OS selection" before. Really? OK. So, I edit this file and it contains a single non-comment line "MAKE_OPTIONS_PRESENT=1". Yes, seems very important, especially since there is nothing regarding "OS selection" at all in this file. Anyway, let's try again: "make" and it compiles \o/.

After compilation, there is a file "doomlegacy" in the bin subdirectory. All seems fine. Running this file, a window pops up and I am presented with tiny green font on a black screen complaining that legacy.wad is missing. The same is repeated in the terminal. So, I press ESC as suggested and choose "Quit Game" to start my quest for the legacy.wad file.

find -iname "legacy.wad": nothing
grep -ir "legacy.wad": ahh, there is mention in the src/Makefile

So, back there, "cd src; make wad" tells me
"Usage: make wad WAD=/path/to/old/legacy.wad"
What?! So I need the WAD I don't have to build the WAD I don't have?

So, it seems that's it for me. :/

As an aside:
1) There is the "$(error ...)" command in Make syntax for the very reason to abort make with an error message.
2) I couldn't even enter a path name into the green-on-black start screen because I need to type Shift+7 in order to print a slash and, guess what, hitting the Shift key was interpreted as down, so it changed fields unintentionally.

Edit: Never give up.

Remember there was talk about a "common" zip file lately. If I cannot create the legacy.wad file myself, I will have to use the one provided in there. I extract it from the ZIP file and copy it into the bin subdirectory of the source directory, right next to the executable. I run it again and am still presented with the tiny green font on black background complaining "Main WAD file not found". Holy mother, I have all IWAD files known to man in /usr/share/games/doom, which is where all reasonable source ports should look first. The other fun fact is that it still complains about "No legacy.wad file", but this has been reported before.

So, for the sake of it, call "./doomlegacy -iwad /usr/share/games/doom/doom2.wad" and there it is. \o/ The lovely title screen! I select New Game and Single Player and Ultra Violence and... wait. Nothing. The eyes of the skull have stopped blinking but nothing else happens. The game does not start. Is it hung? Did it crash? I hit ESC, the menu pops up, I chose Quit Game. Nothing more, that's all folks, let me out of here.

Edit 2: For some reasons I have downloaded and performed my tests with the beta 1. Repeated the same for the 1.45.2 release, it's all the same, nothing has improved. :(

Edit 3: As another aside, please add some reasonable search paths to your application, not just DOOMWADDIR. This is generally not set on a random computer. Whereas it won't hurt to have a look into /usr/[local/]share/games/doom, which is where IWADs reside on all major distros.

Also, if I run "bin/doomlegacy" from the top-level source directory, it throws a segmentation fault. I have to change into the bin/ subdirectory and run "./doomlegacy". Seriously?

Edit 4:
1) Please declare gamma_lookup in v_video.c and draw_dir_line in m_menu.c as "static inline", else the debug build will fail.
2) The segfault happens, because IdentifyVersion() cannot find the legacy.wad file and thus calls "goto fatal_err;", but the first thing that is called after the "fatal_err" mark is "D_AddFile(legacywad);" which is still pointing to NULL, though. The actual segfault is caused by strlen() being called on this invalid pointer in D_AddFile().

[wesleyjohnson]

It appears to me that the instructions were not read, nor followed. As this seems to be the source of much of the trouble, I (somewhat) have a lack of sympathy. I will try to be understanding if you are having a problem finding, reading, or understanding those instructions.

Are you having problems finding those README, or perhaps just ignoring them because so many other projects don't say anything interesting in their README?

I have not figured out how to make the instructions leap out and force you to read them. Perhaps you can tell me why you are not seeing them.

First, there is a common download that is required. It contains the legacy.wad and all the documentation. More instructions are in there.

If you insist on trying to run Doom Legacy without installing SDL first, as the instructions require, then you will have problems. You can resort to using the OLD SDL provided for the lazy in the subdirectory, but that is the individual users choice.

It already searches in three different directories, including DOOMWADDIR. The directories it searches by default are specified in doomdefs.h and the user can set it to anything they want.
You can also set the DOOMWADDIR in the built-in Launcher.

It searches for legacy.wad in multiple places already.

The built-in Launcher is functional, minimal, and not pretty. It is a bare minimal interface for those who do not have a launcher, or have a startup problem. It does not use anything of the OS, so it is not customized to the Windows look.

Mostly, it seems that you are so Windows-centric, that you expect this to be already defaulted to Windows, and it is not.

Fabian: saw the make_options file, ignored it and did not tell the compile any make options, like that if it is a WIN32 system or that it is a SDL compile (or a Direct-draw compile). (Edit: Ok it is Linux. SDL should be the default, but probably missing some others. You might have actually got something runnable. ).

The 64 bit has been tested, and we think we have found all incompatibilities, but it is not directly tested by me.

The MAKE instructions are in the Makefile. I have forgot how many places it says to edit the make_options file to reflect the chosen options. It seems you expected all the instructions to be copied into the make_options file, but that seems excessive. Is there a place to put the Make instructions that would be read ? Perhaps a separate file "Make_instructions". I will have to think about that, got too many instructions files as it is.

Those chosen make options can be edited into the make_options file, or presented to make on the command line, or edited into the Makefile, as is explained in the first two pages of the Makefile.

There are also compile options in doomdefs.h.
I think that is mentioned in the instructions too.

You do not make legacy.wad, that is for the developers to make (because you might not have all the legacy.wad sources). There are other developer commands in the makefile too. I do not have a good idea how to fend inquisitive users off from finding them.


I do not know what that SHIFT key problem could be. Is it that Debian Linux is that much different than Slackware Linux, or do you have some strange keyboard mapping in place. That is one that I would like to find out about.
I run Slackware, Linux 2.6, and my Shift keys are perfectly fine, using the usual SDL codings.
All keyboard input comes through SDL, so I must ask, What version of SDL do you have ??

What specific $(error ) would have helped?
I will look into the segfault you experienced.
Thank you for that information.
I thought I had found every segfault possible.

[Graf Zahl]

Why are you persistently ignoring any negative feedback concerning the setup of your port?

It's a mess to get running, and as my system shows, it doesn't even start at all!

You show some blatant dismissal of people who have problems with it.

The inevitable result will be that people WILL NOT USE YOUR PORT! It's as simple as that. Most people I know do not take lightly software that makes it a hassle to set up. People expect to download either an installer that does all the work or in case of a portable app a package that can be unzipped and started out of the box.

Instead you provide a mess that requires active intervention by the end user to get organized properly, it doesn't output clear error messages when something is wrong (a console message to stderr is NOT sufficient on most OSs!) and the message I got isn't even clear what precisely the problem is!
And the first screen the user encounters is a major turn-off, it looks like it was cheaply slapped together to avoid programming something proper.

Legacy has a 10+ year history of messy development and unstable releases so it will have a hard time anyway to regain the users' trust any yet you do anything imaginable to reinforce the belief that Legacy is shit.


What you really should do is to carefully read and understand the problems users have with your port and then act on these particular issues. In particular you really should do some serious testing on modern Windows. It's quite clear that the hardware setup the engine uses is obsolete on these systems and causes problems with certain drivers.
You should also ensure that users can get Legacy running without reading the README file. Most people tend to ignore these, or only start reading them when problems surface. But that often means it's too late because the first impression was a bad one.
Your setup is a mess, there's no point debating this, either fix it or be prepared for more complaints in the future.

[Coraline]

In regards to my earlier post, I was using version 1.42. 1.45 does not start on my machine and I don't have time to try and jump through hoops.

I had offered to help compile it for modern Windows but it is too complicated to set up...I have been pampered by Andrews excellent XMING setup for 3DGE...but that is more my fault. I even offered to send him a simple Vista laptop for free, the offer is still on the table.. :)

[dew]

wesleyjohnson said in response to Fabian:
Mostly, it seems that you are so Windows-centric, that you expect this to be already defaulted to Windows, and it is not.

I do not know if that SHIFT key problem is due to Windows changing its keyboard codes from what I got (MINGW), or if it is because you are compiling Linux code on Windows because you did not set the make options to WIN32. That is one that I would like to find out about.

Saved for great justice.

[wesleyjohnson]

Thank you fabian for the information. I have found and am correcting the following. You will have to wait a few days for these fixes to show up in the SVN. Because of that I am providing more detail than I would usually.

1. Segfault on legacy.wad not found.
This is caused by the next to last patch before releasing 1.45.2, trying to fix misleading error messages when the user messed up the -game switch. Am adding checks for NULL at fatal_err and in D_AddFile.

2. SHIFT key does downarrow.
Actually the SHIFT key is leaking into code for processing keyboard shortcuts. I had commented out the code that would have prevented this.

In m_menu.c
#if 0
if( !isalpha(ch)) )
return true
#endif

Got to listen more to those nagging doubts.
Enabling the isalpha test again would probably work.
Substituting a "if( ch == 0 ) return true" fixes the problem too.

3. make_options empty
Copy commented out examples into the default make_options.
I really do not like this because it makes it messy and although it looks like something, none of it would be activated. It confuses the fact that the make_options is empty and makes it hard read. So, it also needs instructions that it will not work unless some of the options are un-commented.

[fabian]

wesleyjohnson said:

I have not figured out how to make the instructions leap out and force you to read them. Perhaps you can tell me why you are not seeing them.

The sheer fact that you are forced to read instructions to get the port up and running in the first place is a failure in itself.

First, there is a common download that is required. It contains the legacy.wad and all the documentation. More instructions are in there.

Why don't you just put it into the regular release tarball?

Fabian: saw the make_options file, ignored it and did not tell the compile any make options,

Why should I? You know what, for Chocolate Doom I run "./configure && make" and be done with it. Same for PrBoom+, they just work.

The MAKE instructions are in the Makefile. I have forgot how many places it says to edit the make_options file to reflect the chosen options.

I have skimmed through the first one or two pages of the Makefile, which is where I found the DEBUG option. But I cannot be bothered to read further through the file just to make a simple out-of-the-box build work.

Two more thoughts:
1) By just reading through the Makefile, you still have no idea what you have to put into the make_options file to get the build working. You simply don't know what you are expected to put there or what is even necessary to get it to run.
2) In fact, the compilation did work! It is just that the executable that it created failed at every attempt to start an actual game. And there is no warning or error message, not from the build system nor from the executable, that something crucial might have gone wrong.

It seems you expected all the instructions to be copied into the make_options file, but that seems excessive.

Not all, but the most crucial ones. This is the least that one could expect.

You do not make legacy.wad, that is for the developers to make (because you might not have all the legacy.wad sources).

Please have a look at how conveniently prboom-plus rebuilds its own resources WAD file as a step of the build process.

I do not know what that SHIFT key problem could be. Is it that Debian Linux is that much different than Slackware Linux, or do you have some strange keyboard mapping in place.

No, but it's interesting that your instinctive reaction towards this issue (that has been reported by two separate users on two absolutely different systems) is that there must be something strange with the users systems or their key mappings...

What specific $(error ) would have helped?

What I meant is that Make has a dedicated command for exiting with a defined error message. There is no reason to call a spurious "stop" command knowing that it doesn't exist and will thus cause Make to abort. The negative side effect is that Make's own error message for the unknown command gets in the way of the message you wanted to show in the first palce.

I thought I had found every segfault possible.

Every. Segfault. Possible. ;)



Edit: Adding answers to your latter reply.

wesleyjohnson said:

Thank you fabian for the information. I have found and am correcting the following. You will have to wait a few days for these fixes to show up in the SVN. Because of that I am providing more detail than I would usually.

Sorry, but I don't think I will give this another try. Please don't get me wrong, I am not using this as an excuse to finally hammer on Legacy. Actually, I was trying your proposed method of building Legacy from source to prove your point. But what I have seen so far is enough for me. :(

1. Segfault on legacy.wad not found.
This is caused by the next to last patch before releasing 1.45.2, trying to fix misleading error messages when the user messed up the -game switch. Am adding checks for NULL at fatal_err and in D_AddFile.

So, you are adding band-aid, whereas the underlying error might as well hide in the logic of the surrounding code and the plenty of goto calls there.

2. SHIFT key does downarrow.
Actually the SHIFT key is leaking into code for processing keyboard shortcuts. I had commented out the code that would have prevented this.

I am glad that you found the cause for this in your own code. ;)

3. make_options empty
Copy commented out examples into the default make_options.
I really do not like this because it makes it messy and although it looks like something, none of it would be activated. It confuses the fact that the make_options is empty and makes it hard read. So, it also needs instructions that it will not work unless some of the options are un-commented.

I don't think this will make the make_options file messy and confusing. Quite the contrary, it will finally give that file some meaning! And even if your "instructions" were as short as "uncomment the following line to enable SDL_mixer support" this would be a very welcome step.

Edit 2: Sorry for all the Edits. ;) On the Sourceforge project page there is an SVN repository with two branches, a CVS repository with even more branches and a GIT repository. Which one is the actual active development tree? Which one is used for releases?

[Never_Again]

wesleyjohnson said:

I have not figured out how to make the instructions leap out and force you to read them. Perhaps you can tell me why you are not seeing them.

This is not going anywhere until you figure out that unless you change your attitude drastically (fat chance) or delegate PR responsibilities your port is doomed to obscurity. It is quite obvious that you cannot handle user input and that "user friendliness" is an alien concept to you. Why not concentrate on what you do best - coding - and let someone else deal with ppl?

[wesleyjohnson]

I have made some changes to some information in the dummy make_options
file. It will not be extensive because of the difficulty of writing (echo) from within a makefile, and having to support both DOS file and Linux file while doing that.

For people who do not want to read instructions (shake the box and it works) I don't think it would matter where the instructions were.

Using ./configure is an idea, and I have considered that. I am tempted to try that, and many other changes. The Windows install will require something else.

I install software, and some of the ./configure work, and some do not. I have to find code bugs in about half of the software I install. Most of those I never get to work (ZDoom and some other doom products included). Shake-the-box windows installs are not perfect either, just much much more difficult to fix.
That is why I use Slackware and not Debian (packaged installs).

I do not like installs that insist on configuring the user machine as if there was only one way to do it. I expect that there is a wide variation in how Doom games are installed, sometimes in a user directory, sometimes to play one wad, sometimes with a collection of PWAD, sometimes with other engines present. I let the user decide those things, which also means the user has to make the choice and read the instructions. Sorry.

I do distrust Windows. I abandoned it for Linux for good reason.
So when I hear of a Windows user having a strange problem that I have never seen, I do first suspect the Windows environment and the reported problems with Windows 7/8. Improving that will require more useful bug reports than I usually get. I have a few users who report what they were doing, and exactly what they were doing, so I can recreate it. Many other bug reports are not so helpful. But some of these problems will require debugging on Windows 7/8.

I thank you, fabian, mostly because you described the problem in a way that I could use to investigate it. Mostly, that it showed up in a Linux build, and what you were doing.

I already checked for a better than band-aid fix for the segfault, and there is no better solution. That is a catch for multiple error detections and it must handle them all. That function has too many GOTO, but the alternatives were worse and amounted to code churning for the purpose of aesthetics. I don't mind so much doing that once, and may reconsider, but hesitate after 3 or more visits without a superior solution.

Where this topic leads to any bug discoveries or fixes to Windows problems, it may be useful. Otherwise, I may have it closed due to the venting and abuse which do not help one bit.

[Graf Zahl]

wesleyjohnson said:

I do distrust Windows. I abandoned it for Linux for good reason.
So when I hear of a Windows user having a strange problem that I have never seen, I do first suspect the Windows environment and the reported problems with Windows 7/8

Of course you do. It's just the wrong approach. You cannot assume that stuff that works fine on Windows 98 will still work fine on Windows 7 or 8, especially if you use deprecated old APIs like DirectDraw (even indirectly through SDL) because some required driver support has been removed in the mean time. Unfortunately modern graphics drivers have rather bad support for obsolete features so you may run into problems here.

I still can't say what precisely fails on my system, I already posted everything I got. Other programs that apparently use a DirectDraw 8bpp fullscreen mode seem to work, although I have to say that the only one still available to me is the original WinQuake from 1997, but that one runs without issues. I also had no issues with any other Doom port, but cannot say which one actually uses 8bpp and which ones fall back to 32bpp if 8bpp is not available.

I might have run some tests myself but since Legacy requires a toolchain that's completely alien for me I passed.

[kb1]

You know, in the parent thread, I complained a bit about some of the "port hate", as being unreasonable and uncalled for. I was defending the developers for their hard work, modifying a rather complex game, and offering it free-of-charge to all.

I was defending developers, including you, wesleyjohnson. My point was relevant, and I believe it still is. But, wesley, I have to say, your defense of your compile/setup methods is also unreasonable, and people should be bitching about it.

No, it is NOT reasonable for people to have to read the instructions to get up and running. They may have to respond to "IWAD not found - please place your IWADs into folder X, or change setting Y to point to your IWADs...blah blah". That is ok, and expected. Or, even simply "IWAD not found", and a *small* readme file with a section "Locating your IWADs". Nothing wrong there. Actually, for compatibility's sake, Doom ports should all find WADs and IWADS in a similar manner, so I don't have to copy WADs around. It's just common sense.

You state: "I have to find code bugs in about half of the software I install."

So what? That software sucks. Does that make it ok?

You say that there's a wide variation in how users install Doom, but, there really isn't. The only variation is where I store my WADs. Other than that, I want the port to run. Period. I dislike installers as well. Thank goodness that Doom doesn't need them. Make a directory, unZip, and Run.

When you live and breathe a certain project, it's easy to tell what's keeping your project from running, but that knowledge is unique to you. There's no reason for your end-users to have to know any of that.

What on earth is wrong with an easy install? When you borrow a friend's car to go to the store, you don't read the owner's manual, do you?

There's something very dark surrounding your attitude towards your users. I know it's free, but you're offering a product. Offer it properly, in working condition. Anything else is impolite.

[Edward850]

Graf Zahl said:

Of course you do. It's just the wrong approach. You cannot assume that stuff that works fine on Windows 98 will still work fine on Windows 7 or 8

While true, the ironic thing is that Windows keyboard codes haven't actually changed at all. If they did, a lot more software would be exhibiting some rather critical issues. As it is, I can still run even ZDoom 1.12, let alone a bunch more obscure Windows 95 games.

He's very quick to blame the majority operating system for things it has never actually done.

[Blzut3]

wesleyjohnson said:

ZDoom and some other doom products included

You keep pointing out that you were not able to install ZDoom and yet somehow people with 0 programming experience manage to do it just fine using the directions posted on the wiki. If you can't get ZDoom to work, how do you expect others to follow your considerably more complex installation instructions that even programmers have difficulty following?

Being flexible and supporting many possible environments is fine, but reasonable defaults should be provided out of the box. Only if the defaults don't work should I ever need to look at the compile or running instructions. This is just good UX design.

On that note, I highly recommend skipping autoconf and using CMake. That way all compile options can be provided in a nice format to whatever configuration tool (ccmake, cmake-gui) the user may be using. I honestly find the UX of configure barely better than a custom Makefile since I lost count of the number of times I've had to find hidden configuration options.

Not trusting Windows is not a good excuse for not having a more modern Windows install. What makes Windows 98 so special? You were apparently offered a free Vista laptop. I don't personally use Windows or OS X often, but I have both, in modern incarnations, available at my disposal. Windows 9x and NT are indeed very different. It is trivial to write code that will work in one but not the other even if a vast majority of the API is compatible.

[Edward850]

Blzut3 said:

You keep pointing out that you were not able to install ZDoom and yet somehow people with 0 programming experience manage to do it just fine using the directions posted on the wiki.

I'd argue the point is that you don't even need to follow instructions for the standard Doom ports. Chocolate, PRBoom+, Eternity and ZDoom/derived ports can all run out of the box with no documentation at all, even going as far as auto detecting Steam installs for Doom IWADs. You can just extract the executable into a folder and run. No fuss no muss.

This may just be nit-picking though. I don't really see anybody reading the wiki pages first, anyway. Although that might just be the case in point for wesleyjohnson's ideas of forcing an end user the read a README. Nobody actually reads ZDoom's wiki first, either, and yet they don't have problems at all.

The only notable exception appears to be Doomsday, which actually has an installer and is only properly useable through the launcher. And it has been repeatedly stated that this isn't favourable.

[Blzut3]

I was referring to compiling. Specifically on Linux, but there are a lot of people that compile ZDoom on Windows as well. Of course once all deps are set up the compile instructions for ZDoom typically reduce down to "cmake .. && make".

[ReFracture]

As somebody with zero programming experience I echo that claim. Following instructions on the wikis was all I needed to compile several source ports on Linux without so much as a hiccup.

[fabian]

wesleyjohnson said:

That function has too many GOTO, but the alternatives were worse and amounted to code churning for the purpose of aesthetics.

Wesley, is this one of the object code size optimizations you mentioned earlier in this other thread?
http://www.doomworld.com/vb/post/1347714

[Graf Zahl]

Blzut3 said:

On that note, I highly recommend skipping autoconf and using CMake. That way all compile options can be provided in a nice format to whatever configuration tool (ccmake, cmake-gui) the user may be using. I honestly find the UX of configure barely better than a custom Makefile since I lost count of the number of times I've had to find hidden configuration options.

... not to mention that CMake can also create Visual Studio projects so it'll vastly increase the group of people capable of compiling the source which will mean a lot more feedback for finding and fixing issues.

I don't think it's a coincidence that projects that are hard to get set up on Windows suffer most from technical issues, they effectively shut out most of those who can potentially help.

[chungy]

Blzut3 said:

You keep pointing out that you were not able to install ZDoom and yet somehow people with 0 programming experience manage to do it just fine using the directions posted on the wiki. If you can't get ZDoom to work, how do you expect others to follow your considerably more complex installation instructions that even programmers have difficulty following?

To be fair, ZDoom is pretty difficult, to the point of being nigh-impossible, to install on Linux.

[DaniJ]

Edward850 said:

Doomsday ...is only properly useable through the launcher. And it has been repeatedly stated that this isn't favourable.

Thats not true, Doomsday can be used in exactly the same way as any other port, the launcher is not required and I personally stopped using it several years ago. Its even an optional install component in the installer.

The one difference is the lack of drag and drop support for add-ons.