BTW, same story with PS1 releases - The Lost Levels for GZDoom PSX TC is not real thing but GEC Master Edition does for PS1 hardware. Phoenix Doom is good, but it's an imitation like GZDoom PSX TC is imitation of real PSX Doom. The question is about possibility of the real 3DO hardware to handle Doom in better way than before. I could not be right, but I don't think he meant this. I kinda understand how this one works visualizing the pixels in my mind, but can't think of a better way of doing it. But I wonder if there is a better algorithm for the conversion from vertical to horizontal edges.

That's also why the flat visplanes without depth shading are way faster than the shaded untextured ones.Īnyway, still looking at it from time to time, at some point I'll change strategy and try to replace visplanes. Previously, when in my flat color visplane rendering I skipped this conversion and only drew vertical lines, at the same times I of course avoided the calls to MapPlane. I start wondering if there is less of a bottleneck here and more in the things happening in the later call to draw scanline (in MapPlane). All fit in registers, an ADD to increase, a CMP and a branch. I ask the compiler to display the produce ARM assembly code and man, it seems like it's pretty tight. So, I thought I could find something here (and I can still bother to try porting the other versions and measure (sometimes they do it with a while, sometimes with if, don't know which produces better code)) but it seems the 3DO programmer did the best to produce the optimal compiler code. While the others (chocolate doom, etc) are doing two checks in the inner loop (e.g. while (t1 < t2 & t1<=b1)) the 3DO code has some more if blocks, which however do these checks externally and ends up with a Count, it only increases it and does one check instead of more in the final loop. (and I haven't tested yet by converting the other codes, I need to be careful as it's a confusing code) the 3DO version was optimized to be doing less in the inner loop. I was surprised the versions in the other ports look more clean and short than the one on 3DO (the big do-while loop in DrawVisPlane)Īnd I thought it should be slower, but looking it closer, algorithmically it seems to be doing roughly the same think as the others (comparing top bottom gaps from left to right, depending on inclination it will either mark horizontal edges or call to render a horizontal scanline)īut maybe, maybe. The one that converts vertical visplane gaps to horizontal edges. Interestingly enough I was looking at the source codes of GBADoom and ChocolateDoom for the R_MakeSpans function like here

3do emulator mac