headers
Christophe Cavalaria | 1 Oct 2005 01:48
Picon
Favicon

Re: AltGr and other things

Ingo Schmidt wrote:

> Hi!
> 
> First of all:
> I am new to the list. Hi to everyone :-)
> 
> Now my questions:
> 
> I have this code in a program:
> 
>         SDL_Event event;
>         int eventmask = SDL_EVENTMASK(SDL_KEYDOWN)
>                                         | SDL_EVENTMASK(SDL_KEYUP)
>                                         |
SDL_EVENTMASK(SDL_MOUSEBUTTONDOWN)
>                                         | SDL_EVENTMASK(SDL_MOUSEBUTTONUP)
>                                         | SDL_EVENTMASK(SDL_MOUSEMOTION)
>                                         | SDL_EVENTMASK(SDL_JOYAXISMOTION)
>                                         | SDL_EVENTMASK(SDL_JOYHATMOTION)
>                                         | SDL_EVENTMASK(SDL_JOYBUTTONDOWN)
>                                         | SDL_EVENTMASK(SDL_JOYBUTTONUP)
>                                         | SDL_EVENTMASK(SDL_ACTIVEEVENT)
> #ifdef SDL_GUI
>                                         | SDL_EVENTMASK(GUI_RETURN_INFO)
> #endif
>                                         | SDL_EVENTMASK(SDL_QUIT);
> 
>         SDL_PumpEvents();
>         while (SDL_PeepEvents(&event, 1, SDL_GETEVENT, eventmask)) {
(Continue reading)

Permalink | Reply | 0 comments |
headers
Tim Swast | 1 Oct 2005 02:09
Picon

Re: Dev C++ Linking Issues

Thank you very much. All I had to do was add the int argc, char *argv[] parameters to main and it linked fine. I would have never thought that those parameters would have been the problem.

On 9/29/05, Tyler Montbriand <tsm <at> accesscomm.ca> wrote:

1) It has to be int main(int argc, char *argv[]), not int main().
SDL expects, nay, *demands* it take those two parameters.

2) If your main is in a C++ file, chances are your 'main' function is not
really called 'main' as far as the linker's concerned, but
1502347xcgxf532189_main <at> or some other garbage.  C++ mangles the names to
prevent overloaded functions from having the same names.

Fortunately, there's a way to tell C++ to do that.  Try:
  extern "C" int main(int argc, char *argv[])
instead of
  int main()

and tell me how it goes :)



--
Tim Swast
Purple {Programming} Monkey King 
_______________________________________________
SDL mailing list
SDL <at> libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
Permalink | Reply | 1 comment |
headers
Christophe Cavalaria | 1 Oct 2005 02:00
Picon
Favicon

Unicode key and AltGr support

The thread about the AltGr got me to test the feature with the uncommon keys
in the French keyboard I'm using. I've tried the AltGr + a few keys
combinations to see the result and I found that a lot of times, SDL didn't
give me back a correct unicode value. Here's the results for the AltGr +
azertyuiop keys :

$ ./sdlkeytest-1.2.9
Keyname, (alt gr), Scancode (113), keysym (313), mod (4096), unicode (0)
Keyname, (a), Scancode (24), keysym (97), mod (20480), unicode (230)
Keyname, (z), Scancode (25), keysym (122), mod (20480), unicode (171)
Keyname, (e), Scancode (26), keysym (101), mod (20480), unicode (0)
Keyname, (r), Scancode (27), keysym (114), mod (20480), unicode (182)
Keyname, (t), Scancode (28), keysym (116), mod (20480), unicode (0)
Keyname, (y), Scancode (29), keysym (121), mod (20480), unicode (0)
Keyname, (u), Scancode (30), keysym (117), mod (20480), unicode (0)
Keyname, (i), Scancode (31), keysym (105), mod (20480), unicode (0)
Keyname, (o), Scancode (32), keysym (111), mod (20480), unicode (0)
Keyname, (p), Scancode (33), keysym (112), mod (20480), unicode (254)

Here's the expected result :

>>> s = u"æ«€¶ŧ←↓→œþ"
>>> [ord(c) for c in s]
[230, 171, 8364, 182, 359, 8592, 8595, 8594, 339, 254]

I hope the utf8 message will display correctly for all of you. In the list
there's the corresponding expected unicode values. You can see that no
keypoint above 254 got through the system.

The systems is a Mandrive 2005 with a custom built SDL version 1.2.9.

On a side note, you can see than I get the correct event for the altgr key
so that one isn't an issue for Unix users I guess ;)
Permalink | Reply | 5 comments |
headers
Rainer Deyke | 1 Oct 2005 04:53

Re: Feature Query System (Was: Some multithreaded improvement to the event queue...)

Brian Raiter wrote:
> Yes, but surely you'd agree that that's not a good, portable
> solution. SDL_WM_ToggleFullScreen may become usable on other platforms
> in the future (and/or it might conceivably become unavailabile on
> later versions of the current platform). It would definitely be better
> if you could test for the feature directly, rather than hardcode an
> assumption that it exists on one platform.

I agree that conditional compilation is not the answer to this 
situation.  However, what's wrong with just trying 
SDL_WM_ToggleFullScreen falling back to SDL_SetVideoMode if it fails? 
The only situation I can think of where that wouldn't work is if you 
didn't write the fallback code and want to disable the ability to switch 
between full-screen and windowed mode entirely.

> SDL already uses this idea with the SDL_MUSTLOCK() macro. Having
> a similar feature for features like full-screen toggling would be a
> good thing, I think.

For the record, I consider SDL_MUSTLOCK() a mistake.  90% of the time it 
is used for code like this:

if (SDL_MUSTLOCK(s)) SDL_LockSurface(s);

...which is just a waste of keystrokes, since SDL_LockSurface(s) works 
even if SDL_MUSTLOCK(s) returns false.  I can think of two legitimate 
uses, one of which is purely for error checking 
(assert(!SDL_MUSTLOCK(s))) and the other is completely marginal (i.e. 
completely different code paths optimized for the different performance 
characteristics of surfaces that require locking and those that don't).

Which is not to say that a query system wouldn't be a worthwhile 
addition to SDL.  However, it would need to be carefully designed to 
expose useful information instead just opening up a bunch of useless 
implementation details.

--

-- 
Rainer Deyke - rainerd <at> eldwood.com - http://eldwood.com
Permalink | Reply | 6 comments |
headers
Elden Armbrust | 1 Oct 2005 04:58

Re: Unicode key and AltGr support

So I wasn't wrong in my assumption that AltGr is interpereted as two 
actual key events...even though it's somewhat silly to do things that way.
I think the best way to do this would be (programming using sdl, not sdl 
dev itself) to check for the control key event press, then check the 
next event to see if it is the Alt keypress, then upon the Control keys 
release event, check if the alt key is still in the pressed state.  It's 
somewhat of a hack, but seems like it SHOULD work on any platform...but 
who knows?  It's worth a shot at least.

-Elden

Christophe Cavalaria wrote:

>The thread about the AltGr got me to test the feature with the uncommon keys
>in the French keyboard I'm using. I've tried the AltGr + a few keys
>combinations to see the result and I found that a lot of times, SDL didn't
>give me back a correct unicode value. Here's the results for the AltGr +
>azertyuiop keys :
>
>$ ./sdlkeytest-1.2.9
>Keyname, (alt gr), Scancode (113), keysym (313), mod (4096), unicode (0)
>Keyname, (a), Scancode (24), keysym (97), mod (20480), unicode (230)
>Keyname, (z), Scancode (25), keysym (122), mod (20480), unicode (171)
>Keyname, (e), Scancode (26), keysym (101), mod (20480), unicode (0)
>Keyname, (r), Scancode (27), keysym (114), mod (20480), unicode (182)
>Keyname, (t), Scancode (28), keysym (116), mod (20480), unicode (0)
>Keyname, (y), Scancode (29), keysym (121), mod (20480), unicode (0)
>Keyname, (u), Scancode (30), keysym (117), mod (20480), unicode (0)
>Keyname, (i), Scancode (31), keysym (105), mod (20480), unicode (0)
>Keyname, (o), Scancode (32), keysym (111), mod (20480), unicode (0)
>Keyname, (p), Scancode (33), keysym (112), mod (20480), unicode (254)
>
>Here's the expected result :
>
>  
>
>>>>s = u"æ«€¶ŧ←↓→œþ"
>>>>[ord(c) for c in s]
>>>>        
>>>>
>[230, 171, 8364, 182, 359, 8592, 8595, 8594, 339, 254]
>
>I hope the utf8 message will display correctly for all of you. In the list
>there's the corresponding expected unicode values. You can see that no
>keypoint above 254 got through the system.
>
>The systems is a Mandrive 2005 with a custom built SDL version 1.2.9.
>
>On a side note, you can see than I get the correct event for the altgr key
>so that one isn't an issue for Unix users I guess ;)
>
>
>
>_______________________________________________
>SDL mailing list
>SDL <at> libsdl.org
>http://www.libsdl.org/mailman/listinfo/sdl
>
>
>
>  
>
Permalink | Reply | 0 comments |
headers
Elden Armbrust | 1 Oct 2005 04:59

Re: Dev C++ Linking Issues

Glad to hear it wasn't something horrible and life threatening ;)
Best of luck with your project.

-Elden

Tim Swast wrote:

> Thank you very much. All I had to do was add the int argc, char 
> *argv[] parameters to main and it linked fine. I would have never 
> thought that those parameters would have been the problem.
>
> On 9/29/05, *Tyler Montbriand* <tsm <at> accesscomm.ca 
> <mailto:tsm <at> accesscomm.ca>> wrote:
>
>
>     1) It has to be int main(int argc, char *argv[]), not int main().
>     SDL expects, nay, *demands* it take those two parameters.
>
>     2) If your main is in a C++ file, chances are your 'main' function
>     is not
>     really called 'main' as far as the linker's concerned, but
>     1502347xcgxf532189_main <at>  or some other garbage.  C++ mangles the
>     names to
>     prevent overloaded functions from having the same names.
>
>     Fortunately, there's a way to tell C++ to do that.  Try:
>       extern "C" int main(int argc, char *argv[])
>     instead of
>       int main()
>
>     and tell me how it goes :)
>
>
>
>
> -- 
> Tim Swast
> Purple {Programming} Monkey King
>
>------------------------------------------------------------------------
>
>_______________________________________________
>SDL mailing list
>SDL <at> libsdl.org
>http://www.libsdl.org/mailman/listinfo/sdl
>  
>
>------------------------------------------------------------------------
>
>No virus found in this incoming message.
>Checked by AVG Anti-Virus.
>Version: 7.0.344 / Virus Database: 267.11.9/116 - Release Date: 9/30/2005
>  
>
Permalink | Reply | 0 comments |
headers
Elden Armbrust | 1 Oct 2005 07:00

Re: Re: Feature Query System (Was: Some multithreaded improvement to the event queue...)

I think Rainer is right about the query system, and how it should not 
open up a bunch of useless things.  In addition to that, I think that 
*if* this is added to SDL, it should likely be in the form of an addon 
library, and should be kept as streamlined as possible.  SDL is built 
the way it is for a reason.  Anyone can make additions to SDL through a 
library without it even having to be checked into a CVS/SVN server, or 
approved by a larger audience.  I can almost guarantee (and anyone who's 
even visited the freenode irc channel can likely verify) that newbies 
with no idea of what they're doing would misuse the functions to the 
point where they'd come crying to us to figure out why their program is 
slowing down, not working "the way it should", or just generally saying 
that there's too much to learn. (Yes, I've actually heard that about 
SDL...*shudder*)  I think the big thing here is that whoever wants these 
features added should really put in the effort and either at least try 
to submit a patch which covers some of the functionality, or create an 
addon library (the better option, in my opinion) that does the job.  If 
we just sit back and complain about what SDL can't do, rather than 
adding that functionality for ourselves and others, we do nothing to 
help a great development tool/library such as SDL.

-Elden

Rainer Deyke wrote:

> Brian Raiter wrote:
>
>> Yes, but surely you'd agree that that's not a good, portable
>> solution. SDL_WM_ToggleFullScreen may become usable on other platforms
>> in the future (and/or it might conceivably become unavailabile on
>> later versions of the current platform). It would definitely be better
>> if you could test for the feature directly, rather than hardcode an
>> assumption that it exists on one platform.
>
>
> I agree that conditional compilation is not the answer to this 
> situation.  However, what's wrong with just trying 
> SDL_WM_ToggleFullScreen falling back to SDL_SetVideoMode if it fails? 
> The only situation I can think of where that wouldn't work is if you 
> didn't write the fallback code and want to disable the ability to 
> switch between full-screen and windowed mode entirely.
>
>> SDL already uses this idea with the SDL_MUSTLOCK() macro. Having
>> a similar feature for features like full-screen toggling would be a
>> good thing, I think.
>
>
> For the record, I consider SDL_MUSTLOCK() a mistake.  90% of the time 
> it is used for code like this:
>
> if (SDL_MUSTLOCK(s)) SDL_LockSurface(s);
>
> ...which is just a waste of keystrokes, since SDL_LockSurface(s) works 
> even if SDL_MUSTLOCK(s) returns false.  I can think of two legitimate 
> uses, one of which is purely for error checking 
> (assert(!SDL_MUSTLOCK(s))) and the other is completely marginal (i.e. 
> completely different code paths optimized for the different 
> performance characteristics of surfaces that require locking and those 
> that don't).
>
> Which is not to say that a query system wouldn't be a worthwhile 
> addition to SDL.  However, it would need to be carefully designed to 
> expose useful information instead just opening up a bunch of useless 
> implementation details.
>
>
Permalink | Reply | 5 comments |
headers
Johannes Schmidt | 1 Oct 2005 12:00
Picon

Re: Could not initialize SDL - exiting

On Wednesday 28 September 2005 22:45, yvan wrote:
> I used suse 9.3
> I compiled SDL 1.2.9 (SDL-1.2.9.tar.gz)
> I compiled qemu 0.7.2

[...]
> when I play qemu I found :
>  yvan <at> linux:~/qemu> qemu -m 256 -localtime -enable-audio -user-net -cdrom
> /dev/cd                                   rom -boot d -hda windows.raw
> Could not initialize SDL - exiting

Can you compile and run the test applications of SDL (in the test directory)?

Regards,
Johannes

< http://libufo.sourceforge.net > The OpenGL GUI Toolkit
Permalink | Reply | 0 comments |
headers
Johannes Schmidt | 1 Oct 2005 11:50
Picon

Re: Unicode key and AltGr support

On Saturday 01 October 2005 02:00, Christophe Cavalaria wrote:
[...]
> $ ./sdlkeytest-1.2.9
> Keyname, (alt gr), Scancode (113), keysym (313), mod (4096), unicode (0)
> Keyname, (a), Scancode (24), keysym (97), mod (20480), unicode (230)
> Keyname, (z), Scancode (25), keysym (122), mod (20480), unicode (171)
> Keyname, (e), Scancode (26), keysym (101), mod (20480), unicode (0)
> Keyname, (r), Scancode (27), keysym (114), mod (20480), unicode (182)
> Keyname, (t), Scancode (28), keysym (116), mod (20480), unicode (0)
> Keyname, (y), Scancode (29), keysym (121), mod (20480), unicode (0)
> Keyname, (u), Scancode (30), keysym (117), mod (20480), unicode (0)
> Keyname, (i), Scancode (31), keysym (105), mod (20480), unicode (0)
> Keyname, (o), Scancode (32), keysym (111), mod (20480), unicode (0)
> Keyname, (p), Scancode (33), keysym (112), mod (20480), unicode (254)
>
> Here's the expected result :
> >>> s = u"æ«€¶ŧ←↓→œþ"
> >>> [ord(c) for c in s]
>
> [230, 171, 8364, 182, 359, 8592, 8595, 8594, 339, 254]
>
> I hope the utf8 message will display correctly for all of you. In the list
> there's the corresponding expected unicode values. You can see that no
> keypoint above 254 got through the system.

On X11, SDL uses XLookupString, which returns a character string
as key translation.
SDL copies only the first character into its unicode field.

Perhaps someone wants to fix the "FIXME" at
src/video/x11/SDL_x11events.c, line 716  :)

Regards,
Johannes

< http://libufo.sourceforge.net > The OpenGL GUI Toolkit
Permalink | Reply | 3 comments |
headers
Christophe Cavalaria | 1 Oct 2005 19:18
Picon
Favicon

Re: Unicode key and AltGr support

Johannes Schmidt wrote:

> On Saturday 01 October 2005 02:00, Christophe Cavalaria wrote:
> [...]
>> $ ./sdlkeytest-1.2.9
>> Keyname, (alt gr), Scancode (113), keysym (313), mod (4096), unicode (0)
>> Keyname, (a), Scancode (24), keysym (97), mod (20480), unicode (230)
>> Keyname, (z), Scancode (25), keysym (122), mod (20480), unicode (171)
>> Keyname, (e), Scancode (26), keysym (101), mod (20480), unicode (0)
>> Keyname, (r), Scancode (27), keysym (114), mod (20480), unicode (182)
>> Keyname, (t), Scancode (28), keysym (116), mod (20480), unicode (0)
>> Keyname, (y), Scancode (29), keysym (121), mod (20480), unicode (0)
>> Keyname, (u), Scancode (30), keysym (117), mod (20480), unicode (0)
>> Keyname, (i), Scancode (31), keysym (105), mod (20480), unicode (0)
>> Keyname, (o), Scancode (32), keysym (111), mod (20480), unicode (0)
>> Keyname, (p), Scancode (33), keysym (112), mod (20480), unicode (254)
>>
>> Here's the expected result :
>> >>> s = u"æ«€¶ŧ←↓→œþ"
>> >>> [ord(c) for c in s]
>>
>> [230, 171, 8364, 182, 359, 8592, 8595, 8594, 339, 254]
>>
>> I hope the utf8 message will display correctly for all of you. In the
>> list there's the corresponding expected unicode values. You can see that
>> no keypoint above 254 got through the system.
> 
> On X11, SDL uses XLookupString, which returns a character string
> as key translation.
> SDL copies only the first character into its unicode field.
> 
> Perhaps someone wants to fix the "FIXME" at
> src/video/x11/SDL_x11events.c, line 716  :)
> 
> 
> Regards,
> Johannes
> 
> < http://libufo.sourceforge.net > The OpenGL GUI Toolkit

It's not like some didn't do that already. I did a google search for
XLookupString unicode and the first hit I found was a message on that same
mailing list with a patch for that same issue.

http://lists.arabeyes.org/archives/developer/2004/June/msg00160.html
Permalink | Reply | 2 comments |

Gmane