Speaking about the framerate, how could i lower it so i can do more stuff ?
I personally tried to do that but all i got are flickering blocks, just like before...
It honestly looks like they are drawing to a framebuffer but i could be wrong...
If 3DO is right then we should have cels of a size of 8x240 filling up the screen and draw on them :
it should be faster apparently than one huge cel of 320x240...
Hmm... Frankly, I'm not sure. At first, I'd think that you'd be able to do as much as you wanted per frame, it would just go slower, but maybe 3DO did something in the OS to cut off frames that were taking too long. Maybe their update/game loop is separate from their draw loop. Since you are getting flickering, it could be trying to render your stuff before it is done writing the frame to the buffer (another reason I'd like to have control of my own backbuffer. I'd be able to release it when the frame is ready, not while some of my stuff is still drawing). There might be a variable somewhere for it, but I don't know right now.
Aer Fixus wrote:
p.s. Of course this is beyond us right now, but isn't the OS loaded from the CD? Is it theoretically possible to access the GPU without utilizing the CEL engine?
I heard it was difficult but possible to bypass the OS, but i'm honestly not sure the benefits of doing so
because it's not like the OS was as bad as the CDI's one. (where bypassing it was necessarry for less input latency)
Yes, it is loaded from the CD ; everything is in the System folder.
This is also where it loads the system fonts. (Kanji)
And this is also the reason why it takes so long to load a game on startup.
Another reason to have a custom OS: just make something lightweight that does what we need it to do, nothing more. We don't need much for a functioning game, especially basic 2D ones. Loading all the 3D libraries just seems unnecessary for our projects. Plus, I'm not sure how much I trust the CEL engine. According to Burger Becky, they had memory leaks in String, so I'm not sure how much of the OS works as well as it could. In addition, it wasn't complete (at least not what we have access to). They were continuously updating it. The documentation even says that some stuff will be made better in the next version, or removed or what have you. That means that there are definitely things that aren't optimized like they should be.
And given the specs, I really think the system should be better than it is. And I think the OS is partly holding it back and adding bulk we don't need, but I could be completely wrong. In addition, if we gained access, we could send calculations to the GPUs that just can't be done on the CPU (think of the shaders!)
Also, If we gain access to the hardware, we open up so much! We could directly interface with the serial ports to make custom peripheral adapters, like memory cards or network adapters (once again, this is just as far out there as using a custom OS, but people have made network adapters for the NES). Something I've noticed is that the system resets when the eject button is pressed. If that's an action that the OS controls, it could allow for mid-game disc swapping for some cool/useful stuff (Vib Ribbon comes to mind).
All this said, I think figuring out loading and playing sound effects is a high priority thing we can reasonably try to figure out in the near future.