Do I need to use events, or is there another way to update and
check the mouse and keyboard without them? ie. the simple,
classic main loop:
while (!done)
{
check_keyboard();
if (escape_pressed)
done = true;
move_sprites();
update_screen();
}
Do I need to use events, or is there another way to update and
check the mouse and keyboard without them? ie. the simple,
classic main loop:
while (!done)
{
check_keyboard();
if (escape_pressed)
done = true;
move_sprites();
update_screen();
}
check_keyboard()
{
SDL_Event event;
Uint8 *keystate;
/* First pump events through SDL's state machine */
escape_pressed = 0;
while ( SDL_PollEvent(&event) {
if ( event.type == SDL_QUIT ) {
escape_pressed = 1;
}
}
/* Now check keyboard state */
keystate = SDL_GetKeyState(NULL);
if ( keystate[SDLK_ESCAPE] == SDL_PRESSED ) {
escape_pressed = 1;
}
}
For optimization, in your initialization code, you can do:
for ( i=0; i<SDL_NUMEVENTS; ++i ) {
if ( i != SDL_QUIT ) {
SDL_EventState(i, SDL_IGNORE);
}
}
This will prevent SDL from queuing events, but will still update the internal
keyboard state and mouse position. You still need to call SDL_PollEvent() to
update the interal state, however. SDL_PollEvent() in this case will only
return true when an SDL_QUIT message comes through. Note that if Ctrl-C is
pressed, and SDL_QUIT is ignored, you’ll still get an SDL_QUIT message.
I’m still not sure whether this is a bug or a feature. 
How is it possible to handle SDL events like Java AWT events?
Thank you in advance for your help.–
Matthieu DUFOURNEAUD
49, boulevard Normandie Niemen
42100 Saint-Etienne
FRANCE
Tel: +33 (0)4 77 34 15 24
Email: matthieu.dufourneaud at fnac.net
Maitrise d’Informatique
Faculte des Sciences et Techniques de Saint-Etienne
A suggestion, avoid doing it like Java.
To do it like java, you first have to write an event dispatcher,
and then have your objects wait on IPC. Java’s event model is
heavily thread oriented, and makes sense for that language, but
not as much when threading is done on say a process level.
If you are writing something in C, you are probably better off
with callback lists which gui elements register for, as with
typical X programming. If you are doing this in C++ its not
that hard to write an interface class to handle all this, and
then derive the various event types.
These two approaches may simply seem semantically different, but
that is because the java class libraries have hidden the nasty
interface to the underlying event system from you…On Mon, Apr 09, 2001 at 11:18:26PM +0200, Matthieu DUFOURNEAUD wrote:
How is it possible to handle SDL events like Java AWT events?
–
david j. goehrig bit twiddler www.valinux.com
“There was nothing creative, charming, admirable or innovative in
Pok?mon except that it parted small children from their
money with brutal efficiency. It inexplicably featured the
dramatic story of cockfighting monsters who lived in your pants…”
- John TynesIs it a good method to put my event handler in a separate thread?
In fact what I want is a way to handle events while a function is still
running.
Dave a ?crit:> On Mon, Apr 09, 2001 at 11:18:26PM +0200, Matthieu DUFOURNEAUD wrote:
How is it possible to handle SDL events like Java AWT events?
A suggestion, avoid doing it like Java.
To do it like java, you first have to write an event dispatcher,
and then have your objects wait on IPC. Java’s event model is
heavily thread oriented, and makes sense for that language, but
not as much when threading is done on say a process level.If you are writing something in C, you are probably better off
with callback lists which gui elements register for, as with
typical X programming. If you are doing this in C++ its not
that hard to write an interface class to handle all this, and
then derive the various event types.These two approaches may simply seem semantically different, but
that is because the java class libraries have hidden the nasty
interface to the underlying event system from you…–
david j. goehrig bit twiddler www.valinux.com
“There was nothing creative, charming, admirable or innovative in
Pok?mon except that it parted small children from their
money with brutal efficiency. It inexplicably featured the
dramatic story of cockfighting monsters who lived in your pants…”- John Tynes
–
Matthieu DUFOURNEAUD
49, boulevard Normandie Niemen
42100 Saint-Etienne
FRANCE
Tel: +33 (0)4 77 34 15 24
Email: matthieu.dufourneaud at fnac.net
Maitrise d’Informatique
Faculte des Sciences et Techniques de Saint-Etienne
Dave writes:
[plug for SDLmm follows below…]
If you are doing this in C++ its not that hard to write an interface
class to handle all this, and then derive the various event types.
First of all, short announcement: I’m working on a lib called SDLmm,
which is a C++ wrapper library for SDL. Current wrapping status is
(about): Events 100%, WM 100%, Video all but mouse/GL. It’s hosted on
sourceforge (http://sourceforge.net/projects/sdlmm).
In any case, I have a very nice event system in my opinion. Basically,
you create a classed derived from EventHandler (documented at
http://sdlmm.sourceforge.net/class_SDLmm__EventHandler.html). Each
type of callback has one or more potential handlers. Here’s a simple
example of it’s use:
using namespace SDLmm;
class MyEventHandler : public EventHandler {
public:
bool done;
MyEventHandler() : done(false) { }
bool HandleKeyPressEvent(SDL_keysym &keysym) {
printf(“Got kbd press event: sym = %d (%s).\n”,
keysym.sym, Event::GetKeyName(keysym.sym));
return true; // event handled
}
bool HandleQuitEvent() {
printf(“Got quit event.\n”);
done = true;
return true;
}
bool HandleEvent(SDL_Event &event) {
// Handle every previously unhandled event the old fashioned way.
}
};
[…]
MyEventHandler ev;
while ( !ev.done ) {
Event::HandleEvents(ev);
[do other stuff]
}
I was told this was similar to that in AWT (thanks to gltron/tesmako
in #SDL for the idea of implementing a system like this).
I find it very handy and easy to use personally. Much cleaner than a
switch checking the type (which, on the other hand, is how the
implementation is done in by Event::HandleEvents).–
[ Below is a random fortune, which is unrelated to the above message. ]
If graphics hackers are so smart, why can’t they get the bugs out of
fresh paint?
“David Hedbor” wrote in message
news:m3n1989h09.fsf at stellar.home.hedbor.org…
In any case, I have a very nice event system in my opinion. Basically,
you create a classed derived from EventHandler (documented at
http://sdlmm.sourceforge.net/class_SDLmm__EventHandler.html). Each
type of callback has one or more potential handlers. Here’s a simple
example of it’s use:
Sorry, but that system is simply awful. Consider the following code:
void wait_for_key() {
SDL_Event e;
while (SDL_PollEvent(&e)) {
if (e.type == SDL_KEYDOWN) {
return;
}
}
}
That’s eight lines of code. Then consider what I’d have to do in your
system:
class WaitForKeyEventHandler : public SDLmm::EventHandler {
public:
bool done;
WaitForKeyEventHandler() : done(false) {}
bool HandleKeyPressEvent(SDL_keysym&)
{
this->done = true;
return true;
}
};
void wait_for_key_press()
{
WaitForKeyEventHandler ev;
while (!ev.done) {
SDLmm::Event::HandleEvent(ev);
}
}
That’s 18 lines of code: more than twice the original. It is also more
complicated and less readable. Now consider that there may be hundreds of
places in a program where events are handled differently (think dialogs).
Each of these would see a similar increase in size and complexity. True,
you can use inheritance to factor out common functionality - but this
provides no advantage over factoring through free functions.–
Rainer Deyke (root at rainerdeyke.com)
Shareware computer games - http://rainerdeyke.com
"In ihren Reihen zu stehen heisst unter Feinden zu kaempfen" - Abigor
Rainer Deyke wrote:
“David Hedbor” wrote in message
news:m3n1989h09.fsf at stellar.home.hedbor.org…In any case, I have a very nice event system in my opinion. Basically,
you create a classed derived from EventHandler (documented at
http://sdlmm.sourceforge.net/class_SDLmm__EventHandler.html). Each
type of callback has one or more potential handlers. Here’s a simple
example of it’s use:Sorry, but that system is simply awful. Consider the following code:
void wait_for_key() {
SDL_Event e;
while (SDL_PollEvent(&e)) {
if (e.type == SDL_KEYDOWN) {
return;
}
}
}That’s eight lines of code. Then consider what I’d have to do in your
system:class WaitForKeyEventHandler : public SDLmm::EventHandler {
public:
bool done;
WaitForKeyEventHandler() : done(false) {}
bool HandleKeyPressEvent(SDL_keysym&)
{
this->done = true;
return true;
}
};void wait_for_key_press()
{
WaitForKeyEventHandler ev;
while (!ev.done) {
SDLmm::Event::HandleEvent(ev);
}
}That’s 18 lines of code: more than twice the original. It is also more
complicated and less readable. Now consider that there may be hundreds of
places in a program where events are handled differently (think dialogs).
Each of these would see a similar increase in size and complexity. True,
you can use inheritance to factor out common functionality - but this
provides no advantage over factoring through free functions.
True. It’s not at all better for simple things like the above. That’s
why you, of course, can still use the old style coding.
void wait_for_key() {
SDLmm::Event e;
while (e.Poll()) {
if (e.me.type == SDL_KEYDOWN) {
return;
}
}
}
However, for more complex event handling, the overhead is smaller and
IMHO worth it for the increased readability and lower complexity. The
above is such an amazingly simple example that it’s rather pointless to
use the class based event handler (but I use it in the test program just
to show it basically).
Also, I added the system since I wanted a more C+±ish way of handling
the events. Since both ways are possible, it’s up to the programmer to
choose what is best for him/her.
– David
Granted you want an object to do something on a KeyDownEvent, here’s how
you’d do it in KGB:
class LetsCallItButton:public KGB_KeydownHandler{
public:
LetsCallItButton():KGB_KeyDownHandler(){
game->registerKeydownHandler(this);
}
void handleKeydownEvent(SDLKey key){
do_stuff_here();
}
}
…to show another way of doing it in an object-oriented manner. You just
make the object responding to an event a subclass of the proper eventhandler,
and implement handleEvent().
BLiP!On Monday 23 April 2001 18:21, you wrote:
“David Hedbor” wrote in message
news:m3n1989h09.fsf at stellar.home.hedbor.org…In any case, I have a very nice event system in my opinion. Basically,
you create a classed derived from EventHandler (documented at
http://sdlmm.sourceforge.net/class_SDLmm__EventHandler.html). Each
type of callback has one or more potential handlers. Here’s a simple
example of it’s use:Sorry, but that system is simply awful. Consider the following code:
void wait_for_key() {
SDL_Event e;
while (SDL_PollEvent(&e)) {
if (e.type == SDL_KEYDOWN) {
return;
}
}
}That’s eight lines of code. Then consider what I’d have to do in your
system:class WaitForKeyEventHandler : public SDLmm::EventHandler {
public:
bool done;
WaitForKeyEventHandler() : done(false) {}
bool HandleKeyPressEvent(SDL_keysym&)
{
this->done = true;
return true;
}
};void wait_for_key_press()
{
WaitForKeyEventHandler ev;
while (!ev.done) {
SDLmm::Event::HandleEvent(ev);
}
}That’s 18 lines of code: more than twice the original. It is also more
complicated and less readable. Now consider that there may be hundreds of
places in a program where events are handled differently (think dialogs).
Each of these would see a similar increase in size and complexity. True,
you can use inheritance to factor out common functionality - but this
provides no advantage over factoring through free functions.
Jone Marius Vignes writes:
Granted you want an object to do something on a KeyDownEvent, here’s how
you’d do it in KGB:class LetsCallItButton:public KGB_KeydownHandler{
public:
LetsCallItButton():KGB_KeyDownHandler(){
game->registerKeydownHandler(this);
}void handleKeydownEvent(SDLKey key){
do_stuff_here();
}
}…to show another way of doing it in an object-oriented manner. You just
make the object responding to an event a subclass of the proper eventhandler,
and implement handleEvent().
I like that with my implementation you didn’t have to register event
handlers. You can also easily switch handlers as needed. Now, instead
you need to call Event::HandleEvents() manually, but I don’t see that
as a drawback really.
Thanks for the insight though. Perhaps, eventually, this method will
be implemented as well.–
[ Below is a random fortune, which is unrelated to the above message. ]
share, n.:
To give in, endure humiliation.