Did the original Boom have the tutti-fruitti bug?

Did the original Boom have the tutti-fruitti bug?

If so, can the latest version of Prboom+ emulate it?

Also, can Prboom+ emulate the Vanilla doom tutti-fruitti bug if you're using Prboom+ to emulate compatibility with Vanilla Doom 1.9?

phobosdeimos1 said:

Did the original Boom have the tutti-fruitti bug?

If so, can the latest version of Prboom+ emulate it?

Also, can Prboom+ emulate the Vanilla doom tutti-fruitti bug if you're using Prboom+ to emulate compatibility with Vanilla Doom 1.9?

Boom fixed tutti-frutti. I checked the location in prboom-plus where the tutti-frutti fix is and didn't see anything turning it off or complevel related, so I'm going to say no to the other two questions.


Note that while drawing garbage when wrapping a texture that's not 128 high is easy, drawing the RIGHT garbage is hard; exactly what Doom drew in the tutti frutti case was a buffer overrun and had to do with internal memory arrangement.

Emulating this would either require a large number of branches in the rendering code, an entire secondary set of column drawer routines, or possibly both.

It would slow down the rendering and complicate the code and was therefore considered unreasonable.

Quasar said:

Emulating this would either require a large number of branches in the rendering code, an entire secondary set of column drawer routines, or possibly both.

It would slow down the rendering and complicate the code and was therefore considered unreasonable.

Right, Quasar, hopefully this isn't too cheeky, but I don't want to start a whole new thread on it, but from some reading up, I get the impression that the closest emulation of the Original DOS Boom is PrBoom.

Do you know if this is the case?

phobosdeimos1 said:

Right, Quasar, hopefully this isn't too cheeky, but I don't want to start a whole new thread on it, but from some reading up, I get the impression that the closest emulation of the Original DOS Boom is PrBoom.

Do you know if this is the case?

Chocolate doom is the closest thing to original doom in a modern package. It even does tutti frutti (although it doesn't look quite the same).

natt said:

Chocolate doom is the closest thing to original doom in a modern package. It even does tutti frutti (although it doesn't look quite the same).

I know man, I said dos BOOM

phobosdeimos1 said:

I know man, I said dos BOOM

Ooops. Well you can't blame me, it was only one letter difference =p

There's a WinMBF port somewhere, don't know much about it. But you're probably right.

Of course, if you really want to test thoroughly, you can use Boom in dosbox.

There are two kinds of tutti-frutti to consider here.

One is the kind due to imperfect texture tiling (e.g. a 127 px high texture will leave 1 line of tutti-frutti because of non-compliant height), even when you use otherwide legal "solid" textures on single-sided, solid walls.

The other is the kind you get when you use masked textures on impassable/solid walls: those get rendered distorted and out of shape (the algorithm used for rendering solid walls doesn't expect to deal with masked columns at all, so it treats them as if they have enough data to fill up several solid columns in a row, reading well beyond the texture and distorting their shape).

Now, I'm pretty sure that Boom fixed the first kind of tutti-frutti (due to non-aligned tiling) by introducing an extra dc_texheight rendering variable and checks in the rendering code, so now tutti-frutti due to tiling is a thing of the past.

The second kind can only be fixed in the way ZDoom (and now, even Mocha Doom, in the upcoming v1.5 release) does: requests to draw masked textures on solid walls are intercepted, and treated specially, by drawing specially "bulletproofed" versions of those textures (by caching them beforehand on a black background and making them non-masked). I'm not sure if Boom fixed this particular problem though.

Edit:

From a quick check between various source ports with R.WAD MAP01, here are the results:

• Chocolate Doom: exhibits both tiling and masked effects.
  
• PrBoom/PrBoom+: they fix tiling, but still exhibit masked effects (so it's not a Boom fix). The end result is different than Chocolate Doom because there are large solid grey areas on the pillars.
  
• ZDoom: fixes tiling, renders masked on black background.
  
• Any OpenGL port I could try: they fix tiling and render masked on a black or (the older ZDoomGL) on a transparent background.
  

I'm not sure if prBoom/prBoom+ actually try to emulate the crooked look of misrendered masked texture in a memory-safe way, or they just cheerfully let textures overflow. It looks weird when combined with tiling safeguard though, as if there's only half-a-bug present.

Maes said:

The second kind can only be fixed in the way ZDoom (and now, even Mocha Doom, in the upcoming v1.5 release) does: requests to draw masked textures on solid walls are intercepted, and treated specially, by drawing specially "bulletproofed" versions of those textures (by caching them beforehand on a black background and making them non-masked). I'm not sure if Boom fixed this particular problem though.

Actually, nothing is intercepted. ZDoom creates a pixel buffer for each texture, masked or not, to handle different graphics formats. In such a system it makes no sense to use the original texture data unaltered.

Sadly, ZDoom still hasn't fixed the tiling of non-power-of-two textures for very questionable efficiency reasons.

Maes said:

Any OpenGL port I could try: they fix tiling and render masked on a black or (the older ZDoomGL) on a transparent background.

Of course they do. Hardware renderers need to create a system texture for each game texture and when those are used these tiling and masking issues get fixed automatically. The only potential issue is that some programmers forget to disable the alpha test for one sided walls which creates holes with HOM.

prboom-plus HOMs transparent skies, heh.

this is made slightly more amusing by the fact that the doom2 iwad has a few transparent pixels in SKY2.

kind of hard to notice though

phobosdeimos1 said:

from some reading up, I get the impression that the closest emulation of the Original DOS Boom is PrBoom. Do you know if this is the case?

What is your precise question here? If you are asking which Windows program is the closest to Boom 2.02, then the answer is Prboom 2.02, which pretty much a direct Windows port (differences: higher resolutions available; some sound issues).

The versions of Prboom after the merger with LxDoom had many issues with their Boom emulation, which have been slowly ironed out over the years. The one with best Boom emulation since that point is the current Prboom+ (or any versions since the last fix in Boom emulation, which was either the friction code, or some deh fix, I think). Though it doesn't attempt to maintain compatibility with fatal bugs or ones that lead to severe visual artifacts.

BTW, note that even "original Boom" is ambiguous, since there were versions 2.00, 2.01 and 2.02 of DOS Boom.

Graf Zahl said:

Actually, nothing is intercepted. ZDoom creates a pixel buffer for each texture, masked or not, to handle different graphics formats. In such a system it makes no sense to use the original texture data unaltered.

Hmm I kinda did this, but still keeping the Doom image format: I split the normal GetColumn into the...well, normal GetColumn (which has a dual masked/non-masked nature, and is still called by sprites) and a special "GetCachedColumn" which is instead called when rendering solid walls. This one DOES request that masked textures get cached and "solidified" in the same way that regular ones do (the two caches are separate though).

Graf Zahl said:

this is made slightly more amusing by the fact that the doom2 iwad has a few transparent pixels in SKY2.

Hmm... I wasn't aware of that. Will check to see it can potentially break stuff.

natt said:

prboom-plus HOMs transparent skies, heh.

fixed :)

natt said:

this is made slightly more amusing by the fact that the doom2 iwad has a few transparent pixels in SKY2.

Yeah, a couple of pixels right to the left of a background tower just behind and to the left as well of the tall black tower near the middle.

There's some pinkish smoke around there, so I bet the Fuzzy Pumper Palette Shop or whatever other tool they used to palettize their source image found out that the original color was the closest to index 255 (RGB 167, 107, 107). I'm pretty sure this was used as the "background transparent color" by their "image to patch_t" conversion tool.