3DOlogic

Never copy a file in the CD that is longer than 32 characters (filename + extension). I did just that with some exported CEL files without renaming them to a shorter form first and code that was loading some shorter files that happened to come later in alphabetical order just failed to load. It's like the longer files had put a stop in whatever file loader was searching through the directory till it found the one file I requested to load. My code never touched the new long files I just copied naively in the same data folder inside the CD. It would only try to load a file that happens to come later alphabetically from the new files added. To keep things short, I have a video displaying the issue. I don't even know if this bug was known or if there is something in the official documents describing the issue and suggesting you keep your filenames short. At least 32 characters are much nicer than 8.3 in DOS :P

Long time ago, I had watched the Atari Jaguar demo Facts ( https://www.pouet.net/prod.php?which=50467 ). It was boasting the power of the Jaguar using the object processor to push as many sprites as possible. I was quite impressed back then and wondered whether it will be possible to do the same thing in 3DO. I started a project loading an image similar in size and bit depth as the one in Jaguar, but this time it was a different animal. Assuming the mascot of the 3DO is a gecko lizard. The total image size is 192*160, it's in 16bpp and broken into pieces of 4*4 pixels, totalling 1920 sprites. For now I tried to implement the second part of the Jaguar demo btw, I could try the spirals part in the future. The result of my attempts is here, now reaching 80fps when vsync is off! But it wasn't the case initially. The earliest performance was 40fps. The animation code running on CPU would go over it alone at 109fps (when disabling the rendering of the CELs but still repositioning th

 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

Since I don't have any other writing outlet, I decided to open this blog and start all over again. Previously, I'd post small things related to my 3DO experiments on twitter, but a decision to quit twitter (and facebook, something that I didn't regret), my posts on things related to 3DO coding or previews have disappeared (and twitter wasn't a good medium about it anyway). Meanwhile, I had deleted some other very personal blogs I had and decided to get out from most of social media, except youtube of course. A blog gives me more of an opportunity to type more than what twitter typically allows, present code snippets, interesting tidbits about 3DO, previews and news of what I am working with, without being restricted and without being lost in the addictive but depressive nature of other media. I'll be writing things just for interested people to read. I might be posting links to some interesting articles on our discord. I might even try to post animated gifs or links