I think SDL is not a so good idea

[Lee Salzman]

Definitely do NOT use svgalib. Use SDL! If the idea is to run over Linux
and Windows, then use the best libs for that. The OS stuff is entirely
separate and is more of a side project of mine.

Lee

On Sun, Oct 10, 2004 at 03:13:22AM +0000, Paul Dufresne wrote:
> Tril said:
> >I suggest SDL (simple directmedia layer) [1]; it's portable, runs on
> >"Linux, Windows, BeOS, MacOS, MacOS X, FreeBSD, OpenBSD, BSD/OS,
> >Solaris, IRIX, and QNX" [2] and supports at least X11, svgalib, GGI,
> >and aalib graphics output.
> >
> >1. http://www.libsdl.org/
> >2. http://www.libsdl.org/faq.php?action=listentries&category=1#54
> 
> Well, at first, I did really like your suggestion. In fact, I now remember
> that it was suggested in previour IRC logs.
> 
> But seeing problems that Pupeno seems to have with sharing structures
> between C and Slate, and novo suggesting that he should wait for
> FFI (Foreign function interface I guess), then I am not sure SDL is right
> for the moment.
> 
> The philosophy of Slate seeming to be, "we'll rewrite everything in Slate, 
> even
> the OS", I guess, we should keep a very low-level stuff, like svgalib, or 
> even
> extract the Vesa driver of svgalib (svgalib have it's own drivers for the 
> main
> graphic cards).
> 
> SDL is running over DirectX or GGI or X then, maybe it is too high-level.
> I am afraid people will get use to current SDL way of doing, but all (I)
> want, is to give very low-level access to graphics, to let Slate build a
> gui over.
> 
> svgalib seems reasonable to be rewritten in Slate (850k sources),
> and it is reasonable to begin with just the Vesa driver.
> 
> It's still unclear how we draw stuff with SDL (it's seems to be some kind of
> plugin to do so). Also SDL seems to use a strict by events stuff, and I 
> expect
> Slate to build it's own event mechanism.
> 
> So my idea, is to keep with very near the machine stuff.
> 
> But this give me the portability problem.
> 
> Somehow, I really don't see why svgalib would be very hard to port
> to Windows or an other OS. Or at least, part of it.
> 
> --Paul
>