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

When you say Legacy maps run in GZDoom, is that a universal thing? I remember Phobia: The Age not working in GZDoom (it was technically "playable", but none of the lighting effects worked right, which ruined both the atmosphere and action); has that been fixed?

 

(That would be a really great wad to have playable on modern operating systems...)

Edited by Cynical

Share this post


Link to post
29 minutes ago, Cynical said:

When you say Legacy maps run in GZDoom, is that a universal thing? I remember Phobia: The Age not working in GZDoom (it was technically "playable", but none of the lighting effects worked right, which ruined both the atmosphere and action); has that been fixed?

No. Legacy's lighting is just too weird. Unless you absolutely depend on it, most maps should work if you don't exploit some of the countless bugs Legacy has to offer.

The real question is, why would you map for such a platform. Back in 2002 Legacy was popular, but now?

 

 

Share this post


Link to post

I think it does shed some light on why Boom format is popular even among mappers whose preferred port for playing isn't prboom-plus, though.

 

A universally-acclaimed cacoward winner was basically unplayable five years after its release because it was port-specific.  That's a huge amount of effort that's now useless.  If you're using features that aren't standardized across ports, you're reliant on your source port of choice still being popular when the next version of Windows comes out. 

Share this post


Link to post

Before I forgot, another brightness transfer suggestion: maybe make separate actions for lower, middle, and upper texture? I made a Marathon map once, and I'm still jealous of its lighting system.

Share this post


Link to post
14 minutes ago, Cynical said:

A universally-acclaimed cacoward winner was basically unplayable five years after its release because it was port-specific.

Not because it was port specific. The problem was the chosen port. I mean, Legacy had been having problems for years before so this was hardly surprising.

At least with the current version it is usable, but 1.42 was so bad that I banished it from my computer because it was a menace due to some shitty libraries it used.

 

It's also not without precedent. Something similar happened with Caverns of Darkness. Fortunately for that writing a patch to make it work in ZDoom was simple, otherwise that would also have been a lost WAD - it was basically broken when released with only a DOS EXE that almost nobody coiuld use anymore at the time of release...

 

The real lesson should be not to map for ports that are known to have issues and are at risk of getting neglected by their maintainers.

 

 

Share this post


Link to post

When you say "current version", do you mean the 1.46 branch that's being actively updated, or the old 2.0 branch that never worked at all?

 

If the former, that's interesting -- I didn't know there was a branch of Legacy that worked on modern computers!  Now I really want to play Phobia TA again...

 

EDIT: Nope, only seems to support Windows 32.  Why even bother to update a sourceport that no one can run?

Edited by Cynical

Share this post


Link to post

I can run the latest Legacy build on Windows 8.1 64 bit. Not that it really helps me because the handling of the engine has not improved since 1.42, only its technical stability

Share this post


Link to post
3 hours ago, Graf Zahl said:

Why Vavoom? That port is dead. But like you said, that subset is not clearly defined. It's also not necessarily what Boom+ should aim for.

What I believe is that it should pick features from existing ports that can easily be implemented and thus have a good chance of getting adopted by all relevant ports.

 

Some easier to use scroll linedefs are definitely on that list, for example, and that's present in at least those ports which support Hexen map format.

 

Yes, it makes the most sense to borrow off of the hard work that's already been done. Please see this new thread.

Share this post


Link to post
3 hours ago, Graf Zahl said:

I can run the latest Legacy build on Windows 8.1 64 bit. Not that it really helps me because the handling of the engine has not improved since 1.42, only its technical stability

So, at the risk of getting off-topic, I tried playing Phobia TA with it... and found that the -digmusic option no longer works.

 

That's right -- Legacy no longer runs Legacy compatible wads anymore.  Christ, what a worthless port.

Share this post


Link to post

Yes, that's a downer - but at least it runs without frying my system... :D

 

One of these days I really need to take a look at Legacy's lighting system and try to port the necessary parts to GZDoom, but the code involved is some of the worst stuff I've ever seen in a Doom port. :(

 

 

Share this post


Link to post

The day that everything made for Doom Legacy can run on GZDoom will be a great day indeed, especially if GZDoom eventually gets Split Screen support...

 

If only Sonic Robo Blast 2 based itself on a different port... I'd love it if someone tried to make a SRB2 TC for GZDoom similarly to how Doom 64 Retribution was made (rewrite the SOC stuff as ACS and DECORATE (and, where necessary, ZScript) while keeping the same names for actors etc; add SRB2's exclusive map features (which will have to wait for Doom Legacy support to be completed but still); aim for compatibility for the latest stable version of SRB2 and any SRB2 pwads that don't use SOC or LUA, neither of which would be ported due to redundancy). The closest thing I've seen so far is this, but it doesn't go far enough IMO.

Share this post


Link to post

It's unfair to think of SRB2 as still being Legacy, they've moved in a completely different direction and have a ton of features that Legacy never had. They've got a lot of 3D floor and polyobject stuff that helps with making it a platformer (such as "one-way-through" 3D floors that you can jump up through but not fall down through, or the reverse; and polyobjects with visible tops and bottoms that act as moving platforms and can carry actors). There's also the highly questionable "thokk" feature which never made sense to me.

Share this post


Link to post

Indeed. I had checked out the code some time ago and it deviates that much from original Legacy that trying to port it would be a lot of work. And the fact that it uses Legacy as a base (i.e. a thoroughly rotten code base) doesn't make it any easier.

 

Share this post


Link to post

I used to think porting SRB2 to ZDoom was an inevitability too, but now I like how it's ended up forging it's own path as a separate source port of sorts. It doesn't have to restrict itself to weird Doom limitations either. Also, the way it handles secrets has been said in the past to be against GZDooms spirit, and network support is a big part of SRB2 too. (Nothing against its way of networking but the client server approach is so much easier to set up and get going quickly)

Share this post


Link to post

It's not the "forging its own path" thing that's the issue, it's the port that was used for the forging. I feel like I got a lot worse performance in SRB2 compared to ZDoom based ports. Not only is the codebase bad in itself, but it's differentiated enough that whatever advancements Doom Legacy got (examples include both split screen and networking at the same time as well as any rendering and bugfixes) can't easily be patched into the SRB2 code.

 

That being said, I don't like how it handles secrets either (blocking secret levels etc unless you complete the game, which not only makes no sense from a coop perspective, but the classic Sonic games on the Genesis all had level select codes. Heck, you could access Doomsday Zone in Sonic (3) & Knuckles and The Final Fight in Sonic 3D Blast using the Level Select codes when the emeralds are necessary to unlock those levels in normal gameplay. If all of the features needed to render SRB2 levels correctly along with the proposed SRB2 TC happen, then the main reason Doom Legacy is important would be gone.

Share this post


Link to post

Uh, no it wouldn't. SRB2 is still being developed to this day, so unless you got the devs on board with the TC to continue their work there ( and therefore start doing all their future work via scripting instead of through raw programming, of which they'd have limited control over, and changing their mapping practices to fit a pretty dang different mapping format ) then SRB2 would still continue as its own thing even if GZDoom managed to catch up with all the features it adds.

 

And even then, Doom Legacy would be about as important as it is right now. Because, y'know, SRB2 doesn't actually use Legacy past forking from its code base years back - it's completely standalone. Saying SRB2 makes Legacy important is like saying GZDoom makes ATBDoom important.

 

Which I'm willing to bet most people reading this have never heard of.

Share this post


Link to post
On 4/23/2017 at 4:12 AM, Graf Zahl said:

Indeed. I had checked out the code some time ago and it deviates that much from original Legacy that trying to port it would be a lot of work. And the fact that it uses Legacy as a base (i.e. a thoroughly rotten code base) doesn't make it any easier.

 

Please be nice - Legacy is being actively maintained :)

Share this post


Link to post
16 hours ago, Arctangent said:

Which I'm willing to bet most people reading this have never heard of.

Do tell, please.

Share this post


Link to post
9 minutes ago, kb1 said:

Please be nice - Legacy is being actively maintained :)

It's actively maintained, yes, but if you compare the code with 1.42 you'll see that the overall state is very much the same - and worse - it's still very hard to compile, if not impossible, with anything but old GCC versions. To get it compiled with Visual Studio I had to disable a few parts which had hard dependencies on stuff that only works in a Unix-like environment.

 

What this code really needs to become manageable again is a thorough workover by a Windows based programmer using a modern compiler. (Windows based to make sure that all GCC-isms get removed.)

 

Share this post


Link to post
6 hours ago, Graf Zahl said:

It's actively maintained, yes, but if you compare the code with 1.42 you'll see that the overall state is very much the same - and worse - it's still very hard to compile, if not impossible, with anything but old GCC versions. To get it compiled with Visual Studio I had to disable a few parts which had hard dependencies on stuff that only works in a Unix-like environment.

 

What this code really needs to become manageable again is a thorough workover by a Windows based programmer using a modern compiler. (Windows based to make sure that all GCC-isms get removed.)

 

I know. All I mean is that it is deflating and depressing to hear that something you've poured your heart and soul into for years is shit. Maybe it is, but all I ask is to take it down a notch, out of common courtesy. Not everyone has your mad programming skills :)

Share this post


Link to post
On 4/15/2017 at 4:09 PM, Graf Zahl said:

 

Nothing against Boom, but isn't it sad that PrBoom has been the sole obstacle to further advancement for too many years now?

Imagine where mapping could be if the most demo compatible engine had subscribed to some careful expansion of its feature set instead of just preserving the status quo...

 

Instead, we are still stuck with a 19 year old standard as the most widely accepted baseline. :(

 

Nothing against you, but isn't it sad your idea of improvement is glomming together pieces of other ports?Imagine where mapping could be if there was but one port to rule them all, and with your "standards" bind them?

Share this post


Link to post
On lundi 24 avril 2017 at 10:14 PM, Graf Zahl said:

Speaking of that, the link on the Wiki page is dead, Any way to get the file?

 

It's on Doomworld, so it's another temporary victim of the site update.

Share this post


Link to post
19 hours ago, Giomancer said:

Nothing against you, but isn't it sad your idea of improvement is glomming together pieces of other ports?Imagine where mapping could be if there was but one port to rule them all, and with your "standards" bind them?

1) There's no reason for personal attacks here. Beyond that, little of this statement even makes sense.

 

2) There are quality-of-life features that have been available in other ports for years now that there's really no reason to leave out of a crossport standard. The simplicity of Boom is great for getting mapping work done quickly, and I think we have enough hindsight and experience at this point to improve on it without sacrificing what makes it work so well. It's an ancient standard at this point, riddled with poor decisions and outright bugs that have been a nuisance forever. It only became a fixed "standard" because the community stopped improving it after Boom's developers handed it off to the community.

 

After nearly two decades, creating a new shared standard is a good thing that should be encouraged. If you don't like ZDoom's developers leading the charge, encourage other developers of interested ports to get more involved. Don't spit on the whole premise.

 

In general, I have to say that I'm also simply not sold on the idea that there are ill intentions behind this project. ZDoom already has all of the features being discussed, and more. Anyone wanting to make a map that uses ZDoom-specific functionality can already do so. For Graf to spearhead a "shared standard" that other peoples' ports can't actually implement would only waste his own time in creating it.

Share this post


Link to post
7 hours ago, esselfortium said:

1) There's no reason for personal attacks here. Beyond that, little of this statement even makes sense.

 

2) There are quality-of-life features that have been available in other ports for years now that there's really no reason to leave out of a crossport standard. The simplicity of Boom is great for getting mapping work done quickly, and I think we have enough hindsight and experience at this point to improve on it without sacrificing what makes it work so well. It's an ancient standard at this point, riddled with poor decisions and outright bugs that have been a nuisance forever. It only became a fixed "standard" because the community stopped improving it after Boom's developers handed it off to the community.

 

After nearly two decades, creating a new shared standard is a good thing that should be encouraged. If you don't like ZDoom's developers leading the charge, encourage other developers of interested ports to get more involved. Don't spit on the whole premise.

 

In general, I have to say that I'm also simply not sold on the idea that there are ill intentions behind this project. ZDoom already has all of the features being discussed, and more. Anyone wanting to make a map that uses ZDoom-specific functionality can already do so. For Graf to spearhead a "shared standard" that other peoples' ports can't actually implement would only waste his own time in creating it.

And, here is why Giomancer's statements make even less sense: I am the one "leading the charge" on the new standard, and I do not develop for ZDoom. Graf contributions of UMAPINFO, considerations for Decorate-Lite, and his extensive knowledge of all things Doom have been a priceless inclusion, and resource. This is not a ZDoom project, it's an "all port's" project. I am building the first spec, and I am going to implement it into PrBoom-Plus as proof of concept. I will then port KBDoom over to this new PrBoom-PlusPlus, which will mark the 3rd complete rewrite of KBDoom.

 

@Giomancer What is sad is your attitude towards a project that just might become the greatest collaboration of port developers since the source was released. And, no, if there had not been multiple ports developed, Doom would be nowhere near as rich of an experience as it is now. It is the individual discoveries and efforts that have provided today's vast capabilities. It has also brought some duplication of effort, which this standard is trying to resolve.

 

@esselfortium Give me my due credit, please - the first rough-draft is my project ( I'm trying to get my title changed back, you know? :) This is my in, heh!)

Does someone actually believe that there are "ill intentions" behind this project? I had not heard that one. I guess they are among the people that have not contributed ideas. I'm not sure what ill intentions would be possible, but I *do* know that I wouldn't be able to convince such people with forum posts, so they are going to have to wait and see.

 

You bring up a good point, esselfortium: This standard's focus is not so much about adding capabilities - that just happens to be a happy side-effect of the main goal, which is to develop a method of communication that many ports can understand. The benefits of doing this are huge, and they affect everyone in different (positive) ways:

  • "Niche" features can be used by mappers as standard features, widening their "customer" base, and improving the quality of their maps.
  • Players benefit, cause they get to play more advanced maps, in the port of their choice, confident that the map will play properly.
  • Developers benefit: Their ports see more use, and more use of custom features.

There's other benefits:

  • This provides a bit of a platform for how to add new features, with a cross-port mindset. Developers will be communicating more, which is a good thing.
  • Ports like ZDoom don't directly benefit from the mod features themselves, but having the new standard provides a stepping stone into more-advanced, more port-specific stuff. And, this goes both ways, as it encourages port devs to continue to advance their code, by providing clear upgrade direction.

I am very excited about the prospects of moving the standard forward. It's the right time, and it's about time. I can't think of any possible ill intention that can get in the way of this train.

 

 

 

The new standard will add next to no mod capabilities to ZDoom, other than

Share this post


Link to post
On 5/23/2017 at 11:19 AM, esselfortium said:

1) There's no reason for personal attacks here. Beyond that, little of this statement even makes sense.

 

2) There are quality-of-life features that have been available in other ports for years now that there's really no reason to leave out of a crossport standard. The simplicity of Boom is great for getting mapping work done quickly, and I think we have enough hindsight and experience at this point to improve on it without sacrificing what makes it work so well. It's an ancient standard at this point, riddled with poor decisions and outright bugs that have been a nuisance forever. It only became a fixed "standard" because the community stopped improving it after Boom's developers handed it off to the community.

@esselfortium 1) It was a verbal mirror to Graf's statement. He says we've been constrained for 19 years by following Boom's de facto standard, and cites PrBoom as THE SOLE OBSTACLE TO PROGRESS. He, who headed (heads?) GZDoom, a port which has added quite a bit in the way of single-wad hacks and anything else deemed necessary, -- also demonstrably popular with mappers and modders -- apparently believes that he has been held back by PrBoom somehow. When I see him say this in combination with these proposed standards, I can only interpret that as a desire to control PrBoom and other preservationary ports. Hence my phrasing: "One Ring to rule them all, and in the darkness bind them."

 

2) If ZDoom already has all of the features, fine. They'll become a standard when other ports start implementing them (like Decorate, say). UDMF, too, which was a collaboration between persons of interest. Nothing stops others from implementing UDMF and their own namespace. If kb1 wants to create a cleaner, sharper Boom, let them do so. I don't understand how Graf can imagine mappers being held back by the existence of PrBoom.

 

 

 @kb1 Actually, I have nothing against your project at all, nor do I question your motives. Implement it. I love having new, unique targets.

Share this post


Link to post
1 hour ago, Giomancer said:

@esselfortium 1) It was a verbal mirror to Graf's statement. He says we've been constrained for 19 years by following Boom's de facto standard, and cites PrBoom as THE SOLE OBSTACLE TO PROGRESS. He, who headed (heads?) GZDoom, a port which has added quite a bit in the way of single-wad hacks and anything else deemed necessary, -- also demonstrably popular with mappers and modders -- apparently believes that he has been held back by PrBoom somehow. When I see him say this in combination with these proposed standards, I can only interpret that as a desire to control PrBoom and other preservationary ports. Hence my phrasing: "One Ring to rule them all, and in the darkness bind them."

A classic case of reading something and understanding something entirely else.

 

Let's take this apart.

 

Why do I consider PrBoom an obstacle to progress? Actually it is because all its developers have been extremely conservative when it came to accepting new features - even in places where it really would have made sense to branch out a bit, like abolishing the hard coded level transitions.

Now, why is this a problem? For the simple reason that as a result of no baseline port ever bothering with this stuff there is no reference implementation. Every port has cooked up its own incompatible method. If you want to use any of this you have to jump through hoops and provide ZMAPINFO for ZDoom, EMAPINFO for Eternity and a MAPINFO for ZDaemon, and if you want to branch out futher, DED for Doomsday and DDF for EDGE/3DGE.

The result of this chaos? I only know two mods which went all the route to do this for at least ZDoom and Eternity, but they both still restricted themselves to Doom's original level progression. (The two mods were Valiant and Ancient Aliens, btw., which had an episode selection menu on these ports.)

 

The same problem exists with actor definitions. No baseline implementation exists, so everything has to be duplicated, triplicated etc. for each port supporting such a feature - again, because everybody did their own separate implementation, partially because of NIH and partially because the competitors were deemed insufficient or incompatible with the engine's goals.

 

And say what you want - having 4 or 5 ports do the same thing differently with no common ground is just a losing proposition. The end result of this is that ZDoom gobbled up all the market share in the advanced segment with absolutely no coordination going on on the lower tiers to provide something more universal. And with PrBoom the baseline port not showing the slightest interest it was the major obstacle here.

The people who really lost out here are not the ZDoom users per se. It's the players that love some slightly advanced stuff which isn't done in sufficient quantities because it's either ZDoom only (perceived loss of market share) or would require a lot of redundant work to support the different port, so anyone wanting to target the demo scene is out by default and as to restrict themselves to the 20 year old Boom standard.

 

Why does that bother me? Actually quite simple: These early generation ZDoom maps are some of my favorites but the Boom ecosystem is not particularly conductive to producing them, as the Megawad(TM) seems to be the holy grail of mapping, because that's the only natural progression the engine supports.

 

 

 

Share this post


Link to post
1 hour ago, Graf Zahl said:

A classic case of reading something and understanding something entirely else.

 

Let's take this apart.

 

Why do I consider PrBoom an obstacle to progress? Actually it is because all its developers have been extremely conservative when it came to accepting new features - even in places where it really would have made sense to branch out a bit, like abolishing the hard coded level transitions.

Now, why is this a problem? For the simple reason that as a result of no baseline port ever bothering with this stuff there is no reference implementation. Every port has cooked up its own incompatible method. If you want to use any of this you have to jump through hoops and provide ZMAPINFO for ZDoom, EMAPINFO for Eternity and a MAPINFO for ZDaemon, and if you want to branch out futher, DED for Doomsday and DDF for EDGE/3DGE.

The result of this chaos? I only know two mods which went all the route to do this for at least ZDoom and Eternity, but they both still restricted themselves to Doom's original level progression. (The two mods were Valiant and Ancient Aliens, btw., which had an episode selection menu on these ports.)

 

The same problem exists with actor definitions. No baseline implementation exists, so everything has to be duplicated, triplicated etc. for each port supporting such a feature - again, because everybody did their own separate implementation, partially because of NIH and partially because the competitors were deemed insufficient or incompatible with the engine's goals.

 

And say what you want - having 4 or 5 ports do the same thing differently with no common ground is just a losing proposition. The end result of this is that ZDoom gobbled up all the market share in the advanced segment with absolutely no coordination going on on the lower tiers to provide something more universal. And with PrBoom the baseline port not showing the slightest interest it was the major obstacle here.

The people who really lost out here are not the ZDoom users per se. It's the players that love some slightly advanced stuff which isn't done in sufficient quantities because it's either ZDoom only (perceived loss of market share) or would require a lot of redundant work to support the different port, so anyone wanting to target the demo scene is out by default and as to restrict themselves to the 20 year old Boom standard.

 

Why does that bother me? Actually quite simple: These early generation ZDoom maps are some of my favorites but the Boom ecosystem is not particularly conductive to producing them, as the Megawad(TM) seems to be the holy grail of mapping, because that's the only natural progression the engine supports.

I must admit that, at first, I did not understand what Graf meant when he said that PrBoom was an obstacle, and I fought him about it tooth and nail. But, I now understand that he meant exactly what I've been saying all along: That we should work to standardize all of these differing ways to do the same things. That's the eventual goal of all of this Boom+ spec madness. It's nice that we actually agree - it's much better than fighting :) Again, we cannot make all ports do all of the same things, nor should we. But, thing definitions? There's no reason to have more than one way to define a thing. Switches? Animated walls? Same deal. We're working on it.

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
×