How do you fix the Tutti Frutti effect in Chocolate DOOM?

[coderamen]

I am posing the question in the title to learn more about the rendering engine. I know from reading the exceptional DoomWiki that the bug lies in R_DrawColumnInCache. What would I have to change? Also: Will this fix the Medusa effect?

[DoomGater]

Choco is made to behave as closely to the original engine as possible and so this is an intended behaviour.

Don't fix, what ain't broken...:-).

So possible answers are:
- Use another port

- Fix the Map

 

Or does the original DOS Engine play the wad in question without Tutti?

[houston]

3 hours ago, DoomGater said:

Don't fix, what ain't broken...:-).

He just wants to look deep into the code and know what's happening.

I can't offer any help myself, but here's the function you mentioned: https://github.com/chocolate-doom/chocolate-doom/blob/e96d2c2c1bf33b3367cf40d234563d7c5465b614/src/doom/r_data.c#L186

Also, jesus christ, what is that bracket style? I knew Carmack was a completely unhinged psychopath, but that's just taking it too far.

Edited June 13, 2023 by houston

[SaladBadger]

There's two types of tutti-frutti really. The kind that appears when you use a texture with transparent bits on a 1S wall or on the upper or lower textures should in theory be fixable by filling the cache with a known color value before drawing the data onto it by R_DrawColumnInCache. The other is caused by vertically tiling textures less than 128 pixels tall. R_DrawColumn is hardcoded to wrap at intervals of 128 pixels. This would require presumably a new global to store the texture height and replace the fast &127 with a generic modulo by that height.

[coderamen]

On 6/13/2023 at 2:58 AM, DoomGater said:

Choco is made to behave as closely to the original engine as possible and so this is an intended behaviour.

Don't fix, what ain't broken...:-).

So possible answers are:
- Use another port

- Fix the Map

 

Or does the original DOS Engine play the wad in question without Tutti?

I would like to learn about how Doom's rendering works, and I think this would be a great way to understand the internal texture mapping.

[coderamen]

22 hours ago, SaladBadger said:

There's two types of tutti-frutti really. The kind that appears when you use a texture with transparent bits on a 1S wall or on the upper or lower textures should in theory be fixable by filling the cache with a known color value before drawing the data onto it by R_DrawColumnInCache. The other is caused by vertically tiling textures less than 128 pixels tall. R_DrawColumn is hardcoded to wrap at intervals of 128 pixels. This would require presumably a new global to store the texture height and replace the fast &127 with a generic modulo by that height.

x & y is literally just x % (y - 1)

Most compilers make this optimization already instead of doing a division.

[coderamen]

22 hours ago, SaladBadger said:

There's two types of tutti-frutti really. The kind that appears when you use a texture with transparent bits on a 1S wall or on the upper or lower textures should in theory be fixable by filling the cache with a known color value before drawing the data onto it by R_DrawColumnInCache. The other is caused by vertically tiling textures less than 128 pixels tall. R_DrawColumn is hardcoded to wrap at intervals of 128 pixels. This would require presumably a new global to store the texture height and replace the fast &127 with a generic modulo by that height.

Also I tried memset - ing the cache and it did not do anything.

[AbeAwesome]

@coderamen You really need to consider multi-quoting and editing your posts instead of making a new reply with each new thought. Not doing so doesn't make you a bad person, but this isn't Discord or an IRC chat, this is a forum.

[Dark Pulse]

6 hours ago, coderamen said:

I would like to learn about how Doom's rendering works, and I think this would be a great way to understand the internal texture mapping.

Have you read Fabien Sanglard's book, then? 400+ pages of Doom technical info and breakdowns.

Edited June 14, 2023 by Dark Pulse

[coderamen]

5 hours ago, AbeAwesome said:

@coderamen You really need to consider multi-quoting and editing your posts instead of making a new reply with each new thought. Not doing so doesn't make you a bad person, but this isn't Discord or an IRC chat, this is a forum.

I am new here and this is my first thread.

[QuaketallicA]

Stupid question: Isn't Tutti Frutti an old rock 'n' roll song? What does it mean in context of Doom?

[AbeAwesome]

1 hour ago, coderamen said:

I am new here and this is my first thread.

That's why I said it doesn't make you a bad person. I was just letting you know for future, since a lot of people who are used to faster flowing platforms don't understand forum etiquette.

 

1 hour ago, QuaketallicA said:

Stupid question: Isn't Tutti Frutti an old rock 'n' roll song? What does it mean in context of Doom?

It's a visual bug/oversight in the original engine.

Edited June 15, 2023 by AbeAwesome

[Shepardus]

Here is what Crispy Doom does (sourced from MBF); perhaps someone else can explain it.

[Classic SSG Enjoyer]

As far as I know, you can't fix this bug in Chocolate Doom because this bug occurs in OG Doom and Chocolate Doom's intention is to emulate the original Vanilla behaviour as closely as possible.

[Ramon_Demestre]

20 hours ago, coderamen said:

x & y is literally just x % (y - 1) 

Most compilers make this optimization already instead of doing a division. 

 

This only works if x is positive and y is a power of two.

if x is negative then the remain is negative, because of strange american-style math were rounding is made UP for negative numbers and down for positive numbers.

So the only case the optimization can be done is when x is declared as unsigned or when the compiler can guess that x will always be positive.

However when you use %128, you can use shift right for the division so the performance hit is minimal. Also when using x % FIXED_number then the division can be optimized to a psedo-inverse multiplication.

i386 ASM example: https://godbolt.org/z/oEbc1cG89

With the old i386 it was important to squeeze as much performances as possible from the CPU so id used a fixed power of two for the texture height.

Using a value depending on the actual texture height would be slower as it would force to make the actual division, because you do not know in advance the texture height. Of course on newer CPUs it is a non issue.

 

I would suggest you try for to remove the bug from chocolate-doom, it would be a nice exercise, of course it will never be merged in the main choco repo because chocolate-doom tries to emulate vanilla bugs.

[SaladBadger]

6 hours ago, Shepardus said:

Here is what Crispy Doom does (sourced from MBF); perhaps someone else can explain it.

This appears to only fix the tutti-frutti generated by tiling textures that aren't 128 units tall, using something similar to what I mentioned (though by replacing R_DrawColumn entirely with a much more optimized version that Lee Killough wrote). Though Crispy may have another solution for the using a masked texture on a 1S wall case. It uses an & for textures that are powers of two, but avoids using a modulo for textures that aren't, since doing that divide would probably have been slower.