3DOlogic

 I was recently watching the progress with OpenLara on the 3DO and several people trying the alpha demo discovered sudden rare hickups/locks in the rendering. The original developer realized this was coming from the use of superclipping feature and that reminded me my recent discovery that feedback CEL textures with LRFORM flag will lock if superclipping on them is enabled while they cross certain edges of the screen. However, the developer of the port claims that the textures are regular 4bit palletized and not the 16bit framebuffer format. And the hick ups are rare there, if they were LRFORM then almost every frame would be locked to 1FPS. There is something wrong happening with the rendering of few CELs, as far as I know invalid CELs or other bugs can lock the rendering forever, and there is a timer value of exactly 1 second that can also be controlled from a function (but we don't need to), where if something went truly wrong and a DrawCel doesn't return at that time, the r

 I've been recently trying to do a demoeffect where I render a 3d cube in a backbuffer and have another CEL with the LRFORM flags on to capture the region of the framebuffer and render it in the visible screen as a zooming sprite. And I fell upon yet another hardware bug that of course doesn't replicate in any emulator. When the zooming CEL sprite grew so big that it touched the edges of the screen on the right side, suddenly the frame rate would reach something like 1FPS. This is not a performance issue, but a sudden lock of rendering when as I realized, enabling super clipping on an LRFORM CEL is problematic on the real hardware. I don't know why, but this is what I found after burning few more CDs to try various things. I have talked about super clipping before, and it's a flag (or two) in a CEL that will enable faster clipping/early termination functions when a CEL polygon is clipped against the screen edges. Depending on the side it clips (left-right, up-down)

 There are a series of CEL flags with the LD prefix that I hadn't properly used before. Except one that seemed to be the only one working, the LDPLUT . In fact, I phrased it wrong. When you use CreateCel  to make a new CCB, all these four flags, LDSIZE , LDPRS , LDPIXC and LDPLUT are enabled by default. It is when you decide to disable them that things go awry! I have (ab)used  LDPLUT  in OptiDoom once (although I may have removed this trick in recent versions as some refactoring for speed made it not practical to use it anymore) when a wall segment will send individual CELs (in a linked list) for each column of a wall. So if a single wall is covering the whole screen, 280 CCBs will be passed (in reality Doom has a bigger array fed with various different elements that is only send and flushed when it reaches the max). Since a wall uses a palletized texture that is the same for every column, why every CCB has to be fed with the palette pointer and the hardware has to reload the same

 A very basic feature that for some reason is disabled by default, is that of additional CEL clipping hardware functions. The 3DO will clip the rendering against the framebuffer (or a smaller clipping area if you define it with certain functions) so pixels will never be rendered outside the screen and corrupt memory. However, it does so by continuing the costly interpolation and checking pixel after pixel, finally discarding the rendering of it if it falls out of screen borders. This is called Normal Clipping in the documentation. But little did I know as I was coding some homebrew stuff that very big CEL quads that fall partially or fully outside the screen, like a 3D stars zooming effect with big blobs would sometimes sharply drop down the frame rate as some of the stars came too close even if they were projected outside of the screen (and I was lazy to check that with the CPU back then). By the time I managed to enable the super clipping functionality, everything became much smooth