plib-devel

Re: [Plib-devel] MS linking problems

[Brad C. <bco...@ac...>]

Found it.

The project file that came with 1.1.11 I downloaded didn't include
ssgContext.cxx as a file to be built.

Sorry,

-Brad

----- Original Message -----
From: "Brad Colbert" <bco...@ac...>
To: <pli...@li...>
Sent: Friday, June 02, 2000 11:45 AM
Subject: [Plib-devel] MS linking problems


> Hi folks,
>
> I've been trying to build an app I have that uses plib but I get the
> following linkage error, which is the same errors I get when trying to build
the
> tux example.  (*NOTE: I've only shown the first three of 17)
>
> tux_example.obj : error LNK2001: unresolved external symbol "public: void
> __thiscall ssgContext::setFOV(float,float)" (?setFOV@ssgContext@@QAEXMM@Z)
>
> ssg.lib(ssgLeaf.obj) : error LNK2001: unresolved external symbol "class
> ssgContext *  _ssgCurrentContext" (?_ssgCurrentContext@@3PAVssgContext@@A)
>
> ssg.lib(ssgStateTables.obj) : error LNK2001: unresolved external symbol "class
> ssgContext *  _ssgCurrentContext" (?_ssgCurrentContext@@3PAVssgContext@@A)
>
> Thanks,
>
> Brad Colbert
> GreyStone Technology, Inc.
> bco...@ac...
> (858) 874-7000
>
>
>
> _______________________________________________
> plib-devel mailing list
> pli...@li...
> http://lists.sourceforge.net/mailman/listinfo/plib-devel
>

[Plib-devel] MS linking problems

[Brad C. <bco...@ac...>]

Hi folks,

I've been trying to build an app I have that uses plib but I get the
following linkage error, which is the same errors I get when trying to build the
tux example.  (*NOTE: I've only shown the first three of 17)

tux_example.obj : error LNK2001: unresolved external symbol "public: void
__thiscall ssgContext::setFOV(float,float)" (?setFOV@ssgContext@@QAEXMM@Z)

ssg.lib(ssgLeaf.obj) : error LNK2001: unresolved external symbol "class
ssgContext *  _ssgCurrentContext" (?_ssgCurrentContext@@3PAVssgContext@@A)

ssg.lib(ssgStateTables.obj) : error LNK2001: unresolved external symbol "class
ssgContext *  _ssgCurrentContext" (?_ssgCurrentContext@@3PAVssgContext@@A)

Thanks,

Brad Colbert
GreyStone Technology, Inc.
bco...@ac...
(858) 874-7000

[Plib-devel] Cull Draw and many viewports

[Brad C. <bco...@ac...>]

Hi Steve,

If I have a couple of viewports that I want to render in the same window
is it possible to cull for each viewport then draw in each viewport?

Would this save any time or is ok to call ssgCullAndDraw for each
viewport?

Thanks,

Brad Colbert
GreyStone Technology, Inc.
bco...@ac...
(858) 874-7000

Re: [Plib-devel] Re: control abstraction, continued (ad infinitum)

[James T. <jm...@dc...>]

Steve Baker wrote:

<SNIP>

Why should there be a new type?   I think that all analog inputs
> should have the capability of being driven from digital inputs
> because some people don't like using the mouse or joystick at
> all. (eg Quake fanatics)

Agreed.

> I don't think this should be under program control.  I think the application
> should just state it's needs:
> 
>   addDigital ( "RetractSwitch" ) ;
>   addAnalog  ( "Throttle" ) ;
> 
> ...and have an external file (say '.fgfs_controls' for FlightGear,
> '.tux_aqfh_controls' for Tux, etc) that binds physical controllers
> to each application variable:
> 
> RetractSwitch:DIGITAL:  'R'==1, 'U'==0
> Throttle:ANALOG:  MOUSE_NORTH_SOUTH + MOUSE_MIDDLE_BUTTON, scale=1.5,
>                   deadzone=0.3, linear
> Flaps:ANALOG: '<'==++0.1, '>'==--0.1
> 
> ...and so on.  Then (initially) we can create such a file that installs
> with FGFS (or whatever) which has the default controllers - possibly
> one file for people with joysticks and one without.  Experts can then
> hand-edit that file to set their own personal preferences - and perhaps
> some kind person would create a GUI-driven configuration widget that
> would be application-independent.

Okay the reason for my 'heavy handed' interface is being my goal with
the APIs was to be able to build a GUI pretty mucch exactly like Fly!'s
or FS2000's. With a system as 'lose' as you propose, that won't be
possible. [At least in the standard 'here's a list of analog inputs,
choose a joystick axis,' and 'here's a list of digital inputs, choose a
button / key' method, which I'd like to stick too]

Certain parameters are fixed for the control by the program, such as the
step size and scale, whether the axis is positional or velocity, and
having them in the control file seems pointless. (or for digitals,
whether it is debounced)

Further more, in order to provide a sensible GUI, the list of analog and
digital inputs need to be complete; so the bindings which are 'legal'
need to be specifed by the program.

Eg for a 'flaps' analog axis, probably the 'important' bindings are
increase and decrease; 'center' is probably useless. But without the
program specifying these, the GUI must list all possible digital
bindings on every analog axis. (Currently that's 5 possible bindings for
every analog)

I'd much prefer to sacrifice some configurability in order to keep the
GUIs nice and clean since I certainly can't be bothered hacking a config
file. (But then, I did start coding on the Mac :-)

Seriously, I think that at least scale and legal linkages need to be
specified:
	flaps = ctlAnalog("Flaps", 0.0, 1.0, CTL_ANALOG_POSITIONAL);
	flaps->addDigital(INC, new ctlDigital("Raise Flaps"));
	flaps->addDigital(DEC, new ctlDigital("Lower Flaps"));		

The scale seems important to prevent the returned values exceding the
range the simulation / game is 'expecting'. Similarly the pos /
velocity selector would otherwise affect the code so allowing
customization seems unwise.

And I suppose having an 'advanced' GUI that allows things like step
size, etc to be specified is doable, but I'd still prefer that sensible
defaults were specifed so that I could just bind my favourite buttons to
'increase flaps' without worrying about choosing a step size.

You can tell I'm not a Unix coder; I'd much rather spend a day writing
the GUI than an hour writing a parser for your text config file format
;-)

> 
> > One other suggested change is that digital inputs drive callbacks rather
> > than being polled; this makes a lot of sense I suspect, so I will add a
> > setCallback method and alternate constructor to ctlDigital. I don't
> > think callback behaviour makes sense for analog inputs, but if people
> > disagree then it could be included.
> 
> It should be possible to use three mechanisms:
> 
> 1) Polling (that doesn't work well with GLUT - but it can be done)
> 2) Callbacks.
> 3) Direct variable drive (ie you call a single 'update' function and
>    it updates a bunch of variables that the application bound to the
>    controllers).
> 
> Each method has its benefits.

Eeewwww. I suppose this is true :-(
I suppose the public has the right to choose, hence all 3 options will
be available; this is actually pretty simple to implement.

I will probably just have 3 flavous of the construtor; one will tkae a
variable address and one a function pointer.

James

Re: [Plib-devel] Re: control abstraction, continued (ad infinitum)

[Sam S. <sa...@sp...>]

> > As ever feedback is appreciated especially from non-FG users of
PLIB,
> > who I suspect are all looking on in amazement and thinking 'when
would I
> > *ever* use this junk' :-)
>
> To the contrary - I'm hoping that this will allow me to get mouse and
> keyboard drivers for my two Tux games (A Quest for Herring - and the
> upcoming 'TuxKart') - with zero effort on my part!

Me too..  I quickly knocked up a keyboard callback system for my game
about 7 months ago, and I haven't touched it much since, and it's kinda
groaning under the strain of having mouse and joystick code hacked into
it.  I wasn't looking forward to ripping it to pieces and rebuilding it
over the next couple of weeks - but with a bit of luck now I won't have
to!

Sam

Re: [Plib-devel] Re: control abstraction, continued (ad infinitum)

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

James Turner wrote:
> 
> Some more points that have come up:
> 
> the need for controls with both analog inputs and digital buttons. Hence
> I have a new input type, ctlDual, which clan be used as follows:
> 
> ctlDual *t = new ctlDual("Throttle", 0.1, 0.05, CTL_JS_0, 3);
>         2 parameter is the 'step size', explained below
>         3 param is a threshold, also explained below

Why should there be a new type?   I think that all analog inputs
should have the capability of being driven from digital inputs
because some people don't like using the mouse or joystick at
all. (eg Quake fanatics)

> then:
> 
> t->addDigital(new ctlDigital("100% Throttle", CTL_KEYBOARD, '#'),
> CTL_DUAL_MAX);
> t->addDigital(new ctlDigital("Increase Throttle", CTL_KEYBOARD, '+'),
> CTL_DUAL_INC);

I don't think this should be under program control.  I think the application
should just state it's needs:

  addDigital ( "RetractSwitch" ) ;
  addAnalog  ( "Throttle" ) ;

...and have an external file (say '.fgfs_controls' for FlightGear,
'.tux_aqfh_controls' for Tux, etc) that binds physical controllers
to each application variable:

RetractSwitch:DIGITAL:  'R'==1, 'U'==0
Throttle:ANALOG:  MOUSE_NORTH_SOUTH + MOUSE_MIDDLE_BUTTON, scale=1.5,
                  deadzone=0.3, linear
Flaps:ANALOG: '<'==++0.1, '>'==--0.1

...and so on.  Then (initially) we can create such a file that installs
with FGFS (or whatever) which has the default controllers - possibly
one file for people with joysticks and one without.  Experts can then
hand-edit that file to set their own personal preferences - and perhaps
some kind person would create a GUI-driven configuration widget that
would be application-independent.

> One other suggested change is that digital inputs drive callbacks rather
> than being polled; this makes a lot of sense I suspect, so I will add a
> setCallback method and alternate constructor to ctlDigital. I don't
> think callback behaviour makes sense for analog inputs, but if people
> disagree then it could be included.

It should be possible to use three mechanisms:

1) Polling (that doesn't work well with GLUT - but it can be done)
2) Callbacks.
3) Direct variable drive (ie you call a single 'update' function and
   it updates a bunch of variables that the application bound to the
   controllers).

Each method has its benefits.
 
> As ever feedback is appreciated especially from non-FG users of PLIB,
> who I suspect are all looking on in amazement and thinking 'when would I
> *ever* use this junk' :-)

To the contrary - I'm hoping that this will allow me to get mouse and
keyboard drivers for my two Tux games (A Quest for Herring - and the
upcoming 'TuxKart') - with zero effort on my part!
 
-- 
Steve Baker                  http://web2.airmail.net/sjbaker1
sjb...@ai... (home)  http://www.woodsoup.org/~sbaker
sj...@ht...      (work)

[Plib-devel] Re: control abstraction, continued (ad infinitum)

[James T. <jm...@dc...>]

Some more points that have come up:

the need for controls with both analog inputs and digital buttons. Hence
I have a new input type, ctlDual, which clan be used as follows:
	
ctlDual *t = new ctlDual("Throttle", 0.1, 0.05, CTL_JS_0, 3);
	2 parameter is the 'step size', explained below
	3 param is a threshold, also explained below

then:

t->addDigital(new ctlDigital("100% Throttle", CTL_KEYBOARD, '#'),
CTL_DUAL_MAX);
t->addDigital(new ctlDigital("Increase Throttle", CTL_KEYBOARD, '+'),
CTL_DUAL_INC);

The current 'ops' for dual inputs are centre, min, max, increase and
decrease. A digital source can be bound to any of these operations.
Increase and decrease will use the specified step size. (10% in this
example). The threshold specifies what change is required in the analog
source before it 'overrides' the previous digital setting. So if full
throttle is set, the analog source must change by > 5% before becoming
'active' again.

There also needs to be a flag to determine whether the analog axis is
rounded to step values or not.

One other suggested change is that digital inputs drive callbacks rather
than being polled; this makes a lot of sense I suspect, so I will add a
setCallback method and alternate constructor to ctlDigital. I don't
think callback behaviour makes sense for analog inputs, but if people
disagree then it could be included.

As ever feedback is appreciated especially from non-FG users of PLIB,
who I suspect are all looking on in amazement and thinking 'when would I
*ever* use this junk' :-) 

James Turner

[Plib-devel] Re: PLIB's JS and generality

[James T. <jm...@dc...>]

Alexander Perry wrote:
<SNIP>
> 1.  plib does not place an upper limit on the number of /dev/js devices,
> which is good because I've currently got eight devices declared and four
> running (and in use) at the same time.  I expect more, see below.

This was a misunderstanding on my part; I have got a new library (that
layers above JS) being discussed on the PLIB list. It will detect as
many joysticks as you like!
So you can breath out.

> 
> > > It would be nice to have the button-type controls be able to take
> > > input from a GUI widget (eg a menu entry) as well as/instead of
> > > a physical button (on mouse, keyboard or joystick) so that people
> > > who are learning (say) FGFS wouldn't have to remember that Alt-Shift-W
> > > means "tune the radio up by 1KHz" and could use the menu instead.
> 
> Yes, also need to convert combinations of buttons/menuitems into an
> emulation of an analog quantity so that people with few analog channels
> can emulate things such as throttle steps and fast sweeps easily.

This is an area I need to think about, and some input (hah!) would be
appreciated; using the 'at' functions is an issue here since my stick
reports it jas axes 4/5, but with only -1, 0 or 1 reported for each
axes. Are there stick out there where the hat is analog?

Again right now I have a total seperation of analog and digital inputs,
so for exmaple flaps is two digitals, a 'raise' and a 'lower'.
Potentially someone may desire to hook-up an analog input, BUT then we
need to specify a 'step-size', since only certain postions of the level
make sense (correct?) Similalry for spoliers.....

possibly a 'dual-mode' input which can be either digital or analog? With
a 'step-size' specified; digital moves in steps, analouge rounds to
nearest. (Or not at all if the input really is linear) And then when a
digital input is set (like 'move to max'), can lock at that position
until the analog source moves by a threshold ....

Comments?

<SNIP>
> I've currently got 12 analog channels and 15 buttons so far,
> and expect to hit about 25 analog and 100 buttons within one year.

Well these are just shortcuts : you can *USE* 0 ... n as the device
number :-)
But also defining the CTL_JS(n) macro is trivial. Personally I'm just
using raw numbers, but I thought that it might be awkward to rember
'what the '1' does' after 6 months :-)

> 
> > ctlAnalouge*
> 
> Either "Analog" for americans or "Analogue" for the europeans.
> Omitting the "u" changes the sound of the "g" so that the word
> will rhyme with "rouge".

Yah, please excuse my lack of spelling; I will convert to Yankee style I
think (dammed colonials!) [happy, Steve?]

<SNIP>
> 
> Don't forget leftbrakeCtl rightbrakeCtl propspeedCtl nosesteeringCtl
> radiovolumeCtl nextradiovolumeCtl panelinstrument[i]Ctl etc etc
> 
This list was not mean to be exhaustive. Obviously adding more axes is
trivial, the FG code was simply meant to test the PLIB library's
functioning.

> You're better off having the various control channels in the simulator
> request the joystick channels that they'd like to offer more generically.

Please explain this in more detail : the current method certainly
doesn't look pretty, but it works (kinda).

James Turner

Re: [Plib-devel] Control Abstraction

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

James Turner wrote:

> Before I do any more damage I would appreciate some comments on the API;
> I have attached the header file for review.

Do you think you could correct the spelling of the word 'analouge' (sounds
like a bizarre and uncomfortable winter Olympic event - the anal luge :-)

... it should be 'analog' or 'analogue' (most people use the former spelling).

> Please feel free to rip it apart; it's really a 'first draft' (if a
> working one) and has only had one pair of eyes reviewing it so far.

I need to take time to look at this - so please forgive the superficial
quick response!

-- 
Steve Baker                  http://web2.airmail.net/sjbaker1
sjb...@ai... (home)  http://www.woodsoup.org/~sbaker
sj...@ht...      (work)

Re: [Plib-devel] Control Abstraction

[James T. <jm...@dc...>]

Steve Baker wrote:
> 

> In fact, that idea (or a very close cousin of it) originated on this
> list - and whilst we all agreed that it was a great idea - and a perfect
> candidate for a PLIB library, nobody wanted to do the work of implementing
> it.  It was subsequently discussed on the FGFS list - but I wasn't aware
> that anyone had actually worked on it.
> <SNIP>

> Well, you could either use the existing GLUT API - or steal the
> code for doing that from the freeglut library and embed it directly
> into this new package.

Hmm, right how I'm sitting ontop of GLUT, but the API is rather
irritating.
[I just re-read that sentance - it sounds kinda strange]

> 
> > For analouge inputs, the library may track additional data such as
> > dead-zone, scaling and inversion. This overall design is very similar to
> > 'InputSprocket' on the Macintosh, and bit more high-level than
> > DirectInput (since it includes game controls, as well as physical
> > inputs)
> 
> ...also it would need to have the ability to take the physical device
> input and treat that as either the absolute value of the output data
> or as the velocity of the output (or even possibly the accelleration).
> 
> That's needed (IMHO) in order to cope with things like wanting (say)
> the absolute data value to be tied to the position of the joystick - but
> to allow someone to use the keyboard to move the object - which might
> require a velocity drive in order to make it usable.

I had completely failed to consider this one, but can add it pretty
easily; I need to determine the best way to find the velocity though.
Using (new_pos - old_pos / time) is 'theoretically' accurate, but I
wonder what the stability will be like. Also, how do I get timing
information portably? Examining the last 2 values would help noise
reduction, etc..

<SNIP>
> > I am unsure of a few points:
> >         - whether the GUI should be compulsory (probably not),
> 
> ...certainly not...IMHO.
Agreed

> 
> > or
> > seperate but
> >         related. If the GUI is seperate a much larger interface must be
> > exposed
> >         by the library (as shown above)
> 
> Hmm. I need to think about that.
The interface does get larger but forcing people to use one fixed GUI is
what killed 'InputSprocket' on the Mac (and that GUI was *ugly*)

Right now I am intending to build a basic GUI using PUI, and include
that as an extra, and a template for people who wnat to build their own
GUI

> 
> It would be nice to have the button-type controls be able to take
> input from a GUI widget (eg a menu entry) as well as/instead of
> a physical button (on mouse, keyboard or joystick) so that people
> who are learning (say) FGFS wouldn't have to remember that Alt-Shift-W
> means "tune the radio up by 1KHz" and could use the menu instead.

I'm not sure the best way to implement this; I wil give it some thought

> 
> >         - how to handle persistece of all these settings [some kind of
> > global
> >         save / restore to an iostream? a file? a chunk of memory?]
> 
> They certainly have to be in a file because the user won't want to
> go through and re-configure all those controls to his/her personal
> preferences every time the game is started.  Quite how they get into
> and out of the file is not a big deal IMHO.

Well I don't want to create a stdio / iostreams / etc dpendance
unecessarily.
But yes obviously the settings must be persistence. How do the various
libary users feel about this?

My current status:

I re-wrote the code from scratch to be stand-alone (on-top of JS); the
library is currently called 'ctl' and is sitting in my plib directory
building and running fine.

It supports arbitrary analouge and digital inputs; input using joysticks
via JS and keys via a GLUT-callback thingy. ('special' keys need to be
handled or the whole interface just re-designed not to use GLUT)

The mouse stuff is not hooked up because I don't want to break that bit
of FG :-)
Right now I have used the library to re-write the FG joystick module; I
have the primary flight controls working fine. In addition I have
modified 'keyboard.cxx' to pass key events to the library, and hence I
have sucessfuly driven flaps, brakes and other options with the joystick
buttons and keys.

Before I do any more damage I would appreciate some comments on the API;
I have attached the header file for review.

Please feel free to rip it apart; it's really a 'first draft' (if a
working one) and has only had one pair of eyes reviewing it so far.

To make it clearer how this works for the client program I have also
included my hacked-up FG joystick.cxx file; hopefully it will explain
what the hell I've done :-)

James Turner

Re: [Plib-devel] Control Abstraction

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

James Turner wrote:
> 
> Hi y'all, this is my first post to plib-devel so go easy :-)
> 
> This is an off-shoot from some ideas I had for FlightGear; Norman Vine
> suggested they might be applied more generally.

In fact, that idea (or a very close cousin of it) originated on this
list - and whilst we all agreed that it was a great idea - and a perfect
candidate for a PLIB library, nobody wanted to do the work of implementing
it.  It was subsequently discussed on the FGFS list - but I wasn't aware
that anyone had actually worked on it.

> I propose creating a new library that allows the game to define input
> 'controls'; initally either digital or analouge. The game would pass a
> name for the function, and an identifier. So 'Fire' and 'Jump' might be
> defined as digital controls, and 'throttle' or 'elevator' would be
> defined as analouge controls.
> 
> The library then handles the mapping of the game inputs to physical
> inputs, either joysticks (via JS) or key-presses. (I don't know how to
> clealny handle mouse input, myabe a capture() function?)

Well, you could either use the existing GLUT API - or steal the
code for doing that from the freeglut library and embed it directly
into this new package.

> For analouge inputs, the library may track additional data such as
> dead-zone, scaling and inversion. This overall design is very similar to
> 'InputSprocket' on the Macintosh, and bit more high-level than
> DirectInput (since it includes game controls, as well as physical
> inputs)

...also it would need to have the ability to take the physical device
input and treat that as either the absolute value of the output data
or as the velocity of the output (or even possibly the accelleration).

That's needed (IMHO) in order to cope with things like wanting (say)
the absolute data value to be tied to the position of the joystick - but
to allow someone to use the keyboard to move the object - which might
require a velocity drive in order to make it usable.

> Enough interface must be exposed to allow building a configuration
> dialog in PUI, and saving / restoring the bindings of game controls to
> physical inputs.

Yes - with some kind of configuration widget to allow the end user
to bind whatever controllers he has (and likes) to whatever controls
the game/simulation requires.


> The library would also provide functions to allow enumeration of the
> physical devices attached; again this is for use in building a GUI. For
> configuring the analouge inputs, a simple menu of each available
> physical axes can be provided. For the digital inputs, a more
> intelligent scheme would be desirable : the ability to watch for a
> button / key press and record the source. I.e the standard 'press a key
> or button to assign to this function' behaviour most games use now.
> 
> I am unsure of a few points:
>         - whether the GUI should be compulsory (probably not),

...certainly not...IMHO.

> or
> seperate but
>         related. If the GUI is seperate a much larger interface must be
> exposed
>         by the library (as shown above)

Hmm. I need to think about that.

It would be nice to have the button-type controls be able to take
input from a GUI widget (eg a menu entry) as well as/instead of
a physical button (on mouse, keyboard or joystick) so that people
who are learning (say) FGFS wouldn't have to remember that Alt-Shift-W
means "tune the radio up by 1KHz" and could use the menu instead.
 
>         - how to handle persistece of all these settings [some kind of
> global
>         save / restore to an iostream? a file? a chunk of memory?]

They certainly have to be in a file because the user won't want to
go through and re-configure all those controls to his/her personal
preferences every time the game is started.  Quite how they get into
and out of the file is not a big deal IMHO.
 
>         - how the keyboard / mouse sources will interact with
>         the GLUT input handlers. Probably setCapture()-style
>         calls by them game will be required?

Yep - perhaps.

> I have a FG specific implementation of the above (for analouge inputs
> only) working right now, without a GUI. I will augment it tomorrow and
> generally tidy it up, and then see about making it available for review,
> etc. Since this is my inital attempt at this it will obviously need a
> lot of refinement; please let me know any suggestions you have.

Wonderful!
 
-- 
Steve Baker                  http://web2.airmail.net/sjbaker1
sjb...@ai... (home)  http://www.woodsoup.org/~sbaker
sj...@ht...      (work)

Re: [Plib-devel] JPEG loader

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

Trent Gamblin wrote:
> 
> * Steve Baker <sjb...@ai...> wrote:
> > I refer you to my document: "JPEGS are evil too":
> >
> >    http://web2.airmail.net/sjbaker1/jpegs_are_evil_too.html
> 
> They look good in my game, but I don't have much experience with this
> stuff so I'll take your word for it. The bad thing about it is, that
> all the free texture sites on the net (and most texture cd's) have
> only jpeg textures.

That's usually because people are using them for web page backdrops
or desktop publishing kinds of things - rather than 3D stuff.

> Obviously converting them doesn't help with
> quality...

No - and that's the incidious thing about JPEG.

>, and it makes them about 5-10 times the size. So until I get
> myself a team of artists to create original high quality textures, I
> have to stick with what I can find on the net for my games. When I
> need cartoony textures or text I'll use a lossless format.

Beware of what processing you do to those images too - if you find you
need to (say) make a texture a little less dark, and you read it into
a paint program, do what you need and write it out as a JPEG again, you'll
get double the amount of nastiness (well, not exactly double - but *more*).

At the very least, you should do a one-time conversion to something lossless
and use the lossless format from then on.

Compression ratios on PNG images are pretty good BTW - not quite as good
as JPEG - but since they are lossless and support an alpha channel, they
are really the ideal image format for 3D textures.

The degree to which all of this is a problem does depend quite a lot
on the application - and you may be getting away with it for that
reason.
 
> > What is really needed is to implement some kind of a plugin
> > arrangement for image loaders in PLIB.

<snip lots of good stuff>

> There's probably some errors but you get the idea. It's a lot simpler
> and more portable than using shared object files or DLLs.

Yes - but I *want* to use '.so's and/or DLL's because in that way
the necessary image libraries won't have to be present in order
for a PLIB application that doesn't need those file formats to
compile and run.

Portability isn't too bad - the feature set of Windoze DLL's and
UNIX/Linux DSO's is sufficiently similar that a couple of lines of
'#ifdef WIN32' stuff will handle the differences.

-- 
Steve Baker                  http://web2.airmail.net/sjbaker1
sjb...@ai... (home)  http://www.woodsoup.org/~sbaker
sj...@ht...      (work)

[Plib-devel] Control Abstraction

[James T. <jm...@dc...>]

Hi y'all, this is my first post to plib-devel so go easy :-)

This is an off-shoot from some ideas I had for FlightGear; Norman Vine
suggested they might be applied more generally.

I propose creating a new library that allows the game to define input
'controls'; initally either digital or analouge. The game would pass a
name for the function, and an identifier. So 'Fire' and 'Jump' might be
defined as digital controls, and 'throttle' or 'elevator' would be
defined as analouge controls.

The library then handles the mapping of the game inputs to physical
inputs, either joysticks (via JS) or key-presses. (I don't know how to
clealny handle mouse input, myabe a capture() function?)

For analouge inputs, the library may track additional data such as
dead-zone, scaling and inversion. This overall design is very similar to
'InputSprocket' on the Macintosh, and bit more high-level than
DirectInput (since it includes game controls, as well as physical
inputs)

Enough interface must be exposed to allow building a configuration
dialog in PUI, and saving / restoring the bindings of game controls to
physical inputs. I would assume defining an abstract class 'Input' with
derived clases for digital and analouge inputs.

class inDigital : public Input
{
public:
        inDigital(string &label, int input, int button);

        // interface used by game
        bool get_value();

        // interface used to configure
        string& get_label();

        int get_input();
        void set_input(int i);

        int get_button();
        void set_button(int i);
}

class inAnalouge : public Input
{
public:
        inAnalouge(string &label, int input, int axis, bool invert,
float
nullZone);
        
        // interface used by game
        float get_value();

        // interface used to configure
        string& get_label();
        
        int get_input();
        void set_input(int i);

        float get_null_zone();
        void set_null_zone();

        // etc .....
}

The library would also provide functions to allow enumeration of the
physical devices attached; again this is for use in building a GUI. For
configuring the analouge inputs, a simple menu of each available
physical axes can be provided. For the digital inputs, a more
intelligent scheme would be desirable : the ability to watch for a
button / key press and record the source. I.e the standard 'press a key
or button to assign to this function' behaviour most games use now.

I am unsure of a few points:
        - whether the GUI should be compulsory (probably not), or
seperate but
        related. If the GUI is seperate a much larger interface must be
exposed
        by the library (as shown above)

        - how to handle persistece of all these settings [some kind of
global
        save / restore to an iostream? a file? a chunk of memory?]
        
        - how the keyboard / mouse sources will interact with
        the GLUT input handlers. Probably setCapture()-style
        calls by them game will be required?

I have a FG specific implementation of the above (for analouge inputs
only) working right now, without a GUI. I will augment it tomorrow and
generally tidy it up, and then see about making it available for review,
etc. Since this is my inital attempt at this it will obviously need a
lot of refinement; please let me know any suggestions you have.

James Turner

Re: [Plib-devel] JPEG loader

[Trent G. <tm...@cy...>]

* Steve Baker <sjb...@ai...> wrote:
> I refer you to my document: "JPEGS are evil too":
> 
>    http://web2.airmail.net/sjbaker1/jpegs_are_evil_too.html

They look good in my game, but I don't have much experience with this
stuff so I'll take your word for it. The bad thing about it is, that
all the free texture sites on the net (and most texture cd's) have
only jpeg textures. Obviously converting them doesn't help with
quality, and it makes them about 5-10 times the size. So until I get
myself a team of artists to create original high quality textures, I
have to stick with what I can find on the net for my games. When I
need cartoony textures or text I'll use a lossless format.

> What is really needed is to implement some kind of a plugin
> arrangement for image loaders in PLIB.

How about something like this?


#define MAX_USER_TEXTURE_FORMATS 20

struct {
  char *ext;
  void (*loader)(char *fname, GLubyte **image, int *x, int *y, int *bpp);
} user_texture_formats[MAX_USER_TEXTURE_FORMATS];

int num_user_texture_formats = 0;

int add_texture_loader(char *ext,
  void (*loader)(char *fname, GLubyte **image, int *x, int *y, int *bpp)
{
  if (num_user_texture_formats >= MAX_USER_TEXTURE_FORMATS)
    return -1;

  user_texture_formats[num_user_texture_formats].ext = new char [strlen(ext)+1];
  strcpy(user_texture_formats[num_user_texture_formats], ext);
  user_texture_formats[num_user_texture_formats].loader = loader;
  num_user_texture_formats++;
  return 0;
}

void ssgImageLoader::loadTexture ( char *fname )
{
  char *p = & fname [ strlen ( fname ) ] ;

  while ( p != fname && *p != '.' && *p != '/' && *p != '\\' )
    p-- ;

  if ( *p == '.' )
  {
    if ( _ssgStrEqual ( p, ".bmp"  ) ) { loadTextureBMP ( fname ) ; return ; }
    if ( _ssgStrEqual ( p, ".png"  ) ) { loadTexturePNG ( fname ) ; return ; }
    if ( _ssgStrEqual ( p, ".rgb"  ) ||
         _ssgStrEqual ( p, ".rgba" ) ||
         _ssgStrEqual ( p, ".int"  ) ||
         _ssgStrEqual ( p, ".inta" ) ||
         _ssgStrEqual ( p, ".bw"   ) ) { loadTextureSGI ( fname ) ; return ; }
    if ( _ssgStrEqual ( p, ".jpg"  ) ||
         _ssgStrEqual ( p, ".jpeg" ) ) { loadTextureJPEG ( fname ) ; return ; }

    for (int i = 0; i < MAX_USER_TEXTURE_FORMATS; i++)
      if ( _ssgStrEqual ( p, user_texture_formats[i].ext ) ) {
        GLubyte *image;
        int x, y, z;
        (*user_texture_formats[i].loader)(fname, &image, &x, &y, &z);
        if (image)
          make_mip_maps(image, x, y, z);
        else
          loadDummyTexture();
        return;
      }
  }

  ulSetError ( UL_WARNING, "ssgImageLoader: '%s' - unrecognised file extension.",
                                                    fname ) ;
  loadDummyTexture () ;
}


There's probably some errors but you get the idea. It's a lot simpler
and more portable than using shared object files or DLLs.

Re: [Plib-devel] JPEG loader

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

Trent Gamblin wrote:

> I found some small source code to load JPEG's, and fixed it up a bit
> to work with PLIB.

I refer you to my document: "JPEGS are evil too":

   http://web2.airmail.net/sjbaker1/jpegs_are_evil_too.html

What is really needed is to implement some kind of a plugin
arrangement for image loaders in PLIB.  Right now:

* Adding lots of loader code for obscure or useless file
  formats is a waste of download throughput for people
  sensible enough to avoid them.

* Using other libraries to do the bulk of the work is
  attractive - but imposes boatloads of additional
  dependancies on applications that need PLIB which
  causes a LOT of extra hassle for the application
  developers.

A plugin arrangement would make either of the above
approaches work - developers could then choose which
file formats they need and either add code or dependancies
as needed.

-- 
Steve Baker                  http://web2.airmail.net/sjbaker1
sjb...@ai... (home)  http://www.woodsoup.org/~sbaker
sj...@ht...      (work)

[Plib-devel] JPEG loader

[Trent G. <tm...@cy...>]

I found some small source code to load JPEG's, and fixed it up a bit
to work with PLIB. It's only about 25K of code, it loads every JFIF
version 1 image I've tried and the only part of the code that's from
the IJG is the IDCT algorithm. Would this be something that could go
in the main library? It would be really nice to have a good texture
format supported natively by PLIB. I have the authors permission to
use the code.

I'll send a patch if it's ok to add to the library. Right now it's all
in it's own source file (ssgLoadJPEG.cxx), but I can put it in
ssgImageLoader.cxx if necessary. I separated it because it could get
quite messy having all the loaders in the same file.

The author of the decoder is Angelo Mottola, and you can find the
original package for Allegro at: http://www.orbflux.com/jpgalleg

PS: Anyone have settings for "indent" or an indent.pro that will
format code like in the rest of PLIB? I find it hard to code using
that style :)

Re: [Plib-devel] Ancient history....depth buffer queries

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

Scott McMillan wrote:
> 
> All:
> 
> Just a followup on the discussion below.  I have been able to
> test this under NT for a few more OpenGL boards out there.
> This seems to be a more pervasive error than I would have
> guessed (SGI given for reference):
> 
> board                     glGetIntegerv(GL_DEPTH_RANGE,...);
> --------------------      --------------------------------------
> SGI O2 IRIX 6.5.7         0,2147482496
> SGI iR IRIX 6.5.5         0,2147483647  (MAX_INT)
> 
> nVidia TNT2               0,2147482496
> HP - FX6+                 0,2147483647  (MAX_INT)
> AccelGalaxy(NT)           0,1           (incorrect)
> Intergraph Wildcat 4000   0,1           (incorrect)
> Diamond FireGL            0,1           (incorrect)

Yikes!

Well, it's kinda comforting that the 'big name' companies
like SGI, nVidia and HP are getting it right.

So, You should certainly report this to the offenders
(that's the only way things get better) - and switch
to the glGetFloatv version.

-- 
Steve Baker                  http://web2.airmail.net/sjbaker1
sjb...@ai... (home)  http://www.woodsoup.org/~sbaker
sj...@ht...      (work)

Re: [Plib-devel] Ancient history....depth buffer queries

[Scott M. <mcm...@ca...>]

All:

Just a followup on the discussion below.  I have been able to
test this under NT for a few more OpenGL boards out there.
This seems to be a more pervasive error than I would have
guessed (SGI given for reference):

board                     glGetIntegerv(GL_DEPTH_RANGE,...);
--------------------      --------------------------------------
SGI O2 IRIX 6.5.7         0,2147482496
SGI iR IRIX 6.5.5         0,2147483647  (MAX_INT)

nVidia TNT2               0,2147482496
HP - FX6+                 0,2147483647  (MAX_INT)
AccelGalaxy(NT)           0,1           (incorrect)
Intergraph Wildcat 4000   0,1           (incorrect)
Diamond FireGL            0,1           (incorrect)



Steve Baker wrote:
> 
> Scott McMillan wrote:
> 
> > I have been having problems with the approach below on one piece
> > (so far) of NT/PC hardware:
> >
> >    the AccelGalaxy card and/or its OpenGL driver.
> >
> > The culprit is the following piece of code that I am not sure is valid
> > OpenGL code:
> >
> >    glGetIntegerv( GL_DEPTH_RANGE, z_vals ) ;
> 
> Yes - I have to say that this *looks* like it should be glGetFloatv,
> 
> > The OpenGL 1.1 manual says to use glGetFloatv for this enum...
> 
> No - it doesn't.  The OpenGL 1.1 'Blue Book' says:
> 
>   "Type conversion is performed if params has a different type
>    than the state variable value being requested."
> 
> However, it notes that:
> 
>   "If glGetIntegerv is called...most floating-point values are
>    rounded to the nearest integer value."
> 
> *most*?!?  Well, it goes on to explain that colours and normals
> are exceptions.
> 
> However, a bit later on:
> 
>   "GL_DEPTH_RANGE  params returns two values: the near and far mapping
>    limits for the depth buffer.  Integer values, if requested, are
>    linearly mapped from the internal floating-point representations
>    such that 1.0 returns the most positive representable integer
>    value and -1.0 returns the most negative representable integer
>    value.  The initial vlaue is (0,1)."
> 
> ...so, glGetFloatv should return (0,1) and glGetIntegerv should
> return (0,2147483647)
> 
> > ..., and
> > AccelGalaxy drive truncates the floating point values to ints and
> > reports 0 and 1 for near far (where as an SGI O2 would report 0 and
> > something close to MAX_INT).
> 
> Exactly.  So the AccelGalaxy OpenGL is buggy - presumably because someone
> didn't read the fine print about this peculiar exception to the glGetInteger
> rules.

-- 
Scott McMillan                        mailto:mcm...@ca...
Cambridge Research Associates         http://www.cambridge.com
1430 Spring Hill Road, Ste. 200       Voice: (703) 790-0505 x7235
McLean, VA 22102                      Fax:   (703) 790-0370

Re: [Plib-devel] Re: [Plib-users] Loading ASE file

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

Sam Stickland wrote:

>  >  I suppose you'll also have to construct the bounding sphere
> > for that node around the entire locus of animation (all the curves
> > plus twice the sphere radius of the basic object).
> 
> Is that wise?
> 
> It would make sense if you're only using timed transforms to animate the
> object, and then another transform to move it, but this
> might not always be the case.
> 
> If you can define curves and speeds/time-frames I'm sure that sooner or
> later someone would try to use this to set the path of an
> object using this system.  And if it's a long path, that, just for arguments
> sake, frequently moves out of view, then the above
> clipping system wouldn't actually do any clipping.

Indeed - but think about the alternative.

If you only construct a bounding sphere around where the object is
*NOW* then the object node won't get visited by the cull/draw traversal
(or an intersection test traversals) unless it's last known position
is in the field of view. Hence, as soon as it goes off the screen,
it's position (and hence bounding sphere) will cease to be updated
and the object will freeze until it accidentally gets back into
the field of view - or hit by an intersection test traversal or
something.

The fix for that means that you have to do all the curve processing
for EVERY moving object EVERY frame just in case it happens to move into
the field of view.

That kind of scheme scales really badly to large numbers of moving
objects - and scalability is a big issue for well thought out scene
graph API's.

The issue of having to traverse down to a node whose locus is huge
isn't a huge deal - you just make sure that objects whose animation
takes them over large area are stored near the top of the tree.

I want *LOTS* of moving objects - mostly with pretty small locii - and
for that, my approach is cheaper.  Think of a large Tux level with
dozens and dozens of little critters running around - each with
animated arms, legs, tentacles, whatever.  That could quickly run
to hundreds of animations - but with perhaps just a dozen of them
in the field of view.  The bounding spheres for those animations
would still be tiny.

If you have lots of objects with large locii, then put them at the
top of the scene graph tree and the cost will be no larger than
having to visit every moving object every frame.

-- 
Steve Baker                  http://web2.airmail.net/sjbaker1
sjb...@ai... (home)  http://www.woodsoup.org/~sbaker
sj...@ht...      (work)

Re: [Plib-devel] SL blocking

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

Trent Gamblin wrote:
> 
> * Steve Baker <sjb...@ai...> wrote:
> > From the way SL is supposed to meter it's data rate
> > to suit the rate it's disappearing into the sound card,
> > this shouldn't matter - but I guess you wouldn't have said
> > this if it worked OK for you.
> >
> > Could you explain?  (Not that I mind making the change - I
> > just like to understand what's going on).
> 
> Sorry, it's nothing like that. The call to open just hangs forever
> if there is something else using the device. Adding O_NONBLOCK makes
> that call fail and return right away, and then a dummy driver is set
> up I think?

Oh!  I see.  Yes - I guess that is worth-while.

I'll stuff it into CVS tonight.

-- 
Steve Baker                  http://web2.airmail.net/sjbaker1
sjb...@ai... (home)  http://www.woodsoup.org/~sbaker
sj...@ht...      (work)

RE: [Plib-devel] Re: [Plib-users] Loading ASE file

[Dave M. <Dav...@dy...>]

> * Dave McClurg <Dav...@dy...> wrote:
> > I cleaned up my code to work with the latest PLIB in CVS.
> >    
> > I have a new ssgLoadASE loader which takes care of parent heirarchy
> > and parses TM_ANIMATION SAMPLES and creates new entities called
> > ssgTransformSelectors.  the transformations are not working yet.
> > probably some math problem that eludes me.  but it's very close.
> > take a peek if you would.
> 
> Can you upload the femalespin.ase model?
> 
That is a data file from the Starsiege Tribes Development team.
I don't have permission to release that.  otherwise i would.

You could create something very close to it by loading any BIP
file (biped animation) in animation studio and saving it as ASE format.
Of course, you wouldn't have a SKIN MESH on the skeleton but the BIP
node names are all the same, AFAIK.

Larry Hess said he had an ASE model with animation. Larry?
Anyone with a copy of 3DSMAX/animation studio in the house?

--Dave McClurg

Re: [Plib-devel] Re: [Plib-users] Loading ASE file

[Trent G. <tm...@cy...>]

* Dave McClurg <Dav...@dy...> wrote:
> I cleaned up my code to work with the latest PLIB in CVS.
>    
> I have a new ssgLoadASE loader which takes care of parent heirarchy
> and parses TM_ANIMATION SAMPLES and creates new entities called
> ssgTransformSelectors.  the transformations are not working yet.
> probably some math problem that eludes me.  but it's very close.
> take a peek if you would.

Can you upload the femalespin.ase model?

RE: [Plib-devel] Re: [Plib-users] Loading ASE file

[Dave M. <Dav...@dy...>]

> 
> > Yes I would be interested in helping on the
> > TM_ANIMATION.
> > And yes I have model with animation.
> 
> excellent!
> come over to the plib-devel mailing list
> i'll clean up the code I have finished so far and send it to you
> 
> Does the ssgTransformSelector  work like the ssgSelector ? If 
> so I think we
> should a real animation system. I mean a ssgTransformAni and 
> it would eval
> cruves to get its data. That way you pass it a time value and 
> it eval the
> cruve at that time. I would glad to write this and the cruve class.
> 

I cleaned up my code to work with the latest PLIB in CVS.

I have a new ssgLoadASE loader which takes care of parent heirarchy and
parses TM_ANIMATION SAMPLES and creates new entities called
ssgTransformSelectors.  the transformations are not working yet.  probably
some math problem that eludes me.  but it's very close.  take a peek if you
would.

	http://www.pond.net/~davem/stuff

you can dump these files into the ssg/tux from plib_example-1.1.8 and add
the three new files to the make process and point the loader to your ASE
file and it should do something.

i really appreciate any help on this.

--Dave

Re: [Plib-devel] SL blocking

[Trent G. <tm...@cy...>]

* Steve Baker <sjb...@ai...> wrote:
> From the way SL is supposed to meter it's data rate 
> to suit the rate it's disappearing into the sound card,
> this shouldn't matter - but I guess you wouldn't have said
> this if it worked OK for you.
>
> Could you explain?  (Not that I mind making the change - I
> just like to understand what's going on).

Sorry, it's nothing like that. The call to open just hangs forever
if there is something else using the device. Adding O_NONBLOCK makes
that call fail and return right away, and then a dummy driver is set
up I think?

R: [Plib-devel] Re: [Plib-users] Loading ASE file

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

Should it be useful to anybody dealing with 2D/3D curves for paths,
trajectories ..., for a past project I found rather good libraries at

http://www.magic-software.com/MgcCurve.html

Different kind of curves, within good C++ class frameworks, with a native
concepts of time and velocity associated to path curves, thus suited for
straightforward implementation of camera paths and motion. It takes just a
bit time to select the proper kind of curve for own application, also
depending on the interface these expose.

Greetings -

----------------------------------------------------------------------------
-
Paolo Leoncini						phone:  +39 (0823) 623134
Scientific Visualization Group			fax:    +39 (0823) 623126
CIRA - Italian Center for Aerospace Researches	p.l...@ci...
Via Maiorise - 81043 Capua (CE) Italy		www.cira.it/research/vis

> -----Messaggio originale-----
> Da: pli...@li...
> [mailto:pli...@li...]Per conto di Sam
> Stickland
> Inviato: giovedì 25 maggio 2000 12.43
> A: pli...@li...
> Oggetto: Re: [Plib-devel] Re: [Plib-users] Loading ASE file
>
>
>
> ----- Original Message -----
> From: "Steve Baker" <sjb...@ai...>
> To: <pli...@li...>
> Sent: Thursday, May 25, 2000 1:53 AM
> Subject: Re: [Plib-devel] Re: [Plib-users] Loading ASE file
>
>
>  >  I suppose you'll also have to construct the bounding sphere
> > for that node around the entire locus of animation (all the curves
> > plus twice the sphere radius of the basic object).
>
> Is that wise?
>
> It would make sense if you're only using timed transforms to
> animate the object, and then another transform to move it, but this
> might not always be the case.
>
> If you can define curves and speeds/time-frames I'm sure that
> sooner or later someone would try to use this to set the path of an
> object using this system.  And if it's a long path, that, just
> for arguments sake, frequently moves out of view, then the above
> clipping system wouldn't actually do any clipping.
>
> Sam
>
>
>
> _______________________________________________
> plib-devel mailing list
> pli...@li...
> http://lists.sourceforge.net/mailman/listinfo/plib-devel
>