Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
Sign in to follow this  
Uncle 80

What does "donut overflow" mean?

Recommended Posts

Noticed this image in another thread, and a "donut overflow" bug is something I've never heard about (and can't seem to find any info about searching the forums or using google).

I'm wondering if anyone can tell me what this bug is and how/when it is triggered? I am of course asking because I'm making a map that has a lot of donuts. yum yum.

Share this post


Link to post

Here's some relevant code from PrBoom+:

#define DONUT_FLOORPIC_DEFAULT 0x16
int DonutOverrun(fixed_t *pfloorheight, short *pfloorpic)
{
    if (demo_compatibility && PROCESS(OVERFLOW_DONUT))
    {
        ShowOverflowWarning(OVERFLOW_DONUT, 0, "");
        if (EMULATE(OVERFLOW_DONUT))
        {
            if (pfloorheight && pfloorpic)
            {
                GetMemoryValue(0, pfloorheight, 4);
                GetMemoryValue(8, pfloorpic, 2);
                // bounds-check floorpic
                if ((*pfloorpic) <= 0 || (*pfloorpic) >= numflats)
                {
                    *pfloorpic = MIN(numflats - 1, DONUT_FLOORPIC_DEFAULT);
                }
                return true;
            }
        }
    }
    return false;
}
So apparently it's something to do with a donut not getting the correct floor picture.

There's also this in the history file:

Access violation emulation for the "S1 Floor Raise Donut (changes texture) (9)" action in demo compatibility mode. "-donut floorheight floorpic" - takes custom values, overriding the program's default values ("-donut 0xF1000000 7", for DOSBox behavior). Disabled by default.


So there's an access violation error that can happen in the vanilla code.

Share this post


Link to post

If the lowest numbered linedef of the donut's "ascending pool" sector was single-sided, vanilla Doom would read and write data at an invalid memory address and result in undefined behavior. The option "Try to emulate it" tries to emulate this undefined behavior in PrBoom-plus when the bug already happens. But to make it possible for the bug to happen in the first place, you must set "Use exactly Doom's linedef trigger model" option to "Yes".

Share this post


Link to post

Ah yes, perhaps that compatibility option is included for the rare occasion that a map depends on using line action 9 "wrong", i.e. getting the numeric model sector info from a 1-sided linedef (in which case the donut changes to the last flat in the direcotry and moves to "a strange height" according to Hank Leukarts old reliable faq)

edit: ninja'd by scifi42. Thank you both, seems I do not need to worry about this bug then, since all my donuts have a 2-s line as lowest numbered. Hugs and kisses!

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
Sign in to follow this  
×