plib-devel

[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] 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)

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.

[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] 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] 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:

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