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

Why do people still map in Boom format?

Recommended Posts

In the end, it depends entirely for the mapper to do a map with such compatibility. I, personally, like to do some maps in UDMF format. Others like to do maps in Boom format. It's just a matter of tastes...

Share this post


Link to post
1 hour ago, kb1 said:

Now, without naming them, (it's kinda obvious and boring) there's some people on the forum that hear anything about ZDoom, and get unreasonably defensive, and argumentative

It might help if it wasn't for the fact that the majority of your posts about the subject didn't have the rhetoric of an 80-year-old grandma turning her nose up about the fact that younger women started wearing pants, because back in the old day girls were perfectly happy with not wearing pants.

 

1 hour ago, kb1 said:

So, to evolve, there must be collaboration, and synchronicity between port devs.

And that is why PrBoom+ is an obstacle - because entryway has no desire to collaborate for such a purpose, and it's rather moot to have ZDoom and Eternity lead the charge for a Boom+ format which, y'know, won't be added to the main modern Boom port. Especially since, as has been done for while now, ZDoom and Eternity cross-compatibility makes more sense in terms of Eternity adding ZDoom's addition to Hexen and UDMF, and vice-versa.

Edited by Arctangent

Share this post


Link to post
3 hours ago, Arctangent said:

Neither of those seems like outright breaking - the latter of which just seems like an issue that comes naturally when playing something designed for a primitive renderer in a newer one ( see: fake reflective surfaces via sprites and textures that go "under" the floor that just get clipped in a renderer that uses more general-use 3D rendering ), while the former ... kinda stumps me. Just software, or does it affect hardware too?

The guts isn't a renderer thing -- it's because ZDoom changed how it handles collisions on decorations.  Since it's calculating them on things that it wasn't before, that room slows to a crawl.

 

The reason I bring up the spectre fireball attack being near invisible in GL is because it means there's no remotely "current" version of ZDoom that can run Claustrophobia, which is pretty bad since it was one of the most high-profile ZDoom releases of its era.

Share this post


Link to post
1 hour ago, Arctangent said:

It might help if it wasn't for the fact that the majority of the posts about the subject didn't have the rhetoric of an 80-year-old grandma turning her nose up about the fact that younger women started wearing pants, because back in the old day girls were perfectly happy with not wearing pants.

 

And that is why PrBoom+ is an obstacle - because entryway has no desire to collaborate for such a purpose, and it's rather moot to have ZDoom and Eternity lead the charge for a Boom+ format which, y'know, won't be added to the main modern Boom port. Especially since, as has been done for while now, ZDoom and Eternity cross-compatibility makes more sense in terms of Eternity adding ZDoom's addition to Hexen and UDMF, and vice-versa.

No rhetoric here, just facts about the current state of affairs.

 

It is idiotic to claim that any source port has inhibited progress, when source code is available. Was ZDoom, or Legacy, or Eternity inhibited from adding new features? Of course not. Ridiculous.

 

What inhibits progress is not being able to progress. And that's caused by personal differences in what features are to be implemented, how they are to be implemented, and how to encode those new features into existing systems. Without collaboration and agreement, features will implemented in conflicting ways, or implemented in a way that makes it difficult to share between ports. This and this alone prevents the advancement of the standard beyond Boom/MBF.

 

And, by the way, PrBoom-Plus has completed its mission: To emulate dead ports. Period. Entryway has no obligation to build beyond that. But, guess what? The source is available. This encourages the enhancement of the "standard", because a port dev can start with a fully functional tight port that abides by the current standard 100%. This is the ideal place to start. This is all quite obvious, and I won't state it again. If you don't understand this, I can't make it much clearer.

 

I must admit that I can't get over your assumption that ZDoom is the root of all things advanced, that ports like Eternity have to "step-up to", by adding "ZDoom's additions to Hexen and UDMF"... UDMF, which Eternity's Quasar designed. Yes, Eternity is bending over backwards trying to contort itself into ZDoom's paradigms, which will afford it some cross-port user mod capabilities. But Eternity has had support for its own EDF mod capabilities for a long time. Maybe that's the advancement the community should strive for, and ZDoom should add support for loading Eternity-styled modifications. I can't hold much respect for your viewpoint if this possibility is not considered. DelphiDoom has recently added some really advanced scripting. DoomsDay, Edge, Vavoom, Legacy: all contenders as well.

 

Now, realistically, once a port-specific map is released, it is not possible, or wise, to back out existing features, so advanced ports are stuck with that baggage. But, you can go in the other direction, and start adding simple features to the Boom/MBF standard, and try to achieve, at the least, a Boom+/MBF+ enhancement. If that could be done successfully, with multiple-port collaboration, a second phase could begin.

 

But again, until that happens, many people will stick with what works universally: Boom/MBF.

 

@Linguica: I can't disagree. I know I make big posts. I do what I can to keep them clean, and factual, but it's like there's an emotional tie to certain things that seems to supersede logic and reason. It's downright discouraging that we cannot have a discussion amongst peers, without people deliberately throwing a monkey wrench into the works. I don't understand what the goal is. Does it envoke pleasure, to disrupt a simple discussion? I don't know - I'm out :(

 

Share this post


Link to post
18 minutes ago, kb1 said:

No rhetoric here, just facts about the current state of affairs.

On 4/17/2017 at 11:39 PM, kb1 said:

Wow. PrBoom as the obstacle. Here's the way I see it - time for Memory Lane:

 

In the Good ol' Days, source ports authors had a chance to share code and ideas, ... In fact, for a short time, there was a Doom Committee dedicated to keeping ports compliant, by, for example, dolling out unused linedef types, or doomednums.

 

But then, a strange thing happened. For some reason, certain port authors had lots of ideas, and started refactoring their source to their liking, and adding features without much concern for what other port devs were doing.

 

PrBoom was not the obstacle of progress: Instead, the mentality of sharing was lost.

Yeah, uh. If you're being 100% genuine, then you either have no idea what a rhetoric actually is, or your computer is possessed by a ghost that constantly changes your posts to make it seem like you have nostalgia goggles glued to your face and you haven't bothered proofreading them.

 

28 minutes ago, kb1 said:

It is idiotic to claim that any source port has inhibited progress, when source code is available. Was ZDoom, or Legacy, or Eternity inhibited from adding new features? Of course not. Ridiculous

You literally went on about how the past was so magical because everyone used similar codebases until the refactored source code ports attacked and ruined code sharing forever not so many posts ago, in which you actually said you'd like to include some of ZDoom's code but it's too unvanilla. Of course, that doesn't stop any new features that aren't intended to be backported to a multitude of ports based on older codebases, but is there really any point to a Boom+ format if it's only adopted by ZDoom and Eternity?

 

25 minutes ago, kb1 said:

I must admit that I can't get over your assumption that ZDoom is the root of all things advanced, that ports like Eternity have to "step-up to", by adding "ZDoom's additions to Hexen and UDMF"... UDMF, which Eternity's Quasar designed.

No, yes, I'm well aware of who designed it. It's just that it didn't actually get added into their port until well after ZDoom implemented it themselves. ZDoom absolutely lead the charge on it, albeit I'm pretty sure that mostly came down to having the manpower while Eternity was lacking it.

 

33 minutes ago, kb1 said:

But Eternity has had support for its own EDF mod capabilities for a long time. Maybe that's the advancement the community should strive for, and ZDoom should add support for loading Eternity-styled modifications. I can't hold much respect for your viewpoint if this possibility is not considered.

Not ... particularly. That seems like it could be as painful as Eternity adding in Decorate. Which you seem to have somehow read instead of, y'know, referring to the fact that Eternity's implemented quite a few specials for Hexen format and UDMF in the same vein as ZDoom, two features that they share already, with ZDoom doing similarly. Of course, it's heavily weighted in Eternity adapting to ZDoom, but y'know, that's kind of what happens when you try to be compatible with something that's doing the same thing you're trying to do, but several years earlier.

 

38 minutes ago, kb1 said:

I do what I can to keep them clean, and factual, but it's like there's an emotional tie to certain things that seems to supersede logic and reason. It's downright discouraging that we cannot have a discussion amongst peers, without people deliberately throwing a monkey wrench into the works. I don't understand what the goal is. Does it envoke pleasure, to disrupt a simple discussion? I don't know - I'm out :(

Ah, yes, the ol' "I'm the victim here" trick. What a classic.

Share this post


Link to post
2 hours ago, Linguica said:

Why do I even let these threads continue when they all degenerate into the same exact shit?

I find the technical aspects of the discussion super interesting, it's a shame some people get so emotional and/or deliberately provocative and send it down the shitter

Share this post


Link to post
8 hours ago, Cynical said:

Claustrophobia comes to mind (the "gut-spewing" room slows to a crawl in modern software ZDoom, the "spectre'd fireballs" attack that the final boss has is obscenely hard to see in GL).

 

That problem has been fixed years ago when a better solution to handle what was intended became available. Just verifying with the latest devbuild shows no slowdown at all. Yes, it had been a problem for some time, but that's long gone.

 

Nevertheless, behold an example that didn't use ZDoom's features but abused them. That's the actual problem here. It's not maps that play along the rules that tend to break but mostly those that try to play against the rules - unfortunately that's one tendency that seems to be prevalent in some Doom mappers. I have seen DECORATE code where I seriously had to question their makers' sanity and which just work by happenstance, not by careful design.

 

Doing stuff like that in a simpler engine is a lot harder so obviously it's also a lot harder to break.

 

Share this post


Link to post
5 hours ago, kb1 said:

And, by the way, PrBoom-Plus has completed its mission:

And that is the crux of the issue, isn't it?

 

PrBoom+ is one of the big names. People make maps for PrBoom+. An evolution of the Boom standard would have to be adopted by PrBoom+ to be worth anything.

PrBoom+ is not interested in adding new features (unless Eternal needs them). An evolution of the Boom standard would not be adopted by PrBoom+.

 

Does it start to make sense, then, why PrBoom+ is seen as an obstacle to an evolution of the Boom standard?

Share this post


Link to post
6 hours ago, kb1 said:

And, by the way, PrBoom-Plus has completed its mission:

 

Like Gez said, that is the problem. PrBoom+'s mission has been extremely conservative on the gameplay side, the entire focus was backwards compatibilty but no forward movement.

 

And since it has apparently completed its mission, which is evidenced by the low activity on the repo (62 commits since January 2016, 27 days of active work)

 

Ironically PrBoom+ is now in exactly the same place where PrBoom was when it got forked by entryway. So if someone could be found to fork it again and evolve it...

 

Remember, PrBoom+ also started as a fork of PrBoom when its development stalled, and has become the de-facto successor by now. With a port that updates this infrequently the same thing should be possible again, provided it is done by someone who actually cares about the fundamentals but on the other hand is interested in careful advancements.

 

Maybe what this needs is a working git clone - and a setup aimed at modern compilers.

Having it hosted on a private SVN server is most certainly a major roadblock to find contributors and the newest Windows project being for some long obsolete version of the compiler is also not that inviting because it's very hard to filter back some changes to the project.

Share this post


Link to post
6 hours ago, kb1 said:

The source is available. This encourages the enhancement of the "standard", because a port dev can start with a fully functional tight port that abides by the current standard 100%. This is the ideal place to start.

 

5 minutes ago, Graf Zahl said:

Remember, PrBoom+ also started as a fork of PrBoom when its development stalled, and has become the de-facto successor by now. With a port that updates this infrequently the same thing should be possible again, provided it is done by someone who actually cares about the fundamentals but on the other hand is interested in careful advancements.

It's so nice to see you two not exactly disagreeing on something. :')

Share this post


Link to post
1 hour ago, Gez said:

And that is the crux of the issue, isn't it?

 

PrBoom+ is one of the big names. People make maps for PrBoom+. An evolution of the Boom standard would have to be adopted by PrBoom+ to be worth anything.

PrBoom+ is not interested in adding new features (unless Eternal needs them). An evolution of the Boom standard would not be adopted by PrBoom+.

 

Does it start to make sense, then, why PrBoom+ is seen as an obstacle to an evolution of the Boom standard?

Is it considered a mistep to fork prboom+ into say prboomX which adds a conservative set of new actions/features at a new (much higher) complevel? Once the additions are considered set (and stable) they could then be implemented by other ports that are happy to expand on the Boom standard.

 

Easier said than done of course :) maintaining source code for publicly available software seems like a tough gig at times. I can also see the positives/enjoyment it brings too though for both the developer and user.

 

Of course everyone posted answers to my question before I hit submit :D

Share this post


Link to post
11 hours ago, Graf Zahl said:

What map from 10 years ago does not work anymore?

 

 

Pirate Doom has lots of glitches with recent GZDoom updates, most notably missing sounds. Unfortunately  I had to recomend it to be played with  GZDoom 1.9 which was the current version 3 years ago.

Share this post


Link to post
14 minutes ago, Da Werecat said:

It's so nice to see you two not exactly disagreeing on something. :')

... which doesn't mean that drawing different conclusions here is not an issue.

 

 

5 minutes ago, traversd said:

Is it considered a mistep to fork prboom+ into say prboomX which adds a conservative set of new actions/features at a new (much higher) complevel? Once the additions are considered set (and stable) they could then be implemented by other ports that are happy to expand on the Boom standard.

 

For some people it seems that decisions by the current PrBoom maintainers are sacrosanct.

Let's not forget the biggest misstep PrBoom ever made, which was including FraggleScript. Of course that version was quickly abandoned because the feature was too broken.

 

5 minutes ago, traversd said:

Easier said than done of course :) maintaining source code for publicly available software seems like a tough gig at times. I can also see the positives/enjoyment it brings too though for both the developer and user.

 

Yes, that's the big problem.

To be honest, if a PrBoom fork can find a competent maintainer that is willing to discuss and define a Boom+ standard extension with Eternity and ZDoom I see this as something that has a very good chance of getting accepted. Of course what must not happen under any circumstances is that the original mission statement gets diluted, i.e. any additon must not affect backwards demo compatibility one bit.

 

I'd gladly help out by hosting a fork on Github for willing contributors to be used as a base but so far the crappy repo has done a good job of preventing a conversion (with old PrBoom being the trunk and PrBoom + being hosted as a maintenance branch, deep down in the folder hierarchy.)

 

Share this post


Link to post
4 minutes ago, Graf Zahl said:

Let's not forget the biggest misstep PrBoom ever made, which was including FraggleScript.

At attempt to support SMMU?

 

I recall there's at least one feature from that port that received a permanent residence in PrBoom+: liquid swirling effect.

Share this post


Link to post
2 minutes ago, Darch said:

Pirate Doom has lots of glitches with recent GZDoom updates, most notably missing sounds. Unfortunately  I had to recomend it to be played with  GZDoom 1.9 which was the current version 3 years ago.

 

The sound problems were caused by FMod bugs. This was actually one of the main deciding factors to dump FMod and focus on OpenAL instead, because there I have sound loading under my control and do not completely depend on an opaque library that seems to change at a whim.

It is not the first time that FMod's non-focus on backward stability has bitten us in the ass - but it definitely was the last time... >)

 

It has become very clear that the main focus of FMod is not open source software but getting $$$ from commercial developers which do not require long-term support over several versions. It was just that with Randi in charge there was nothing that could be done about it.

 

And what other bugs were there? Since nothing got reported nothing got fixed.

 

Also, why 1.9 and not 2.1, which is the equivalent with the modernized renderer?

 

Share this post


Link to post
1 minute ago, Da Werecat said:

I recall there's at least one feature from that port that received a permanent residence in PrBoom+: liquid swirling effect.

Hooray: We got ourselves the first cross-port feature in all relevant Boom compatible ports... :D:D:D

 

Share this post


Link to post
8 hours ago, Arctangent said:

And that is why PrBoom+ is an obstacle - because entryway has no desire to collaborate for such a purpose, and it's rather moot to have ZDoom and Eternity lead the charge for a Boom+ format which, y'know, won't be added to the main modern Boom port

 

That doesn't matter. Entryway would probably merge someone else's work if it was done to a suitable standard. Him not getting involved in the work isn't a blocker. And even if he didn't accept it, maybe Prof would take it in prboom upstream, or accept additional maintainers into prboom (although there's a can of worms,would that happen, what of prboom+ should be merged back in? all of it?) There's also WinMBF, and we will have a chocolate-boom (and chocolate-mbf) probably sometime "soon". Let's not forget doomretro, in fact positing this as Zdoom and Eternity only is misleading.

Share this post


Link to post

All those older ports are too niche to be relevant. They serve a historical purpose, but very little beyond that. They are not the target for 'advanced Boom' maps.

 

Chocolate-Boom should be a precise reproduction of Boom, as should Chocolate-MBF be a precise reproduction of the original MBF, both with all original limitations and bugs in place, just like Chocolate-Doom is.

As such, these ports wouldn't even be able to play 'advanced Boom' maps as they already exist, they still have a low seg limit, they have no support for extended nodes and there's probably a few other things I did not think about.

 

Stuff like Valiant, Ancient Aliens or Chris Lutz's Hellscape as a recent example would definitely not run on them as thess mods all require strong limit removal.

 

Concerning filtering back stuff to PrBoom, I have my doubts that this is going to work, for various reasons. Like I said, the entire repo is only set up for ancient compilers, none of which I still have, so if I were to make a submission I would not be able to alter the projects accordingly. The first thing this needs is an upgrade to something more modern and the other thing of course is, there's not one ancient Windows project but three! And there's the typical Linux mess of autotools littered throughout the entire folder hierarchy which needs to be maintained.

 

So if I were to work on it, the first thing I'd do is toss all this garbage out and create a single CMake project for everything. And that would probably already kill all chance of the former maintainers being willing to work on it, even though it may be the only chance to get new contributors.

 

 

 

 

Share this post


Link to post
20 minutes ago, Graf Zahl said:

 

 

And what other bugs were there? Since nothing got reported nothing got fixed.

 

Also, why 1.9 and not 2.1, which is the equivalent with the modernized renderer?

 

I can't run GZDoom since version 2.0 with my toaster computer. So I've noticied these bugs watching videos of others playing,  couln't really check them myself. Maybe the missing sounds alone were enough for me to think at the time "OMG now it's totally broken", I don't remember exactly. 

But glad to know that it has been fixed in recent GZDoom versions. (Is it? Can't test heh)

Share this post


Link to post

Recent GZDooms should run on GL 2.x hardware. What kind of problems do you get when starting 2.4.0?

 

Share this post


Link to post
10 hours ago, kb1 said:

No rhetoric here, just facts about the current state of affairs.

 

It is idiotic to claim that any source port has inhibited progress, when source code is available. Was ZDoom, or Legacy, or Eternity inhibited from adding new features? Of course not. Ridiculous.

That entirely depends on how the code is maintained and if its state of affairs is conductive to contribution. And here I see some issues.

 

Let's first start with the ultimate negative example, Doom Legacy. Declaring this code a mess would be a gigantic understatement. It is utterly broken, unless using an old and long obsolete version of GCC to compile it. And don't even think about using anything else, it won't work. Been there, tried that, gave up, and I don't think I was the only one to see that happen. For obvious reasons such a port won't see any external contributors, nobody wants to work with such code.

 

PrBoom is nowhere near this state but from looking at the project I see one potential issue: It only comes with project files for ancient Windows compilers. Never mind that the Visual Studio 8 (i.e. 2005) solution can be upgraded, but the implications lie deeper. The mere presence of the project files suggests that someone actively develops the port with some ancient compilers, one 12, the other 18(!) years old. What that means is that all those neat features that come bundled with modern C++ versions are out! Even though the code base is C, it could easily interoperate with some C++ code, but as things stand, if that code uses some more modern stuff from the STL the game is over, if one wants to get the feature back into the mainline. Again, progress is stalled by maintainers that are thoroughly living in the past.

 

And what for? Presumably so that the compiled binary can run on Windows 95 - I really cannot see any other reason to stick to a broken compiler like MSVC 6 that doesn't even properly support C++. So who's up to working with a dinosaur language from another time than the fossil programmers that aged with it?

 

 

Share this post


Link to post
1 minute ago, Da Werecat said:

Rude.

Par for course, I'd say. Check this guy's previous posts.

Age-wise I'd be among those 'fossils', too... :D When I started programming there was no C++, I went through the entire chain of advancements, some good, some bad, and for coding I adopted those that make sense and ignored the rest.

 

About the voiced concerns, they are obviously blown far out of proportion. Let me elaborate.

 

Yes, having to keep code compatible with MSVC6 is definitely an issue. It means I cannot use std::map, and probably neither std::vector. But here comes the bright side: ZDoom already comes with its own array class that is completely independent of those STL classes. And these classes have started out on MSVC 6, so all I need to do is grab the source of, say, ZDoom 2.0.24, grab its TArray class, and use that to store stuff. It sure has some limitations but is perfectly workable for the job at hand. I had to work with worse situations where broken old compilers were an issue.

 

 

 

 

Share this post


Link to post

The reason is, presumably, because it removes vanilla limitations such as visplane overflow and whatnot. Ultimately though not a whole lot of Boom features are used in most mappacks, I hardly see even something as basic as a scrolling floor, which isn't exactly hard to pull off. Hell, even look at something like caverns of darkness, a very old mod which although had its own engine it was still mostly boom/MBF (IIRC), try to compare the features that one had with the features from almost any major boom mappack today and you will see that said mappacks do not even make use of 1/10th of the actual boom features allowed there.

 

But let's go further. Take a mod like Mars Doom, which is a /vanilla/ wad, yet had stuff like a minefield you had to traverse by finding a computer area map, turrets you can switch on and off ala duke3d force fields, a girl you have to escort in levels and you can only exit the level after she uses the exit teleporter. All this done in /vanilla/. How many mods do you see today that use 1/100th of the creativity of mars doom?

 

See, this is the issue. The reason vanilla/boom mapping is so widespread is merely because it's the accepted conservative standard, which does not necessarily stem from a hatred of ZDoom or Doomsday or EDGE or whatever "Plus" port out there (you could argue the dislike is still there, but it's secondary to the main issue). The core issue is that innovation or "anything that's not faithful to vanilla style rules (and even then there's a lot of arguments we could make in terms of gameplay and style where most of today's big boom/vanilla wads have less in common with the original game than enjay zdoom does, so to speak) is simply frowned upon and discouraged. Ultimately all the big mappers (the authors of BTSX, Valiant, CChest, you name it) work on this type of projects, and so this is what other mappers who look up to them are more likely to be indoctrinated into doing. The argument that pops up all the time as accusations against ZDoom developers is "you took a wonderful game and ruined it with your features", but really, that's more of an excuse than anything. Because ZDoom is frowned upon arguably as much as projects like Mars Doom are. Creativity and interesting mods are not tied to what source port they are developed for. It's mostly the entire mapping scene that is filled with ultra conservative dinosaurs who simply push for this type of mapping to be the main one and the most widely accepted one, ignoring almost everything else.

 

That's not to say that others don't have fault. To begin with, ultimately to each their own but it's definitely impossible not to praise people like the BTSX team, or skillsaw, or all the others who make these impressive mods which, obviously, have a HUGE amount of effort and care put into them. Regardless of whether you like them or not (personally for instance I'm not a fan of BTSX) it's obvious that they are worthy of the praise that they get and that they are not cheap cash ins, but articulate projects that are well crafted in every respect. However, the thing is that ultimately these people push this agenda because /they get things done/. Sure, they went around forums trolling people who used 3d floors (and anybody who has been around long enough can very much confirm this is the case) among other things, but really, ultimately this is the accepted agenda because nobody managed, or cared, to push a different agenda.

 

For instance, what has the ZDoom community done to change this? Think about it. Beyond the occasional (excellent, I would add) Enjay or Xaser maps and a few other projects, such as the dump community project or some other surprises that seem to come out of nowhere sometimes (but are tragically often left unfinished for one reason or another) there really is not any "block" of ZDoom mappacks that could ever challenge the established boom/vanilla format. Most of the ZDoom community is content of playing gameplay mods ultimately, and typically on the very same conservative mappacks such as BTSX or ancient aliens. I find it to be a bit surreal, personally. But evidently this is the state of things and although things have improved to a certain extent, it's clear that there is simply no willingness to the other side to once and for all establish that "you know, I think we can do a lot better than what the current established format is pushing people to make.". This has been a source of complaints in the past by some people and if I'm not mistaken even Graf himself expressed his disappointment at the lack of ZDoom-specific maps. As to why there's a lack of maps, the reasons are varied. I believe most people are simply content with playing gameplay mods on boom mappacks, even though at the end of the day it's a less than ideal matchup because you are playing a gameplay mod which is not built around most of the maps you are going to play on maps that on the other hand were also not built to support anything beyond standard doom weapons and enemies. There are merits to be found for sure, but it's still less than ideal. Another reason that was brought up to my attention recently was that there is some sort of stigma surrounding ZDoom maps from the ZDoom community itself, even. There is this myth that for some reason if a map is made in ZDoom format then it must absolutely abide to some insanely high standards, use absolutely all of ZDoom's features and replace everything in the game and even after that's done, must have for some reason an amazing story to top it all off. If you want an example of this type of train of thought all you gotta do is google Daedalus, without question one of the absolute best doom mods ever made and while the non-linear and occasionally cryptic (but imo less so than hexen) nature could turn people off, when I looked for threads about it I was honestly shocked to read complaints like "well the story was silly so I didn't like it", as if that somehow was now a necessary staple that ZDoom mappacks must abide to. There's absolutely no reason for such double standards, it results in nothing and eventually discourages people from mapping for the source port. Is that what ZDoom really wants?

 

Personally I will say that I'm a big fan of vanilla doom and especially the 90s and early 2000s era of doom modding. I have played basically every notable (and play all lesser known ones as soon as I run into them) doom mod: memento mori, icarus, requiem, eternal, strain, hell to pay, scientist 2, etc. . I absolutely love those and I don't find nearly anything of what I enjoyed in those to be present in most of today's "conservative" mappacks, making me question whether conservative is even the word that should be used in this context. But this is merely personal preference and not an accusation against anybody.

 

To conclude, I think conservativism is an issue on both sides of the fence here. We can keep blaming this or that source port as much as we want but at the end of the day maybe we should go back to how doom modding was in the 90s, where every modder was interested in seeing how much they could squeeze the engine to do, both when it came to simple maps depicting their home or larger scale projects. To me that is what has always made doom special. It's not phobos, not the demons, not the revenants' AAAAAA, but the fact that you can do pretty much anything with it, to your heart's desire. The fact that people would seek to limit this to me is paramount to killing the spirit of the entire game. But that's just my thought.

 

This post may be controversial for many people and that is fine - but I do not really intend to offend anyone and am merely offering my two cents. Disagree as you will.

Share this post


Link to post
3 hours ago, Graf Zahl said:

Par for course, I'd say. Check this guy's previous posts.

Age-wise I'd be among those 'fossils', too... :D When I started programming there was no C++, I went through the entire chain of advancements, some good, some bad, and for coding I adopted those that make sense and ignored the rest.

 

I'm with you there - I've got to claim to be a fossil too.

 

Now, I have to ask: Would you be able to assist me some time in the future, with helping set up a repository, and providing some tips on compilers and language cross-compatibility on a PrBoom++-type project? Partially based on pressure in this forum, and my own internal stress, I've decided that it's important for me to make some progress with my source port. This highlights some issues:

My source started as ZDoom 1.11, as it was the only port I could figure out how to get it to compile without difficulties. So, yes, I still use DirectX for fullscreen video, DirectInput for keyboard/mouse, and Midas sound system, of all things, God help me. It all actually still works on Win10. But I want to move to SDL2, and definitely want to be able to run on Mac, Linux, and others.

 

So, instead of reworking all of that, I've decided to start a 3rd rewrite, using a port that has a lot of the features I've been wanting to implement. I've decided to take a port that already has good SDL2 support, and port my custom source into it. So, naturally, I chose PrBoom-Plus.

 

Instead of perpetuating all of these forum debates, I'll be able to backup my theories with source. But, being a fossil, I am lacking in the knowledge of setting up repositories, daily compiles, a web forum, etc, and I need a few pointers on cross-OS compatibility. I could use your help, and you sound like you might be willing.

 

This is something down the road - I work slowly, and it's going to be a while before I am ready, but it'd be nice to know if I can count on some assistance. I really don't like to have these petty arguments, and I know the you have skills. I hope you can appreciate that I do as well, despite me having not provided a lot of demonstration in the form of source.

 

If someone doesn't beat me to it, I have a lot of ideas for creating a first draft of specifications on various aspects of a Boom+ nature. Rather than using "design-by-committee", I believe this first draft should be done by one person with a cohesive vision, and presented as a whole complete idea. Once that has happened, the community can tweak and bugfix the specification. This method has the advantage of being able to present a complete system that inter-operates smoothly and efficiently.

 

At that time, we can determine if the major devs can actually get behind a singular specification. It's not too late to go back, and try to bring some unity into the picture.

 

@arctangent: Please take the time to formulate your ideas better. Your narrow-minded circular arguments and conclusions lead the community nowhere. No, I do not see myself as a victim, because your attacks are ineffective. I think, if you try to see the bigger picture, and follow the logic to it's total conclusion, you'll see what I mean. If you provided reasonable points, in a polite manner, I would consider each and every point you make...but, instead, you don't seem to want to have an adult debate. You simply insult and attack every sentence, which makes you lose credibility and look like a junior-high-school punk. You are representing yourself when you post. I suggest trying to post words that you can be proud of. Post reasonable counterpoints politely, when necessary, and also give credit where credit is due. I am here to share ideas, and I will not be discouraged by petty pointless non-truths. Why are you here, exactly? Something to think about.

Share this post


Link to post
8 minutes ago, kb1 said:

Why are you here, exactly?

Speaking of, didn't you say just above that you were out of this thread? Thanks for insulting the guy and letting us all know about your reliability, I guess?

Share this post


Link to post

Man, dude, you are so unironically far up your own ass that it's a surprise that you're not currently in the hospital for a broken neck. This might surprise you, but I'm well aware that I'm mixing in my actual debate points with my very intentionally hyperbolized eye-rolling - that because I'm doing it on purpose, because one, I find your attitude insufferable, and two, this isn't some formal debate in the slightest, this is a casual-as-hell debate that's just as much socializing as it is bringing out each other's points.

 

Which means when you act like an utter holier-than-thou twat with your nose pointed to high heaven, people are going to call you out for being an utter holier-than-thou twat with your nose to high heaven.

 

I mean, you're only digging yourself deeper and deeper into that yourself, what with your finger-wagging attitude of "oh but you were aggressive so now all your points are stupid!!!" and the whole idea that you are the one who determines what someone can take pride in. Seriously, dude, do you read what you write? Are you this passive-aggressively smug in real life, too?

Share this post


Link to post
18 minutes ago, Dynamo said:

The fact that people would seek to limit this to me is paramount to killing the spirit of the entire game.

Limits will always be a part of Doom modding, simply because it's so hopelessly obsolete. You're already limiting yourself by choosing one of the Doom-derived engines for your self-expression needs, and not the current Unreal Engine.

 

But the kind of simplicity Doom offers is what allows modders to get shit done. Older standarts also help in this case, which is one of the reasons you're seeing a lot of finished vanilla+ projects, and not a lot of ZDoom releases.

 

As for the story - well, if it's present, then it should be good, no? The thing about conservative projects is that in many cases they pretty much don't have a story to speak of, so there's nothing to criticize. This is probably the main reason for such high standarts when it comes to ZDoom. You can do many new things there, but you're expected to do them well, otherwise what's the point?

Share this post


Link to post
12 minutes ago, kb1 said:

I am lacking in the knowledge of setting up repositories, daily compiles, a web forum, etc

I'd suggest setting up a GitHub account, and hosting your repository there. Use GitHub's built-in issue tracker and you won't need to have a dedicated forum, which while certainly nice to have, is quite a hassle to handle (fighting spam, moderating posts, keeping the data base secure from hacking attempts (yes that will happen regardless of how obscure you think you are, there are bots)). For general discussion, a pinned thread on Doomworld with the occasional news thread for a release announcement is good enough for PrB+, Choco, Retro, and Crispy.

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
×