I'd like to make some comments regarding Windows. It is not such a hell as
it is considered. :-)
>
> > However, you really shouldn't interface to the graphics subsystem
> > directly- the calls are encapsulated nicely (in order to
> make it easy to
> > add additional targets).
> What counts as directly? Using ggi calls or doing
> memcpy() on the
> buffer or what?
Yes, using ggi counts as directly. Unfortunately ggi doesn't work on
Windows, and thus I will have to reimplement all the ggi-using functions.
> > libggi provides rectangle fills, and libggi2d gives more
> sophisticated
> > operations. Still, using GGI directly is a bad idea, as it
> would break the
> > DirectX target.
> Oh no. Not another project with "we can't do that
> because windows
> can't do it." Can I just write the function for unix and
> stick them inside
> of
> #ifndef I_AM_IN_HELL
>
> #else
> #define sci_malloc malloc
> #endif
Well, I think it will be just enough for Windows. Anyway, if there is no
free memory at all, it's the OS itself that crashes first, not applications.
:-)
> > Yes, the "widget buffer" was your idea originally. I didn't think we
> > should to this, but since graphics need to be re-written
> anyway (it's
> > simply too slow), we'd get it as a bonus.
> Shouldn't it be something like
>
> /SCI engine/ => Widget set => GGI/Gnome/Gtk/etc.
> So that we don't have to re-implement GGI/Gnome/Gtk, etc?
> There are plenty
> of options, and even cross platform ones which work on
> windows. Is there
> really a need to re-invent another one?
GTK is a pretty good thing, but if we want games under freesci to look like
they did under DOS, we will have to reimplement the widgets, at least
partially. In my opinion, implementing the widgets from scratch is about the
same amount of trouble as redoing them on the base of GTK, interfacing GTK
with SCI scripts and so on.
> What about the SDL? Maybe that would be something we
> should look
> into as it was made for things like this and has a windows target too.
SDL is a good thing, but its major drawback is that it requires DirectX 5 or
higher. Under Windows NT 4.0 (that's the OS I'm using) only DirectX 3 is
available. Yes, Microsoft is like that.
I think that a viable option is PTC. It is also portable, and it works fine
under NT 4.0. However, I don't know how well does it support Linux.
> And your idea about openGL is a decent one too as it would work
> pretty well. It would definitely require a faster computer,
> but it would
> make resizing easier, as well as color depth independence.
> As more and more
> 3D cards are supported for Linux, this might well be fairly
> doable at this
> point. You don't need a good 3D card to get decent 2D
> performance out of
> openGL, and in many places you don't need a 3D card. I think
> that there are
> different openGL rendering modes, and there may well be a 2D one with
> textures which is faster than a 3D one using just a 2D plane.
> I'll check it
> out in my openGL book.
Actually I see no point in using OpenGL for doing graphics. The resizing and
color depth independence can be handled just nice by Hermes, pretty fast,
with very little code and no requirements for 3D cards or whatever.
