Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
Dee

curious [about purist ports]

Recommended Posts

I always thought the idea of source ports was to improve the original game and add extra features and such, but with ports such as zdoom and gzdoom, why does the community continue to support projects such as strawberry doom and chocolate doom, etc. when zdoom already has all those features and then some? I mean honestly, very few people are going to play with those ports, when we have something better to run. And while everyone can appreciate the effort made on behalf of the doom community, I personally think that the effort should be spent on making a better product, and not something that has already been done better. really and truly though, I dont think it should go much further than zdoom anyways, because once you start getting technical and adding features such as 3d objects, floors, dynamic lights, etc. its practically not doom anymore, you might as well just pick up a modern fps if you want that. that being said, what does everyone else think?

Share this post


Link to post

I love Chocolate Doom, etc. and they all definitely need to be supported into the future. Every player has different tastes, and also port developers want to make a port that they themselves want to play. The community can't just stop playing a port and expect the developer to stop working on it.

ZDoom also can't correctly play "hacky" vanilla projects like Batman Doom and others, while Chocolate Doom can. And ZDoom/GZDoom also don't have some graphical features of Doomsday, or the demo compatibility of Chocolate and Prboom, or the portal possibilities of Eternity.

Share this post


Link to post

Dee said:
why does the community continue to support projects such as strawberry doom and chocolate doom, etc. when zdoom already has all those features and then some?

Because it doesn't have the features (strict Doom compatibility) and because it does have others that aren't wanted (a barrage of features, options and changes).

I mean honestly, very few people are going to play with those ports, when we have something better to run.

There's is a good number of people that use them to a smaller or greater degree for different things, and many of those use them quite intensively (which is quality, not quantity).

And while everyone can appreciate the effort made on behalf of the doom community, I personally think that the effort should be spent on making a better product, and not something that has already been done better.

So do others, and thus they do things you don't like, because they like them. Likewise, to them, doing what you prefer may be a waste of time and effort.

really and truly though, I dont think it should go much further than zdoom anyways, because once you start getting technical and adding features such as 3d objects, floors, dynamic lights, etc. its practically not doom anymore, you might as well just pick up a modern fps if you want that.

Some people like "true 3D" (no such thing in a monitor, although they certainly are "more 3D") and models, high resolution graphics or GL lighting, and want these in DOOM, thinking they're a betterment.

that being said, what does everyone else think?

The best thing here is that there is room for many different tastes and ideas. Most of the people in the community that put effort into the game understand that it's kept alive by their activity and thus don't need "other people" to think like them. They are the community. The people who need the community at large to think like them to feel secure are just losers.

Share this post


Link to post
phi108 said:

ZDoom also can't correctly play "hacky" vanilla projects like Batman Doom and others, while Chocolate Doom can.


that is something I did not know which is a good point and makes a lot of sense, and im certainly not saying we should abandon these projects, like I said, we can all appreciate the effort made in the community, and we need more like it. me personally, ive played about every port available (to my knowledge) and I just stuck with zdoom in the end. which is why I brought it up, but everyone has different tastes.

Share this post


Link to post

OP is too stupid for words. Thankfully, myk always has a sizable pile of words no matter the stupid. And I guess I do too, here are my personal reasons for using Chocolate Doom (and my own personal variants), and occasionally using ports like PrBoom(+):

- First off not everyone here uses Windows all the time, or at all. While ZDoom "works" in Linux, sometimes, depending on the svn revision number, it's not terribly reliable and it's definitely a chore to use. And god forbid someone use any other operating system and try to run ZDoom. The same goes for GZDoom, Skulltag (to a degree), and unfortunately even Eternity. Chocolate Doom runs on hardware and software that these ports wouldn't even dream about, and Pr(+) is not that far behind.

- As myk said, ZDoom doesn't have all the features of vanilla. It's not just Doom with bits tacked on, it's pretty much an entirely new engine that happens to be more-or-less Doom compatible. Really high levels of compatibility don't exist in ZDoom. Also: demos. ZDoom ports don't even try to play demos, and while some other more advanced ports have some degree of demo compatibility, nothing works like the more "purist" ports for demos.

- From a coding perspective, Chocolate Doom is clean, tight code. Most of the bugs in the code are intentional, the code is well documented, and it's easy to understand. With many different port authors having tacked on many different features over time, a lot of advanced ports have code that looks like spaghetti. Even semi-purist ports like Pr(+) suffer from this.

Anyway, it is really all about taste, and I can guarantee you that there are plenty of people that have tastes that are different from yours. Thats why other ports exist. I find it amazing that these threads crop up from time to time about "why purist derp?" but you'll notice no "purist" ever posts a "why zdoom derp?" thread.

Share this post


Link to post
John Smith said:

First off not everyone here uses Windows all the time, or at all. While ZDoom "works" in Linux, sometimes, depending on the svn revision number, it's not terribly reliable and it's definitely a chore to use. And god forbid someone use any other operating system and try to run ZDoom. The same goes for GZDoom, Skulltag (to a degree), and unfortunately even Eternity. Chocolate Doom runs on hardware and software that these ports wouldn't even dream about, and Pr(+) is not that far behind.

Rather odd since one of the developers for ZDoom and Skulltag doesn't even have a Windows install. That said fmodex does limit the number of platforms that ZDoom can run on. (For the record Windows x86 (and to and extent Windows x86-64), Linux x86, Linux x86-64, Mac OS X x86, and Mac OS X PowerPC are all supported platforms.)

Share this post


Link to post

I tried to install GZDoom last week but gave up as soon as I had to face the "hunt down the right version of FMOD to use" issue that's totally not mentioned in its documentation.

Chocolate Doom and PrBoom avoid that whole FMOD mess with SDL :-)

Share this post


Link to post
chungy said:

I tried to install GZDoom last week but gave up as soon as I had to face the "hunt down the right version of FMOD to use" issue that's totally not mentioned in its documentation.

Granted it's a little hard to find, but it's right here.

Edit: Not to mention all the "how to compile" pages on the wiki point to a specific version of fmodex.

Share this post


Link to post
chungy said:

Chocolate Doom and PrBoom avoid that whole FMOD mess with SDL :-)



It goes both ways:
ZDoom avoids the mess of SDL sound by using FMod. :P

SDL sound is a joke. No features whatsoever.
And SDL_Mixer is too broken to be considered a serious choice (and yet it seems the favorite choice of GPL software but that's most likely more a lack of options than a sign that it has any value.)

As for 'hunting down the correct version': Sorry to be harsh, but if that's a problem for you you are not qualified to use the internet. Even a half-blind idiot should be able to find the link on the FMod download page leading to it.

Share this post


Link to post

You know Graf it does go both ways. Both FmodEx and SDL_mixer have a fair share of issues. The issues for FmodEx though are much greater on Linux (or just non-Windows platforms) however. Seriously, if a hardcore Linux user is commenting that finding a specific version of a library is difficult, then it's fucking difficult. And frankly there isn't any good reason why the library cant be included in the GZDoom distribution, or a link provided in the documentation. It's inexcusable and it's flat out poor project management.

Share this post


Link to post

Chocolate Doom is the best source port for playing Doom. Because fraggle is so awesome, he has an open invitation for a free pint of beer if he comes to Portland.

Share this post


Link to post
John Smith said:

The issues for FmodEx though are much greater on Linux (or just non-Windows platforms) however.


I can't tell much about that but it's easy to count the users that complain at the fingers of one hand. From what I get most don't seem to have problems with getting ZDoom to run with FMod.

John Smith said:

Seriously, if a hardcore Linux user is commenting that finding a specific version of a library is difficult, then it's fucking difficult.



Uh, what?

Yes, it's difficult if 'sudo apt-get' and similar commands is as far as you are willing to think because you are too 'hardcore'... :D
However, if you are not, a quick look at the source would tell you that you'll need FMod 4.28 to build ZDoom. (The version listed on the 'compiling ZDoom on Linux' page in thr Wiki is admittedly older but should also work fine so please don't tell me this information is hard to get by.)

Now:

  • Go to 'www.fmod.org'.
  • Click on 'Downloads'. The page will tell you that 4.32 is the latest version which is not compatible with ZDoom. Big deal. Below the list of downloads you'll find a link to older versions. Click on it.
  • You will find a list box with versions to download. Get the latest 4.28, or whatever you like, install it and you are done.
Now what's so hard about it? Anyone with half a brain should be able to process these steps.

Share this post


Link to post

The hard part about it is having to go source diving to find what version of fmod to use. That shitty wiki is not a decent documentation source and you goddamn well know it. This should be well documented in the developer documentation. In fact you didn't respond to the point as to why the library isn't included in the distribution package or why a link to the library cant be put into the documentation (probably better). I suspect theres a reason why...

Share this post


Link to post
John Smith said:

That shitty wiki is not a decent documentation source

That's the dumbest thing I've ever seen you write.

Share this post


Link to post

Yeah well, as of right now, the version of fmodex listed on the wiki to use for compiling in Linux is "fmod(sic) 4.26", when Graf just said that 4.28 is the version listed in the source. And Gez I heard you were a pretty major contributor to the wiki, so I'm interested in what reason you might have, if any, for not changing that number on the wiki. Because surely you've read Graf's post and know it isn't as it should be. So you tell me how much quality the ZDoom wiki has.

Share this post


Link to post

So, either April 5 information isn't relevant on August 19, or graf doesn't know what he's talking about in his above post. Your link is implying one or the other.

Share this post


Link to post
John Smith said:

That shitty wiki is not a decent documentation source and you goddamn well know it.



I agree with Gez. That's just dumb, if not flat out retarded. Care to tell us why you think that?

John Smith said:

So, either April 5 information isn't relevant on August 19, or graf doesn't know what he's talking about in his above post. Your link is implying one or the other.



ZDoom compiles and runs with both, technical issues nonwithstanding.
I don't know if the problem mentioned there has been fixed in more recent 4.28 builds because I don't work on the sound code. Somebody else needs to check.

That said: Changed the text file in the source to mention this issue.

Regardless, no matter which reference is being used to check which version is needed, the following steps are the same, whether you decide to download 4.28.17 or 4.26.27 - and with both you get a working ZDoom binary.

Share this post


Link to post
Graf Zahl said:

I agree with Gez. That's just dumb, if not flat out retarded. Care to tell us why you think that?

We just spent the last five posts or so figuring out if you, a developer, or a fucking wiki contained the proper information about the best version of a library to use when compiling ZDoom. And the wiki appears to have won out. Depending on how you view it that would make me wrong about the wiki (I think it does), but that also makes you, a developer (of a project with precious few developers) wrong about the best version of fmodex to use with ZDoom. And the source documentation failed to mention the issue with 4.28.x until just now when a complaint was made and you changed it. And the wiki (which is supposed to act as official documentation in the absence of proper developer documentation) still doesn't mention that 4.28.x works with ZDoom, that it simply has an issue (possibly), it just refers to using 4.26.26 (which I'd add isn't the version you just listed in your post, fwiw) and 4.26.26 alone.

If this were a professional project this would be the sort of project management issue that doesn't necessarily get resolved with just a team chat, but with some one on one employee counseling, or possibly a dismissal. This isn't a professional project, so clearly neither you nor anyone else are going to be dismissed, but that doesn't make it acceptable project management practice. So maybe the problem isn't with the wiki, but with the overall documentation philosophy and implementation in general.

Share this post


Link to post

Because I have little to no involvement in ZDoom, including using it most of the time, and I'm not defending it's documentation. Not to mention the fact that I personally think that having user created documentation is a terrible idea in the first place. I think it's poor project management from developers who are more interested in churning out features than creating a solid product. Nobody know's whats going on better than the developers and people involved in extensive testing. IMO, end users have no more business editing software documentation than priests do editing a Bible. Clearly someone in the ZDoom community disagrees, that's why there's a wiki in the first place. And if it has to happen, there's no excuse that said end users can't keep up quality documentation standards, especially when the information is laid out for them and they don't have to hunt for it. I'd ask what your excuse is for not fixing it in the wiki but frankly I have no confidence in getting as straight an answer.

Share this post


Link to post
John Smith said:

We just spent the last five posts or so figuring out if you, a developer, or a fucking wiki contained the proper information about the best version of a library to use when compiling ZDoom.


There were 2 sources for this information that did not match. Big deal. I just happened to refer to the other one. When the comment in the Wiki was made (by Randy, btw.) he should have added this to the text file too. Well, shit happens.

John Smith said:

And the wiki appears to have won out. Depending on how you view it that would make me wrong about the wiki (I think it does), but that also makes you, a developer (of a project with precious few developers) wrong about the best version of fmodex to use with ZDoom. And the source documentation failed to mention the issue with 4.28.x until just now when a complaint was made and you changed it.


You are running in circles here. But instead of accepting the fact that with a hobby project such things are bound to happen because it's not in anyone's main focus you are making a big deal out of it which really isn't worth it.


John Smith said:

And the wiki (which is supposed to act as official documentation in the absence of proper developer documentation) still doesn't mention that 4.28.x works with ZDoom, that it simply has an issue (possibly), it just refers to using 4.26.26 (which I'd add isn't the version you just listed in your post, fwiw) and 4.26.26 alone.


It's mentioned in the changelog history only, which probably was a mistake. But since the version info is templated it's hard to put such info in there.

As for 4.26.26 vs. 4.26.27, the later one was only released a few days ago and apparently none of the Wiki maintainers has realized it. Will be updated at the earliest point possible.

John Smith said:

If this were a professional project this would be the sort of project management issue that doesn't necessarily get resolved with just a team chat, but with some one on one employee counseling, or possibly a dismissal. This isn't a professional project, so clearly neither you nor anyone else are going to be dismissed, but that doesn't make it acceptable project management practice. So maybe the problem isn't with the wiki, but with the overall documentation philosophy and implementation in general.


Lol!, no forget that: LOL!!

You have no fucking idea how professional projects are run then.
You wouldn't believe some of the things I have seen over the last 15 years ever since I started working as a professional developer.
Often the project managers have no fucking clue what's going on in the project they are supposed to manage because they have no programming experience whatsoever and more often stand in the way than not.

A minor mixup of version numbers of a supporting library is forgotten one day after discovery.

I think a dismissal would be in order if someone behaved like you. :P

Share this post


Link to post
John Smith said:

Because I have little to no involvement in ZDoom, including using it most of the time, and I'm not defending it's documentation. Not to mention the fact that I personally think that having user created documentation is a terrible idea in the first place. I think it's poor project management from developers who are more interested in churning out features than creating a solid product.


The Wiki has maintainers who do know the insides of the engine rather well. Most of the docs is written by Gez, btw., and his contributions have been consistently of extremely high quality. There's also other contributors that know what they do. The stuff added by the average user gets culled rather quickly most of the time.

John Smith said:

Nobody know's whats going on better than the developers and people involved in extensive testing. IMO, end users have no more business editing software documentation than priests do editing a Bible.


Guess what position in the food chain the major contibutors have. :P

John Smith said:
Clearly someone in the ZDoom community disagrees, that's why there's a wiki in the first place.
[/B]


OMG! The world is doomed because ZDoom has a Wiki (and
Eternity has one, too, as do Legacy and Vavoom.) Clearly the doom port developers are all an inept bunch of idiots who have to rely on the dumb masses for such things.

Share this post


Link to post
John Smith said:

And the wiki (which is supposed to act as official documentation in the absence of proper developer documentation) still doesn't mention that 4.28.x works with ZDoom, that it simply has an issue (possibly)

Why should it? What's the point of listing all the versions of a library that the program can work suboptimally with? It'd just make the articles overly long and needlessly confusing.

Same deal with DirectX libs for Windows builds. Microsoft is removing DirectDraw from the SDK, so the link on the wiki is still for the last version of the SDK which included it. Because it's simpler and less convoluted than digressing about how you can use the latest but you'll have this and that problem.

And anyway, anyone who knows how a Mediawiki wiki works can just look at the history page.

The latest recommended FMOD Ex version is updated regularly. Not slavishly every hour, because the minor revisions are not exactly important anyway, but it is. There's even a template made to update all the "Compile on ..." articles at once.

John Smith said:

If this were a professional project this would be the sort of project management issue that doesn't necessarily get resolved with just a team chat, but with some one on one employee counseling, or possibly a dismissal. This isn't a professional project, so clearly neither you nor anyone else are going to be dismissed, but that doesn't make it acceptable project management practice. So maybe the problem isn't with the wiki, but with the overall documentation philosophy and implementation in general.

What are you smoking? What is leading you to compare a community-maintained wiki for a free software port that's a hobby project for its developers, with the high standards you ascribe (not that rightly BTW) to corporate documentation?

John Smith said:

Clearly someone in the ZDoom community disagrees, that's why there's a wiki in the first place.

http://www.chocolate-doom.org/wiki/index.php/Chocolate_Doom
http://dengine.net/dew/index.php?title=Main_Page
http://eternity.youfailit.net/index.php?title=Main_Page
http://legacywiki.net/index.php/Main_Page
http://odamex.net/wiki/Main_Page
http://sourceforge.net/apps/mediawiki/remood/index.php?title=Main_Page
http://skulltag.net/wiki/Main_Page
http://www.vavoom-engine.com/wiki/index.php?title=Main_Page

...

I guess PrBoom+ and Risen3D are good ports with a good approach to documentation, because they seem to be the only major ports without one. At least, not that I found.

Share this post


Link to post

Graf, I know this must be an odd idea to you, but it's the burden of the developer to provide accurate documentation on their project, not the users. If you or anyone else on your team can't be bothered, then what else in your project is lacking?

And being a hobby is no excuse. If you're making something for other people to use, there is a certain value of quality and work that's expected. Were you making this solely for yourself and not releasing it to other people, it would certainly be different.

As to why people support other ports than zdoom, the argument made by the OP assumes that zdoom is better than the original doom. The problem is, more features do not a better port make. Whether a port is "better" is, by its nature, a subjective thing. For me, Chocolate-Doom is better because it is, and strives to be, essentially vanilla doom on newer computers (and other architectures and OSs, but that's a side effect of good coding). That may not be the case for everybody, and that's fine.

Share this post


Link to post
Graf Zahl said:

There were 2 sources for this information that did not match. Big deal. I just happened to refer to the other one. When the comment in the Wiki was made (by Randy, btw.) he should have added this to the text file too. Well, shit happens.

Blithe dismissal of criticism is all I see here: "big deal, we didn't do something we shouldn't do, so what?" is the sort of response I expect from a high school student not an adult professional.

You are running in circles here. But instead of accepting the fact that with a hobby project such things are bound to happen because it's not in anyone's main focus you are making a big deal out of it which really isn't worth it.

Documentation damn well should be someones focus. If I cant rely on my software's documentation as an end user then what at all can I rely on from the software? Who knows what other things aren't anyones "main focus." Perhaps clean code, or bug fixing, or anything at all really, isn't anyones "main focus" and unless I go source diving (which I shouldn't have to do as an end user) I have no way of knowing. Documentation is the face of quality control and discipline that the developers show to end users. Bad documentation is an ugly face.

It's mentioned in the changelog history only, which probably was a mistake. But since the version info is templated it's hard to put such info in there.

As for 4.26.26 vs. 4.26.27, the later one was only released a few days ago and apparently none of the Wiki maintainers has realized it. Will be updated at the earliest point possible.

It's a wiki, as wildweasel suggests its not that hard to fix! In fact, regarding the "As for 4.26.26 vs. 4.26.27" the earliest possible point to update it is right fucking now, and as I look at the page I still see 4.26.26.

Lol!, no forget that: LOL!!

You have no fucking idea how professional projects are run then.
You wouldn't believe some of the things I have seen over the last 15 years ever since I started working as a professional developer.
Often the project managers have no fucking clue what's going on in the project they are supposed to manage because they have no programming experience whatsoever and more often stand in the way than not.

A minor mixup of version numbers of a supporting library is forgotten one day after discovery.

I think a dismissal would be in order if someone behaved like you. :P

I do very much know how professional projects are run. I run a business, I consult with multiple business customers, and I design solutions for their business needs, and I have dismissed people before. If I heard of a developer on any project I was managing in any position I held giving such an attitude laden response as you've given me to a tester or user of the product I was in charge of I would tell them to clean out their shit and get the fuck up out my office. And I would gladly defend it to my superiors.

The Wiki has maintainers who do know the insides of the engine rather well. Most of the docs is written by Gez, btw., and his contributions have been consistently of extremely high quality. There's also other contributors that know what they do. The stuff added by the average user gets culled rather quickly most of the time.

I apologize then that I misunderstood the inner workings of the ZDoom wiki, my mistake. However, in the discussed page alone I have already pointed out an error that has yet to be fixed, when clearly it has time to be. And I'm just going to highlight for any readers the "most of the time" at the end of that last statement and let them draw their own conclusions.

Guess what position in the food chain the major contibutors have. :P

Unless they are, in this analogy, at the level of God himself, then they have no business rewriting His reference guide. Not even the god damn pope makes edits does he?

OMG! The world is doomed because ZDoom has a Wiki (and
Eternity has one, too, as do Legacy and Vavoom.) Clearly the doom port developers are all an inept bunch of idiots who have to rely on the dumb masses for such things.

And they're all shit. Even Quasar will agree the Eternity wiki is very sorely lacking.

Share this post


Link to post
DoomCup said:

Graf, I know this must be an odd idea to you, but it's the burden of the developer to provide accurate documentation on their project, not the users. If you or anyone else on your team can't be bothered, then what else in your project is lacking?


There's people who concentrate on the development and others who concentrate on the docs. There's enough information exchange so that it works. Did it ever occur to you that some people are just not good at writing documentation? I know for sure that Gez is a lot better at it than me so if I had to write this stuff myself it'd be of significant lower quality which would serve nobody.

Share this post


Link to post
DoomCup said:

the argument made by the OP

Was an obvious troll.

Share this post


Link to post
Gez said:

What are you smoking? What is leading you to compare a community-maintained wiki for a free software port that's a hobby project for its developers, with the high standards you ascribe (not that rightly BTW) to corporate documentation?


What are you on? Professional does not mean corporate. OpenBSD manages to be a professional project without being corporate, and they actually manage to provide documentation on everything.


Oh, my, aren't you clever? Every project has a wiki, so we're vindicated! This is a rebuttal I would expect from a middle school student. Also, the wikis you have listed manage to actually have relevant, up to date information, as far as I can tell. Man up, grab an editor, write some documantation.

Share this post


Link to post

Honestly John, if you look back on this thread, your first post alone paints just how much of a prick you are being, which makes it that much harder to listen to a damn thing you have to say.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×