Why do people still map in Boom format?

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. 

1 person likes this

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
1 person likes this

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.

1 person likes this

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. :(

 

 

1 person likes this

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)

Edited by Death Egg

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.

1 person likes this

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

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

 

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

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