Freedoom 1.0 will be vanilla-compatible

[chungy]

Okay, this is probably going to get me burned at a stake, but I'm going to make this a 1.0 release goal, that all three IWADs in 1.0 will be vanilla-compatible. FreeDM already is, so this is a target changing for Phase 1 and Phase 2.

Freedoom from its inception has always targeted Boom. It was assumed that Boom was a reasonable common ground for port support and targeting it would assure wide-spread compatibility for the project. This has largely been true, but there's always the exceptions. Certain versions of Doom Legacy, Doomsday, Vavoom, and a few others seem to get tried for running Freedoom, and usually the beginning levels are fine, but there's always some level in the middle of the game the engines just won't handle the Boom extensions on, and a crash happens. Freedoom gets blamed instead of the engines, and players don't understand what "Boom-compatible" means. We have been recommending Odamex on our download page, but this isn't quite enough to avoid these happenings, and it's not right to blame their choice of engine, either.

One of the founders of the Freedoom project, fraggle, even started up a source port a few years later that has some good recognition in the Doom community: Chocolate Doom. This port is a hardcore replication of vanilla Doom, limits, bugs, and all. It may possibly be the only port of significant value that wouldn't be able to handle even a limit-removing re-target (though many one-off console ports just base directly on Linux Doom and would be affected too). It does present a nice niche for Freedoom's free software philosophy and tradition: no proprietary software will be required to test Freedoom's vanilla compatibility, and no obtuse DOS emulation would be required either (which Boom does, and results in issues like C3M7 being incompatible with Boom because nobody bothered to test in anything but PrBoom).

Mappers might, understandably, be upset and taken aback by this announcement. I am sorry for any potential ones that do not want to target vanilla. It really is much harder to make a vanilla-compatible map than limit-removing or Boom-compatible maps. But there is a bit of good news for any that are actively editing maps and don't like this announcement: I said that Freedoom 1.0 will be vanilla-compatible. I'm giving some leeway for Boom maps to still be accepted as present, and it's possible any releases in the interim will not yet be vanilla-compatible. We can rework maps. It would definitely be nice to start targeting now, but if you feel it's too much work, keep going your course for the time being.

[Danfun64]

As long as the BEX string replacements are kept, I am all for this change!

...though maybe as many strings as possible should be converted to vanilla dehacked for maximum compatibility.

[chungy]

BEX will still be used. It provides a nice property in that no copyrighted/trademarked strings from Doom are necessary in order to make text replacements (and it's overall a nicer format). Even Chocolate Doom supports loading Freedoom's BEX patch :)

[Danfun64]

...I don't know what to say...but this is going to be awesome!

[Breezeep]

I'm not really sure how I feel about this. I've heard that some of the maps seem to go overboard with the seg count. I personally think this should be vanilla limit removing compatibility for the time being. Also, Odamex? Honestly? That thing's not even being worked on anymore.

[Blastfrog]

I'm quite glad for this move. It will maximize compatibility, and that's not a bad thing. Too many high profile ports that don't support Boom functionality to justify using it.

Danfun64 said:

...though maybe as many strings as possible should be converted to vanilla dehacked for maximum compatibility.

Agreed, not a bad idea.

[fabian]

chungy said:

I'm going to make this a 1.0 release goal, that all three IWADs in 1.0 will be vanilla-compatible

Yay! \o/

[Danfun64]

One more thing. Will Boom effects that don't affect vanilla compatibility, like coloured lighting, still be used in the vanilla maps?

[raymoohawk]

will we still be able to add aditional textures or not? either way i'm fine with this decision

[chungy]

Danfun64 said:

One more thing. Will Boom effects that don't affect vanilla compatibility, like coloured lighting, still be used in the vanilla maps?

I think I'm ok with this, but be wary of the behavior in other ports, and don't make your map depend on it.

raymoohawk said:

will we still be able to add aditional textures or not? either way i'm fine with this decision

Yes.

[Blastfrog]

Danfun64 said:

One more thing. Will Boom effects that don't affect vanilla compatibility, like coloured lighting, still be used in the vanilla maps?

Personally, I'd rather extra effects not be used even if it doesn't break compatibility, because the experience would be different between engines.

Slopes are an example of something I want to see completely removed.

Your thoughts, Chungy?

[Danfun64]

Considering slopes aren't even a boom feature, I don't think freedoom maps ever had them.

[Doctor Nick]

Danfun64 said:

Considering slopes aren't even a boom feature, I don't think freedoom maps ever had them.

Map07 does, on the stair railings. It's a zdoom hack. It shows up as flat in boom.

[raymoohawk]

it would be kinda cool if it there where slight diferences depending on the sourceport, could encourage the player to try out diferent source ports

[Blastfrog]

raymoohawk said:

it would be kinda cool if it there where slight diferences depending on the sourceport, could encourage the player to try out diferent source ports

That makes no sense. It's not an in-game challenge, it's a simple choice of program.

[funduke]

chungy said:

... I'm going to make this a 1.0 release goal, that all three IWADs in 1.0 will be vanilla-compatible. ...

I would highly welcome this.

Greetings
Funduke

[HorrorMovieRei]

As much as I love the idea of making Freedoom vanilla compatible, I'm also worried about how this will affect the gameplay and aesthetic of the maps. Mainly because of the 128 visplane limit of vanilla doom.

[raymoohawk]

btsx and dtwid are vanilla and they look and play real good

[Linguica]

Just make dtwid / d2twid the offical maps, sheesh

[Blastfrog]

Linguica said:

Just make dtwid / d2twid the offical maps, sheesh

Each contributor whose stuff made it in would have to sign off on that. Besides, we're trying to get away from being "Doom-like", not more.

[frithiof]

We must take this heretic and burn him to death!

Ready your torches, comrades!!

[Gez]

This makes me more interested in the idea of a fork.

[RestlessRodent]

This is welcoming.

As for limit removing and not limit removing, there are many projects that are highly detailed yet run fine in Doom usually due to new tools (such as Chocorenderlimits) that make it easier to find such issues.

[Jewellds]

While I have my reservations, I can see the majority are for this. Having everyone united towards a common goal is the most important thing for the project. This is a great opportunity to put real effort into tightening up some of the project's more ropey maps.

Based on the crude method of running both iwads in Chocolate Doom, running around with no clip on and waiting for a crash, Phase 2 is affected by this decision more than Phase 1. This is good as IMHO Phase 1 is the strongest set overall.

[jerk-o]

Would it be possible to sticky this thread?

*Edit: Since most (all) of the maps are going to have to be checked to see if they're vanilla compatible, what would you think about having a sticky mention what monsters and/or weapons are allowed on each level?

[andrewj]

On the one hand, I do like the idea of the Freedoom IWADs being a "drop in" replacement for the originals, and hence working in vanilla Doom.

On the other hand, making maps is so much harder when having to be worry about visplane overflow, drawseg overflow, and also savegame buffer overflow (which limits how many things can be on the map). Plus the reduction in mapping features.

But projects like BTSX prove that high quality maps that work in Vanilla *are* possible. So I'm sure that, at least eventually, Freedoom will contain a full set of good quality vanilla-compatible maps. I hope to contribute to help make that happen.

[esselfortium]

FWIW, I think most vanilla projects since around the time of Alien Vendetta in 2002 tend to ignore the savegame limit because saving isn't strictly necessary to a map's completion (yeah, yeah, I know) and because, more importantly, there's no reliable way to test for it, since mobj count can vary dramatically throughout a level as things are spawned, picked up, resurrected, dropped, and so on. (Projectiles count towards this as well.) Chocolate Doom even has an option to extend the savegame limit because of how rarely it's respected.

All the other vanilla limits are generally pretty straightforward to work within, especially with all the tools we have at our disposal nowadays, but the savegame limit is a huge can of worms to open, haha.

[fraggle]

Maybe you can implement this in stages across a couple of releases, eg. stage 1: all levels changed to be limit removing (eliminating Boom features); stage 2: all levels vanilla compatible (fixing vanilla incompatibilities). Could make for a couple of targetable milestones.

[Catoptromancy]

I think a megawad should be released of the current maps. Many current maps are way to big to trim down or too detailed to nicely trim without massively altering. A completely new mapset would be best. Would do best with a project leader and defined goals for theme and gameplay.

[chungy]

Sodaholic said:

Personally, I'd rather extra effects not be used even if it doesn't break compatibility, because the experience would be different between engines.

Slopes are an example of something I want to see completely removed.

Your thoughts, Chungy?

raymoohawk said:

it would be kinda cool if it there where slight diferences depending on the sourceport, could encourage the player to try out diferent source ports

I think I'm going to have to agree with Sodaholic. We can make impressive-looking maps within the vanilla restriction, many projects from the earliest days of Doom modding to today prove as much. Plus, showing off ports is best done with port-specific mods :)

GhostlyDeath said:

As for limit removing and not limit removing, there are many projects that are highly detailed yet run fine in Doom usually due to new tools (such as Chocorenderlimits) that make it easier to find such issues.

I think I can recommend Chocorenderlimits as a port to test with and assist with trimming down limits. :D

fraggle said:

Maybe you can implement this in stages across a couple of releases, eg. stage 1: all levels changed to be limit removing (eliminating Boom features); stage 2: all levels vanilla compatible (fixing vanilla incompatibilities). Could make for a couple of targetable milestones.

I kind of want to see how it plays out immediately, but yeah, I kind of hinted at something like this in the opening post. I wouldn't mind 0.11 remaining Boom-compatible if the need arises, but trimming things down to limit-removing then vanilla does make a lot of sense.