Playing/testing Boom format

While Jenesis Part 1 was going through its testing phase, my mind was opened to the sheer number of bugs and nuances that certain sourceports retain from the original Vanilla engine but are fixed in more advanced ones. PrBoom+ in particular brought out a lot of bugs I failed to spot during my own testing runs. MBF practically refused to cooperate with me due to... something or other (I lost patience with it in the end).

I'm a ZDoom nut, it has to be said. I like it because it's one of the easiest and most configurable sourceports I could possibly hope to use for playing/testing anything, even non-ZDoom projects. I recently got Eternity as well and it also seems like a good advanced sourceport to use when you want ease of customization and a decently-sized array of helpful features for mappers AND testers.

However, ZDoom and Eternity are almost completely independent from any other Doom sourceport because of how advanced they've become. I know it's stupid to use ZDoom when testing something that isn't designed for it, but it can be configured quite easily to run Boom WADs like a dream, in exactly the way they were intended. And honestly, I have trouble adjusting to more constrictive sourceports, which is why I turn to ZDoom - to feel like I'm getting the easiest possible testing experience. Of course, I then pay for my stubbornness later on when I find multitudes of bugs in my Boom-format maps that have cropped up but fallen beneath my radar. :P

I don't particularly want this to (d)evolve into some kind of sourceport war, but I would like to ask you guys: what's the appeal with classic sourceports? Do you play Boom WADs strictly with Boom/PrBoom/+, or are you are more of an Eternity/ZDoom kind of guy who makes sure he's using the most modern iteration of the id Tech 1 engine that currently exists for virtually anything? And even in testing your own maps, are you the kind of person who will run something like a Boom format mapset in a much more up-to-date sourceport like ZDoom/Eternity just so you can get a familiar and comfortable testing experience, in full knowledge that you are effectively spitting in the face of compatibility? (That's me, by the way. :P)

(Obviously, I don't run things like Legacy, JDoom or EDGE WADs in ZDoom - that's just asking for a horrendous play experience. xP)

EDIT: Oh, whoops. Wrong section - this should probably be in Source Ports. x(

I use Risen3D since it is 100% boom compatible - and it just looks nice to the eyes ... ;)

I play and test everything in Eternity unless a wad absolutely requires another port to run. Nowadays it can run pretty nearly anything that PrBoom+'s software mode can handle, and the speed and rendering precision are great.

As far as Boom-compatibility goes, personally I don't consider there to be very much of a point in aiming for classic Boom 2.02 as a target port anymore.

A number of pretty significant mapping features are shared between PrBoom+, Eternity, and ZDoom/GZDoom/Skulltag nowadays. This includes MBF sky transfers, doubled sidedefs limit for large maps, ZDBSP extended nodes for even larger maps, tall patch format for big textures, and probably some other things I'm forgetting.

Chances are that very nearly anyone playing a map claiming to be Boom-compatible will be using one of those ports, so I embrace the unofficial 'Boom+' standard. (Note that I don't encourage the use of the term "Boom-compatible" here, as -strictly- it's not at all.)

I'm using GZDoom, of course, for any WAD that works with it. Fortunately there isn't much out there it can't support, especially when it comes to Boom compatible maps.

Of course I use other ports if a WAD requires it but if that port doesn't have uncapped frame rate it's very unlikely that I ever revisit such WADs after an initial playthrough.

:|

EarthQuake said:

:|

That's an odd port. Where can I download it?

At any rate, I use ZDoom by default but have gotten into the habit of testing things out with Eternity or Chocolate if they're not intended to be ZDoom-only (a very good one to get into, and absolutely CRITICAL if you plan to brand anything as 'vanilla-compatible'). ZDoom, Eternity, and Chocolate basically cover the full spectrum of Xaserian port needs. Counting GZDoom and Skulltag as part of the broad "ZDoom" category, of course, in case something needs 3DFloors or networking.

I have PRBoom+ ready too, but I don't use it much since demos aren't my thing and Eternity more or less fills the "purer-than-ZDoom" Boom-y gap for me.

Personally I exclusively use PrBoom+ unless the wad isn't compatible (e.g. a ZDoom wad) in which case I use GZDoom.

I do this because I mainly care about the compatibility with recording demos. I tend to record most of my playthroughs even though I'll never share the majority of them for not being interesting, but it's nice to know that should something interesting happen it'll be watchable in the future without any hassle.

I guess I got too used to Worms Armageddon automatically making a demo of every game, although hilarious stuff happens in that game more often than Doom.

EDIT: If a wad is stated as being "Boom-compatible" I will play it with complevel 9 (or complevel 2 if it's vanilla compatible). Personally, I kind of expect if someone says it's boom-compatible that they mainly tested it in PrBoom+ in complevel 9 rather than the actual original Boom exe, but maybe it's wrong to assume that.

Whatever the map author's source port preferences he should keep in mind that ZDoom will gloss over some serious mapping errors that can break the map in most other ports. Of these linedef specials missing the corresponding sector tags are the most common. So testing a non-ZDoom-specific WAD with ZDoom is worse than just wasting time: it gives you the false sense of security of having tested your map properly whereas you have not.

Jimmy91 said:

I don't particularly want this to (d)evolve into some kind of sourceport war, but I would like to ask you guys: what's the appeal with classic sourceports?

Their appeal is that they can do all that classic Doom needs most of the time without being too hairy. Among them there's a gem called MBF (rather, WinMBF) which while still limited, gives you some degree of freedom regarding mod customization. Eternity is based on MBF and I'm an MBF fanboy really, so I like running Eternity (which is more up-to-date and stable than WinMBF). I only run GZDoom when I need to, and that's almost always GZDoom, not ZDoom, due to almost having no flaws and being more robust in some situations (such as stacked sectors or -- newly -- 3d floors). Moreover, if the wad is designed all for vanilla, I test it with the basic executables, but sometimes I use entryway's Plus hacks instead.

what's the appeal with classic sourceports?

For me, it's accuracy and stability. I used to use only GZDoom and when I switched to PrBoom+ I slowly realised how ZDoom broke most Doom/Boom maps - by which I don't necessarily mean crashing, in fact I don't remember ZDoom crashing on me, but maps made significantly easier by ZDoom fixes or changes.

I'm not a Doom expert so it's easier to pick a port that focuses on compatibility than one that focuses on adding new features and then mess around to find the correct compatibility. ZDoom has been getting better on that recently but it's still way different on player movement, which is more important than anything else for me.

To be honest, I wouldn't care about compatibility that much if most maps that focus on gameplay wouldn't be made for Boom, but that's the state of the community.

Phml said:

ZDoom has been getting better on that recently but it's still way different on player movement, which is more important than anything else for me.

This is one thing that repeatedly comes up which I have never been able to experience. Nothing significant about how the player's movement is handled was ever changed and yet so many people claim it's different. It still used the same acceleration values, the same friction and the same collision detection. The only major changes were related to sliding against walls but those are compatibility optioned.

So I'd really appreciate if I could get more info. Without knowing what to look for I can't address this issue.

The first port I used was ZDoom. I got sold on the extra features, decals and such. I fell into the same trap as Jimmy91 - making vanilla compat maps and testing in ZDoom. I got a lot of bad feedback due to various broken tags etc so I played through in Doom95 and choked on the bug list.

When I got involved in the PCCP I decided to download PRBoom+ just for testing purposes but the more I used it the more I appreciated it's simplicity so it then became my source port of choice.

Now I primarily test and play in PRBoom+ and when the map is nearly complete I do a final test in ZDoom & Legacy (love split-screen, voodoo dolls (re)added in the latest release to significantly increase PRBoom+ compat) to pretty much cover the spectrum.

This is one thing that repeatedly comes up which I have never been able to experience. Nothing significant about how the player's movement is handled was ever changed and yet so many people claim it's different. It still used the same acceleration values, the same friction and the same collision detection. The only major changes were related to sliding against walls but those are compatibility optioned.

So I'd really appreciate if I could get more info. Without knowing what to look for I can't address this issue.

As I've said in previous topics about that, just starting Doom2 Map01 in Chococale Doom/PrBoom+ and Doom2 Map01 in ZDoom, quickly tapping the movement keys is enough to notice that's there's definite difference. PrBoom+ is more stop and go, and ZDoom is overall smoother with a gradual decrease to a stop.

Going up and down stairs in Chocolate Doom/PrBoom+ and ZDoom is also different, in PrBoom+ you fall fast and sharp even if it's a ridiculously small height like 8 pixels, in ZDoom it's, again, smoother and you keep more control over your movement. This can also be tested in the stairs of Doom2 map01 (with the two zombiemen) right next to the start.

If you want more info than that, I can't give you any. I'm a player, not a programmer. Best I can do is tell you how to replicate the (very obvious, to me) differences.

Yet another thing that I didn't mention before because it doesn't happen all that much is I sometimes bump into a monster or a wall and get pushed back in a different direction in PrBoom+. I've never seen that happening in ZDoom.

Its probably mostly demos that keep prboom+ going (in zdoom you have to download the same source port version the demo was recorded in).

One movement difference in zdoom is the 180 degree flip key:
prboom: pretty much instant flip
zdoom: a slightly slower flip. I think I like this one better because it feels more natural and less like you're cheating because it actually takes time. One problem though is that you can press the flip key while still in the middle of flipping. So if you're facing south and press the flip key twice fast before the first flip finishes, you might be facing westish or something instead of back south again.

Ability to move under floating enemies is is maybe the main prboom+/zdoom gameplay difference when playing boom wads. Also being able to punch easier with better bounding boxes. Both make zdoom gameplay a lot better.

A lot of the bad guys that are difficult/near impossible to punch in Vanilla Doom due to the blockmap actually visually look like they would be difficult to punch.

I can envisage a punch having little to no effect on a Mancubus, the Aracnotron's leg's swatting you away etc

Hence maybe the block map limitation (the quotes are deliberate), that ZDoom considered a bug, was deliberately not fixed by ID.

gggmork said:

I think I like this one better because it feels more natural and less like you're cheating because it actually takes time.

I'm pretty sure that with enough sensitivity you can turn large numbers of degrees very fast.

You know those alleged changes in movement between vanilla and ZDoom could be caused by slightly off gravity or air-control values. Graf maybe you could check these?

Vermil said:

Hence maybe the block map limitation (the quotes are deliberate), that ZDoom considered a bug, was deliberately not fixed by ID.

No, definitely not. There were 2 problems with this code and both can only be understood when thinking about how Doom developed (that's first linking each actor into only one block of the blockmap and secondly,using a cross section for hit tests.)

The first important thing is that in Doom 1, with the exception of the 2 bosses all monsters are small. So with these the error only gets noticable in rare situations. That leaves the Cyberdemon and the Spider to consider. The Cyberdemon is relatively fast and its attack is devastating so punching him requires a lot of skill - which back in 1993 nobody had - so obviously this was never tested.

Not to the Spider boss. There's a few places in the code that mention its large size and 'since it only appears once in the game' the programmers were a bit liberal with it being somewhat glitchy. They certainly knew but didn't bother then because just for the E3M8 showdown it really did not matter at all.

Enter Doom 2 now, with several new monsters, including larger ones like the Mancubus and the Arachnotron. If this had been done without the time crunch factor and whatever else enters the picture when upgrading an engine without wanting to put in any real work, some collision detection code would have had to be upgraded but it all remained in the same state that was designed for Doom 1's smaller monsters. I bet at this point in time nobody thought about the liberties taken with the Spider Boss anymore even though they also applied to those new monsters.

It's a typical corporate development situation: At some point you have to ignore a glitch due to time constraints but then later on, when it should be addressed nobody thinks about it anymore. I have lost count how many times the companies I worked for got into such situations.

Are you referring to this in p_local.h?

// MAXRADIUS is for precalculated sector block boxes
// the spider demon is larger,
// but we do not have any moving sectors nearby
#define MAXRADIUS        32*FRACUNIT

Yes, precisely that particular gem.

I assume that any monster wider than 2x32 has the risk of getting stuck with neighboring actors, like the spiderdemon often does?

Yes. And if I remember correctly that was the main motivation for ZDoom's change to this code.

Sorry to bump the thread, but this was exactly what I was looking for, and there's no conclusion apart from what essel said. So, would everyone agree Eternity will pick up bugs that Zdoom won't, so Eternity is an alternative to Prboom+ when it comes to "Boom+" Testing?

phobosdeimos1 said:

Sorry to bump the thread, but this was exactly what I was looking for, and there's no conclusion apart from what essel said. So, would everyone agree Eternity will pick up bugs that Zdoom won't, so Eternity is an alternative to Prboom+ when it comes to "Boom+" Testing?

I would not agree with that. I think that as a map creator, you have to be willing to devote a good deal of time and effort into testing; and if you say that your map works in port x, you better have tested it in port x.

The situation is a bit more complicated with "Boom+", because it's not really a port. What it does mean is that your map should work (and work the same) in a variety of modern ports that all implement the boom editing features. Well, that means you have to test your map in a variety of modern ports that all implement the boom editing features. I would say that would include at least ZDoom (because of its massive popularity), PrBoom or PrBoom+ (because it's most like original Boom), and a few other popular engines as well. Considering that it's 2011, I also think that you should test with hardware accelerated rendering ports as well and consider not acceptable any weird tricks that don't work in GL/D3D modes.

If you're only willing to test in eternity, label your maps as "eternity only".

natt: No, because then people expect Eternity features, and you get a bad rep for misleading.

I'm only having this dilenma in the first place because Prboom+ has started lagging and running with a low framerate for some reason, and it just looks so pale and colourless in comparison to, for example, Zdoom or Eternity.

Also, it needs a launcher like Eternitys'.

If you're exclusively testing Boom maps in a more advanced engine, you're much less likely to run into 'Eternityisms' than 'ZDoomisms', but yeah, unless you really know what you're doing, you should probably test your maps in whatever engines you expect people to play them in.

You could build maps intended for "Boom+" engines and warn that you only tested them in Eternity, I guess, if you hate testing, or can't run PrBoom+, or whatever.

phobosdeimos1 said:

it just looks so pale and colourless in comparison to, for example, Zdoom or Eternity.

What? You don't have the gamma maxed, do you? Does hitting F11 a few times fix the problem?

It's kind of a long shot, but it sounds like maybe you've accidentally started using glboom-plus.exe instead of prboom-plus.exe, or something like that?

Mithran, I know this is gonna sound like i'm defeating the point of asking a question, but you just gave me EXACTLY the answer I was looking for. I'm just the kind of person who needs reassurance.

Also, i'll try messing with the settings like you suggest, and i'm pretty sure i'm using prboomplus.wad but i'll get rid of the glboom+ wad anyway since I'm not gonna use it anymore (suddenly my Glboom's started lagging aswell :( )

Thanks dude, btw, when are you gonna come back to DTWID? You only made one map :(

phobosdeimos1 said:

Thanks dude, btw, when are you gonna come back to DTWID? You only made one map :(

Next month, maybe. I've got no real time for mapping right now as I'm taking eight hours of evening classes every night, on top of an eight hour workday.

phobosdeimos1 said:

Also, it needs a launcher like Eternitys'.

Why?

Gez said:

Why?

Good point, the eternity launcher works with Prboom+