hi,
that's probably a good idea :)
The upcomming SDL 1.3 has a new method for doing better user events...
until then, it's probably good to do something like Ian suggests -
except maybe start way higher. Perhaps have some functions for
getting events? That way your code would be more abstracted for
working with later changes. eg. FRAME_READY =
webcam.get_event("FRAME_READY") etc.
ps. do you have a url for your code repository? I've also been
thinking about starting a webcam module probably based of VidCapture,
and opencv. I think webcam support would be good for the next release
of pygame, that is version 1.9. Same with wiimote support.
I think if we include new code with pygame that requires new events,
we would increment USEREVENT, and hopefully that won't break much user
code.
That could be another approach that you take, increment USEREVENT
yourself at init time, and require your init code before USEREVENT
usage.
On Tue, Feb 26, 2008 at 7:40 AM, Ian Mallett <geometrian@xxxxxxxxx> wrote:
I really have no idea what I'm talking about. :)
If I have separate modules that must use the same set of integers to do
something, (like my solution for wxPython menu bindings), I go like this:
module number + number
1 + 1 = 11
2 + 52 = 252
1 + 31 = 131
...and so on. This ensures that the bandwidth for each module remains
reserved. All of the numbers beginning in 1 belong to module 1, like 11,
110, and 1100, all the ones to 2 begin with 2, like 21, 210, and 2100. You
could add this value to pygame.USEREVENT for each submodule.
I've never used pygame.USEREVENT, so I have no idea what I'm talking about.
This might totally work, or be completely in the wrong direction. I
apologise in the case of the latter. :)
HTH
Ian
--
There are 10 kinds of people;
those who understand binary and those who don't.
Without order nothing can exist - without chaos nothing can evolve.