Re: [pygame] Further standardizations

["ShredWheat" <shredwheat@mediaone.net>]

> - right now I guess we're doing new_rect() instead of Rect(), but
> we're still doing pygame.font.font(). Should it be new_font() instead?
> Actually, now that I'm writing significant amounts of code, I'm
> starting to come around to the Rect() idea instead of new_rect() -
> it's embarrassing, since I recently kind of argued for the opposite :(
> The capitals sure make it easy to see my constructors at a glance,
> though.

heh, i've flip-flipped on many things like this already. most of 
them before i wrote the code since it's a little harder to change
directions once code is out there.

well, the font function does need to be changed. i still have been
trying to find a good solution to this constructor problem. you can
always put "Rect = new_rect" in your code, but it would be a lot 
nicer if everyone's code was consistent. i'll dig through the code
and get all the 'constructor-like' functions in a list. perhaps
seeing them all with a column or two of name-options things might
be easier to decide on. i'm not opposed to switching them again
at this stage.


> - There's ambiguity about rgb tuples vs. color numbers. For example,
> surface.fill() uses a color number, while font.render() uses a rgb
> tuple. Could we settle on a specific alternative? Personally, I prefer
> the rgb tuple; it's just more intuitive.

yeah. the font constructor doesn't use a surface image, so the color
cannot be mapped before it is passed. as ray noted, using premapped
color can speed things up. most of the color-needing-functions are
either intense enough (fill) or only needed once (set_colorkey) so
the color lookup would not be too noticeable. the only function
that might be used in a tight loop is "set_at()". i could experiment
and see what the performance hit actually is (on colormapped and non-
colormapped surfaces)

anyways, the RGB tuple is a lot more untuitive. i think the idea of
switching all the functions to use RGB[A] is a good idea. i'll put
that on my list. if set_at() becomes too slow, it would not be hard
to allow it to support both types, but that will come at a later time.

if the user wants to speed things up a bit by using packed/mapped
color numbers they can always use the surfarray module, which is a
lot quicker than set_at/get_at anyways.



____________________________________
pygame mailing list
pygame-users@seul.org
http://pygame.seul.org