plib-devel Mailing List for PLIB (Page 32)
Brought to you by:
sjbaker
Menu
▾
▴
plib-devel
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
(80) |
Mar
(128) |
Apr
(111) |
May
(157) |
Jun
(70) |
Jul
(116) |
Aug
(465) |
Sep
(574) |
Oct
(325) |
Nov
(163) |
Dec
(182) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
(167) |
Feb
(191) |
Mar
(319) |
Apr
(118) |
May
(252) |
Jun
(427) |
Jul
(187) |
Aug
(96) |
Sep
(219) |
Oct
(161) |
Nov
(109) |
Dec
(210) |
| 2002 |
Jan
(97) |
Feb
(80) |
Mar
(143) |
Apr
(234) |
May
(72) |
Jun
(246) |
Jul
(155) |
Aug
(280) |
Sep
(418) |
Oct
(81) |
Nov
(72) |
Dec
(88) |
| 2003 |
Jan
(59) |
Feb
(63) |
Mar
(33) |
Apr
(27) |
May
(87) |
Jun
(50) |
Jul
(97) |
Aug
(45) |
Sep
(35) |
Oct
(67) |
Nov
(78) |
Dec
(13) |
| 2004 |
Jan
(167) |
Feb
(144) |
Mar
(172) |
Apr
(93) |
May
(43) |
Jun
(7) |
Jul
(27) |
Aug
(36) |
Sep
(48) |
Oct
(54) |
Nov
(5) |
Dec
(44) |
| 2005 |
Jan
(53) |
Feb
(36) |
Mar
(13) |
Apr
(3) |
May
(19) |
Jun
|
Jul
(49) |
Aug
(39) |
Sep
(8) |
Oct
(8) |
Nov
(51) |
Dec
(23) |
| 2006 |
Jan
(26) |
Feb
(5) |
Mar
(26) |
Apr
(26) |
May
(52) |
Jun
(36) |
Jul
(8) |
Aug
(12) |
Sep
(6) |
Oct
(75) |
Nov
(34) |
Dec
(25) |
| 2007 |
Jan
(46) |
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
(7) |
Jul
(2) |
Aug
|
Sep
(40) |
Oct
(9) |
Nov
(3) |
Dec
|
| 2008 |
Jan
|
Feb
|
Mar
(26) |
Apr
|
May
|
Jun
(2) |
Jul
(4) |
Aug
(6) |
Sep
|
Oct
|
Nov
(5) |
Dec
(2) |
| 2009 |
Jan
(63) |
Feb
(4) |
Mar
(12) |
Apr
|
May
(5) |
Jun
(1) |
Jul
|
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2010 |
Jan
|
Feb
(14) |
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2011 |
Jan
(2) |
Feb
(1) |
Mar
(2) |
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(5) |
| 2012 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(3) |
Sep
|
Oct
|
Nov
(2) |
Dec
|
| 2013 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Melchior F. <mf...@us...> - 2005-07-05 06:01:55
|
I had responded immediately after my first message showed up on the list, but then I used the wrong mail address. And the bloody sf.net server didn't complain, so it took me a while to notice. Here again: The patch from yesterday wasn't complete: it hadn't considered, that the same bug would happen in puts() after "\n", and also in putch(). The attached patch fixes that, too. But I'm not sure if I did it right. I set the RasterPos only with 2i, assuming that the z-component would be zero in all cases. Is this true? Or should I rather have used: glRasterPos3f(0.0f, 0.0f, curpos[2]) in all three cases instead? m. |
|
From: Bram S. <br...@sa...> - 2005-07-04 15:00:01
|
Bram Stolk wrote: > I have cvs write access, and will commit this patch. committed... examples/src/fnt still works. Bram |
|
From: Steve B. <sjb...@ai...> - 2005-07-04 14:56:29
|
Bram Stolk wrote: > Franz, > > > At first glance, this looks like good detective-work by you. > I have cvs write access, and will commit this patch. > > Please note that I assume the following: > -1- This still works in cases with positive coords :-) > -2- You tested your own patch and found it to be satisfactory. > Let me know if these assumptions are incorrect. It's an ugly hack - but it *is* the ugly hack that the OpenGL standard approves of. I've used it quite a few times, so I know it works. You can go ahead an commit it - I know it'll work. ---------------------------- Steve Baker ------------------------- HomeEmail: <sjb...@ai...> WorkEmail: <sj...@li...> HomePage : http://www.sjbaker.org Projects : http://plib.sf.net http://tuxaqfh.sf.net http://tuxkart.sf.net http://prettypoly.sf.net -----BEGIN GEEK CODE BLOCK----- GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M- V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++ -----END GEEK CODE BLOCK----- |
|
From: Bram S. <br...@sa...> - 2005-07-04 14:50:54
|
Franz,
At first glance, this looks like good detective-work by you.
I have cvs write access, and will commit this patch.
Please note that I assume the following:
-1- This still works in cases with positive coords :-)
-2- You tested your own patch and found it to be satisfactory.
Let me know if these assumptions are incorrect.
Bram
Melchior FRANZ wrote:
> plib does currently not display bitmap fonts with negative coordinates.
> As soon as a the first character in a string lies outside the viewport
> (movable dialogs!), the *whole* string isn't displayed.
>
> The reason is, that glBitmap() must not get called on negative coordinates.
> Its manpage says:
>
> NOTES
> To set a valid raster position outside the viewport, first set
> a valid raster position inside the viewport, then call glBitmap
> with NULL as the bitmap parameter and with xmove and ymove set to
> the offsets of the new raster position. This technique is useful
> when panning an image around the viewport.
>
> This is done by the attached patch, and it fixes the bug.
> Please review and apply!
>
> m.
>
>
> ------------------------------------------------------------------------
>
> Index: fntBitmap.cxx
> ===================================================================
> RCS file: /cvsroot/plib/plib/src/fnt/fntBitmap.cxx,v
> retrieving revision 1.1
> diff -u -p -r1.1 fntBitmap.cxx
> --- fntBitmap.cxx 15 Feb 2004 19:51:23 -0000 1.1
> +++ fntBitmap.cxx 4 Jul 2005 14:22:49 -0000
> @@ -84,7 +84,9 @@ void fntBitmapFont::putch ( sgVec3 curpo
> void fntBitmapFont::puts ( sgVec3 curpos, float pointsize, float italic, const char *s )
> {
> float x0 = curpos[0];
> - glRasterPos3fv(curpos);
> + glRasterPos2i(0, 0);
> + glBitmap(0, 0, 0, 0, curpos[0], curpos[1], NULL);
> +
> for (int i = 0; s[i] != '\0'; i++) {
> if (s[i] == '\n') {
> curpos[0] = x0;
|
|
From: Melchior F. <mf...@us...> - 2005-07-04 14:34:47
|
plib does currently not display bitmap fonts with negative coordinates.
As soon as a the first character in a string lies outside the viewport
(movable dialogs!), the *whole* string isn't displayed.
The reason is, that glBitmap() must not get called on negative coordinates.
Its manpage says:
NOTES
To set a valid raster position outside the viewport, first set
a valid raster position inside the viewport, then call glBitmap
with NULL as the bitmap parameter and with xmove and ymove set to
the offsets of the new raster position. This technique is useful
when panning an image around the viewport.
This is done by the attached patch, and it fixes the bug.
Please review and apply!
m.
|
|
From: Steve B. <sjb...@ai...> - 2005-05-20 02:42:11
|
FranXois Saulnier wrote: > My question is what do I have to do to load it with ssg > What need my function LoadMSDF to implement to load a simple triangle I suggest you look at the existing loaders. plib/src/ssg/ssgLoadTRI.cxx is probably closest to what you want. ---------------------------- Steve Baker ------------------------- HomeEmail: <sjb...@ai...> WorkEmail: <sj...@li...> HomePage : http://www.sjbaker.org Projects : http://plib.sf.net http://tuxaqfh.sf.net http://tuxkart.sf.net http://prettypoly.sf.net -----BEGIN GEEK CODE BLOCK----- GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M- V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++ -----END GEEK CODE BLOCK----- |
|
From: Steve B. <sjb...@ai...> - 2005-05-20 02:40:40
|
Kevin Walchko wrote: > Why don't you use templates for your sg math functions for floats and > doubles. Portability onto some of the more obscure platforms we support has proven tricky where templates are present. SG changes only very rarely - so maintaining two copies of everything is very little effort. ---------------------------- Steve Baker ------------------------- HomeEmail: <sjb...@ai...> WorkEmail: <sj...@li...> HomePage : http://www.sjbaker.org Projects : http://plib.sf.net http://tuxaqfh.sf.net http://tuxkart.sf.net http://prettypoly.sf.net -----BEGIN GEEK CODE BLOCK----- GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M- V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++ -----END GEEK CODE BLOCK----- |
|
From: Bram S. <br...@sa...> - 2005-05-19 14:35:13
|
IkZyYW7vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73v v73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73v v73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv70iIHdyb3RlOg0KDQo+ IE15IHF1ZXN0aW9uIGlzIHdoYXQgZG8gSSBoYXZlIHRvIGRvIHRvIGxvYWQgaXQgd2l0aCBz c2cgDQo+IFdoYXQgbmVlZCBteSBmdW5jdGlvbiBMb2FkTVNERiB0byBpbXBsZW1lbnQgdG8g bG9hZCBhIHNpbXBsZSB0cmlhbmdsZQ0KPiBUaGFua3MNCg0KaHR0cDovL3BsaWIuc291cmNl Zm9yZ2UubmV0L3NzZy9Mb2FkZXJXcml0ZXIuaHRtbA0KDQo= |
|
From: François S. <le....@wa...> - 2005-05-19 14:29:37
|
Yes and ... > Message du 19/05/05 16:08 > De : "Bram Stolk" <br...@sa...> > A : pli...@li... > Copie à : > Objet : Re: [Plib-devel] How to make a loader for ssg > > |
|
From: Bram S. <br...@sa...> - 2005-05-19 14:06:01
|
IkZyYW7vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73v v73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73v v73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv70iIHdyb3RlOg0KPiBJ IGhhdmUgZGVmaW5lIG15IG93biBzY2VuZSBkZXNjcmlwdGlvbiBmb3JtYXQgKE1TREYpIGZv ciBzY2VuZXMgd2hpY2ggbG9va3MgbGlrZSB0aGF0IGZvciBhIHRyaWFuZ2xlOg0KDQo+IE15 IHF1ZXN0aW9uIGlzIHdoYXQgZG8gSSBoYXZlIHRvIGRvIHRvIGxvYWQgaXQgd2l0aCBzc2cg DQo+IFdoYXQgbmVlZCBteSBmdW5jdGlvbiBMb2FkTVNERiB0byBpbXBsZW1lbnQgdG8gbG9h ZCBhIHNpbXBsZSB0cmlhbmdsZQ0KPiBUaGFua3MNCg0KaHR0cDovL3BsaWIuc291cmNlZm9y Z2UubmV0L3NzZy9Mb2FkZXJXcml0ZXIuaHRtbA0K |
|
From: Kevin W. <wa...@co...> - 2005-05-19 12:33:03
|
Hi, Why don't you use templates for your sg math functions for floats and doubles. It would make maintaining them easier. I noticed this discussion has occurred previously in the archives, but I don't know what ever became of it. Later. Kevin |
|
From: François S. <le....@wa...> - 2005-05-19 12:01:53
|
I have define my own scene description format (MSDF) for scenes which looks like that for a triangle:
tri{
0.0 0.0 1.0
0.0 0.0 0.0
0.0 1.0 0.0
}
I have a parser for my scene description format which loads datas in a C structure like
struct tri{
Vert x ;
Vert y ;
Vert z ;
}
My question is what do I have to do to load it with ssg
What need my function LoadMSDF to implement to load a simple triangle
Thanks
|
|
From: Fay J. F C. AAC/W. <joh...@eg...> - 2005-05-06 19:14:47
|
Gentlemen, Since JC Jones has very kindly given me CVS write access, I have put a bunch of changes into the CVS versions of PUIO and "puAux". In particular, - PUI now allows the application to specify which mouse button activates a widget - PUI now allows the application to specify when a widget is deactivated (calling the down callback)--when the mouse button is released or when the next widget is activated - puAux has a new widget, the "puaList" submitted by somebody and not particularly tested at all, at least not by me - puaLargeInput no longer refers to deprecated PUI widgets - puaCOmboBox has been reworked extensively, so that now it works in my application; any flames over it suddenly not working for others should be directed towards me (I'll put on my asbestos underwear) - puaBiSliderWithEnds now has two-pixel gaps between the slider and the end boxes I've updated the "puAux.dsp" file to reflect the new "puaList.cxx" file, but it will need to be checked out and tested for Linux line-endings before we release next. I _think_ I got all the changes in the list. Please let me know how things work for your applications. John F. Fay 850-729-6330 joh...@eg... |
|
From: Steve B. <sjb...@ai...> - 2005-05-05 02:39:17
|
Bram Stolk wrote: > Trammell Hudson wrote: > >> I can envision a HOTAS stick and radio stack with far more than 64 or >> 128 buttons or knobs. Who wants to go down in history as having said >> that: >> >> 64 buttons should be enough for anybody. But would you *really* approach that problem using the joystick API? That makes no sense at all. Once you're interfacing to an entire cockpit mockup, you likely also have a bazillion little lights to light up, things like instruments - you name it. At that point, you're going to need a much more serious API. > I think we should consult the man (Steve :-) ) before doing > API changes. Maybe a good solution would be to extend the API, > instead of changing it. Have a 32 button member func, and a n-button > member func in addition. Yeah - but if we do that, we shouldn't just go to a 64 bit word - we should switch to a bool array of variable length or something. But whatever we do, the present API *must* be retained and must continue to work ok for the first 32 buttons. ---------------------------- Steve Baker ------------------------- HomeEmail: <sjb...@ai...> WorkEmail: <sj...@li...> HomePage : http://www.sjbaker.org Projects : http://plib.sf.net http://tuxaqfh.sf.net http://tuxkart.sf.net http://prettypoly.sf.net -----BEGIN GEEK CODE BLOCK----- GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M- V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++ -----END GEEK CODE BLOCK----- |
|
From: Trammell H. <hud...@sw...> - 2005-05-04 23:35:56
|
On Wed, May 04, 2005 at 04:12:55PM -0700, Steve Baker wrote: > Trammell Hudson wrote: > >I've recently started using a Saitek X52 joystick with my Linux box and > >have run into problems with plib's JS module limitation in the number > >of supported buttons. It only supports up to 32 buttons due to the > >MAX_BUTTONS definition and the fact that it uses an int to store the > >button state, but the X52 has 34 buttons (and 12 axes). > > That's practically a keyboard! I'm not sure I could touch type on it -- I have enough trouble remembering which button is "lower the flaps" and which one will irrevocably initiate the autodestruct sequence. > [...] > I personally find it very hard to believe that there are any > applications out there that would actually use that many - so > for now, I'm not inclined to change the interface to support > more buttons. Flight simulators have an insatiable desire for more buttons and axes. In this case, I have a subset of these mapped, depending on the flight model that I am debugging: Flaps up/down Gear up/down Speed brakes up/down Arrestor hook up/down Forward view POV "Check 6" Autopilot mode Autopilot heading bug left/right Drouge chute Ejector seat Left brake Right brake Timer start/stop/reset Elevator trim up/down/reset Rudder trim left/right/reset Vector sweep forward/aft Thrust vector up/down Weapon select Pause Engine start Flight model load/save/reset > If there is a bug to fix in *limiting* the number of buttons > to 32 - then we should fix that. plib doesn't seem to have a problem, but other applications do. xplane, for instance, maps 32 -> 0 and 33 -> 1 on Linux. On OS X, it doesn't see any button higher than 16 (I think -- not all of them work and I haven't done any serious debugging on it). > >Changing tmp_buttons to a uint64_t, updating the arguments to > >jsJoystick::rawRead and jsJoystick::read fixed that for me. > > But it would break other applications. We absolutely cannot do that. Exactly, which I why I cautioned against on making the change too soon, since there is probably a better way to represent button state rather than a single integral type bitmask. It worked for me on my system, but I was recompiling plib, SimGear and FlightGear from source, so there was no problem with binary compatibility. Trammell |
|
From: Fay J. F C. AAC/W. <joh...@eg...> - 2005-05-04 21:27:50
|
Heh, heh, you won't find _that_ getting into "freeglut" any time soon! What Steve didn't address--apart from the (at the moment) very limited application of a 34-button joystick--is the question of an interface extension: "jsJoystick::read64 ( ... )" and "jsJoystick::rawRead64 ( ... )". Those would not break any existing applications. John F. Fay joh...@eg... 850-729-6330 -----Original Message----- From: pli...@li... [mailto:pli...@li...] On Behalf Of Steve Baker Sent: Wednesday, May 04, 2005 6:13 PM To: pli...@li... Subject: Re: [Plib-devel] Saitek X52 joystick with 34 buttons Trammell Hudson wrote: > I've recently started using a Saitek X52 joystick with my Linux box and > have run into problems with plib's JS module limitation in the number > of supported buttons. It only supports up to 32 buttons due to the > MAX_BUTTONS definition and the fact that it uses an int to store the > button state, but the X52 has 34 buttons (and 12 axes). That's practically a keyboard! Changing PLIB to support more than 32 buttons would break 100% of joystick using applications. I personally find it very hard to believe that there are any applications out there that would actually use that many - so for now, I'm not inclined to change the interface to support more buttons. If there is a bug to fix in *limiting* the number of buttons to 32 - then we should fix that. > Changing tmp_buttons to a uint64_t, updating the arguments to > jsJoystick::rawRead and jsJoystick::read fixed that for me. But it would break other applications. We absolutely cannot do that. ---------------------------- Steve Baker ------------------------- HomeEmail: <sjb...@ai...> WorkEmail: <sj...@li...> HomePage : http://www.sjbaker.org Projects : http://plib.sf.net http://tuxaqfh.sf.net http://tuxkart.sf.net http://prettypoly.sf.net -----BEGIN GEEK CODE BLOCK----- GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M- V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++ -----END GEEK CODE BLOCK----- ------------------------------------------------------- This SF.Net email is sponsored by: NEC IT Guy Games. Get your fingers limbered up and give it your best shot. 4 great events, 4 opportunities to win big! Highest score wins.NEC IT Guy Games. Play to win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20 _______________________________________________ plib-devel mailing list pli...@li... https://lists.sourceforge.net/lists/listinfo/plib-devel |
|
From: Steve B. <sjb...@ai...> - 2005-05-04 21:20:19
|
Trammell Hudson wrote: > I've recently started using a Saitek X52 joystick with my Linux box and > have run into problems with plib's JS module limitation in the number > of supported buttons. It only supports up to 32 buttons due to the > MAX_BUTTONS definition and the fact that it uses an int to store the > button state, but the X52 has 34 buttons (and 12 axes). That's practically a keyboard! Changing PLIB to support more than 32 buttons would break 100% of joystick using applications. I personally find it very hard to believe that there are any applications out there that would actually use that many - so for now, I'm not inclined to change the interface to support more buttons. If there is a bug to fix in *limiting* the number of buttons to 32 - then we should fix that. > Changing tmp_buttons to a uint64_t, updating the arguments to > jsJoystick::rawRead and jsJoystick::read fixed that for me. But it would break other applications. We absolutely cannot do that. ---------------------------- Steve Baker ------------------------- HomeEmail: <sjb...@ai...> WorkEmail: <sj...@li...> HomePage : http://www.sjbaker.org Projects : http://plib.sf.net http://tuxaqfh.sf.net http://tuxkart.sf.net http://prettypoly.sf.net -----BEGIN GEEK CODE BLOCK----- GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M- V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++ -----END GEEK CODE BLOCK----- |
|
From: Bram S. <br...@sa...> - 2005-05-04 17:55:26
|
Trammell Hudson wrote: > I can envision a HOTAS stick and radio stack with far more than 64 or > 128 buttons or knobs. Who wants to go down in history as having said > that: > > 64 buttons should be enough for anybody. He he he ... good one! I think we should consult the man (Steve :-) ) before doing API changes. Maybe a good solution would be to extend the API, instead of changing it. Have a 32 button member func, and a n-button member func in addition. PS: ofcourse I recognized you as the Wizard of aerial robotics :-) Bram > > Trammell > > > ------------------------------------------------------- > This SF.Net email is sponsored by: NEC IT Guy Games. > Get your fingers limbered up and give it your best shot. 4 great events, 4 > opportunities to win big! Highest score wins.NEC IT Guy Games. Play to > win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20 > _______________________________________________ > plib-devel mailing list > pli...@li... > https://lists.sourceforge.net/lists/listinfo/plib-devel |
|
From: Trammell H. <hud...@sw...> - 2005-05-04 17:37:04
|
On Wed, May 04, 2005 at 10:00:08AM -0700, Andy Ross wrote: > In this case, though, I wonder if perhaps the joystick bitmask could > just be stored in a unsigned char array instead rather than playing > portability games with the preprocessor. The other problem with making the arguments uint64_t* is that it is a user-visible change and would require all clients of the jsJoystick class to update their code. I agree that if there is to be a change with the number of supported buttons that it should be done the "right way", rather than another temporary postponement of the inevitable. I can envision a HOTAS stick and radio stack with far more than 64 or 128 buttons or knobs. Who wants to go down in history as having said that: 64 buttons should be enough for anybody. Trammell |
|
From: Fay J. F C. AAC/W. <joh...@eg...> - 2005-05-04 17:21:32
|
Gentlemen, Unfortunately Windows does not recognize "uint64_t". Instead they have their own 64-bit integer keyword, "__int64". I am sure that a "typedef" would help matters, but that introduces an operating-system-specific conditional compile into the "js.h" file. John F. Fay joh...@eg... 850-729-6330 -----Original Message----- From: pli...@li... [mailto:pli...@li...] On Behalf Of Bram Stolk Sent: Wednesday, May 04, 2005 11:25 AM To: pli...@li... Subject: Re: [Plib-devel] Saitek X52 joystick with 34 buttons <snip> Hi Trammell! I'll be happy to commit your changes to CVS. However, before I do that, I need to check for portability. jsLinux.cxx is pretty safe to adapt. However, js.h is cross-platform, and I wonder about the portability of uint64_t. Do all plib platforms know uint64_t ? <snip> |
|
From: Andy R. <an...@pl...> - 2005-05-04 17:02:40
|
Bram Stolk wrote: > jsLinux.cxx is pretty safe to adapt. > However, js.h is cross-platform, and I wonder about the > portability of uint64_t. Do all plib platforms know uint64_t? The subject came up recently on the FlightGear list, and the upshot is that everyone but Microsoft supports the stdint.h header in recent compiler versions. MSVC does, however, have 64 bit integer types, so what we did is something to the effect of: #ifdef _WIN32 typedef unsigned long long uint64_t; #else #include <stdint.h> #endif etc... In this case, though, I wonder if perhaps the joystick bitmask could just be stored in a unsigned char array instead rather than playing portability games with the preprocessor. Andy |
|
From: Trammell H. <hud...@sw...> - 2005-05-04 16:39:40
|
On Wed, May 04, 2005 at 06:24:50PM +0200, Bram Stolk wrote: > Trammell Hudson wrote: > >I've recently started using a Saitek X52 joystick with my Linux box and > >have run into problems with plib's JS module limitation in the number > >of supported buttons. [...] > > Hi Trammell! Don't we know each other from somewhere else? > I'll be happy to commit your changes to CVS. > However, before I do that, I need to check for portability. > > jsLinux.cxx is pretty safe to adapt. > However, js.h is cross-platform, and I wonder about the > portability of uint64_t. Do all plib platforms know uint64_t ? It is defined in C99 and many platforms have supported it as part of the C9X preliminary standard for the past five years. I can't speak to anything other than Unix like platforms, all of which support it (Linux, BSD, Cygwin and OS X). I only ever use gcc compilers, so this answered the question for me: http://gcc.gnu.org/c99status.html > It seems to be defined by stdint.h, which is included in inttypes.h I don't believe plib is targetting any non-hosted, free standing environments, so you should be safe to include the larger <inttypes.h> header, which also provides formatting macros, etc. Trammell |
|
From: Bram S. <br...@sa...> - 2005-05-04 16:25:05
|
Trammell Hudson wrote: > I've recently started using a Saitek X52 joystick with my Linux box and > have run into problems with plib's JS module limitation in the number > of supported buttons. It only supports up to 32 buttons due to the > MAX_BUTTONS definition and the fact that it uses an int to store the > button state, but the X52 has 34 buttons (and 12 axes). This code in > jsLinux.cxx is the problem: Hi Trammell! I'll be happy to commit your changes to CVS. However, before I do that, I need to check for portability. jsLinux.cxx is pretty safe to adapt. However, js.h is cross-platform, and I wonder about the portability of uint64_t. Do all plib platforms know uint64_t ? It seems to be defined by stdint.h, which is included in inttypes.h This is something I found with google on the subject of inttypes (which seems incompatible with Nec SX-5 super computers ;-) In the email thread, a lack of standardization is mentioned. http://www.cactuscode.org/pipermail/developers/2004-September/000608.html So... what to do? Bram Stolk > > case JS_EVENT_BUTTON : > if ( os->js.value == 0 ) /* clear the flag */ > os->tmp_buttons &= ~(1 << os->js.number) ; > else > os->tmp_buttons |= (1 << os->js.number) ; > break ; > > Changing tmp_buttons to a uint64_t, updating the arguments to > jsJoystick::rawRead and jsJoystick::read fixed that for me. > > Another problem is that the mode switch holds down one of three > buttons depending on which of the three modes is selected. This > interferes with the calibration routine used by FlightGear and > required me to modify the fgjs program. Any code that uses > level triggered button handling may run into starvation as it > always services the mode buttons. > > With FC3 I had to patch my kernel's USB hid-core file, as documented > here to deal with the slow joystick device. Apparently Saitek has some > problems across their entire product line -- the patch was originally > for an X45 joystick, but works for the X52 as well: > > http://baron.flightgear.org/pipermail/flightgear-users/2004-July/008234.html > > Trammell > > > ------------------------------------------------------- > This SF.Net email is sponsored by: NEC IT Guy Games. > Get your fingers limbered up and give it your best shot. 4 great events, 4 > opportunities to win big! Highest score wins.NEC IT Guy Games. Play to > win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20 > _______________________________________________ > plib-devel mailing list > pli...@li... > https://lists.sourceforge.net/lists/listinfo/plib-devel |
|
From: Trammell H. <hud...@sw...> - 2005-05-04 15:21:07
|
I've recently started using a Saitek X52 joystick with my Linux box and
have run into problems with plib's JS module limitation in the number
of supported buttons. It only supports up to 32 buttons due to the
MAX_BUTTONS definition and the fact that it uses an int to store the
button state, but the X52 has 34 buttons (and 12 axes). This code in
jsLinux.cxx is the problem:
case JS_EVENT_BUTTON :
if ( os->js.value == 0 ) /* clear the flag */
os->tmp_buttons &= ~(1 << os->js.number) ;
else
os->tmp_buttons |= (1 << os->js.number) ;
break ;
Changing tmp_buttons to a uint64_t, updating the arguments to
jsJoystick::rawRead and jsJoystick::read fixed that for me.
Another problem is that the mode switch holds down one of three
buttons depending on which of the three modes is selected. This
interferes with the calibration routine used by FlightGear and
required me to modify the fgjs program. Any code that uses
level triggered button handling may run into starvation as it
always services the mode buttons.
With FC3 I had to patch my kernel's USB hid-core file, as documented
here to deal with the slow joystick device. Apparently Saitek has some
problems across their entire product line -- the patch was originally
for an X45 joystick, but works for the X52 as well:
http://baron.flightgear.org/pipermail/flightgear-users/2004-July/008234.html
Trammell
|
|
From: Fay J. F C. AAC/W. <joh...@eg...> - 2005-04-14 14:47:09
|
Gentlemen, Has anybody worked with submenus in PUI? By "submenus" I mean that the user clicks on a button on the menu bar and a drop-down menu drops down. One (or more) of the entries in the drop-down menu has a right-pointing error at its right-hand edge; when the user moves the mouse (or clicks the mouse) on this entry and another drop-down menu appears to the right of the entry with its top entry level with the top of the entry. The "freeglut" library has these--implemented with considerable difficulty and still (I believe) not working perfectly. If PUI has this capability I'd like to hear about it; if not I anticipate the painful process (with the "freeglut" owner's permission) of moving code over. John F. Fay 850-729-6330 joh...@eg... |
34 messages has been excluded from this view by a project administrator.
