These posts are from BlueCrab on several different occasions.
BlueCrab wrote:SDL is a layer on top of KOS, so it will always use more resources than just using KOS directly to do an otherwise identical program (in functionality). The version of SDL included with KOS in its kos-ports tree is known to leak memory quite badly, and pretty much every other port of SDL to the Dreamcast (that I know of) has problems.
Speed wise, SDL does everything by drawing to the framebuffer. That means, in practical terms, that you're using the CPU to do what the GPU can do for you. Also, the framebuffer itself is a lot slower to access via the CPU than main ram (especially if you're using a cached area to access it), so that can become a concern too.
Simply put, if you're developing something specifically for the Dreamcast, I wouldn't recommend using SDL. If you're developing something for both a PC and Dreamcast, I'd recommend making some sort of abstraction library yourself and avoiding SDL on the Dreamcast. I've done similar things in the past when developing cross-platform stuff.
BlueCrab wrote:Chui's SDL will not work, as it is using function calls that have been deprecated (and removed) from KOS. That is to say, it is old and very out of date. Without a bunch of updates to the source code, it's not going to work.
There is a version of SDL included in kos-ports that is much more up-to-date.
However, it is worth noting that SDL on the Dreamcast is basically junk. It is slow, leaks memory, and just generally does not work the way that one might expect. I would not recommend using it for anything, unless you really just want a super-quick port of something that already uses SDL (as a stepping stone to porting it properly without SDL).
SDL 1.x is designed as a simple framebuffer blitting system, which does not mesh well with the Dreamcast's hardware. SDL 2.x basically requires video hardware functionality that is much newer than what the Dreamcast provides (really, it's not SDL itself, but rather the stuff using it), and thus would be a pain to use even if you did have a port of the library itself.
Lack of support and performance are the main reasons I don't think using SDL is smart. Plus, to me, I'd much rather do something in KOS if possible rather than depend on yet another library; especially for something as relatively simple as control and blitting (since Doom has a software renderer).
As for avoiding OpenGL... I don't know anything about OpenGL is the main reason
. And I find the old software rendered look of Doom to be more pleasing. If getting a truer-to-form source port like Chocolate Doom or Crispy Doom on the Dreamcast works, I'll definitely look into getting an OpenGL source port like GZDoom working as well.
