Marnetmar Posted November 13, 2011 Some of you may have heard of the famous Medusa Effect, which was definitely a pain in the ass if you encountered it not knowing what it was. The reason I created this thread was mainly because of a question I couldn't find the answer to. When you look at the medusa effect and the game slows down to a crawl, what is actually happening causing that to happen? Does the ugliness turn your processor to stone or what? 0 Share this post Link to post
andrewj Posted November 13, 2011 Due to a bug, the engine starts drawing the contents of random memory (or the executable) instead of a texture. Textures are divided into posts which require a certain value to terminate, so it ends up drawing thousands of posts per column (instead of a couple) because the terminator rarely occurs in random memory. 0 Share this post Link to post
Koko Ricky Posted November 14, 2011 It's also called the tutti-fruity effect because of the appearance of the pixels. Seems like it's an easily enough avoided bug if you have good mapping skills, but I wouldn't know. 0 Share this post Link to post
Marnetmar Posted November 14, 2011 Actually, the medusa effect and the tutti-frutti effect are two different things. 0 Share this post Link to post
EarthQuake Posted November 14, 2011 Technically, wouldn't medusa actually generate tutti-fruttis? It certainly appears that way, with medusa drawing a lot more junk pixels. Also, can you use a multipatch middle texture with only one patch showing and avoid the bug? 0 Share this post Link to post
Quasar Posted November 14, 2011 IIRC, Lee Killough claimed once that the extreme slowdown that stems from the Medusa effect originated from Z_Malloc. I have never figured out the wherefores or whatnots involved, however. He described it as "heap thrashing". I do know some memory corruption and/or illegal reads are involved, however, as Chocolate Doom will often crash when subjected to displaying the Medusa effect. As usual, DOOM under DOS was able to commit murder that no app on a modern OS can get away with. 0 Share this post Link to post
Maes Posted November 14, 2011 TBQH I hardly ever remember seeing the effect in action, as it requires a very specific set of circumstances to occur. Perhaps the most important one is having to draw a transparent (aka not fully covered) multi-patched two-sided sidedef. If you simply draw this on a single-sided wall, you get plain old tutti-frutti (since the tiling eventually puts an end to the runaway drawing, no matter how fugly it looks). On two-sided walls, the engine is trying to draw the equivalent of a composite transparent patch, which does not exist in vanilla Doom, and is NOT stopped by texture tiling. Ports like Boom and derivatives introduced this concept (creating transparent mid-textures from multiple patches) and thus indirectly fixed the medusa effect. A good example of what could cause medusa is in cybie2 (the gridded fencing on top of the brick walls): these are actually one single transparent texture made up from multiple patches, a concept which is alien to the vanilla engine. 0 Share this post Link to post
hex11 Posted November 14, 2011 FreeDM (from Freedoom v0.7) has a good demonstration of the medusa effect: chocolate-doom -iwad freedm.wad -warp 2 Turn around counter-clockwise. If you're unlucky, the game will crash (segmentation fault), but if not there's a good chance for some heavy slowdown as you turn to face the hallway where the chaingun is located. I guess GRAY4 is a multi-patch texture? :) 0 Share this post Link to post
Koko Ricky Posted November 14, 2011 I don't think I really understand the difference between the Medusa Effect and the tutti-fruity effect. 0 Share this post Link to post
printz Posted November 14, 2011 GoatLord said:I don't think I really understand the difference between the Medusa Effect and the tutti-fruity effect. Tutti-frutti is static and harmless, Medusa is out of control and as Quasar said potentially harmful. However, I tend to call this one the more appropriate Medusa effect: Visplane overflows! I have to keep my eyes on the automap not to be bombed by them. 0 Share this post Link to post
Wagi Posted November 14, 2011 Tutti frutti effect happens when you try to make a wall texture tile vertically when it is less than 128 pixels tall. Because R_DrawColumn() ignores the texture height and instead opts to use "&127" for all of it's vertical tiling, it causes textures with lower heights to run out of bounds, reading from either junk data or the column to the right (left?). The effect you will see is that one of the iterations of the texture will display perfectly fine, while the next iteration will be shifted sideways with a column of multicolored garbage in there, and sandwhiched between the two is a row of garbage. The medusa effect is explained above. An interesting note, Vanilla doom's medusa effect seems much more random than Chocolate doom's. In Chocolate, it seems to be reading more from other, unrelated textures (with consistent coloring), whereas in Vanilla it's just multicolored snakes. Probably because the different memory layouts. Edit: I thought R_DrawColumn() would reject trying to draw outside of the screen bounds anyway. Can somebody explain to me how the medusa effect corrupts memory? Wouldn't some of that show up on the status bar or in screens[1] to screens[3]? 0 Share this post Link to post
Graf Zahl Posted November 14, 2011 Wagi said:Edit: I thought R_DrawColumn() would reject trying to draw outside of the screen bounds anyway. Can somebody explain to me how the medusa effect corrupts memory? Wouldn't some of that show up on the status bar or in screens[1] to screens[3]? I'm not sure it corrupts memory. But due to the strange way Doom's textures are defined (a post's start is always relative to the top of the texture) it can endlessly overdraw the texture and grind the computer to a halt. I think the worst that can happen is an eventual crash because it tries to read beyond the end of valid memory. 0 Share this post Link to post
printz Posted November 14, 2011 Quasar said:As usual, DOOM under DOS was able to commit murder that no app on a modern OS can get away with. What about protected-mode runtime (as in Windows 98 or even XP without DOSBOX)? Would it bomb out of Doom and display that message box in the down-right corner, with the explicit "you need to close all programs and restart your computer"? 0 Share this post Link to post
Wagi Posted November 14, 2011 Graf Zahl said:I'm not sure it corrupts memory. But due to the strange way Doom's textures are defined (a post's start is always relative to the top of the texture) it can endlessly overdraw the texture and grind the computer to a halt. I think the worst that can happen is an eventual crash because it tries to read beyond the end of valid memory. Ahh. I guess I was under the impression that invalid reads were somehow less restricted than invalid writes. 0 Share this post Link to post
Marnetmar Posted November 14, 2011 GoatLord said:I don't think I really understand the difference between the Medusa Effect and the tutti-fruity effect. The medusa effect looks much more screwed up and slows the game down to probably a frame every 5-10 seconds. This can still be replicated on DOOM95, actually. I was able to make it happen twice, but I don't have any idea how I did it and that was before I even knew what the medusa effect was. 0 Share this post Link to post
Quasar Posted November 14, 2011 printz said:What about protected-mode runtime (as in Windows 98 or even XP without DOSBOX)? Would it bomb out of Doom and display that message box in the down-right corner, with the explicit "you need to close all programs and restart your computer"? When DOOM was run under Win9x, DOS4GW would not load itself since it detected a DPMI host already loaded (Win9x provide their own DPMI services to DOS programs). Win9x DPMI is, in some ways, more strict, and in others, less strict, than known DOS DPMI hosts. Win9x is far more strict than Watcom's DOS4GW, but is known to be significantly less strict than DJGPP's CWSDPMI. I know this because many of the early problems in SMMU v3.21 and v3.30 happened because fraggle was running/testing it under Windows 98 instead of DOS. When I ran the same EXE he thought was perfect under DOS, all kinds of problems would suddenly and violently surface. With a more strict DPMI, DOOM is forced to bomb out before it can damage operating system, driver, and real-mode application data structures outside of its strictly owned pages of RAM. Otherwise "harmless" illegal reads are also treated as instantly fatal. 0 Share this post Link to post
Superfly TNT Posted November 23, 2011 When I first started mapping I used to raise floors and lower ceilings, texturing the upper and lower parts thereupon creating the effect and had no idea. 0 Share this post Link to post