Index: [thread] [date] [subject] [author]
  From: Andrew Apted <ajapted@netspace.net.au>
  To  : ggi-develop@eskimo.com
  Date: Sat, 18 Jul 1998 12:41:07 +1000

Re: ggiSetFlags patch (was Re: triggered some probs with libAA-target)

Marcus writes:

>  > -       int (*dummy_miscman[2])(void);  /* Place holder */
>  > +       int (*dummy_miscman[1])(void);  /* Place holder */
>  
>  Uh-uh, running out of space here...
>  As we're breaking everything now anyway I propose that we add
>  new dummy entries so that each dummy-array is at least 5
>  entries long. Agreed?

IIRC the plan was to drop the various function tables and have one big
function table (where presumable we just add new stuff onto the end).

Is that still the plan ?

>  > 2. I don't think it's proper for ggiSetFlags to go in generic-stubs.  So we
>  >    just require targets to include this code if they don't do anything
>  >    special with the flags (like they do with other misc management stuff):
>  
>  Hmm. The purpose of the generic-stubs library is to provide all functions
>  that's possible, and the default ggiSetFlags() is highly generic.
>  As most targets will use the generic version I don't see why it shouldn't
>  go in there.

I also think generic-stubs will do.  The only problem I can see is that
some targets like to set up certain function pointers at GGIdlinit time,
whereas generic-stubs is loaded at GGIsetmode time.  No biggy.

Also (a bit offtopic) the color-mapping code should be removed from
generic-stubs once and for all, because it is highly mode-dependent
(nothing generic about it).  Any objections ?

Cheers,
_____________________________________________  ____
                                               \  /
  Andrew Apted   <andrew@ggi-project.org>       \/
  

Index: [thread] [date] [subject] [author]