Re: [AD] Display options that aren't really options

[Thomas Fjellstrom <tfjellstrom@xxxxxxxxxx>]

On June 8, 2010, Trent Gamblin wrote:
> On Tue, June 8, 2010 4:24 pm, Thomas Fjellstrom said:
> > I thought it would be a good enough solution to put things like
> > ALLEGRO_MAX_BITMAP_SIZE as part of the display option api, but its more
> > annoying than anything. when you call al_get_new_display_option, you
> > have to pass a pointer to an int you're just going to ignore, and they
> > seem to be documented under al_set_new_display_option which is
> > slightly odd, since you can't actually set them.
> > 
> > Noticed this while working on the tutorial I started on the weekend.
> 
> I think we need a specialized solution for capabilities... something like
> (consider non-display caps like number of cpus or speaker setup (which
> brings up another thing to consider, hooking addons into the capabilities
> api))
> 
> bool al_get_capability(enum CAP, void *data);
> 
> Data would be filled based on whatever you pass for CAP. Most things
> would be integers but it's possible there would be strings and maybe
> even other things we need to query.
> 
> I don't think it needs to go into 5.0, but having those display options
> "out there" is not really a good idea either if we're going to change the
> api.
> 
> Trent :n)

I don't know if a single function is good for that either. It might be 
better to split it into separate functions for different types.. Like 
display, sound, and system caps.

At some point we might want to provide cpu level capabilities like we used 
to in A4, and other low level system caps like that (thought I'm not sure 
what they'd be atm).

> 
> -------------------------------------------------------------------------
> ----- ThinkGeek and WIRED's GeekDad team up for the Ultimate
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
> lucky parental unit.  See the prize list and enter to win:
> http://p.sf.net/sfu/thinkgeek-promo


-- 
Thomas Fjellstrom
tfjellstrom@xxxxxxxxxx