plib-users

Re: [Plib-users] Linux on Playstation 2

[Steve B. <sjb...@ai...>]

Steve Wendt wrote:
> 
> On Tue, 5 Feb 2002, Steve Baker wrote:
> 
> > It'll be interesting to see if SGI sue them.
> 
> Or Microsoft, considering how SGI has been selling everything.  :(

OpenGL licensing is *still* in the hands of SGI.

----------------------------- Steve Baker -------------------------------
Mail : <sjb...@ai...>   WorkMail: <sj...@li...>
URLs : http://www.sjbaker.org
       http://plib.sf.net http://tuxaqfh.sf.net http://tuxkart.sf.net
       http://prettypoly.sf.net http://freeglut.sf.net
       http://toobular.sf.net   http://lodestone.sf.net

Re: [Plib-users] Linux on Playstation 2

[Steve W. <st...@sh...>]

On Tue, 5 Feb 2002, Steve Baker wrote:

> It'll be interesting to see if SGI sue them.

Or Microsoft, considering how SGI has been selling everything.  :(

Re: [Plib-users] Linux on Playstation 2

[Steve B. <sjb...@ai...>]

Jari Jokivuori wrote:
> 
> Here is some more links and info.
> 
> About OpenGL:
>  http://playstation2-linux.com/forum/forum.php?thread_id=24&forum_id=4
> 
> "By: mogul ( Bret Mogilefsky (SCEA) )
> Actually you'll notice that there is a skeleton project on the site called "ps2gl". This is a lib that's very close to OpenGL in API (but not so close that it can use the OpenGL trademark). It's pretty easy to move OpenGL code to and from it. There's a version for native PS2 development (ie. pro game developers) that has pretty high performance (high enough to be used in a pro game). The ps2linux version comes from the same source base, and source will be provided. If SDL makes use of ps2gl for acceleration, you can probably make something impressive pretty easily. The main point is that looking at the code will educate you about the PS2 hardware as well as point out areas where the kernel devices need work to really throttle up the speed... "
> 
> And http://playstation2-linux.com is place to get more info.

Ah!  Curt was speculating that this might be available - I was suprised that
they'd release it because of the OpenGL license issue which would not only
cost them money - but also force them to pass the OpenGL compliance tests.

It'll be interesting to see if SGI sue them.

----------------------------- Steve Baker -------------------------------
Mail : <sjb...@ai...>   WorkMail: <sj...@li...>
URLs : http://www.sjbaker.org
       http://plib.sf.net http://tuxaqfh.sf.net http://tuxkart.sf.net
       http://prettypoly.sf.net http://freeglut.sf.net
       http://toobular.sf.net   http://lodestone.sf.net

Re:[Plib-users] Loaded ssgEntity, speed, Arrays??

[Jari J. <jar...@mo...>]

>> I tried using makeDList() but no speed improvements here. 
>
>Have you tried to call
>
>void ssgStripify ( ssgEntity *ent ) ;
>
>This takes a bit of time, but only once. One thing game authors can do
>is model in an external file format like *.obj or *.ac, load it into
>PLIB (for example, using PPE, prettypoly.sf.net ), stripify it and
>maybe clean it up and then save out as an *.ssg file. This will then
>be loaded fast by the game and will render fast since stripified.
>To stripify means to make strips and fans.

Yes I tried, actually I started my journey into PLIB by modifying sgg/tux example (that shows spining tux over small land object..)
So I was and I am using flatten & striptify methods.

After those is PLIB using vertex arrays to draw or just bag of glVertex() etc. ?

Cheers,
JJ

Re: [Plib-users] Loaded ssgEntity, speed, Arrays??

[Wolfram K. <w_...@rz...>]

"Jari Jokivuori" <jar...@mo...> wrote:

>Hi,=20
>
>I'm fresh user of the PLIB and I have some questions..
>
>I loaded one 3d object as a ssgEntity and used that for 100 separate =
ssgTransform.=20
>(so I could get 100 3d object to the screen to test object culling)=20

Ok.

> I tried using makeDList() but no speed improvements here.=20

Have you tried to call

void ssgStripify ( ssgEntity *ent ) ;

This takes a bit of time, but only once. One thing game authors can do
is model in an external file format like *.obj or *.ac, load it into
PLIB (for example, using PPE, prettypoly.sf.net ), stripify it and
maybe clean it up and then save out as an *.ssg file. This will then
be loaded fast by the game and will render fast since stripified.
To stripify means to make strips and fans.

Keep us informed.

>Thanks,
>
>JJ

Bye bye,
Wolfram.

[Plib-users] Loaded ssgEntity, speed, Arrays??

[Jari J. <jar...@mo...>]

Hi, 

I'm fresh user of the PLIB and I have some questions..

I loaded one 3d object as a ssgEntity and used that for 100 separate ssgTransform. (so I could get 100 3d object to the screen to test object culling) So far so good, but speed was bit slow, I calculated that on screen triangle draw speed was (including back faces) about 600 000 to 800 000 tris/s. I was expecting at least close to 2Mtris/s (Tested with Duron800/Kyro2/win2000)

 I tried using makeDList() but no speed improvements here. I assume this object is drawn only using normal OpenGL "slowest" method and not vertex/normal/color arrays? So, how to use vertex arrays when loading normal object files (*.obj, *.dxf etc...) ??

Thanks,

JJ
      

Re:[Plib-users] Linux on Playstation 2

[Jari J. <jar...@mo...>]

Here is some more links and info.

About OpenGL:
 http://playstation2-linux.com/forum/forum.php?thread_id=24&forum_id=4

"By: mogul ( Bret Mogilefsky (SCEA) ) 
Actually you'll notice that there is a skeleton project on the site called "ps2gl". This is a lib that's very close to OpenGL in API (but not so close that it can use the OpenGL trademark). It's pretty easy to move OpenGL code to and from it. There's a version for native PS2 development (ie. pro game developers) that has pretty high performance (high enough to be used in a pro game). The ps2linux version comes from the same source base, and source will be provided. If SDL makes use of ps2gl for acceleration, you can probably make something impressive pretty easily. The main point is that looking at the code will educate you about the PS2 hardware as well as point out areas where the kernel devices need work to really throttle up the speed... "

And http://playstation2-linux.com is place to get more info.

JJ

------ Alkuperäinen viesti ------
Steve Baker wrote:
> 
> Paolo Leoncini wrote:
> >
> > >From vis-sim.org for your knowledge -
> >
> > http://dailynews.yahoo.com/h/nm/20020130/tc/tech_sony_linux_dc_1.html

I looked into this in some detail.
...

Re: [Plib-users] Linux on Playstation 2

[Steve B. <sjb...@ai...>]

Steve Baker wrote:
> 
> Paolo Leoncini wrote:
> >
> > >From vis-sim.org for your knowledge -
> >
> > http://dailynews.yahoo.com/h/nm/20020130/tc/tech_sony_linux_dc_1.html

I looked into this in some detail.

There are some juicy details in the bottom 6 paragraphs of this article:

  http://www.execpc.com/~halkun/PS2/

I find it a little depressing.  Sony appear to have crippled the system
in the worst way.  Being unable to read CD-R's is pretty bad, the weirdness
over Sync-on-green monitors isn't good news, 

For $199 you get:

  * A hard drive (40Gb) that's hardwarily hacked so
    you can't put it into a PC or replace it with a
    standard PC drive.
  * A 100baseT Ethernet adaptor for the PS-2.
  * A VGA adaptor - but only for (rare) sync-on-green monitors.
  * A USB mouse.
  * A USB keyboard.
  * A special magic boot DVD that's impossible to copy
    because it's a double-layer disk...and for which source code
    is not provided.
  * A pair of Linux DVD's that include source code - including Xfree and
    a optimised Sony-special gcc version.
  * Documentation.

You have to boot with the magic boot DVD which adds a software layer
*beneath* Linux proper in order to avoid Sony giving away secrets about
their hardware.  Hence the Linux device drivers are really just a layer
on top of the 'real' (and *secret*) drivers that Sony provide.

By the time you add up the cost of the parts ($10 mouse, $25 keyboard,
$80 hard drive, $30 NIC) the Linux distro is costing maybe $50 - which
isn't bad compared to RedHat or SuSE.   I don't think this is a ripoff.

So, for $199+$299 (for the PS-2 itself), you have a Linux box that's
not *great* - but probably usable.  I don't think you'll be able to
write and distribute games that run on regular PS-2's - so only other
Linux-PS2 users will be able to benefit.

You also won't be able to use PS-2 memory cartridges without reformatting
them in a way that makes them useless for non-Linux PS-2 games.

There is some confusion about whether you can drive a TV set from PS-2 Linux.

Biggest problem of all is that I don't *think* it supports OpenGL...I suspect
that you have to talk to the low level registers in the graphics hardware
or something equally nasty.

As a cheap ($499) PC, it's probably not bad - so long as you don't want to
run OpenGL stuff.  Games that only use X-windows should run OK.  Of course
you'll never be able to add a second hard drive, upgrade the RAM, put in
a faster CPU or a better graphics card, add a CD writer...that kind of
thing...that's not good.

So, I think that if you are already a PS-2 owner who'd like to use it for Word
Processing, email, etc then this is a good deal.  It's cheaper than buying
a new PC and it's got all you need right there in the box with no installation
hassles.

But if you are a PC owner who thinks this would be a neat way to get your games
onto PS-2 so you can give them away to all your PS-2 owning friends...forget
it!  Even if you own a PS-2 already, the $200 is probably better spent on
getting a new graphics card and a CPU upgrade for your existing PC.  The PS-2's
CPU is pretty slow and whilst it's graphics aren't bad, they don't come close to
the quality of a modern nVidia card and they are going to be a *bitch* to program
without OpenGL.

On that basis, I doubt that anyone will bother porting PLIB to it unless some
enthusiast gets hardware-accellerated Mesa onto it somehow.

----------------------------- Steve Baker -------------------------------
Mail : <sjb...@ai...>   WorkMail: <sj...@li...>
URLs : http://www.sjbaker.org
       http://plib.sf.net http://tuxaqfh.sf.net http://tuxkart.sf.net
       http://prettypoly.sf.net http://freeglut.sf.net
       http://toobular.sf.net   http://lodestone.sf.net

Re: [Plib-users] Linux on Playstation 2

[Steve B. <sjb...@ai...>]

Paolo Leoncini wrote:
> 
> >From vis-sim.org for your knowledge -
> 
> http://dailynews.yahoo.com/h/nm/20020130/tc/tech_sony_linux_dc_1.html

Yes - it's not cheap ($200) but the kit includes a hard drive - so I
guess it's not too unreasonable.

The report on Slashdot said that it contained all the API's needed to
do graphics and write games - but it *DIDN'T* say whether that API
was OpenGL or whether it was something proprietary.

If it's the latter, we'll have to see whether it's worth trying to
port PLIB onto it.  Of course, even if we did - it might still take
a lot of effort to port existing PLIB software to PS2 because most
PLIB programs actually contain quite a bit of OpenGL and GLUT code.

Is anyone planning on getting one of these?

----------------------------- Steve Baker -------------------------------
Mail : <sjb...@ai...>   WorkMail: <sj...@li...>
URLs : http://www.sjbaker.org
       http://plib.sf.net http://tuxaqfh.sf.net http://tuxkart.sf.net
       http://prettypoly.sf.net http://freeglut.sf.net
       http://toobular.sf.net   http://lodestone.sf.net

[Plib-users] Linux on Playstation 2

[Paolo L. <p.l...@ci...>]

From vis-sim.org for your knowledge -

http://dailynews.yahoo.com/h/nm/20020130/tc/tech_sony_linux_dc_1.html

Re: [Plib-users] Animation system

[Steve B. <sjb...@ai...>]

Paolo Leoncini wrote:

> - has anyone ever tought on the same topic wrt Plib?

I'm not aware of anything like that.
 
> - is there anywhere work on animation direction (an "exotic format") which
> inspire to? (assuming to take the burden to write the described mapping
> layer)

Not something I'd know about.
 
> - has anyone interfaced a scripting language (e.g. Tcl) to Plib (SSG in
> particular)?

Well, there has been work on building a set of Python language bindings.

I guess it never got finished because it hasn't been committed into PLIB.
 
----------------------------- Steve Baker -------------------------------
Mail : <sjb...@ai...>   WorkMail: <sj...@li...>
URLs : http://www.sjbaker.org
       http://plib.sf.net http://tuxaqfh.sf.net http://tuxkart.sf.net
       http://prettypoly.sf.net http://freeglut.sf.net
       http://toobular.sf.net   http://lodestone.sf.net

Re: [Plib-users] Animation system

[Steve B. <sjb...@ai...>]

Wolfram Kuss wrote:
> 
> This is completely from the top of my head I never thought about it,
> but it is an interesting question.
> 
> If I understand correct, instead of sending a finished movie (for
> example MPEG), you want to send a program and the "source", like 3D
> models and an animation script to the people that want to see it.
> 
> IMVHO, for a minimal animation script, you need the commands:
> 1. Load object A
> 2. Delete object A
> 3. Set Position Object A: x, y, z, h, p, r
> 4. Set Speed Object A to Vx, Vy, Vz, Vh, Vp, Vr
> 5. Wait n seconds

I would add at least:

  6. Switch selector node A to step N.
  7. Switch selector node A to bitmask M.
  8. Position camera to absolute location x,y,z,h,p,r
  9. Attach camera to object A with offset x,y,z,h,p,r from it's
     coordinate system.
 10. Set camera FOV to NxM degrees.
 11. Position light source N to absolute location x,y,z,h,p,r
 12. Attach lightsource N to object A with offset x,y,z,h,p,r from it's
     coordinate system.

> You could hardcode a special object "eyepoint", so you could set
> its position and or speed this way.

Yes - that would work instead of (8) and (9).

> IMVHO; this would theoretically be sufficient, but it would be very
> hard to make the camera rotate around something, react intelligently
> to user input, you could not have object deformations etc.

Yes - but there comes a point where it's easier to hand-code something.

FWIW: I've found that having a program that writes a program is the
easiest way to do this.  ie: The scripting language is just C++.

This means that you don't spend all your effort increasing the list of
command in the set above - because your 'scripting language' is the
whole of the PLIB API.

I agree that this is something that PPE should have - the ability to
model the path of an object and have the system write out the C++ code
to make it perform that in realtime.

It would have to write a C++ function that took as it's parameter the
ssgEntity that is being operated on and the amount of time that has
elapsed since the start of the animation.

Part of the joy of that is that you can (if you have to) hand-edit the
C++ code it generates to add special effects at certain points that the
scripting 'system' hadn't thought of (eg if you wanted to trigger a
particle system to show a rocket firing or something).

----------------------------- Steve Baker -------------------------------
Mail : <sjb...@ai...>   WorkMail: <sj...@li...>
URLs : http://www.sjbaker.org
       http://plib.sf.net http://tuxaqfh.sf.net http://tuxkart.sf.net
       http://prettypoly.sf.net http://freeglut.sf.net
       http://toobular.sf.net   http://lodestone.sf.net

Re: [Plib-users] Animation system

[Wolfram K. <w_...@rz...>]

This is completely from the top of my head I never thought about it,
but it is an interesting question.

If I understand correct, instead of sending a finished movie (for
example MPEG), you want to send a program and the "source", like 3D
models and an animation script to the people that want to see it.

IMVHO, for a minimal animation script, you need the commands:
1. Load object A=20
2. Delete object A
3. Set Position Object A: x, y, z, h, p, r
4. Set Speed Object A to Vx, Vy, Vz, Vh, Vp, Vr
5. Wait n seconds


You could hardcode a special object "eyepoint", so you could set=20
its position and or speed this way.=20
IMVHO; this would theoretically be sufficient, but it would be very
hard to make the camera rotate around something, react intelligently
to user input, you could not have object deformations etc.

Probably it would be nice:
- UI (for example, "override" camera position)
- movement along Splines
- position and move objects relative to each other.

One idea would be to use PPE instead of "raw" :-) PLIB. You would get
a UI, Python scripts, "move camera around object" routines and maybe
some minor stuff.
There are already some of the above commands implemented, at least a)
and it should be *very* easy to add the rest (Ok, I would have to
think about 5).

Bye bye,
Wolfram.

Re: [Plib-users] Animation system

[Martin H. <how...@os...>]

I have interest in a similar package: I use Plib to produce animated mockups
of displays and systems not yet in use.  A storyboard addition to Plib would
be VERY welcome!

M.

Paolo Leoncini jotted down the following:

> Dear Plib friends,
> 
> My group at work is in the process to produce a computer animation of a
> space vehicle's typical mission. Afterwards, since of the perspective need
> to link the vehicle path to a dynamics simulator, we are evaluating the
> opportunity to employ a 3D engine/scene graph like Plib instead of a
> rendering system like 3DSMax or Softimage. Whilst a modelling phase is still
> needed in those tools, the actual rendering would occur in real-time, thus
> offering the ability to expose "plugs" for controlling objects' motion
> during the simulation-animation.
> 
> We have realized that what is needed for accomplish this task by relying on
> the Plib is a layer that could actually maps a storyboard-like direction
> directives, coded in some script language or in some exotic format, into the
> dynamic manipulation of the scenegraph and node properties as time passes.
> 
> The question for which I'm asking your valuable suggestions are:
> 
> - has anyone ever tought on the same topic wrt Plib?
> 
> - is there anywhere work on animation direction (an "exotic format") which
> inspire to? (assuming to take the burden to write the described mapping
> layer)
> 
> - has anyone interfaced a scripting language (e.g. Tcl) to Plib (SSG in
> particular)?
> 
> I don't want to overload this communication, yet should someone want to go
> deeper on the kind of directives I'm referring to, I'll be willing to share
> my few toughts about it.
> 
> Thanks a lot in advance -
> 
> Paolo
> 
> 
> _______________________________________________
> plib-users mailing list
> pli...@li...
> https://lists.sourceforge.net/lists/listinfo/plib-users
> 

-- 
Martin Howard
PhD Stude^ezhh%%%gzh....<CARRIER LOST>

[Plib-users] Animation system

[Paolo L. <p.l...@ci...>]

Dear Plib friends,

My group at work is in the process to produce a computer animation of a
space vehicle's typical mission. Afterwards, since of the perspective need
to link the vehicle path to a dynamics simulator, we are evaluating the
opportunity to employ a 3D engine/scene graph like Plib instead of a
rendering system like 3DSMax or Softimage. Whilst a modelling phase is still
needed in those tools, the actual rendering would occur in real-time, thus
offering the ability to expose "plugs" for controlling objects' motion
during the simulation-animation.

We have realized that what is needed for accomplish this task by relying on
the Plib is a layer that could actually maps a storyboard-like direction
directives, coded in some script language or in some exotic format, into the
dynamic manipulation of the scenegraph and node properties as time passes.

The question for which I'm asking your valuable suggestions are:

- has anyone ever tought on the same topic wrt Plib?

- is there anywhere work on animation direction (an "exotic format") which
inspire to? (assuming to take the burden to write the described mapping
layer)

- has anyone interfaced a scripting language (e.g. Tcl) to Plib (SSG in
particular)?

I don't want to overload this communication, yet should someone want to go
deeper on the kind of directives I'm referring to, I'll be willing to share
my few toughts about it.

Thanks a lot in advance -

Paolo

RE: [Plib-users] legend update

[Sebastian U. <ud...@ha...>]

On Tue, 29 Jan 2002, st...@nt... (stathis) wrote:
> Date: Tue, 29 Jan 2002 17:33:41 -0000
> To: pli...@li...
> From: st...@nt... (stathis)
> Subject: RE: [Plib-users] legend update
>
> Hi again,
>
> I read carefully what everyone proposed. For my purposes the sliderCB as
> I initialy said is a "generic" callback used by many sliders, so the static
> idea is not solving it [...] I think the best solution would be to
> actually derive a class from puSlider as Sebastian said. To quickly solve
> it I ended up hacking a little bit the pu.h.I know I shouldn't but I have
> to get a solution quickly for now.

[...]

How about:

class legendSlider : public puSlider
{
protected:
  char legendbuf [ 10 ] ;

public:
  void doHit ( int button, int updown, int x, int y )
  {
    puSlider::doHit ( button, updown, x, y ) ;

    snprintf ( legendbuf, 10, "%.2f", getFloatValue () ) ;
  }

  legendSlider ( int minx, int miny, int sz, int vertical = FALSE ) :
    puSlider ( minx, miny, sz, vertical )
  {
    setLegend ( legendbuf ) ;
  }
} ;


- Sebastian

Re: [Plib-users] legend update

[Sebastian U. <ud...@ha...>]

On Tue, 29 Jan 2002, sj...@li... (Stephen J Baker) wrote:
> Date: Tue, 29 Jan 2002 11:01:25 -0600 (CST)
> To: <pli...@li...>
> From: sj...@li... (Stephen J Baker)
> Reply-To: sj...@li...
> Subject: Re: [Plib-users] legend update

[...]

> > A possible, but not the best, solution would be to abuse the slider's
> > string buffer to store the legend string.
>
> Yuk.

Hehe ... I know it sounds ugly, but it does work since the callback is
invoked in puSlider::doHit () *after* the setValue () call, which does fill
the string value buffer with the floating-point number.

So, basically, you connect the widget's string value buffer to it's legend
pointer once and then override the content of the string buffer on every
slider movement from the callback.

Okay ... Yuk :).


> > You could also derive your own
> > class from puSlider and add a char[] array member.
>
> That would work...or you could use the 'userdata' field to hold the
> array - that's *probably* what I would do.

So you would place something like that in the callback:

/* [...] */

if ( sli -> getUserData () == NULL )
{
  char *p = new char [10] ;

  sli -> setUserData ( p ) ;
}

snprintf ( (char *) sli -> getUserData (), 10, "%.2f", sli -> getFloatValue () ) ;

/* [...] */

Mhm ... you had take care of the deallocation of the array then ...


- Sebastian

RE: [Plib-users] legend update

[stathis <st...@nt...>]

Hi again,

I read carefully what everyone proposed. For my purposes the sliderCB as I initialy said 
is a "generic" callback used by many sliders, so the static idea is not solving it (globally 
defined pointers to arrays of chars do, but need 1 for each slider). I think the best 
solution would be to actually derive a class from puSlider as Sebastian said. To quickly 
solve it I ended up hacking a little bit the pu.h.I know I shouldn't but I have to get a 
solution quickly for now.

Here is what I've done, which I am sure is not the most compact and correct way of 
doing it, but it works for now:

pu.h around line 415:

  char  string  [ PUSTRING_MAX ] ;
  char  formatted  [ PUSTRING_MAX ] ; // I added this to store my formatted string

pu.h around line 482:

  char *getStringValue () { return res_string ? res_string : string ; }
  // I added the one below
  char *getStringValue (const char * format) {
	  sprintf(formatted, format, string);
	  return res_string ? res_string : formatted ; 
  }


This allows me to change my initial solution with the long digit output

from:
slicb->setLegend(slicb->getStringValue());

to:
slicb->setLegend(slicb->getStringValue("%.4s"));

Now all my sliders will return me a user defined formatted output. I don't think this will 
break the other widgets, but feel free to correct me.

I'm sorry I don't mean to intrude the inner workings of this so nice library so I will move 
my stuff where it belongs when time and skill allows. (Be kind I'm not a pro programmer).

Thank you very much for the input.

stathis

Re: [Plib-users] legend update

[Stephen J B. <sj...@li...>]

>> Someone already (correctly) pointed out that sliText is a local variable
>> (which is certainly a problem) - but it's also not large enough.
>
>Correct Steve - thanks for pointing that out.
>
> However, there is yet another problem with your design. If you have more
> than one slider connected to that callback, there will be only one string
> buffer, but there has to be one for each slider. You surely don't want all
> sliders to have the same legend.

Yep - if there is more than one of these beasts, that's true.

> A possible, but not the best, solution would be to abuse the slider's
> string buffer to store the legend string.

Yuk.

> You could also derive your own
> class from puSlider and add a char[] array member.

That would work...or you could use the 'userdata' field to hold the
array - that's *probably* what I would do.

----
Steve Baker                      (817)619-2657 (Vox/Vox-Mail)
L3Com/Link Simulation & Training (817)619-2466 (Fax)
Work: sj...@li...           http://www.link.com
Home: sjb...@ai...       http://www.sjbaker.org

Re: [Plib-users] legend update

[dave <da...@mi...>]

Good tips all, but none of them are the one that instantly popped into 
my mind, which is:


If you are going to use the C strings rather than a string class, always 
zero the destination space before printing,cat-ing,or copying into it. 
For one thing, this forces you to consider the length of the space 
before clearing.

<SOAPBOX>
I have found hundreds of bugs in my employers codes over the years 
related to sloppy C programming practices, especially strings (and yes, 
I too get sloppy). One employer even built a special set of wrappers for 
the string functions that eliminated having to think about the n+1 byte 
for the terminating zero. It sure looked ugly! :)
Having gotten tired of all this I abandoned C string functions entirely  and
learned the iostreams part of C++ and started looking for a String class 
in whatever projects I am assigned. If one isnt there I have my own I 
wrote. This has saved me so much pain it was well worth it the effort. 
But there is a footprint price to be paid if you are in an embedded 
environment and using C++. This month's ELJ (Embedded Linux Journal) has 
an article on a GUI project for a handheld where they use X-windows but 
chose GTK+ instead of FLTK or QT. The complaint was that C++ brings too 
many problems and its best to just try to be extremely disciplined in C.
So my usual snappy answer of "just dont use C", ahem, cough cough, 
doesnt seem to work anymore, at least for highly tuned environments.
</SOAPBOX>

Regards,
Dave

Oh, BTW, Steve, the translucent widgets are sweet!


Stephen J Baker wrote:

>>void sliderCB( puObject *sli) {
>>
>>   float value;
>>   char sliText[4];
>>
>>   slicb->getValue(&value);
>>   sprintf(sliText, "%.2f", value);
>>   cout << sliText << endl; // this output is *exactly* what I need
>>
>>   slicb->setLegend(sliText); // non-sense chars on the legend :(
>>   ...
>>}
>>
>>No matter what I do to try and reformat the string (with sprintf),
>>prior to sending it on the legend, I get on my legend some strange
>>characters. What am I possibly doing wrong?
>>Can somebody see my mistake above?
>>
> 
> Someone already (correctly) pointed out that sliText is a local variable
> (which is certainly a problem) - but it's also not large enough.
> 
> The '%.2f' format will generate things like '0.01' - four characters
> plus a '\0' byte - making five characters in all.  Hence, sliText
> needs to have *AT LEAST* five elements - not four as you declared it.
> 
> ----
> Steve Baker                      (817)619-2657 (Vox/Vox-Mail)
> L3Com/Link Simulation & Training (817)619-2466 (Fax)
> Work: sj...@li...           http://www.link.com
> Home: sjb...@ai...       http://www.sjbaker.org
> 
> 
> _______________________________________________
> plib-users mailing list
> pli...@li...
> https://lists.sourceforge.net/lists/listinfo/plib-users
> 
> 
> 
> 

Re: [Plib-users] legend update

[Sebastian U. <ud...@ha...>]

On Tue, 29 Jan 2002, sj...@li... (Stephen J Baker) wrote:
> Date: Tue, 29 Jan 2002 08:31:04 -0600 (CST)
> To: <pli...@li...>
> From: sj...@li... (Stephen J Baker)
> Reply-To: sj...@li...
> Subject: Re: [Plib-users] legend update

[...]

> Someone already (correctly) pointed out that sliText is a local variable
> (which is certainly a problem) - but it's also not large enough.

Correct Steve - thanks for pointing that out.

However, there is yet another problem with your design. If you have more
than one slider connected to that callback, there will be only one string
buffer, but there has to be one for each slider. You surely don't want all
sliders to have the same legend.

A possible, but not the best, solution would be to abuse the slider's
string buffer to store the legend string. You could also derive your own
class from puSlider and add a char[] array member.


- Sebastian

RE: [Plib-users] legend update

[Norman V. <nh...@ca...>]

Stephen J Baker writes:
>
>> void sliderCB( puObject *sli) {
>>
>>    float value;
>>    char sliText[4];
>>
>>    slicb->getValue(&value);
>>    sprintf(sliText, "%.2f", value);
>>    cout << sliText << endl; // this output is *exactly* what I need
>>
>>    slicb->setLegend(sliText); // non-sense chars on the legend :(
>>    ...
>> }
>>
>> No matter what I do to try and reformat the string (with sprintf),
>> prior to sending it on the legend, I get on my legend some strange
>> characters. What am I possibly doing wrong?
>> Can somebody see my mistake above?
>
>Someone already (correctly) pointed out that sliText is a 
>local variable
>(which is certainly a problem) - but it's also not large enough.
>
>The '%.2f' format will generate things like '0.01' - four characters
>plus a '\0' byte - making five characters in all.  Hence, sliText
>needs to have *AT LEAST* five elements - not four as you declared it.

Good Catch !

FWIW
I implemented a variation of this theme for the FlightGear 
AutoPilot Gain adjuster.   

http://www.vso.cape.com/~nhv/files/PLib/APDialog.jpg

The code while not the prettiest, works and should be adapatable
if anyone is interested see FlightGear / src / AutoPilot / auto_gui.cxx
which is accessible through the CVS web Interface
< follow link to CVS Resources @ www.flightgear.org >

Cheers

Norman

Re: [Plib-users] legend update

[Stephen J B. <sj...@li...>]

> void sliderCB( puObject *sli) {
>
>    float value;
>    char sliText[4];
>
>    slicb->getValue(&value);
>    sprintf(sliText, "%.2f", value);
>    cout << sliText << endl; // this output is *exactly* what I need
>
>    slicb->setLegend(sliText); // non-sense chars on the legend :(
>    ...
> }
>
> No matter what I do to try and reformat the string (with sprintf),
> prior to sending it on the legend, I get on my legend some strange
> characters. What am I possibly doing wrong?
> Can somebody see my mistake above?

Someone already (correctly) pointed out that sliText is a local variable
(which is certainly a problem) - but it's also not large enough.

The '%.2f' format will generate things like '0.01' - four characters
plus a '\0' byte - making five characters in all.  Hence, sliText
needs to have *AT LEAST* five elements - not four as you declared it.

----
Steve Baker                      (817)619-2657 (Vox/Vox-Mail)
L3Com/Link Simulation & Training (817)619-2466 (Fax)
Work: sj...@li...           http://www.link.com
Home: sjb...@ai...       http://www.sjbaker.org

Re: [Plib-users] legend update

[Sebastian U. <ud...@ha...>]

On Tue, 29 Jan 2002, st...@nt... (stathis) wrote:
> Date: Tue, 29 Jan 2002 09:21:26 -0000
> To: pli...@li...
> From: st...@nt... (stathis)
> Subject: [Plib-users] legend update
>
> Hi everyone,
>
> I am trying to setup sliders that will update their legend with the
> slider value. So as I move the slider along I can see it's value. I
> managed to do this with getStringValue and then setLegend. However on a
> floating point slider, it send back values with too many digits (.i.e
> 0.44555).

[...]

> void sliderCB( puObject *sli) {
>
>    float value;
>    char sliText[4];
>
>    slicb->getValue(&value);
>    sprintf(sliText, "%.2f", value);
>    cout << sliText << endl; // this output is *exactly* what I need
>
>    slicb->setLegend(sliText); // non-sense chars on the legend :(
>    ...
> }
>
> No matter what I do to try and reformat the string (with sprintf), prior
> to sending it on the legend, I get on my legend some strange characters.
> What am I possibly doing wrong?

You are playing with pointers to arrays that have a limited lifetime !

The sliText[4] array is allocated when the sliderCB () routine is entered
and destroyed when it exits. After it has been destroyed, chances are high
that the appropiate memory region will be re-used for something else soon -
hence the non-sense chars.

Try declaring the array "static":

static char sliText[4] ;

This way, the array will be allocated upon application startup and
destroyed when the application quits (like a global variable). This has two
important effects:

- It's content is kept from one call of the routine to another
- It's adress does not become invalid after the function has returned

As a general rule, be *very* careful with pointers to variables or arrays
that have a limited lifetime !


- Sebastian

[Plib-users] legend update

[stathis <st...@nt...>]

Hi everyone,

I am trying to setup sliders that will update their legend with the slider value. So as I 
move the slider along I can see it's value. I managed to do this with getStringValue and 
then setLegend. However on a floating point slider, it send back values with too many 
digits (.i.e 0.44555). I would like to display only a meanigful part of it for the user (say 
0.44). I set this to happen in a generic slider cb used by many sliders as follows:

void sliderCB( puObject *sli) {
   
   sli->setLegend(sli->getStringValue());
   .....
   ...
}

This works fine so far. I tried to reformat it like this (amongst other ways)

void sliderCB( puObject *sli) {

   float value;
   char sliText[4];

   slicb->getValue(&value);
   sprintf(sliText, "%.2f", value);
   cout << sliText << endl; // this output is *exactly* what I need

   slicb->setLegend(sliText); // non-sense chars on the legend :(
   ...
}

No matter what I do to try and reformat the string (with sprintf), prior to sending it on the 
legend, I get on my legend some strange characters. What am I possibly doing wrong?
Can somebody see my mistake above?

thanks in advance.

--st