[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
- To: alleg-developers@xxxxxxxxxx
- Subject: Re: [AD] NewAPI Poll
- From: Chris <chris.kcat@xxxxxxxxxx>
- Date: Tue, 21 Feb 2006 00:53:32 -0800
- Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:from:to:subject:date:user-agent:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id; b=R9/SgRDhAm7MtRjC7LdaLBtWAxUhJ2CfEZQtntEravbPc9neh6EZEo+dfW7VuUqiWuANDQ2e+PCHWlAAcejUHyWD81x0aNWpZjOzLVXESVEqgKBIQQw/sgo7pqmnfqXJxtq60z8Jhck7ebtxpxKLfqYBfbTiX5oPlC8hmcWCBkg=
Well, if you're going to take this poll seriously, then I vote state-based as
well, at least for things that aren't going to change much (eg. contexts,
target display/bitmap, etc; things like color can potentially change a lot
between calls, so I don't see a reason to make that a state).
The reason for this, my biggest one, is that the main cross-platform graphics
backend target (OpenGL) is state-based. And as I understand it, changing
certain OpenGL states can be costly, so mirroring those would be beneficial
to getting the most out of the hardware. As well, the states can be stored in
contexts, so if we run across non-state-based backends, you have the data
stored and ready to go.
Removing parameters from functions that aren't likely to change often in favor
of making them states would probably help with coding efficiency, as well.
The programmer wouldn't need to worry about keeping a bunch of variables
floating around and wouldn't have to juggle them through his functions to
keep passing them to Allegro functions when there's no possibility of them
changing.
And another, more personal, reason is that I can't stand functions with a lot
of parameters:
void al_blit(AL_DISPLAY *dst_dpy, AL_BITMAP *src_bmp, int sx, int sy, int sw,
int sh, int dx, int dy, int dw, int dh, int flags); :P