plib-devel Mailing List for PLIB (Page 30)

Brought to you by: sjbaker

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

Flat | Threaded

<< < 1 .. 28 29 30 31 32 .. 367 > >> (Page 30 of 367)

Re: [Plib-devel] SSG: Using the bitmap loaders for own texture classes?

From: <p.l...@ci...> - 2005-08-12 15:06:46

You could approach by overriding the default createTexture() method in the
ssgLoaderOptions class, which is then used by almost all 3D loaders. To do
that:

class LoaderOpts_CustomCreateTextures : public ssgLoaderOptions
{
public:
  virtual void createTexture( char* tfname, int wrapu, int wrapv, int mipmap )
  {
    // fill it with your code
    // refer to the default ssgLoaderOptions::createTexture in ssgLoad.cxx
  }
}

LoaderOpts_CustomCreateTextures loader_opts;

ssgSetCurrentOptions( &loader_opts );

// all further calls to ssgLoad() will call
LoaderOpts_CustomCreateTextures:createTexture()

Greetings -

Paolo



Scrive Jan Reucker <slo...@gm...>:

> Hello,
>
> I'm planning to create my own ssgTexture classes, because I need
> some special handling not covered by the standard ssgTextures:
>
> - subdivision of large bitmaps (1536x1536 or 2048x2048) into
>   small textures suitable for the given OpenGL implementation
> - no mipmapping
> - GL_CLAMP_TO_EDGE, if supported by the implementation,
>   GL_CLAMP otherwise
>
> Creating the texture class wouldn't be a problem, but I'd
> like to use SSG's bitmap loaders to get access to all
> supported file types at once. The only problem is that the
> loader routines automatically call ssgMakeMipmaps() to create
> the textures which is, in my situation, not applicable.
>
> Wouldn't it be a useful extension to SSG if the loaders could
> be accessed separately if someone only needs the raw pixels?
> What do you think?
>
> Kind regards,
> Jan R.
>
> --
> Jan Reucker
> email: jan dot reucker at web dot de
> web:   http://www.reucker-online.de
>
>
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
> _______________________________________________
> plib-devel mailing list
> pli...@li...
> https://lists.sourceforge.net/lists/listinfo/plib-devel
>

[Plib-devel] SSG: Using the bitmap loaders for own texture classes?

From: Jan R. <slo...@gm...> - 2005-08-11 19:17:23

Hello,

I'm planning to create my own ssgTexture classes, because I need
some special handling not covered by the standard ssgTextures:

- subdivision of large bitmaps (1536x1536 or 2048x2048) into
  small textures suitable for the given OpenGL implementation
- no mipmapping
- GL_CLAMP_TO_EDGE, if supported by the implementation,
  GL_CLAMP otherwise

Creating the texture class wouldn't be a problem, but I'd
like to use SSG's bitmap loaders to get access to all
supported file types at once. The only problem is that the
loader routines automatically call ssgMakeMipmaps() to create
the textures which is, in my situation, not applicable.

Wouldn't it be a useful extension to SSG if the loaders could
be accessed separately if someone only needs the raw pixels?
What do you think?

Kind regards,
Jan R.

-- 
Jan Reucker
email: jan dot reucker at web dot de
web:   http://www.reucker-online.de

Re: [Plib-devel] noisy font

From: Steve B. <sjb...@ai...> - 2005-08-06 03:02:15

Fay John F Contr AAC/WMG wrote:
> Bram,
> 
>         The first thing I would note is that the "hello_world" font is 
> 30 points while the "fnt_test" fonts are 25 points.  That seems to make 
> a big difference; when I changed the "hello_world" font size to 25 
> points it looked a lot like the other.
> 
>         This raises the next question:  why does changing the point size 
> make the rendering that much noisier?

Well, fonts are rendered using textures.

If you have a texture that's (say) 25 texels high - and you stretch it
out to cover (say) 30 pixels - what happens?

If the texture map's magnification filter is set to interpolated sampling
(GL_LINEAR) then every display pixel will be linearly interpolated between
the two texels closest to the ideal position.  This generally results in a
certain amount of blurring in the map.

On the other hand, if the texture map's magnification filter is set up
for point sampling (GL_NEAREST) then you'll find that every fifth texel
is duplicated to fill the gaps you'd get from stretching the texture.
This produces the 'noisier' look that you are seeing.

So - take your pick!  Noisy or blurry?

The only way to get reasonably crisp fonts from texture is to render
using GL_NEAREST and to render the font at the exact size of the map.
Going to exactly twice the size also works reasonably well providing
your screen is high enough resolution that you can stand the blockiness
you get from doubling the size of the texels in the font.

On higher resolution displays, GL_LINEAR looks better to my eyes.  It's
a little blurrier - but it stays looking pretty much the same over a
wider range of sizes.

---------------------------- 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-----

RE: [Plib-devel] noisy font

From: Fay J. F C. AAC/W. <joh...@eg...> - 2005-08-05 23:03:04

Bram,

	The first thing I would note is that the "hello_world" font is 30
points while the "fnt_test" fonts are 25 points.  That seems to make a big
difference; when I changed the "hello_world" font size to 25 points it
looked a lot like the other.

	This raises the next question:  why does changing the point size
make the rendering that much noisier?

John F. Fay
Technical Fellow, Jacobs/Sverdrup TEAS Group
joh...@eg...
850-729-6330 
-----Original Message-----
From: pli...@li...
[mailto:pli...@li...] On Behalf Of Bram Stolk
Sent: Friday, August 05, 2005 3:41 AM
To: pli...@li...
Subject: [Plib-devel] noisy font

Hello,

Is it normal that the examples/src/fnt/hello_world rendering
looks rather noisy?

http://stolk.org/tmp/plibfnt.tiff

The renderings from fnt_test look better than hello_world for me.

  Bram


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
plib-devel mailing list
pli...@li...
https://lists.sourceforge.net/lists/listinfo/plib-devel

[Plib-devel] noisy font

From: Bram S. <br...@sa...> - 2005-08-05 08:40:03

Hello,

Is it normal that the examples/src/fnt/hello_world rendering
looks rather noisy?

http://stolk.org/tmp/plibfnt.tiff

The renderings from fnt_test look better than hello_world for me.

  Bram

RE: [Plib-devel] md2

From: Fay J. F C. AAC/W. <joh...@eg...> - 2005-08-03 16:42:16

Gentlemen,
 
    Should the change in (2) below be put into CVS?
 

John F. Fay
Technical Fellow, Jacobs/Sverdrup TEAS Group
joh...@eg...
850-729-6330 

 

  _____  

From: pli...@li...
[mailto:pli...@li...] On Behalf Of
ha...@th...
Sent: Monday, July 25, 2005 4:18 AM
To: pli...@li...
Subject: [Plib-devel] md2



I use the md2 format in qcake (http://www.qcake.org)

1. 

On Intel System it works. On PPC-Linux and OSX i have problems. I think
tihis is an endian problem.

The md2 loader reads the binary data from the file in the memory in a
strucht pointer. On ppc the byteorder is not the same as on intel systems.

 2. I have changed the routine to load a bmp texturfile if it ist not
devined in the md2 File, it works fine.

I use md2 files from cube. I convert the skin files to bmp und rotate them. 


-- SNIP -- 

 


static ssgEntity * convert_to_ssg()
{
    sgVec3 vert;
    sgVec2 uv; 



  ...
  ...


    /**Activate the first state*/
    if(stated)
        states -> selectStep( 0 );
    else {
        ulSetError(UL_WARNING, "LoadMD2: No skins specified in MD2 file! use
skin.bmp");

      ssgSimpleState *state = new ssgSimpleState();
          state ->  enable ( GL_TEXTURE_2D );
          state ->  setTexture( current_options -> createTexture (
"skin.bmp" ) );
          states -> setStep(0, state);
          states -> selectStep( 0 );
    }

} 

-- SNIP --
 





------------------------------------------------------- SF.Net email is
sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple
to follow Roadmaps, straightforward articles, informative Webcasts and more!
Get everything you need to get up to speed, fast.
http://ads.osdn.com/?ad_idt77&alloc_id492&op=click
_______________________________________________ plib-devel mailing list
pli...@li...
https://lists.sourceforge.net/lists/listinfo/plib-devel

[Plib-devel] md2

From: <ha...@th...> - 2005-07-25 09:18:39

<p>I use the md2 format in qcake (http://www.qcake.org)</p><p>1.&nbsp;</p><=
p>On Intel System it works. On PPC-Linux and OSX i have problems. I think t=
ihis is an endian problem.</p><p>The md2 loader reads the binary data from =
the file in the memory in a strucht pointer. On ppc the byteorder is not th=
e same as on intel systems.</p><p>&nbsp;2. I have changed the routine to lo=
ad a bmp texturfile if it ist not devined in the md2 File, it works fine.</=
p><p>I use md2 files from cube. I convert the skin files to bmp und rotate =
them. <br /></p><p>-- SNIP -- </p><p>&nbsp;</p><p><p>static ssgEntity * con=
vert_to_ssg()<br />{<br />&nbsp;&nbsp;&nbsp; sgVec3 vert;<br />&nbsp;&nbsp;=
&nbsp; sgVec2 uv; <br /></p></p><p><p>&nbsp; ...<br />&nbsp; ...<br />  </p=
><p>&nbsp;&nbsp;&nbsp; /**Activate the first state*/<br />&nbsp;&nbsp;&nbsp=
; if(stated)<br />&nbsp;&nbsp;&nbsp; &nbsp;&nbsp; &nbsp;states -&gt; select=
Step( 0 );<br />&nbsp;&nbsp;&nbsp; else {<br />&nbsp;&nbsp;&nbsp; &nbsp;&nb=
sp; &nbsp;ulSetError(UL_WARNING, &quot;LoadMD2: No skins specified in MD2 f=
ile! use skin.bmp&quot;);<br /><br />&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ssgSimp=
leState *state =3D new ssgSimpleState();<br />&nbsp;&nbsp;&nbsp; &nbsp;&nbs=
p; &nbsp;&nbsp; state -&gt;&nbsp; enable ( GL_TEXTURE_2D );<br />&nbsp;&nbs=
p;&nbsp; &nbsp;&nbsp; &nbsp;&nbsp; state -&gt;&nbsp; setTexture( current_op=
tions -&gt; createTexture ( &quot;skin.bmp&quot; ) );<br />&nbsp;&nbsp;&nbs=
p; &nbsp;&nbsp; &nbsp;&nbsp; states -&gt; setStep(0, state);<br />&nbsp;&nb=
sp;&nbsp; &nbsp;&nbsp; &nbsp;&nbsp; states -&gt; selectStep( 0 );<br />&nbs=
p;&nbsp;&nbsp; }</p><p>}&nbsp;</p></p><p>-- SNIP --<br />&nbsp;</p><p><br /=
></p><BR>=

Re: [Plib-devel] [BUG] Minor bug in ulClock

From: Joerg H. <jo...@lu...> - 2005-07-20 12:34:36

Hi John,

 > Is there a reason we shouldn't set "delta" in "reset()" to 0.0000001
 > (its minimum value in update() ) rather than 1.0 / 30.0 ?  I value the
 > consistency, which I would consider a good enough reason to change it.

Sorry, I was busy - yes, I agree that this should be changed to be 
consistent. And thanks for fixing the bug!

Cheers,
    Joerg

-- 
----------------------------------------------------------------
Joerg Henrichs
Luding Administration
e-mail: jo...@lu...
URL:    http://luding.org

RE: [Plib-devel] [BUG] Minor bug in ulClock

From: Fay J. F C. AAC/W. <joh...@eg...> - 2005-07-19 13:21:26

Gentlemen,
 
    Not hearing any screams of anguish, I am changing "ul.h" to set the
"delta" variable in "ulClock::reset()" to 0.0000001 instead of 1.0/30.0 .
This makes the reset function consistent with the update function.
 

John F. Fay
Technical Fellow, Jacobs/Sverdrup TEAS Group
joh...@eg...
850-729-6330 

 

  _____  

From: pli...@li...
[mailto:pli...@li...] On Behalf Of Fay John F
Contr AAC/WMG
Sent: Thursday, July 14, 2005 12:06 PM
To: pli...@li...
Subject: RE: [Plib-devel] [BUG] Minor bug in ulClock



Joerg, 

        Thank you very much for spotting that.  I am putting the fix into
CVS.  I also set "now" to zero seconds in reset(), making it consistently
"seconds since reset" instead of starting out being "seconds since epoch"
and then changing.

Folks, 

        Is there a reason we shouldn't set "delta" in "reset()" to 0.0000001
(its minimum value in update() ) rather than 1.0 / 30.0 ?  I value the
consistency, which I would consider a good enough reason to change it.

John F. Fay 
Technical Fellow, Jacobs/Sverdrup TEAS Group 
850-729-6330 
joh...@eg...

RE: [Plib-devel] trivial bug in jsLinuxOld.cxx

From: Fay J. F C. AAC/W. <joh...@eg...> - 2005-07-16 17:29:02

Stanislaus,

	In the department of "Better Late Than Never," I have committed your
change.

	I thank JC Jones one more time for his "pCVSc" program.

John F. Fay
Technical Fellow, Jacobs/Sverdrup TEAS Group
joh...@eg...
850-729-6330 
-----Original Message-----
From: pli...@li...
[mailto:pli...@li...] On Behalf Of Stanislav
Ievlev
Sent: Tuesday, February 08, 2005 5:49 AM
To: pli...@li...
Subject: [Plib-devel] trivial bug in jsLinuxOld.cxx

Greetings!

You have a little mistake in the #ifdefs

jsLinux.cxx
--
#if defined(JS_VERSION) && JS_VERSION >= 0x010000 
--

jsLinuxOld.cxx
--
#if !defined(JS_VERSION) || JS_VERSION >= 0x010000

--

As a result _both_ versions of each method will always include if JS_VERSION
>=0.10000 and JS_VERSION defined.


diff -Naur plib-1.8.4/src/js/jsLinuxOld.cxx
plib-1.8.4.new/src/js/jsLinuxOld.cxx             
--- plib-1.8.4/src/js/jsLinuxOld.cxx    2004-10-21 03:49:33 +0400

+++ plib-1.8.4.new/src/js/jsLinuxOld.cxx        2005-02-08 14:33:24 +0300

@@ -27,7 +27,7 @@

 

 #include <linux/joystick.h>

 

-#if !defined(JS_VERSION) || JS_VERSION >= 0x010000

+#if !defined(JS_VERSION) || JS_VERSION < 0x010000

 

 #include <fcntl.h>

 #include <sys/ioctl.h>   

--
With best regards
Stanislav Ievlev

ALT Linux Team.



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
plib-devel mailing list
pli...@li...
https://lists.sourceforge.net/lists/listinfo/plib-devel

RE: [Plib-devel] [BUG] Minor bug in ulClock

From: Fay J. F C. AAC/W. <joh...@eg...> - 2005-07-16 16:53:38

OK, I think I fixed that.  (Did I say this already?  I confuse easily these
days.)

John F. Fay
Technical Fellow, Jacobs/Sverdrup TEAS Group
joh...@eg...
850-729-6330 
-----Original Message-----
From: pli...@li...
[mailto:pli...@li...] On Behalf Of
jo...@lu...
Sent: Monday, July 11, 2005 10:07 PM
To: pli...@li...
Subject: [Plib-devel] [BUG] Minor bug in ulClock

Hi all,

I think there is a minor bug in ulClock, causing the first reported delta
after a reset() to be wrong. Reset basically sets:

    start     = getRawTime () ;
    now       = start ;
    delta     = 1.0 / 30.0 ;  /* Faked so stoopid programs won't div0 */
    last_time = now - delta ;

So basically 'now' and 'last_time' are in 'seconds since epoch'.

But in update():

  now = getRawTime() - start ;
  delta = now - last_time ;
  [...]
  if ( delta <= 0.0 ) delta = 0.0000001 ;
  last_time = now ;

So here 'now' gets set to second since reset() (not since epoch), and delta
therefor becomes a huge negative number, which then gets clamped.
'last_time' then gets set to seconds since start, and from then on
everything works fine.

Easy solution seems to be to set last_time in reset() to 0.

Best regards,
   Joerg


-------------------------------------------------------
This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening
July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
core and dual graphics technology at this free one hour event hosted by HP, 
AMD, and NVIDIA.  To register visit http://www.hp.com/go/dualwebinar
_______________________________________________
plib-devel mailing list
pli...@li...
https://lists.sourceforge.net/lists/listinfo/plib-devel

[Plib-devel] Re: [PATCH] puListBox: don't use hard-coded colo rs

From: Melchior F. <mf...@us...> - 2005-07-14 18:09:28

* Fay John F Contr AAC/WMG -- Thursday 14 July 2005 19:51:
> I fixed the "puListBox" color and mentioned that elsewhere.

Yes, I saw it. Thanks.


 
> I took a quick look at the "puComboBox" code and didn't see
> any colors mentioned, so I wasn't sure where to go with it.  Perhaps we
> should simply change the "setColour" functions to flow the colors down to
> the subwidgets in the parent widget.

Yes, that's the theory: just let the children inherit the widget's colors.
But here's a problem: we only have 6, and all of them are used already(?).

- PUCOL_FOREGROUND, PUCOL_BACKGROUND, PUCOL_HIGHLIGHT for widget color plus
     bevel frame color (e.g. the tiny puSelectBox up/down buttons)
 
- PUCOL_LEGEND, and PUCOL_LABEL for what they say they are  :-)
- PUCOL_MISC for the the cursor color (puComboBox)


Nothing left that we could use for the puInput area. One possible way
would be to introduce another color, for example one that is always used
for input fields (puInput, puComboBox, puSelectBox). Another would be to
add an extra color setter for these puObjects. The latter is quite ugly.
The former is probably not acceptable, either. (Despite the fact that
plib is prepared for another color ... PUCOL_MAX.)

And that's why I didn't submit a patch for this. Seems to be an
architecture question, not just a simple bugfix.

m.

RE: [Plib-devel] Re: [PATCH] puListBox: don't use hard-coded colo rs

From: Fay J. F C. AAC/W. <joh...@eg...> - 2005-07-14 17:52:37

OK, I think you've settled the questions about the fonts.

I fixed the "puListBox" color and mentioned that elsewhere.

I actually work at two separate locations now, and the e-mails regarding
"puSelectBox" and "puComboBox" are at the other location, so I can't get to
them right now.  I took a quick look at the "puComboBox" code and didn't see
any colors mentioned, so I wasn't sure where to go with it.  Perhaps we
should simply change the "setColour" functions to flow the colors down to
the subwidgets in the parent widget.

John F. Fay
Technical Fellow, Jacobs/Sverdrup TEAS Group
850-729-6330
joh...@eg...
 
-----Original Message-----
From: pli...@li...
[mailto:pli...@li...] On Behalf Of Melchior FRANZ
Sent: Thursday, July 14, 2005 12:15 PM
To: pli...@li...
Subject: [Plib-devel] Re: [PATCH] puListBox: don't use hard-coded colo rs

Well, I wrote "It increases the space after j and f", and that's what it
does.
You can't decrease the space before a j and f, because, as one can easily
see, they are already left aligned:

  {  3,  0,  0,  0, 64, 64, 64, 64, 64, 64,224, 64, 48,  0,  0,  0}
                                           ^^^
  {  3,128, 64, 64, 64, 64, 64, 64, 64, 64, 64,  0, 64,  0,  0,  0}
       ^^^

I just increased the character width by one, thus introducing one zero bit
at the right. (If the character would already have been 8 bits wide, then
this would have meant to add 15 bytes per character. But why do you ask?
All characters are left-aligned, and there's not enough gap after these two.
I'd say the choice is somewhat limited.

m.


PS: what about the patch that this thread was originally about? The
hardcoded
    puListBox colors. And, which color should we (ab)use for the puSelectBox
    and puComobBox input field?


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from
IBM. Find simple to follow Roadmaps, straightforward articles, informative
Webcasts and more! Get everything you need to get up to speed, fast.
http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
plib-devel mailing list
pli...@li...
https://lists.sourceforge.net/lists/listinfo/plib-devel

[Plib-devel] Re: [PATCH] puListBox: don't use hard-coded colo rs

From: Melchior F. <mf...@us...> - 2005-07-14 17:15:21

* Fay John F Contr AAC/WMG -- Thursday 14 July 2005 18:31:
> <off-topic>
> 	Ah, so you're not fair dinkum ... I can see where people might get
> confused, though.  Do Austrians have an expression like "fair dinkum" to
> indicate membership?

Not that I knew. But I'm sure all of our neighbor countries have some
"nice" names/descriptions for us. Ha! And the other way around, too!  :-)
> </off-topic>


 
> 	I'm not quite up on my bitmap font conventions, but I need to ask
> whether your change moves the letters "j" and "f" over one pixel to the left
> or whether it increases their width by one pixel.

Well, I wrote "It increases the space after j and f", and that's what it does.
You can't decrease the space before a j and f, because, as one can easily see,
they are already left aligned:

  {  3,  0,  0,  0, 64, 64, 64, 64, 64, 64,224, 64, 48,  0,  0,  0}
                                           ^^^
  {  3,128, 64, 64, 64, 64, 64, 64, 64, 64, 64,  0, 64,  0,  0,  0}
       ^^^

I just increased the character width by one, thus introducing one zero bit
at the right. (If the character would already have been 8 bits wide, then
this would have meant to add 15 bytes per character. But why do you ask?
All characters are left-aligned, and there's not enough gap after these
two. I'd say the choice is somewhat limited.

m.


PS: what about the patch that this thread was originally about? The hardcoded
    puListBox colors. And, which color should we (ab)use for the puSelectBox
    and puComobBox input field?

RE: [Plib-devel] [BUG] Minor bug in ulClock

From: Fay J. F C. AAC/W. <joh...@eg...> - 2005-07-14 17:06:50

Joerg,

	Thank you very much for spotting that.  I am putting the fix into
CVS.  I also set "now" to zero seconds in reset(), making it consistently
"seconds since reset" instead of starting out being "seconds since epoch"
and then changing.

Folks,

	Is there a reason we shouldn't set "delta" in "reset()" to 0.0000001
(its minimum value in update() ) rather than 1.0 / 30.0 ?  I value the
consistency, which I would consider a good enough reason to change it.

John F. Fay
Technical Fellow, Jacobs/Sverdrup TEAS Group
850-729-6330
joh...@eg...
 
-----Original Message-----
From: pli...@li...
[mailto:pli...@li...] On Behalf Of
jo...@lu...
Sent: Monday, July 11, 2005 10:07 PM
To: pli...@li...
Subject: [Plib-devel] [BUG] Minor bug in ulClock

Hi all,

I think there is a minor bug in ulClock, causing the first reported delta
after a reset() to be wrong. Reset basically sets:

    start     = getRawTime () ;
    now       = start ;
    delta     = 1.0 / 30.0 ;  /* Faked so stoopid programs won't div0 */
    last_time = now - delta ;

So basically 'now' and 'last_time' are in 'seconds since epoch'.

But in update():

  now = getRawTime() - start ;
  delta = now - last_time ;
  [...]
  if ( delta <= 0.0 ) delta = 0.0000001 ;
  last_time = now ;

So here 'now' gets set to second since reset() (not since epoch), and delta
therefor becomes a huge negative number, which then gets clamped.
'last_time' then gets set to seconds since start, and from then on
everything works fine.

Easy solution seems to be to set last_time in reset() to 0.

Best regards,
   Joerg


-------------------------------------------------------
This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening
July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
core and dual graphics technology at this free one hour event hosted by HP,
AMD, and NVIDIA.  To register visit http://www.hp.com/go/dualwebinar
_______________________________________________
plib-devel mailing list
pli...@li...
https://lists.sourceforge.net/lists/listinfo/plib-devel

RE: [Plib-devel] [PATCH] puListBox: don't use hard-coded colors

From: Fay J. F C. AAC/W. <joh...@eg...> - 2005-07-14 16:43:23

Done ...

John F. Fay
Technical Fellow, Jacobs/Sverdrup TEAS Group
850-729-6330
joh...@eg...
 
-----Original Message-----
From: pli...@li...
[mailto:pli...@li...] On Behalf Of Melchior FRANZ
Sent: Thursday, July 07, 2005 3:59 PM
To: pli...@li...
Subject: [Plib-devel] [PATCH] puListBox: don't use hard-coded colors

The puListBox uses black as textcolor, no matter what the color scheme is.
This makes the text very hard to read on dark backgrounds. Likewise,
selected text is hardcoded to be white.

The attached patch uses PUCOL_LABEL for text, and
(PUCOL_BACKGROUND-PUCOL_LABEL)/2 for selected text. This assumes that
background and text have good contrast against each other, and something in
between differs enough from either, while still being legible.

m.

RE: [Plib-devel] Re: [PATCH] puListBox: don't use hard-coded colo rs

From: Fay J. F C. AAC/W. <joh...@eg...> - 2005-07-14 16:32:06

Melchior,

<off-topic>
	Ah, so you're not fair dinkum ... I can see where people might get
confused, though.  Do Austrians have an expression like "fair dinkum" to
indicate membership?  I think the best we can muster in the United States is
"red-blooded American."
</off-topic>

	I'm not quite up on my bitmap font conventions, but I need to ask
whether your change moves the letters "j" and "f" over one pixel to the left
or whether it increases their width by one pixel.  I think it does the
latter.  If this is the case, the next question is do we want them to be
wider or do we want them one pixel to the left?

John F. Fay
Technical Fellow, Jacobs/Sverdrup TEAS Group
850-729-6330
joh...@eg...
 
-----Original Message-----
From: pli...@li...
[mailto:pli...@li...] On Behalf Of Melchior FRANZ
Sent: Wednesday, July 13, 2005 8:38 AM
To: pli...@li...
Subject: [Plib-devel] Re: [PATCH] puListBox: don't use hard-coded colo rs

* Fay John F Contr AAC/WMG -- Wednesday 13 July 2005 15:11:
> I'm back.  Bring on the patch!

One is attached. It increases the space after j and f in the Helvetica_12
font. You can see the "before" state in this screenshot:

  http://members.aon.at/mfranz/fgfs_gui8.jpg  [50 kB]

This screenshot also shows the puComboBox ugliness (same for puSelectBox):
the input areas don't pick up any color and only use setColourScheme-colors,
but not explicitly set colors. FlightGear's theming "engine" would need
that, though. I don't really know how it's fixed best. The problem are the
puObject children. All six colors are used up already, so how would we set
the color of the puInput-child's PUCOL_FOREGROUND? Adding a seventh color is
probably not welcomed. Abusing another color for that? PUCOL_MISC? And
having no way to set the cursor color? Hmmm ...



> Melchior, if I may ask, where is "here" that you don't have this kind 
> of catastrophe?

Austria (no kangaroos). No tornado and such things here. I guess we are too
far away from the sea. All we have are occasional floods after heavy rain,
but our country isn't exactly flat, so that can't last long either. :-)

m.

RE: [Plib-devel] Repost of HID Usage Tables

From: Fay J. F C. AAC/W. <joh...@eg...> - 2005-07-14 16:20:51

Gentlemen,

	Who's in charge of the "js" library?  I took a quick look at this
and frankly have no idea what to do with it.  Anybody?

John F. Fay
Technical Fellow, Jacobs/Sverdrup TEAS Group
850-729-6330
joh...@eg...
 
-----Original Message-----
From: pli...@li...
[mailto:pli...@li...] On Behalf Of Jim Campbell
Sent: Tuesday, July 05, 2005 4:20 AM
To: pli...@li...
Subject: [Plib-devel] Repost of HID Usage Tables

Hi,
I have re-posted this as may have got lost somewhere - sorry if you get
duplicate.

I am just joining plib devel in order to suggest some modifications to
joystick handling in MacOSX for use in FlightGear.
I am just looking at the USB "HID Usage tables" specification and for
Generic Desktop there are a few other useful things that might be reported
by a joystick or gamepad and also keypad and Multi-Axis-controller. Maybe we
need the "multi-access-controller' application and "wheel" dynamic for
example? I have already added and submitted to flightgear the
kHIDUsage_GD_Dial to jsMacOSX.cxx as this is reported by my Saitek X45
joystick but it needs to be more general.

/* GenericDesktop Page (0x01) */
enum
{
	kHIDUsage_GD_Pointer	= 0x01,	/* Physical Collection */
	kHIDUsage_GD_Mouse	= 0x02,	/* Application Collection */
	/* 0x03 Reserved */
	kHIDUsage_GD_Joystick	= 0x04,	/* Application Collection */
	kHIDUsage_GD_GamePad	= 0x05,	/* Application Collection */
	kHIDUsage_GD_Keyboard	= 0x06,	/* Application Collection */
	kHIDUsage_GD_Keypad	= 0x07,	/* Application Collection */
	kHIDUsage_GD_MultiAxisController	= 0x08,	/* Application
Collection */
	/* 0x09 - 0x2F Reserved */
	kHIDUsage_GD_X	= 0x30,	/* Dynamic Value */
	kHIDUsage_GD_Y	= 0x31,	/* Dynamic Value */
	kHIDUsage_GD_Z	= 0x32,	/* Dynamic Value */
	kHIDUsage_GD_Rx	= 0x33,	/* Dynamic Value */
	kHIDUsage_GD_Ry	= 0x34,	/* Dynamic Value */
	kHIDUsage_GD_Rz	= 0x35,	/* Dynamic Value */
	kHIDUsage_GD_Slider	= 0x36,	/* Dynamic Value */
	kHIDUsage_GD_Dial	= 0x37,	/* Dynamic Value */
	kHIDUsage_GD_Wheel	= 0x38,	/* Dynamic Value */
	kHIDUsage_GD_Hatswitch	= 0x39,	/* Dynamic Value */

also for future reference there is a "Simulation Page"  which if we can make
our own USB "cockpit" device may be useful. For example the following (and
more!) are
specifically mentioned:
/* Simulation Page (0x02) */
/* This section provides detailed descriptions of the usages employed by
simulation devices. */ enum {
	kHIDUsage_Sim_FlightSimulationDevice	= 0x01,/* Application
Collection 
*/
	kHIDUsage_Sim_AutomobileSimulationDevice= 0x02,/* Application
Collection */
	kHIDUsage_Sim_TankSimulationDevice	= 0x03,/* Application
Collection */
	kHIDUsage_Sim_SpaceshipSimulationDevice= 0x04,/* Application
Collection */
	kHIDUsage_Sim_SubmarineSimulationDevice= 0x05,/* Application
Collection */
	kHIDUsage_Sim_SailingSimulationDevice	= 0x06,/* Application
Collection 
*/
	kHIDUsage_Sim_MotorcycleSimulationDevice= 0x07,/* Application
Collection */
	kHIDUsage_Sim_SportsSimulationDevice	= 0x08, /* Application
Collection 
*/
	kHIDUsage_Sim_AirplaneSimulationDevice= 0x09, /* Application
Collection */
	kHIDUsage_Sim_HelicopterSimulationDevice= 0x0A,/* Application
Collection */
	kHIDUsage_Sim_MagicCarpetSimulationDevice= 0x0B,/* Application
Collection */
	kHIDUsage_Sim_BicycleSimulationDevice	= 0x0C,/* Application
Collection 
*/
	/* 0x0D - 0x1F Reserved */
	kHIDUsage_Sim_FlightControlStick	= 0x20,/* Application
Collection */
	kHIDUsage_Sim_FlightStick	= 0x21,	/* Application Collection */
	kHIDUsage_Sim_CyclicControl	= 0x22,	/* Physical Collection */
	kHIDUsage_Sim_CyclicTrim	= 0x23,	/* Physical Collection */
	kHIDUsage_Sim_FlightYoke	= 0x24,	/* Application Collection */
	kHIDUsage_Sim_TrackControl	= 0x25,	/* Physical Collection */
	/* 0x26 - 0xAF Reserved */
	kHIDUsage_Sim_Aileron	= 0xB0,	/* Dynamic Value */
	kHIDUsage_Sim_AileronTrim	= 0xB1,	/* Dynamic Value */
	kHIDUsage_Sim_AntiTorqueControl	= 0xB2,/* Dynamic Value */
	kHIDUsage_Sim_AutopilotEnable	= 0xB3,	/* On/Off Control */
	kHIDUsage_Sim_ChaffRelease	= 0xB4,	/* One-Shot Control */
	kHIDUsage_Sim_CollectiveControl	= 0xB5,/* Dynamic Value */
	kHIDUsage_Sim_DiveBrake	= 0xB6,	/* Dynamic Value */
etc. etc.

cheers
Jim



-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from
IBM. Find simple to follow Roadmaps, straightforward articles, informative
Webcasts and more! Get everything you need to get up to speed, fast.
http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
plib-devel mailing list
pli...@li...
https://lists.sourceforge.net/lists/listinfo/plib-devel

[Plib-devel] Re: [PATCH] puListBox: don't use hard-coded colo rs

From: Melchior F. <mf...@us...> - 2005-07-13 13:38:30

Attachments: fntBitmap.diff

* Fay John F Contr AAC/WMG -- Wednesday 13 July 2005 15:11:
> I'm back.  Bring on the patch!

One is attached. It increases the space after j and f in the Helvetica_12
font. You can see the "before" state in this screenshot:

  http://members.aon.at/mfranz/fgfs_gui8.jpg  [50 kB]

This screenshot also shows the puComboBox ugliness (same for puSelectBox):
the input areas don't pick up any color and only use setColourScheme-colors,
but not explicitly set colors. FlightGear's theming "engine" would need that,
though. I don't really know how it's fixed best. The problem are the puObject
children. All six colors are used up already, so how would we set the color
of the puInput-child's PUCOL_FOREGROUND? Adding a seventh color is probably
not welcomed. Abusing another color for that? PUCOL_MISC? And having no way
to set the cursor color? Hmmm ...



> Melchior, if I may ask, where is "here" that you don't have this kind of
> catastrophe?

Austria (no kangaroos). No tornado and such things here. I guess we are
too far away from the sea. All we have are occasional floods after heavy
rain, but our country isn't exactly flat, so that can't last long either. :-)

m.

RE: [Plib-devel] legal matters

From: Fay J. F C. AAC/W. <joh...@eg...> - 2005-07-13 13:35:46

Roma locuta est, causa finita est.

("Rome has spoken, the matter is finished.")

John F. Fay
Technical Fellow, Jacobs/Sverdrup TEAS Group
joh...@eg...
850-729-6330 
-----Original Message-----
From: pli...@li...
[mailto:pli...@li...] On Behalf Of Steve Baker
Sent: Friday, July 08, 2005 9:52 PM
To: pli...@li...
Subject: Re: [Plib-devel] legal matters

There is no explicit protection for fonts or typeface designs in US or
European
copyright laws.  Some people have patented their fonts - others have tried
to use
trademark law - but copyrights do not apply.  Things may be different in
other
juristictions, but being legal everywhere on the planet is generally
impossible anyway.

They can license the actual files - and limit what the licensee does with
them,
but converting a font from vector to bitmap means we've simply rendered the
font - which is OK.

I don't think there are legal issues here.

---------------------------- 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-----

RE: [Plib-devel] Re: [PATCH] puListBox: don't use hard-coded colo rs

From: Fay J. F C. AAC/W. <joh...@eg...> - 2005-07-13 13:12:22

I'm back.  Bring on the patch!

Melchior, if I may ask, where is "here" that you don't have this kind of
catastrophe?

John F. Fay
Technical Fellow, Jacobs/Sverdrup TEAS Group
joh...@eg...
850-729-6330 
-----Original Message-----
From: pli...@li...
[mailto:pli...@li...] On Behalf Of Melchior FRANZ
Sent: Saturday, July 09, 2005 7:56 AM
To: pli...@li...
Subject: [Plib-devel] Re: [PATCH] puListBox: don't use hard-coded colors

* Norman Vine -- Saturday 09 July 2005 14:45:
> Melchior FRANZ writes:
> > Could this, please, be considered anyway, [...]?
 
> John Fay the main PUI maintainer is probably currently more concerned
> with preparing for Hurricaine Dennis then PLIB.  

Oh, yes. I had forgotten. We don't have this kind of catastrophes here,
so it's all too easy to forget. Global warming will fix that soon. :-)

m.



-------------------------------------------------------
This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening
July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
core and dual graphics technology at this free one hour event hosted by HP, 
AMD, and NVIDIA.  To register visit http://www.hp.com/go/dualwebinar
_______________________________________________
plib-devel mailing list
pli...@li...
https://lists.sourceforge.net/lists/listinfo/plib-devel

[Plib-devel] I'm OK

From: Fay J. F C. AAC/W. <joh...@eg...> - 2005-07-13 12:41:12

Gentlemen,

	With the recent passage of Hurricane Dennis I was out for a long
weekend.  Damage to my house was very limited--just the requisite number of
shingles broken off and the usual infinite number of branches and leaves
down.  There were actually fewer than I had expected of the latter because,
I guess, there hadn't been enough time since Hurricane Ivan for them to grow
back.  Life is now coming back more-or-less to normal and I am back at work.
Anything happen while I was out?

John F. Fay
Technical Fellow, Jacobs/Sverdrup TEAS Group
joh...@eg...
850-729-6330

[Plib-devel] [BUG] Minor bug in ulClock

From: <jo...@lu...> - 2005-07-12 03:07:00

Hi all,

I think there is a minor bug in ulClock, causing the first reported delta after a reset() to be wrong. Reset basically sets:

    start     = getRawTime () ;
    now       = start ;
    delta     = 1.0 / 30.0 ;  /* Faked so stoopid programs won't div0 */
    last_time = now - delta ;

So basically 'now' and 'last_time' are in 'seconds since epoch'.

But in update():

  now = getRawTime() - start ;
  delta = now - last_time ;
  [...]
  if ( delta <= 0.0 ) delta = 0.0000001 ;
  last_time = now ;

So here 'now' gets set to second since reset() (not since epoch), and delta therefor becomes a huge negative number, which then gets clamped. 'last_time' then gets set to seconds since start, and from then on everything works fine.

Easy solution seems to be to set last_time in reset() to 0.

Best regards,
   Joerg

[Plib-devel] Re: [PATCH] puListBox: don't use hard-coded colors

From: Melchior F. <mf...@us...> - 2005-07-09 12:56:39

* Norman Vine -- Saturday 09 July 2005 14:45:
> Melchior FRANZ writes:
> > Could this, please, be considered anyway, [...]?

> John Fay the main PUI maintainer is probably currently more concerned
> with preparing for Hurricaine Dennis then PLIB.  

Oh, yes. I had forgotten. We don't have this kind of catastrophes here,
so it's all too easy to forget. Global warming will fix that soon. :-)

m.

RE: [Plib-devel] Re: [PATCH] puListBox: don't use hard-coded colors

From: Norman V. <nh...@ca...> - 2005-07-09 12:39:17

Melchior FRANZ writes:
> 
> * Melchior FRANZ -- Thursday 07 July 2005 22:58:
> > The attached patch uses PUCOL_LABEL for text, and (PUCOL_BACKGROUND-PUCOL_LABEL)/2
> > for selected text. This assumes that background and text have good contrast
> > against each other, and something in between differs enough from either, while
> > still being legible.
> 
> Could this, please, be considered anyway, independent of my qualities as
> "lawyer" or lack thereof? puComboBox has a similar problem: it doesn't
> propagate its own color to its children. Would you accept a patch?

John Fay the main PUI maintainer is probably currently more concerned
with preparing for Hurricaine Dennis then PLIB.   

Hopefully he will be back on line in a few days

Norman

34 messages has been excluded from this view by a project administrator.

Flat | Threaded

<< < 1 .. 28 29 30 31 32 .. 367 > >> (Page 30 of 367)