*ahem*

Is this mailing list dead?–

-Stephan /
/ tisprut productions [tm]

        http://wiktor.dk/~stephan

Good question. Are the messeges being posted on the newsgroup being
forwarded to this mailing list too?On Sat, 23 Oct 1999, Stephan Dragehjerte wrote:

Is this mailing list dead?

-Stephan /
/ tisprut productions [tm]

        http://wiktor.dk/~stephan

I’m posting to the newsgroup, so if you can see this the answer is yes.

		-fjr

Garrett Robert Banuk wrote:>

Good question. Are the messeges being posted on the newsgroup being
forwarded to this mailing list too?

On Sat, 23 Oct 1999, Stephan Dragehjerte wrote:

Is this mailing list dead?

-Stephan /
/ tisprut productions [tm]

        http://wiktor.dk/~stephan

I think it moved to a news group. I thought though that the list would
still have posts to the newgroup, but it does not seem like it.On Sat, 23 Oct 1999, Stephan Dragehjerte wrote:

Is this mailing list dead?

-Stephan /
/ tisprut productions [tm]

        http://wiktor.dk/~stephan

Mike Machado
mike at innercite.com
InnerCite
Network Specialist

I’m posting to the newsgroup, so if you can see this the answer is yes.

Blarg! I can see this but I can’t see the newsgroup on my server.

Paul Braman
@Paul_BramanOn Sat, 23 Oct 1999, Frank J. Ramsay wrote:

I’m posting to the newsgroup, so if you can see this the answer is yes.

Blarg! I can see this but I can’t see the newsgroup on my server.

Both the mailing list and the newsgroup are active.
If you want to use the newsgroup, point your news client at:
news.lokigames.com

I think it’s just been quiet the past few days. :slight_smile:

-Sam Lantinga				(slouken at devolution.com)

Lead Programmer, Loki Entertainment Software> On Sat, 23 Oct 1999, Frank J. Ramsay wrote:

“Any sufficiently advanced bug is indistinguishable from a feature”
– Rich Kulawiec

Both the mailing list and the newsgroup are active.
If you want to use the newsgroup, point your news client at:
news.lokigames.com

I think it’s just been quiet the past few days. :slight_smile:

-Sam Lantinga (slouken at devolution.com)

I was starting to wonder what was going on myself. I sent all those
messages on the mouse focus stuff and only two people ever replied. And
Dave Ashley never responded to one that was sort of directed at him. Not
like the old days when there was over ten messages a day. Oh well.

DanielOn Sat, 23 Oct 1999, Sam Lantinga wrote:

Danny Sinclair wrote:

I was starting to wonder what was going on myself. I sent all those
messages on the mouse focus stuff and only two people ever replied. And
Dave Ashley never responded to one that was sort of directed at him. Not
like the old days when there was over ten messages a day. Oh well.

Daniel

I always read all SDL messages, yours not less than others.
Oh, about the mouse focus stuff I’m still waiting for the answer by Sam
(but maybe he’s too busy).

Enzo.

Well, since the list seems to be alive, I have a question.
I’ve been trying in the newsgroup a couple of times, but
noone has ever answered.

I have a program with all the SDL-stuff in one function (not
main()).
When I call it the first time, everything works file; the
surface is allocated, opened, images are loaded and
displayed. And everything appears to be closed and released
as supposed to.

But here things start to go wrong. If I break the loop in
main() with ctrl+c, the terminal locks. And if the
sdl_function() is called again, only a black screen is
opened, and then it freezes. Kill -9 is necessary…

A newer version of SDL gives a parachute instead og crash…

Am I forgetting something? Is there a specielt way,
functions should be exit?

Here’s the entire code. It is mainly copied from the HTML
manual:

#ifndef main_cpp
#define main_cpp

#include <iostream.h> // streams
#include <sys/stat.h> // file stats
#include <stdlib.h> // exit(), getenv()
#include <unistd.h> // sleep(), stat()
#include <math.h> // sin() …
#include <SDL.h> // Simple DirectMedia Layer library
#include <SDL_audio.h>
#include <SDL_error.h>
#include <SDL_timer.h>

#include “./flika.h” //
#include “./click.h” // Mouse clicks within area.

//
// Global variables.
//
SDL_Surface *screen,
*image_surface[IMAGES];

//
// Function prototypes.
//
int flika();
int filter_events(const SDL_Event *event);
void update_screen();
void display_image(int i);

int
main(int argc, char **argv)
{
bool newmail=0;

cout << "Flika started." << endl;


for(;;) {
	flika();
	sleep(5);
}


return 0;

}

int
flika()
{
SDL_Event event;
bool update = 0;

atexit(SDL_Quit);

if( SDL_Init(SDL_INIT_VIDEO) < 0 ) {
	cerr << "Error initiating video." << endl;
	exit(1);
}


SDL_WM_SetCaption("flika!", "flika");

SDL_SetEventFilter( filter_events );

for(int i=0; i<IMAGES; ++i) {
	cout << "Loading image [" << image_file[i] << "]: ";

	image_surface[i] = SDL_LoadBMP( image_file[i] );
	if( !image_surface[i] ) {
		cerr << "Error loading image!" << endl;
		exit(1);
	}

	cout << "Supergeil!" << endl;
}

screen = SDL_SetVideoMode(image_surface[0]->w, image_surface[0]->h, 16,
					SDL_SWSURFACE);
if( !screen ) {
	cerr << "Error initiating video mode." << endl;
	exit(1);
}
cout << "Set " << (int) screen->w << "x" << (int) screen->h
     << " at " << (int) screen->format->BitsPerPixel << " bpp." << endl;


update_screen();

    while ( SDL_WaitEvent(&event) >= 0 ) {
            switch (event.type) {

                    case SDL_ACTIVEEVENT: {
                            if ( event.active.state & SDL_APPACTIVE ) {
                                    if ( event.active.gain ) {
                                            cout << "activated" << endl;
                                    } else {
                                            cout << "iconified" << endl;
                                    }
                            }
                    }
		break;
                                    
                    case SDL_MOUSEBUTTONDOWN: {
			if( event.button.button == 3 ) {
				cout << "trickster!" << endl;
			}

			if( within_rectangle( (int) event.button.x,
			(int) event.button.y, 125, 90, 72, 24) ) {
				image_flags.mouth = !image_flags.mouth;
				update = 1;
			}

			if( within_rectangle( (int) event.button.x,
			(int) event.button.y, 143, 80, 40, 8) ) {
				for(int i=0; i<4; ++i) {
					image_flags.eyes
						= !image_flags.eyes;
					update_screen();
					SDL_Delay(200);
				}
			}

			if( within_circle( (int) event.button.x,
			(int) event.button.y, 212, 71, 20) ) {
				image_flags.fuck = !image_flags.fuck;
				update = 1;
			}

			if(update) update_screen();
			update = 0;
		}
		break;

// case SDL_MOUSEBUTTONUP: {
// }
// break;

                    case SDL_QUIT: {
                            cout << "Leaving.." << endl;
			for(int i=0; i<IMAGES; ++i) {
				cout << "Freeing surface ["
				     << image_file[i] << "].." << endl;
				SDL_FreeSurface(image_surface[i]);
			}
			cout << "Calling SDL_Quit()..";
			SDL_Quit();
			cout << "done." << endl;
                            return 0;
                    }
		break;
            }
    }
    /* This should never happen */
cout << "SDL_WaitEvent error: " << (int) SDL_GetError() << "." << endl;



cout << "HMM..." << endl;

return 0;

}

//
// Event filter
//
int
filter_events(const SDL_Event event)
{
if( event->type == SDL_MOUSEMOTION ) {
/

cout << “moved to (”
<< (int) event->motion.x << “;”
<< (int) event->motion.y << “).\n”;
*/
return 0;
}

    return 1;

}

//
// Update screen and all the images.
//
void
update_screen()
{
if( image_flags.background != image_flags_backup.background )
display_image(0);

if( image_flags.mouth != image_flags_backup.mouth ) {
	if(image_flags.mouth)
		display_image(1);
	else
		display_image(2);
}

if( image_flags.eyes != image_flags_backup.eyes ) {
	if(image_flags.eyes)
		display_image(3);
	else
		display_image(4);
}

if( image_flags.fuck != image_flags_backup.fuck ) {
	if(image_flags.fuck)
		display_image(5);
	else
		display_image(6);
}


image_flags_backup = image_flags;

}

//
// Display individual images.
//
void
display_image(int i)
{
SDL_Rect area;

    area.x = image_offset[i].x;
    area.y = image_offset[i].y;
    area.w = image_surface[i]->w;
    area.h = image_surface[i]->h;
    SDL_BlitSurface(image_surface[i], NULL, screen, &area);
    SDL_UpdateRects(screen, 1, &area);

}

#endif

-Stephan /
/ tisprut productions [tm]

        http://wiktor.dk/~stephan

Danny Sinclair wrote:

I was starting to wonder what was going on myself. I sent all those
messages on the mouse focus stuff and only two people ever replied. And
Dave Ashley never responded to one that was sort of directed at him. Not
like the old days when there was over ten messages a day. Oh well.

Daniel

I always read all SDL messages, yours not less than others.
Oh, about the mouse focus stuff I’m still waiting for the answer by Sam
(but maybe he’s too busy).

Oh, right, I forgot. :slight_smile:

Okay, the official way the mouse focus stuff is supposed to work:

When the mouse leaves the visible area of the window, you should
lose the mouse focus. When it reenters the visible area, you should
get the mouse focus. If you get a mouse button down event, you should
get a corresponding mouse up event. If the underlying window system
does not allow you to easily get mouse up events when the mouse leaves
the window area, a synthetic mouse up event should be generated
(keypresses are handled in the same way). Mouse button events should
be dropped if they do not change the current state. i.e. if you generate
a mouse up event, and then the OS generates one later, the OS generated
one shouldn’t reach the application.

I think that covers it. The event processing should be very low overhead
and shouldn’t impact other processes on the system (i.e. no server grabbing
if possible, etc.)

Not all supported platforms behave this way, but they should. :slight_smile:

-Sam Lantinga				(slouken at devolution.com)

Lead Programmer, Loki Entertainment Software–
“Any sufficiently advanced bug is indistinguishable from a feature”
– Rich Kulawiec

[snip]

Okay, the official way the mouse focus stuff is supposed to work:

When the mouse leaves the visible area of the window, you should
lose the mouse focus. When it reenters the visible area, you should
get the mouse focus. If you get a mouse button down event, you should
get a corresponding mouse up event. If the underlying window system
does not allow you to easily get mouse up events when the mouse leaves
the window area, a synthetic mouse up event should be generated
(keypresses are handled in the same way). Mouse button events should
be dropped if they do not change the current state. i.e. if you generate
a mouse up event, and then the OS generates one later, the OS generated
one shouldn’t reach the application.

That’s exactly how I though it should work except for one detail. I don’t
like that you can get mouse up events outside of your SDL window (and the
mouse move events to get there). I think that when a mouse button is down,
the mouse cursor should be restricted to the client area of the window.
You’re guaranteed to get mouse up events then, and you never get mouse
move events outside of your window. You also can’t lose mouse focus when a
button is down. You should gain/lose focus EVERY time the cursor moves
in/out, instead of just when buttons aren’t down.

I think that covers it. The event processing should be very low overhead
and shouldn’t impact other processes on the system (i.e. no server grabbing
if possible, etc.)

I’m mostly a Win32 guy, what’s server grabbing? Taking control of the X
server?

DanielOn Sun, 24 Oct 1999, Sam Lantinga wrote:

Danny Sinclair wrote:

That’s exactly how I though it should work except for one detail. I don’t
like that you can get mouse up events outside of your SDL window (and the
mouse move events to get there).

I don’t like that: you know, for example, the xeyes program? (two little eyes
that follows
mouse cursor position). If you can’t get mouse position outside you client area
you can’t
create a program like that. I really think that sometimes there are other
program that
need to get mouse position also outside the client area.

Enzo.

Danny Sinclair wrote:

That’s exactly how I though it should work except for one detail. I don’t
like that you can get mouse up events outside of your SDL window (and the
mouse move events to get there).

I don’t like that: you know, for example, the xeyes program? (two little
eyes that follows mouse cursor position). If you can’t get mouse
position outside you client area you can’t create a program like that. I
really think that sometimes there are other program that need to get
mouse position also outside the client area.

Well, for that purpose, yes you need all mouse move events. But right now
SDL only gets mouse move events ‘when a mouse button is down.’ Xeyes can’t
be done with SDL right now. I think, by default, the way it should work is
how Sam and I have detailed in previous messages and add the OPTION of
’capturing’ the mouse so you can get all events from it. Capturing the
mouse should not interfere, in any way, the input of other programs.

Actually, I just though of a something. Xeyes IS possible (call it
SDLeyes?) without getting all events. Every time you want to update the
eyes (running on a timer), you query the mouse position using
SDL_GetMouseState. Then you just draw your eyes pointed at the mouse
cursor. There’s no need to get all mouse move events - you only need the
position when you do your screen update.

Yep, I still don’t see a good reason for getting all mouse events…

That stirs up another thing that was brought up a few weeks ago: some
people want periodic timers events (me included). If you need your eyes
updated twice a second, just set your timer to go off every 500ms. That
solution is much better (conceptually and efficiency wise) than polling
the time.

DanielOn Mon, 25 Oct 1999, Enzo wrote:

Danny Sinclair wrote:

That’s exactly how I though it should work except for one detail. I don’t
like that you can get mouse up events outside of your SDL window (and the
mouse move events to get there).

I don’t like that: you know, for example, the xeyes program? (two little
eyes that follows mouse cursor position). If you can’t get mouse
position outside you client area you can’t create a program like that. I
really think that sometimes there are other program that need to get
mouse position also outside the client area.

One other reason that an SDL window shouldn’t get mouse move events
outside of it’s client area: what coordinate system do you use?

If you use absolute screen coordinates, you have to figure out where the
cursor is in relation to your client area by getting your window’s
position and subtracting the top left corner from the mouse’s position;
and you have to do that every time the mouse moves, even when the user is
using a different program and the SDL one is in the background.

If you use coordinates relative to your client area, you still have to do
clipping yourself by getting your window’s size and checking if the cursor
is within the client area; again, you have to do it every time the mouse
moves.

Either way is a waste of processing power because it’s rare that anyone
would want those events. You can always get the screen coordinates of the
cursor using SDL_GetMouseState if you need to.

And what about mouse button events? Should you get those outside of your
window? You can’t (well you shouldn’t) stop the user from clicking on a
different application. If the user clicks on a different window, you’ll
get a mouse button down event. At the same time, you will lose focus and
go inactive. Then you won’t get the coresponding button up event.

Sorry to flog a dead horse…

DanielOn Mon, 25 Oct 1999, Enzo wrote:

Danny Sinclair wrote:

Danny Sinclair wrote:

That’s exactly how I though it should work except for one detail. I don’t
like that you can get mouse up events outside of your SDL window (and the
mouse move events to get there).

I don’t like that: you know, for example, the xeyes program? (two little
eyes that follows mouse cursor position). If you can’t get mouse
position outside you client area you can’t create a program like that. I
really think that sometimes there are other program that need to get
mouse position also outside the client area.

One other reason that an SDL window shouldn’t get mouse move events
outside of it’s client area: what coordinate system do you use?

If you use absolute screen coordinates, you have to figure out where the
cursor is in relation to your client area by getting your window’s
position and subtracting the top left corner from the mouse’s position;
and you have to do that every time the mouse moves, even when the user is
using a different program and the SDL one is in the background.

If you use coordinates relative to your client area, you still have to do
clipping yourself by getting your window’s size and checking if the cursor
is within the client area; again, you have to do it every time the mouse
moves.

Either way is a waste of processing power because it’s rare that anyone
would want those events. You can always get the screen coordinates of the
cursor using SDL_GetMouseState if you need to.

And what about mouse button events? Should you get those outside of your
window? You can’t (well you shouldn’t) stop the user from clicking on a
different application. If the user clicks on a different window, you’ll
get a mouse button down event. At the same time, you will lose focus and
go inactive. Then you won’t get the coresponding button up event.

Sorry to flog a dead horse…

Daniel

Ooops! Ok, you’re right…

In my application I needed the cursor position outside the client area only to
detect if the mouse enter / leave the window, because the mouse focus event
didn’t work. If the mouse focus event works correctly, I don’t need to get
mouse state outside.

Well, let’s work to make this event work as Sam said… :slight_smile:

Thanks, bye, Enzo.