plib-devel

[Plib-devel] R: Texture loading problems (bmp/rgb)

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

> -----Messaggio originale-----
> Da: pli...@li...=20
> [mailto:pli...@li...] Per conto=20
> di Jan Reucker
> Inviato: marted=EC 21 novembre 2006 17.49
> A: pli...@li...
> Oggetto: Re: [Plib-devel] Texture loading problems (bmp/rgb)
>=20
[snip]
> I think I'll prepare a patch, but I guess this will breakt 3ds=20
> loading until we also remove the forced bmp texture flipping there...

I can supply the updated ssgload3ds.cxx also including other patches =
that
were tested time ago by someone in the FlightGear dev team but never put =
in
cvs since I'm not an official Plib developer. If agreed I'll send it to =
the
good will man...

> Kind regards,
> Jan R.

Greetings -

Paolo Leoncini

Re: [Plib-devel] Example Program Changes

[Melchior F. <mf...@us...>]

* Fay John F Dr CTR USAF AFSEO/SK -- Monday 06 November 2006 14:50:
> 	It appears that we are not looking at the same thing.

I doubt it:


  $ cd ~/fgfs/plib

  $ svn up
  At revision 2104.

  
There! A full revision, not an incomplete checkout. Only:


  $ svn status|grep "^M "|grep -v html
  M      src/ssg/ssgLoadTexture.cxx


There are only two changed lines in one unrelated file (texture
compression patch). The changes to html files only fix the
horrible colors so as to make the documentation actually useful.
And still:


  $ find -type f|xargs grep PUCLASS_SCROLLINGLIST
  $


There! No PUCLASS_SCROLLINGLIST! So there's not surprise that it
can't compile. After Wolfram's hint and the following patch, I
could finally compile and the program runs here on Linux:



$ svn diff
Index: src/Makefile.am
===================================================================
--- src/Makefile.am     (revision 2104)
+++ src/Makefile.am     (working copy)
@@ -1,7 +1,9 @@
 bin_PROGRAMS = pguide

-pguide_SOURCES = CreateWidget.cxx pGuide.cxx StatusWindow.cxx WidgetList.h \
+pguide_SOURCES = pGuide.cxx StatusWindow.cxx WidgetList.h \
        WidgetWindow.cxx WriteCode.cxx LoadSave.cxx PropertiesWindow.cxx

+pguide_LDADD = -lplibpuaux
+
 EXTRA_DIST = pGuide.dsp



So the file CreateWidget.cxx is really useless and should be removed?

m.

Re: [Plib-devel] Example Program Changes

[Melchior F. <mf...@us...>]

* Wolfram Kuss -- Wednesday 08 November 2006 15:53:
> As you see, it does not compile CreateWidget.cxx and renaming that
> file does not affect compilation. Please take that file out of the
> makefile and see what happens. 

You are right. That file is apparently not used. I get another
error then ...   :-]

see my other message

m.

Re: [Plib-devel] Texture loading problems (bmp/rgb)

[Jan R. <slo...@gm...>]

Am Sat, 18 Nov 2006 09:08:35 -0600 schrieb steve <sjb...@ai...>:

> Yes - that's it exactly.  There is an 'upside down' flag.  This
> is a typically stupid Microsoftian coding stupidity.   It makes
> it very fractionally easier for some programs to write out images
> if they store them that way up internally - at the price of
> belabouring every single image reading program with the additional
> code to conditionally flip them back the right way around.

> Worse still, the BMP file format is a horrible mess with
> multiple headers inside other headers - each of which can have
> duplicates of that flag bit.  Some programs set all of the
> flag bits - others set only one of them - some seem to treat
> the bit as applying consecutively so two 'invert' flags are
> supposed to flip it back the right way up.

Steve,

I found some more detailed information on the .bmp (DIB) format on
MSDN:

http://msdn2.microsoft.com/en-us/library/ms532290.aspx

But I didn't find any information about nested headers with duplicate
"upside down" flags. I only found this:

"biHeight
Specifies the height of the bitmap, in pixels. If biHeight is positive,
the bitmap is a bottom-up DIB and its origin is the lower-left corner.
If biHeight is negative, the bitmap is a top-down DIB and its origin
is the upper-left corner."

The biHeight field can only appear once in a bmp file, so it
shouldn't be a problem to get the orientation right. I think I'll
prepare a patch, but I guess this will breakt 3ds loading until
we also remove the forced bmp texture flipping there...

Kind regards,
Jan R.

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

Re: [Plib-devel] Texture loading problems (bmp/rgb)

[Jan R. <slo...@gm...>]

Am Sun, 19 Nov 2006 18:12:49 +0100 schrieb p.l...@ci...:

> Scrive Jan Reucker <slo...@gm...>:
> 
> > Am Sun, 19 Nov 2006 09:47:37 +0100 schrieb p.l...@ci...:
> >
> > > I also use BMP along with the 3DS loader and it works fine (the loader
> > manages
> > > the y-flipping so to resemble the other serious image format habit).
> >
> > Hmm, as far as I could see in the BMP loader source code it *always*
> > flips the image. So it might depend on the program that you create
> > the BMP's with if the texture loads correctly.
> 
> No, it doesn't - look at the ssgLoad3ds.cxx code off the SVN:
> 
> line 891:
>       /* flip textures y-coord if texture is a BMP */
>       char *texture_extension =
> 	material->tex_name + strlen(material->tex_name) - 3;
> 
>       flip_texture_y = ulStrEqual( texture_extension, "BMP" );

Hello Paolo,

I was just referring to the BMP loader (ssgLoadBMP.cxx, line 246):

  /* read and flip image */
  {
    int row_size = w * (bpp / 8) ;
    for ( int y = h-1 ; y >= 0 ; y-- )
    {
      GLubyte *row_ptr = &data [ y * row_size ] ;
      if ( fread ( row_ptr, 1, row_size, curr_image_fd ) != (unsigned)row_size )
      {
        ulSetError ( UL_WARNING, "Premature EOF in '%s'", curr_image_fname ) ;
        return false ;
      }
    }
  }

So this loader code *always* flips the image, and the 3ds model loader
*always* flips it back. Does this make sense? No. And other model loaders
don't do this. If I model something in AC3D using a bmp texture and then
load it into an SSG application, the texture is always flipped while it
looks right in AC3D. And if I export the model from AC3D to the 3ds format
it loads correctly in SSG! This is definitely inconsistent, and I'd highly
recommend to fix this behaviour.

IMHO it would make sense to remove the pixel row flipping from ssgLoadBMP.cxx
AND the texture flipping code from ssgLoad3ds.cxx. I'm willing to
do this fix and submit a patch. But if someone can dig up a document
describing the full details of BMP, especially regarding pixel row
orientation, this would definitely help in this discussion. The
documents on wotsit.org didn't help me much.

Kind regards,
Jan R.

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

Re: [Plib-devel] Texture loading problems (bmp/rgb)

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

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

> Am Sun, 19 Nov 2006 09:47:37 +0100 schrieb p.l...@ci...:
>
> > I also use BMP along with the 3DS loader and it works fine (the loader
> manages
> > the y-flipping so to resemble the other serious image format habit).
>
> Hmm, as far as I could see in the BMP loader source code it *always*
> flips the image. So it might depend on the program that you create
> the BMP's with if the texture loads correctly.

No, it doesn't - look at the ssgLoad3ds.cxx code off the SVN:

line 891:
      /* flip textures y-coord if texture is a BMP */
      char *texture_extension =
	material->tex_name + strlen(material->tex_name) - 3;

      flip_texture_y = ulStrEqual( texture_extension, "BMP" );

> Kind regards,
> Jan R.

Greetings -

Paolo Leoncini

Re: [Plib-devel] Texture loading problems (bmp/rgb)

[Jan R. <slo...@gm...>]

Am Sun, 19 Nov 2006 09:47:37 +0100 schrieb p.l...@ci...:

> I also use BMP along with the 3DS loader and it works fine (the loader ma=
nages
> the y-flipping so to resemble the other serious image format habit).

Hmm, as far as I could see in the BMP loader source code it *always*
flips the image. So it might depend on the program that you create
the BMP's with if the texture loads correctly.

Now if I could only get svn up and running... I'm always getting a
version mismatch:

# svn  co https://svn.sourceforge.net/svnroot/plib/trunk=20
svn: PROPFIND Anfrage fehlgeschlagen auf =BB/svnroot/plib/trunk=AB
svn: PROPFIND von =BB/svnroot/plib/trunk=AB: SSL negotiation failed: SSL di=
sabled due to library version mismatch (https://svn.sourceforge.net)

OS is Debian GNU/Linux.

Kind regards,
Jan R.

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

Re: [Plib-devel] Texture loading problems (bmp/rgb)

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

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

> Am Sat, 18 Nov 2006 09:08:35 -0600 schrieb steve <sjb...@ai...>:
>
> > Yes - that's it exactly.  There is an 'upside down' flag.  This
> > is a typically stupid Microsoftian coding stupidity.   It makes
>
> Well, if it's done the right way (only one flag at a fixed place
> in the header), it's no problem to write a loader for it, the
> overhead is actually very small. I'm not sure but I think TGA
> does it that way.

TGA is among the best format to use in Plib - I warmly suggest it.

I also use BMP along with the 3DS loader and it works fine (the loader manages
the y-flipping so to resemble the other serious image format habit).

I'm not 100% sure but PNG also suffers the y-flipping problem, and, should it be
the case, it is not managed by the loaders.

> Kind regards,
> Jan R.

Greetings -

Paolo Leoncini

Re: [Plib-devel] Texture loading problems (bmp/rgb)

[Jan R. <slo...@gm...>]

Am Sat, 18 Nov 2006 09:08:35 -0600 schrieb steve <sjb...@ai...>:

> Yes - that's it exactly.  There is an 'upside down' flag.  This
> is a typically stupid Microsoftian coding stupidity.   It makes

Well, if it's done the right way (only one flag at a fixed place
in the header), it's no problem to write a loader for it, the
overhead is actually very small. I'm not sure but I think TGA
does it that way.

> Worse still, the BMP file format is a horrible mess with
> multiple headers inside other headers - each of which can have
> duplicates of that flag bit.  Some programs set all of the
> flag bits - others set only one of them - some seem to treat
> the bit as applying consecutively so two 'invert' flags are
> supposed to flip it back the right way up.

In that case I agree. And it's really typical for M$'s file
formats. IMHO the DirectX model format (.x) is the same kind
of mess.
 
> It's a horrible mess - and I refuse to take the time to sort
> it all out.
> So don't use BMP.   It's a crappy format anyway.

Personally I prefer .rgb for textures, no problem. But I'd like
to make it easier for Windoze users to create models for my
program, and it's hard to find Windoze tools that can write
.rgb (yes, I know there's a port of the Gimp). And of course,
if PLIB offers the BMP loader as a feature it would be nice
if it would work for as many input files as possible, so
I'm willing to contribute patches to fill the holes if it
isn't too time consuming.

Do you know a good description of the BMP format? I found one
on Wotsit.org, but didn't find any information on the
"upside down" flag.

> > really set to values less than 1.0? None of the tools I'm currently
> > working with (mainly the GIMP) seems to be capable of producing
> > a pure RGB .rgb image, only RGBA, so the textured objects will
> > randomly be hidden behind other translucent objects.
> 
> No - that's not true.  I do this in GIMP all the time - and I
> know other people who do it in PhotoShop - so I know it's
> possible.  In GIMP, use the 'flatten image' menu item (I think
> it's under the 'Image' menu) - then you'll have
> no alpha plane in the image at all and when you save you'll
> get a 1 or a 3 byte image.  

Aaah, found it! I never knew what this function was supposed to
do. I just tested it, and it works. In the meantime I also learned
how to use Image Magick for that purpose:

convert file_alpha.rgb +matte sgi:file_noalpha.rgb

But of course it's much more convenient to do it right inside
the Gimp.

> Similarly, if you load an opaque
> image (eg from JPEG which doesn't support alpha) and just
> write it out, it'll be a 3-band image.  You have to explicitly
> add an alpha plane or create an alpha layer to make GIMP
> write 2 or 4 bands.

Yes, I knew this behaviour, but I never knew how to remove the
alpha channel from existing RGBA images.

> > My only
> > choice right now is to fall back to .bmp textures which I don't
> > like for several reasons, one being the bug mentioned above.
> > Would it hurt to extend the rgb loader like this?
> 
> It might break existing programs that load the image and then
> add alpha information themselves - so it wouldn't be an entirely
> 'safe' change.

O.k., less work for me ;-) I'm convinced that it's a practical
solution to leave it as it is and do a proper texture conversion
with other tools.

Kind regards,
Jan R.

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

Re: [Plib-devel] Texture loading problems (bmp/rgb)

[steve <sjb...@ai...>]

Jan Reucker wrote:
> Hello,
> 
> I'm currently having two problems with texture loading, and I want
> your opinion if these are real bugs, missing features or whatever.
> 
> First: bmp loading
> 
> As already stated in bug tracker item 1275291, bmp textures are
> displayed flipped (upside down). Is this a generall problem?
> Or does bmp support different modes (like "first pixel bottom left" /
> "first pixel top left") which aren't properly evaluated?
> The loader seems to always flip the loaded data. If someone can
> give me a heads-up on the bmp format details I'd like to prepare
> a bugfix.

Yes - that's it exactly.  There is an 'upside down' flag.  This
is a typically stupid Microsoftian coding stupidity.   It makes
it very fractionally easier for some programs to write out images
if they store them that way up internally - at the price of
belabouring every single image reading program with the additional
code to conditionally flip them back the right way around.

Worse still, the BMP file format is a horrible mess with
multiple headers inside other headers - each of which can have
duplicates of that flag bit.  Some programs set all of the
flag bits - others set only one of them - some seem to treat
the bit as applying consecutively so two 'invert' flags are
supposed to flip it back the right way up.

It's a horrible mess - and I refuse to take the time to sort
it all out.

So don't use BMP.   It's a crappy format anyway.


> Second: rgb loading
> 
> When loading an rgb texture, there's a check if the number of
> bit planes is two or four. If this is the case, the texture
> is deemed to be translucent (translucent greyscale or RGBA).

Right.  There is really no other way to do that.

> But this makes a textured object translucent no matter if the
> texture really uses the alpha channel or not. Wouldn't it make
> more sense to check if any pixels in the alpha channel are
> really set to values less than 1.0? None of the tools I'm currently
> working with (mainly the GIMP) seems to be capable of producing
> a pure RGB .rgb image, only RGBA, so the textured objects will
> randomly be hidden behind other translucent objects.

No - that's not true.  I do this in GIMP all the time - and I
know other people who do it in PhotoShop - so I know it's
possible.  In GIMP, use the 'flatten image' menu item (I think
it's under the 'Image' menu) - then you'll have
no alpha plane in the image at all and when you save you'll
get a 1 or a 3 byte image.   Similarly, if you load an opaque
image (eg from JPEG which doesn't support alpha) and just
write it out, it'll be a 3-band image.  You have to explicitly
add an alpha plane or create an alpha layer to make GIMP
write 2 or 4 bands.

You should do that for images that don't have alpha because
otherwise you are wasting disk space, memory space and texture
memory and making the file take longer to load.

> My only
> choice right now is to fall back to .bmp textures which I don't
> like for several reasons, one being the bug mentioned above.
> Would it hurt to extend the rgb loader like this?

It might break existing programs that load the image and then
add alpha information themselves - so it wouldn't be an entirely
'safe' change.

[Plib-devel] Texture loading problems (bmp/rgb)

[Jan R. <slo...@gm...>]

Hello,

I'm currently having two problems with texture loading, and I want
your opinion if these are real bugs, missing features or whatever.

First: bmp loading

As already stated in bug tracker item 1275291, bmp textures are
displayed flipped (upside down). Is this a generall problem?
Or does bmp support different modes (like "first pixel bottom left" /
"first pixel top left") which aren't properly evaluated?
The loader seems to always flip the loaded data. If someone can
give me a heads-up on the bmp format details I'd like to prepare
a bugfix.


Second: rgb loading

When loading an rgb texture, there's a check if the number of
bit planes is two or four. If this is the case, the texture
is deemed to be translucent (translucent greyscale or RGBA).
But this makes a textured object translucent no matter if the
texture really uses the alpha channel or not. Wouldn't it make
more sense to check if any pixels in the alpha channel are
really set to values less than 1.0? None of the tools I'm currently
working with (mainly the GIMP) seems to be capable of producing
a pure RGB .rgb image, only RGBA, so the textured objects will
randomly be hidden behind other translucent objects. My only
choice right now is to fall back to .bmp textures which I don't
like for several reasons, one being the bug mentioned above.
Would it hurt to extend the rgb loader like this?

Kind regards,
Jan R.

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

Re: [Plib-devel] Example Program Changes

[Fay J. F Dr C. U. AFSEO/SK <joh...@eg...>]

I don't know that I can say *always*.  Certainly it does most of the time
and mixing the two is never a good idea.  Do the PLIB library or any of the
examples/demos mix the two?

John F. Fay
Technical Fellow
Jacobs/Sverdrup TEAS Group
850-883-1294 

-----Original Message-----
From: pli...@li...
[mailto:pli...@li...] On Behalf Of Wolfram Kuss
Sent: Wednesday, November 08, 2006 3:02 PM
To: PLIB Developers
Subject: Re: [Plib-devel] Example Program Changes

I would have guessed that say Single Threaded versus Multithreaded
always leads to an error (and not just a warning), does it not?


>Greetings -
>
>Paolo Leoncini

Bye bye,
Wolfram.


-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job
easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
plib-devel mailing list
pli...@li...
https://lists.sourceforge.net/lists/listinfo/plib-devel

Re: [Plib-devel] Example Program Changes

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

Scrive Wolfram Kuss <w_...@rz...>:

> I would have guessed that say Single Threaded versus Multithreaded
> always leads to an error (and not just a warning), does it not?

MS VC++ 6 hates symbol redefinitions. Hence as far as the inclusion of a new
library produces redefinitions, the linker generates errors. In the case
indicated, libcmt.lib was probably included in the link command but not used
(no function actually used), so we just got a warning.

The problem with Single Threaded versus Multithreaded is exactly the same as
Multithreaded versus Multithreaded DLL (apparently less important): the linked
libraries have may be 95% of the symbol in common, not to mention the .lib used
to point to runtime dlls - a collision on symbols is almost sure, and this leads
to tons of linker error.

>
> >Greetings -
> >
> >Paolo Leoncini
>
> Bye bye,
> Wolfram.

Best redards -

Paolo Leoncini

Re: [Plib-devel] Example Program Changes

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

I would have guessed that say Single Threaded versus Multithreaded
always leads to an error (and not just a warning), does it not?


>Greetings -
>
>Paolo Leoncini

Bye bye,
Wolfram.

Re: [Plib-devel] Example Program Changes

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

Scrive Wolfram Kuss <w_...@rz...>:

> I wrote:
>
> >M. wrote:
> >
> >>
> >>    p-guide doesn't compile. It issues this error message:
> >
> >It does not compile under Windows with a clean checkout either.
>
> I finally can commit to SVN and am so spending a bit more time.
> The issue with the MSVC6 compilation actually was fairly trivial and
> MSVC6 specific; It did not link to puAux in the *.dsp (MSVC6 project).
>
> Fixed and committed, here is the output of compilation:
>
> ------------Configuration: pGuide - Win32 Release----------------
> Compiling...
> LoadSave.cxx
> pGuide.cxx
> PropertiesWindow.cxx
> StatusWindow.cxx
> WidgetWindow.cxx
> WriteCode.cxx
> Linking...
> LINK : warning LNK4098: defaultlib "LIBCMT" conflicts with use of
> other libs; use /NODEFAULTLIB:library
>
> pGuide.exe - 0 error(s), 1 warning(s)
>
> I don't know what to do about that warning, sorry. But from experience
> it is harmless. Unfortunately Microsoft does not tell you what
> conflicts with what, only that there is a conflict. BTW I get the same
> with a few other PLIB projects as well.

It is usually due to different code generation modes among the various parts of
an application (libraries, the app itself) - in the case of a Release
Configuration, these are, namely, Single Threaded, Multithreaded, and
Multithreaded DLL. So the reccomendation is to unify all to the same code
generation model, typically Multithreaded or Multithreaded DLL (which is
probably the current mode for Plib, not sure yet).

This is a positive end case since in similar cases the link phase gives up with
error.

In this case just try to put LIBCMT.lib in Project settings -> Link tab ->
Category: Input -> Ignore libraries input field, or put libc.lib instead.

Greetings -

Paolo Leoncini

Re: [Plib-devel] release candidate awaits your testing.

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

I went through all warnings now and apart from two exceptions did all
that=20
can be done effectively.

One MSVC specific exception is that I did not commit the MSVC8
*.vcproj files.
These contain defines drastically reducing the warning count and do
not=20
clobber the MSVC6 files that have the *.dsp extension.
However, they do not work with MSVC7.X. My suggestion is
I commit them nevertheless and in some readme (which?) mention
MSVC7.X users should recreate the *.vcproj from the *.dsp themselves.

######################################################

The other exception is warnings like these:

.\ssgSaveASC.cxx(167) : warning C4996: 'stricmp' was declared
deprecated
        C:\Programme\Microsoft Visual Studio
8\VC\include\string.h(213) : see declaration of 'stricmp'
        Message: 'The POSIX name for this item is deprecated. Instead,
use the ISO C++ conformant name: _stricmp. See online help for
details.'
			=09

If someone with more knowledge on portability can tell me, this is ok,
I will replace all=20
stricmp with _stricmp.
The same for _strnicmp. Also _fileno. Also _open, _close, _read (see
slMODfile.cxx).

			=09
#######################################################			=09
			=09

Here are (MSVC specific) warnings I (suggest to) ignore:

--------------------Configuration: sg_quat_test - Win32
Release--------------------
Compiling...
sg_quat_test.cxx
Linking...
LINK : warning LNK4089: all references to "USER32.dll" discarded by
/OPT:REF
--------------------Configuration: plib_examples - Win32
Release--------------------

plib_examples - 0 error(s), 1 warning(s)

--------------------Configuration: pview - Win32
Release--------------------
Compiling...
pview.cxx
Linking...
LINK : warning LNK4098: defaultlib "LIBCMTD" conflicts with use of
other libs; use /NODEFAULTLIB:library

pview.exe - 0 error(s), 1 warning(s)

Re: [Plib-devel] Example Program Changes

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

I wrote:

>M. wrote:
>
>>
>>    p-guide doesn't compile. It issues this error message:
>
>It does not compile under Windows with a clean checkout either.

I finally can commit to SVN and am so spending a bit more time.
The issue with the MSVC6 compilation actually was fairly trivial and
MSVC6 specific; It did not link to puAux in the *.dsp (MSVC6 project).

=46ixed and committed, here is the output of compilation:

------------Configuration: pGuide - Win32 Release----------------
Compiling...
LoadSave.cxx
pGuide.cxx
PropertiesWindow.cxx
StatusWindow.cxx
WidgetWindow.cxx
WriteCode.cxx
Linking...
LINK : warning LNK4098: defaultlib "LIBCMT" conflicts with use of
other libs; use /NODEFAULTLIB:library

pGuide.exe - 0 error(s), 1 warning(s)

I don't know what to do about that warning, sorry. But from experience
it is harmless. Unfortunately Microsoft does not tell you what
conflicts with what, only that there is a conflict. BTW I get the same
with a few other PLIB projects as well.

@ Melchior:
As you see, it does not compile CreateWidget.cxx and renaming that
file does not affect compilation. Please take that file out of the
makefile and see what happens.=20

@John F. Fay:
Please check that file is superfluous and then remove it from SVN.

>- tools, exposer, ttt3d and almost all examples work without warnings.
>The non working one is tween_test, which I fixed on my computer. Now I
>just need to be able to commit stuff. I am working on this.

Committed, again the error was in a MSVC only file.


>- There are no MSVC6 workspaces for some projects (IIRC: simon and
>widgy).=20

The new Simon one works and widgy is superseded by p-guide, so
everything ok here as well.

Bye bye,
Wolfram

Re: [Plib-devel] Example Program Changes

[Fay J. F Dr C. U. AFSEO/SK <joh...@eg...>]

I have put up MSVC workspace and project files for Simon.  Widgy has been
deprecated in favor of P-Guide.

I have not been able to get Simon to run properly.  I gave it the
"astropong" script and it failed the "Dead Beef" test.

I have fixed P-Guide, at least according to me and SVN.  The SVN may not
have gotten updated at the time that I announced the fixes to P-Guide.

When I compiled PLIB proper, I only got one warning, which I have fixed.
What are the other warnings?

John F. Fay
Technical Fellow
Jacobs/Sverdrup TEAS Group
850-883-1294 

-----Original Message-----
From: pli...@li...
[mailto:pli...@li...] On Behalf Of Wolfram Kuss
Sent: Saturday, November 04, 2006 7:36 PM
To: PLIB Developers
Subject: Re: [Plib-devel] Example Program Changes

M. wrote:

>
>    p-guide doesn't compile. It issues this error message:

It does not compile under Windows with a clean checkout either.
Unfortunately in my first test I had only tested plib "proper", sorry.

I now checked all in MSVC6 and found:

- PLIB: 15 warnings, but compiles and works.
- tools, exposer, ttt3d and almost all examples work without warnings.
The non working one is tween_test, which I fixed on my computer. Now I
just need to be able to commit stuff. I am working on this.
- There are no MSVC6 workspaces for some projects (IIRC: simon and
widgy). This is ok IMVHO, MSVC6 is old.
- p-guide does not compile or to be more exact compiles but does not
link.

Bye bye,
Wolfram


-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job
easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
plib-devel mailing list
pli...@li...
https://lists.sourceforge.net/lists/listinfo/plib-devel

Re: [Plib-devel] Example Program Changes

[Fay J. F Dr C. U. AFSEO/SK <joh...@eg...>]

Melchior,

	It appears that we are not looking at the same thing.  I
specifically changed the "scrolling list" to a simple "list", which is
indeed a defined widget.  If you don't believe me, I invite you to browse
the SVN tree under SourceForge.

John F. Fay
Technical Fellow
Jacobs/Sverdrup TEAS Group
850-883-1294 

-----Original Message-----
From: pli...@li...
[mailto:pli...@li...] On Behalf Of Melchior
FRANZ
Sent: Saturday, November 04, 2006 1:51 AM
To: pli...@li...
Subject: Re: [Plib-devel] Example Program Changes

* Fay John F Dr CTR USAF AFSEO/SK -- Friday 03 November 2006 23:38:
> I have now fiddled with the demo programs (as distinct from the
> example programs) and they all compile under Windows 

They don't here. The original bug is still there, and it seems you
didn't even read that part of my already *twice* sent message:

    CreateWidget.cxx: In function 'puObject* createWidget(int)':
    CreateWidget.cxx:32: error: 'PUCLASS_SCROLLINGLIST' was not declared in
this scope
    [...]
    CreateWidget.cxx:32: error: 'puaScrollingList' was not declared in this
scope

    And, indeed: neither PUCLASS_SCROLLINGLIST nor puaScrollingList
    are defined anywhere in plib/svn. Some private widget that you
    never committed? Or is this a planned, new name for puList or
    puAuxList?



I REPEAT:

  neither PUCLASS_SCROLLINGLIST nor puaScrollingList are defined anywhere in
plib/svn
 
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
^^^^^^^

Here's the proof:

  $ find -type f|xargs grep PUCLASS_SCROLLINGLIST
  $
  $ find -type f|xargs grep puaScrollingList
  $

Nothing!


So how can it compile for you? In which files of your unmodified copy
are those two defined?

Have you uninstalled any further instance of plib that may be
installed anywhere on your computer? A hacked version where
you had added PUCLASS_SCROLLINGLIST and puaScrollingList, and
that's picked up here?

m.

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job
easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
plib-devel mailing list
pli...@li...
https://lists.sourceforge.net/lists/listinfo/plib-devel

Re: [Plib-devel] Example Program Changes

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

M. wrote:

>
>    p-guide doesn't compile. It issues this error message:

It does not compile under Windows with a clean checkout either.
Unfortunately in my first test I had only tested plib "proper", sorry.

I now checked all in MSVC6 and found:

- PLIB: 15 warnings, but compiles and works.
- tools, exposer, ttt3d and almost all examples work without warnings.
The non working one is tween_test, which I fixed on my computer. Now I
just need to be able to commit stuff. I am working on this.
- There are no MSVC6 workspaces for some projects (IIRC: simon and
widgy). This is ok IMVHO, MSVC6 is old.
- p-guide does not compile or to be more exact compiles but does not
link.

Bye bye,
Wolfram

Re: [Plib-devel] Example Program Changes

[Melchior F. <mf...@us...>]

* Fay John F Dr CTR USAF AFSEO/SK -- Friday 03 November 2006 23:38:
> I have now fiddled with the demo programs (as distinct from the
> example programs) and they all compile under Windows 

They don't here. The original bug is still there, and it seems you
didn't even read that part of my already *twice* sent message:

    CreateWidget.cxx: In function 'puObject* createWidget(int)':
    CreateWidget.cxx:32: error: 'PUCLASS_SCROLLINGLIST' was not declared in this scope
    [...]
    CreateWidget.cxx:32: error: 'puaScrollingList' was not declared in this scope

    And, indeed: neither PUCLASS_SCROLLINGLIST nor puaScrollingList
    are defined anywhere in plib/svn. Some private widget that you
    never committed? Or is this a planned, new name for puList or
    puAuxList?



I REPEAT:

  neither PUCLASS_SCROLLINGLIST nor puaScrollingList are defined anywhere in plib/svn
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Here's the proof:

  $ find -type f|xargs grep PUCLASS_SCROLLINGLIST
  $
  $ find -type f|xargs grep puaScrollingList
  $

Nothing!


So how can it compile for you? In which files of your unmodified copy
are those two defined?

Have you uninstalled any further instance of plib that may be
installed anywhere on your computer? A hacked version where
you had added PUCLASS_SCROLLINGLIST and puaScrollingList, and
that's picked up here?

m.

Re: [Plib-devel] Example Program Changes

[Fay J. F Dr C. U. AFSEO/SK <joh...@eg...>]

Gentlemen,

	I have now fiddled with the demo programs (as distinct from the
example programs) and they all compile under Windows with neither errors nor
warnings.  The "simon" demo does not run, apparently failing the Dead Beef
check somewhere.  Please check that they still compile and run under Linux.

	I had to do some fancy path-setting to get them to compile on my
substitute Windows box; I did not put the modified paths into the SVN
version as they are not general.  I still need some guidance on how to get
the PLIB demos and examples to look for GLUT/freeglut.  Should we just let
the user do it by himself--assuming a proper install puts files into the
appropriate directories, should we use environment variables (I don't think
I like this alternative), or should we do something else? 

John F. Fay
Technical Fellow
Jacobs/Sverdrup TEAS Group
850-883-1294 

-----Original Message-----
From: pli...@li...
[mailto:pli...@li...] On Behalf Of Melchior
FRANZ
Sent: Friday, November 03, 2006 2:17 PM
To: pli...@li...
Subject: Re: [Plib-devel] Example Program Changes

* Fay John F Dr CTR USAF AFSEO/SK -- Friday 03 November 2006 21:10:
> I have run through the example programs and [...]

And what about the "demo" programs? I had almost forgotten this
bug:


    p-guide doesn't compile. It issues this error message:

    CreateWidget.cxx: In function 'puObject* createWidget(int)':
    CreateWidget.cxx:32: error: 'PUCLASS_SCROLLINGLIST' was not declared in
this scope
    [...]
    CreateWidget.cxx:32: error: 'puaScrollingList' was not declared in this
scope

    And, indeed: neither PUCLASS_SCROLLINGLIST nor puaScrollingList
    are defined anywhere in plib/svn. Some private widget that you
    never committed? Or is this a planned, new name for puList or
    puAuxList?


Does this compile for anyone?

m.

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job
easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
plib-devel mailing list
pli...@li...
https://lists.sourceforge.net/lists/listinfo/plib-devel

Re: [Plib-devel] Example Program Changes

[Fay J. F Dr C. U. AFSEO/SK <joh...@eg...>]

I'll get onto the demos.

John F. Fay
Technical Fellow
Jacobs/Sverdrup TEAS Group
850-883-1294 

-----Original Message-----
From: pli...@li...
[mailto:pli...@li...] On Behalf Of Melchior
FRANZ
Sent: Friday, November 03, 2006 2:17 PM
To: pli...@li...
Subject: Re: [Plib-devel] Example Program Changes

* Fay John F Dr CTR USAF AFSEO/SK -- Friday 03 November 2006 21:10:
> I have run through the example programs and [...]

And what about the "demo" programs? I had almost forgotten this
bug:


    p-guide doesn't compile. It issues this error message:

    CreateWidget.cxx: In function 'puObject* createWidget(int)':
    CreateWidget.cxx:32: error: 'PUCLASS_SCROLLINGLIST' was not declared in
this scope
    [...]
    CreateWidget.cxx:32: error: 'puaScrollingList' was not declared in this
scope

    And, indeed: neither PUCLASS_SCROLLINGLIST nor puaScrollingList
    are defined anywhere in plib/svn. Some private widget that you
    never committed? Or is this a planned, new name for puList or
    puAuxList?


Does this compile for anyone?

m.

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job
easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
plib-devel mailing list
pli...@li...
https://lists.sourceforge.net/lists/listinfo/plib-devel

Re: [Plib-devel] Example Program Changes

[Melchior F. <mf...@us...>]

* Fay John F Dr CTR USAF AFSEO/SK -- Friday 03 November 2006 21:10:
> I request that somebody with Linux please test the changes out.

No problems here on Linux. No warnings either.

m.

Re: [Plib-devel] Example Program Changes

[Melchior F. <mf...@us...>]

* Fay John F Dr CTR USAF AFSEO/SK -- Friday 03 November 2006 21:10:
> I have run through the example programs and [...]

And what about the "demo" programs? I had almost forgotten this
bug:


    p-guide doesn't compile. It issues this error message:

    CreateWidget.cxx: In function 'puObject* createWidget(int)':
    CreateWidget.cxx:32: error: 'PUCLASS_SCROLLINGLIST' was not declared in this scope
    [...]
    CreateWidget.cxx:32: error: 'puaScrollingList' was not declared in this scope

    And, indeed: neither PUCLASS_SCROLLINGLIST nor puaScrollingList
    are defined anywhere in plib/svn. Some private widget that you
    never committed? Or is this a planned, new name for puList or
    puAuxList?


Does this compile for anyone?

m.