Hi,
On Mon, 6 Dec 1999, Christopher T. Lansdown wrote:
> > sleep() gets interrupted by signals (and GGI uses a signal to synchronize
> > the screen). A better way to handle this would be to call the
> > graphics target's "wait" function (which also reads mouse events and
> > updates the pointer position)
> Possible. Would ggi process events so that we'd get them queued up,
> or what in its delay function? Are you sure that it has one, btw?
I don't know how GGI handles event processing internally, but the API
interface uses a function very similar to select(). I consider that to be
a Good Thing.
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).
> > Doing a few memcpy()s and calling s->gfx_driver->Redraw() should suffice.
> Ok. I'll look up what to do in a little bit (probably the next week
> or so). For the moment where should I put the empty function sci_malloc()
> (which right now would just be a pass-through to malloc())? I mean so that
> anyone who does coding can use sci_malloc instead of malloc and when we add
> the functionality, it will automatically be there.
We need a new file for that, maybe "core/tools.c" or something similar.
This file should also contain the getInt16() implementation for big endian
machines and the memtest() function (which is used sporadically for
debugging memory corruption- it's not used anywhere right now, though).
> > Sounds good. Writing to stderr wouldn't help in fullscreen mode, after
> > all.
> That's what I was thinking. And it wouldn't help people who launched
> freesci from a menu or a gnome button, etc.
> Probably wouldn't hurt to print it out. A question or two:
> 1. Does ggi have rectangle and text drawing 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.
Just draw the image to s->pic->view (which points to the 320x200 bytes
area containing the graphics) and call
s->gfx_driver->Redraw(s, GRAPHICS_CALLBACK_REDRAW_ALL, 0, 0, 0, 0);
for the changes to take effect.
The graphics subsystem, as you can see, isn't optimized for peak
performance right now. Since we're getting close to having all of the
graphics stuff documented sufficiently, I'd suggest a complete re-design
of the graphics subsystem for 0.3.x; my suggestion would be to make it
look like this:
/SCI engine/
|
V
/Widget set/ <----> Widget buffer (for save/restore)
|
V
/Graphics API/
|
V
/GFX driver/
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.
> 2. Is there an online programming manual/tutorial for ggi like there is for
> gtk?
There is an API reference somewhere at the http://www.ggi-project.org
site, similar in quality to the glib one. I don't know of any tutorials.
They've got man pages, though.
> 3. What do you think about realloc()? Should that be handled in the code or
> should we have an sci_realloc() that does the same sort of thing as
> sci_malloc()?
If we have sci_alloc(), we need sci_realloc() as well- handling this in
the code would require that code to take care of the "low memory" window
manually.
realloc() could still be used, though, like this:
newbuffer = realloc(buffer, bufsize * 2);
if (newbuffer) {
bufsize *= 2;
buffer = newbuffer;
} else
buffer = sci_realloc(buffer, ++bufsize);
Maybe "int sci_realloc(void **buffer, int newsize, int block_if_lowmem)"
(takes care of *buffer, blocks on low memory if (block_if_lowmem), returns
0 on success, returns 1 if (!block_if_lowmem) and out of memory) would be
a nice way to handle this, too; after all, you wouldn't have to use a
"newbuffer" as in the example above...
llap,
Christoph
