Thread: RE: [Plib-devel] [Fwd: PLIB -> OpenVMS]
Brought to you by:
sjbaker
Menu
▾
▴
plib-devel
|
From: Ben W. <be...@bg...> - 2000-09-18 12:18:50
|
Sounds interesting, I would like to see this, but I don't think anybody will actually care that its been ported to OpenVMS and may not be worth the additional pain. More OSs we support the more #ifdef stuff we have in each file. But hey, sounds good to me. Later Ben > -----Original Message----- > From: Steve Baker [mailto:sjb...@ai...] > Sent: Friday, September 15, 2000 12:43 AM > To: PLIB-devel > Subject: [Plib-devel] [Fwd: PLIB -> OpenVMS] > > > > This came to my personal email address - I'm not sure there > will be *HUGE* demand > for this port - but every little helps! > > > Pet...@te... wrote: > > > > Hi, > > > > Just wanted to inform you that I have a working port of > PLIB running on > > OpenVMS > > Alpha at the moment see: > > > > http://byron.ext.telia.se/vms/vmsporting.htmlx > > > > the zipped archives will be updated soon, there's a few > minor errors in > > the VMS building > > script MAKE.COM right now > > > > /P.Lj > > -- > Steve Baker HomeEmail: <sjb...@ai...> > WorkEmail: <sj...@li...> > HomePage : http://web2.airmail.net/sjbaker1 > Projects : http://plib.sourceforge.net > http://tuxaqfh.sourceforge.net > http://tuxkart.sourceforge.net > http://prettypoly.sourceforge.net > > > _______________________________________________ > plib-devel mailing list > pli...@li... > http://lists.sourceforge.net/mailman/listinfo/plib-devel > |
|
From: Ben W. <be...@bg...> - 2000-09-18 13:44:10
|
> -----Original Message----- > From: Va...@t-... [mailto:Va...@t-...] > Sent: Monday, September 18, 2000 10:29 AM > To: pli...@li... > Subject: Re: [Plib-devel] [Fwd: PLIB -> OpenVMS] > > > Ben Woodhead wrote: > > > > Sounds interesting, I would like to see this, but I don't > think anybody will > > actually care that its been ported to OpenVMS and may not > be worth the > > additional pain. More OSs we support the more #ifdef stuff > we have in each > > file. But hey, sounds good to me. > > That's just a little inconveniance for a much greater gain: ever > additional system that the code gets ported to increases the chances > that a bug won't get unnoticed. > > CU, > Christian Good point. Thanks Ben > _______________________________________________ > plib-devel mailing list > pli...@li... > http://lists.sourceforge.net/mailman/listinfo/plib-devel > |
|
From: Fay J. F C. AAC/W. <joh...@eg...> - 2001-01-04 20:07:54
|
I'm going to have to plead ignorance on this one. The character string
"blendEnabled" does not occur anywhere in PUI--or in my (probably old) copy
of PLIB. I couldn't find it in GLUT either. Also, my copy of "complex.cxx"
only has 586 lines. Does anybody else know where this bug is coming from?
John F. Fay
joh...@eg...
-----Original Message-----
From: Steve Baker [mailto:sjb...@ai...]
Sent: Thursday, January 04, 2001 14:41
To: PLIB-devel
Subject: [Plib-devel] [Fwd: More plib bugs]
David Megginson wrote:
<snip>
> 5. examples/src/pui/complex dies on a failed assertion in line 1231
> ("us->blendEnabled == cts->Color.BlendEnabled"). I don't have time
> to chase this one down right now, but I'm using a Voodoo3 with DRI
> under XFree86 4 if that's helpful.
>
<snip>
> David
>
> --
> David Megginson da...@me...
> http://www.megginson.com/
--
Steve Baker HomeEmail: <sjb...@ai...>
WorkEmail: <sj...@li...>
HomePage : http://web2.airmail.net/sjbaker1
Projects : http://plib.sourceforge.net
http://tuxaqfh.sourceforge.net
http://tuxkart.sourceforge.net
http://prettypoly.sourceforge.net
_______________________________________________
plib-devel mailing list
pli...@li...
http://lists.sourceforge.net/mailman/listinfo/plib-devel
|
|
From: Wolfram K. <w_...@rz...> - 2001-01-04 21:25:55
|
[Sending a cc to David] =46ay John F Contr AAC/WMG <joh...@eg...> wrote: >I'm going to have to plead ignorance on this one. The character string >"blendEnabled" does not occur anywhere in PUI--or in my (probably old) = copy >of PLIB. I couldn't find it in GLUT either. Also, my copy of = "complex.cxx" >only has 586 lines. =20 So has mine. I think David has a new plib sources, but old examples. David wrote: > 7. examples/src/ssg/tux/WavingFlagDemo.cxx has an implicit conversion > from int to GLenum in line 40 >=20 > int time =3D glutGet(GLUT_ELAPSED_TIME); >=20 > my compiler wants GLUT_ELAPSED_TIME cast to GLenum (!!!) I don't have any glutGet in WavingFlagDemo.cxx. David, thank you very much for your input. It would be very nice of you if you could try to get the newest plib inclusive examples and try again. >John F. Fay >joh...@eg... Bye bye, Wolfram. |
|
From: David M. <da...@me...> - 2001-01-04 22:05:17
|
Wolfram Kuss writes:
> Fay John F Contr AAC/WMG <joh...@eg...> wrote:
>
> >I'm going to have to plead ignorance on this one. The character string
> >"blendEnabled" does not occur anywhere in PUI--or in my (probably old) copy
> >of PLIB. I couldn't find it in GLUT either. Also, my copy of "complex.cxx"
> >only has 586 lines.
>
> So has mine. I think David has a new plib sources, but old examples.
I'm using the examples that are bundled in the main plib CVS
distribution. My guess is that the message must be coming from my
Voodoo3 driver, if it's not coming from PLIB. I did a
find . -type f | xargs grep -i blendenabled
from the root of the plib distribution and nothing turned up but a
couple of core dumps.
Actually, a stack trace shows the error coming from fxSetupBlend (I'm
not sure where that lives):
(gdb) where
#0 0x40240d41 in __kill () from /lib/libc.so.6
#1 0x402409b6 in raise (sig=6) at ../sysdeps/posix/raise.c:27
#2 0x402420d8 in abort () at ../sysdeps/generic/abort.c:88
#3 0x4023abae in __assert_fail () at assert.c:59
#4 0x4042c981 in fxSetupBlend (ctx=0x80f5268) at fxsetup.c:1231
#5 0x40430cde in fxSetupFXUnits (ctx=0x80f5268) at fxsetup.c:1864
#6 0x403c6abc in fxDDUpdateDDPointers (ctx=0x80f5268) at fxdd.c:1360
#7 0x40507303 in gl_update_state (ctx=0x80f5268) at state.c:1109
#8 0x4054abda in gl_maybe_transform_vb (IM=0x810ae88) at vbxform.c:64
#9 0x4054ac6f in gl_flush_vb (ctx=0x80f5268,
where=0x4055abe0 "glPushAttrib") at vbxform.c:92
#10 0x40471506 in _mesa_PushAttrib (mask=16384) at attrib.c:103
#11 0x809307f in puFont::drawString (this=0xbffff518,
str=0x812a7a0 "door.ase", x=175, y=310) at puFont.cxx:159
#12 0x8092156 in puListBox::draw (this=0x81263e8, dx=160, dy=105)
at pu.h:384
#13 0x808deed in puGroup::draw (this=0x812c170, dx=0, dy=0)
at puGroup.cxx:244
#14 0x808deed in puGroup::draw (this=0x811fa48, dx=0, dy=0)
at puGroup.cxx:244
#15 0x808d147 in puDisplay () at pu.cxx:309
#16 0x804b49a in display () at viewer.cxx:330
#17 0x4002d3a9 in processWindowWorkList ()
from /usr/X11R6/lib/libglut.so.3
#18 0x4002d46c in glutMainLoop () from /usr/X11R6/lib/libglut.so.3
#19 0x804c2d4 in main (argc=1, argv=0xbffff7fc) at viewer.cxx:664
(gdb)
> David wrote:
> > 7. examples/src/ssg/tux/WavingFlagDemo.cxx has an implicit conversion
> > from int to GLenum in line 40
> >
> > int time = glutGet(GLUT_ELAPSED_TIME);
> >
> > my compiler wants GLUT_ELAPSED_TIME cast to GLenum (!!!)
>
> I don't have any glutGet in WavingFlagDemo.cxx.
I did the CVS checkout today. The CVS log for
plib/examples/ssg/tux/WavingFlagDemo.cxx shows that I have version
1.3, checked in 2000/10/02 18:24:39. The call to glutGet appears in
the idle() function.
All the best,
David
--
David Megginson da...@me...
http://www.megginson.com/
|
|
From: Wolfram K. <w_...@rz...> - 2001-01-04 22:44:37
|
Dave wrote: > #4 0x4042c981 in fxSetupBlend (ctx=3D0x80f5268) at fxsetup.c:1231 Ah!=20 So the line 1231 is in fxsetup.c, not in our complex.cxx. No wonder our complex.cxx has only 600 or so lines. > > I don't have any glutGet in WavingFlagDemo.cxx. Sorry about that, I see it now. (standard excuse: It is late) It compiles for me (MSVC under Windo$). Do other Linux people have the same problem? And the makefile problems? Dave, what compiler do you use and do you know what Glut you have? =46reeGlut or Mark Kilgards (sp?) Glut? >All the best, > > >David Good night :-), Wolfram. |
|
From: David M. <da...@me...> - 2001-01-05 11:06:31
|
Wolfram Kuss writes:
> Dave wrote:
>
> > #4 0x4042c981 in fxSetupBlend (ctx=0x80f5268) at fxsetup.c:1231
>
> Ah!
> So the line 1231 is in fxsetup.c, not in our complex.cxx.
> No wonder our complex.cxx has only 600 or so lines.
>
> > > I don't have any glutGet in WavingFlagDemo.cxx.
>
> Sorry about that, I see it now. (standard excuse: It is late)
> It compiles for me (MSVC under Windo$).
>
> Do other Linux people have the same problem?
> And the makefile problems?
The Makefile problems should occur on all Unix platforms -- since
several headers, including js.h, now use ul, -lplibul has to be added
to the examples Makefiles.
> Dave, what compiler do you use and do you know what Glut you have?
> FreeGlut or Mark Kilgards (sp?) Glut?
Compiler: gcc version 2.95.2 19991024 (release)
GLUT: libglut.so.3.7.0, bundled with tdfx_dri-4.0.00-3 (Voodoo3 DRI
driver for Linux). I think it's the version usually distributed
with Mesa, whichever that is.
All the best,
David
--
David Megginson da...@me...
http://www.megginson.com/
|
|
From: Joel U. <joe...@ya...> - 2001-01-05 08:52:35
|
David Megginson wrote: > > Wolfram Kuss writes: > > > Fay John F Contr AAC/WMG <joh...@eg...> wrote: > > > > >I'm going to have to plead ignorance on this one. The character string > > >"blendEnabled" does not occur anywhere in PUI--or in my (probably old) copy > > >of PLIB. I couldn't find it in GLUT either. Also, my copy of "complex.cxx" > > >only has 586 lines. > > > > So has mine. I think David has a new plib sources, but old examples. > > I'm using the examples that are bundled in the main plib CVS > distribution. My guess is that the message must be coming from my > Voodoo3 driver, if it's not coming from PLIB. I did a I was getting the same error with my Voodoo 3 in the viewer program ; I'll try to help track it down later. Must go now. Bye - Joel. |
|
From: Joel U. <joe...@ya...> - 2001-01-05 15:32:41
|
Joel Utting wrote: > > David Megginson wrote: > > > > Wolfram Kuss writes: > > > > > Fay John F Contr AAC/WMG <joh...@eg...> wrote: > > > > > > >I'm going to have to plead ignorance on this one. The character string > > > >"blendEnabled" does not occur anywhere in PUI--or in my (probably old) copy > > > >of PLIB. I couldn't find it in GLUT either. Also, my copy of "complex.cxx" > > > >only has 586 lines. > > > > > > So has mine. I think David has a new plib sources, but old examples. > > > > I'm using the examples that are bundled in the main plib CVS > > distribution. My guess is that the message must be coming from my > > Voodoo3 driver, if it's not coming from PLIB. I did a > > I was getting the same error with my Voodoo 3 in the viewer program ; > I'll try to help track it down later. Must go now. Yes, I am still getting this error now - but I wasn't getting it before my voodoo3 was setup properly ; so it is probably a driver problem or a problem with the DRI thing. Maybe an updated X4 will help, or new drivers. Which X are you running ? If we can figure out what is causing the error, maybe we can work around it ? Bye - Joel. |
|
From: <ma...@va...> - 2001-01-05 16:16:06
|
On Fri, 5 Jan 2001, Joel Utting wrote: > > Joel Utting wrote: > > > > David Megginson wrote: > > > > > > I'm using the examples that are bundled in the main plib CVS > > > distribution. My guess is that the message must be coming from my > > > Voodoo3 driver, if it's not coming from PLIB. I did a > > > > I was getting the same error with my Voodoo 3 in the viewer program ; > > I'll try to help track it down later. Must go now. > > If we can figure out what is causing the error, maybe we can work around > it ? A temporary fix that worked for Banshee with tdfx_dri-4.0.1-1 is to simply comment out the calls to glPushAttrib/glPopAttrib at lines 159 and 169 in puFont.cxx. That may produce incorrect results of course, but you could then use glGet to save and restore the OpenGL state manually, even if that is less efficient. Regards, Marten |
|
From: Steve B. <sjb...@ai...> - 2001-01-05 17:48:49
|
Mårten Strömberg wrote:
>
> On Fri, 5 Jan 2001, Joel Utting wrote:
> >
> > Joel Utting wrote:
> > >
> > > David Megginson wrote:
> > > >
> > > > I'm using the examples that are bundled in the main plib CVS
> > > > distribution. My guess is that the message must be coming from my
> > > > Voodoo3 driver, if it's not coming from PLIB. I did a
> > >
> > > I was getting the same error with my Voodoo 3 in the viewer program ;
> > > I'll try to help track it down later. Must go now.
> >
> > If we can figure out what is causing the error, maybe we can work around
> > it ?
>
> A temporary fix that worked for Banshee with tdfx_dri-4.0.1-1 is to simply
> comment out the calls to glPushAttrib/glPopAttrib at lines 159 and 169 in
> puFont.cxx. That may produce incorrect results of course, but you could
> then use glGet to save and restore the OpenGL state manually, even if that
> is less efficient.
That pushattrib saves GL_COLOR_BUFFER_BIT. In fact, only the blendfunc
and alphafunc parameters and the GL_ALPHA_TEST and GL_BLEND enables are
relevent here.
Perhaps it would be better to try pushing GL_ALL_ATTRIB_BITS in the hope
of finding a better-tested pathway through Mesa. At any rate, you should
check this out with the latest and greatest Mesa revision - and if it's
still screwy - report it to the Mesa list.
--
Steve Baker HomeEmail: <sjb...@ai...>
WorkEmail: <sj...@li...>
HomePage : http://web2.airmail.net/sjbaker1
Projects : http://plib.sourceforge.net
http://tuxaqfh.sourceforge.net
http://tuxkart.sourceforge.net
http://prettypoly.sourceforge.net
|
|
From: Fay J. F C. AAC/W. <joh...@eg...> - 2001-01-04 23:03:16
|
I've taken a good look at the stack trace (below) and traced the flow of
control from the main program (the SSG "viewer" program), through PUI (it's
drawing a file picker widget and chokes on writing the name of the file
"door.ase"), and into "puFont". It's in the "puFont :: drawString" method
(line 11 of the stack trace) and has just called "glPushAttrib". It looks
like it may be a Mesa problem; have you also spoken to them? Also, if there
are any Mesa gurus on this mailing list I'm willing to work with them to try
and track this down. I can get you through lines 11-19 of the stack trace;
below 11 I don't have any source code.
John F. Fay
joh...@eg...
-----Original Message-----
From: David Megginson [mailto:da...@me...]
Sent: Thursday, January 04, 2001 16:03
To: Wolfram Kuss
Cc: pli...@li...
Subject: Re: [Plib-devel] [Fwd: More plib bugs]
<snip>
Actually, a stack trace shows the error coming from fxSetupBlend (I'm
not sure where that lives):
(gdb) where
#0 0x40240d41 in __kill () from /lib/libc.so.6
#1 0x402409b6 in raise (sig=6) at ../sysdeps/posix/raise.c:27
#2 0x402420d8 in abort () at ../sysdeps/generic/abort.c:88
#3 0x4023abae in __assert_fail () at assert.c:59
#4 0x4042c981 in fxSetupBlend (ctx=0x80f5268) at fxsetup.c:1231
#5 0x40430cde in fxSetupFXUnits (ctx=0x80f5268) at fxsetup.c:1864
#6 0x403c6abc in fxDDUpdateDDPointers (ctx=0x80f5268) at fxdd.c:1360
#7 0x40507303 in gl_update_state (ctx=0x80f5268) at state.c:1109
#8 0x4054abda in gl_maybe_transform_vb (IM=0x810ae88) at vbxform.c:64
#9 0x4054ac6f in gl_flush_vb (ctx=0x80f5268,
where=0x4055abe0 "glPushAttrib") at vbxform.c:92
#10 0x40471506 in _mesa_PushAttrib (mask=16384) at attrib.c:103
#11 0x809307f in puFont::drawString (this=0xbffff518,
str=0x812a7a0 "door.ase", x=175, y=310) at puFont.cxx:159
#12 0x8092156 in puListBox::draw (this=0x81263e8, dx=160, dy=105)
at pu.h:384
#13 0x808deed in puGroup::draw (this=0x812c170, dx=0, dy=0)
at puGroup.cxx:244
#14 0x808deed in puGroup::draw (this=0x811fa48, dx=0, dy=0)
at puGroup.cxx:244
#15 0x808d147 in puDisplay () at pu.cxx:309
#16 0x804b49a in display () at viewer.cxx:330
#17 0x4002d3a9 in processWindowWorkList ()
from /usr/X11R6/lib/libglut.so.3
#18 0x4002d46c in glutMainLoop () from /usr/X11R6/lib/libglut.so.3
#19 0x804c2d4 in main (argc=1, argv=0xbffff7fc) at viewer.cxx:664
(gdb)
<snip>
All the best,
David
--
David Megginson da...@me...
http://www.megginson.com/
_______________________________________________
plib-devel mailing list
pli...@li...
http://lists.sourceforge.net/mailman/listinfo/plib-devel
|
|
From: Steve B. <sjb...@ai...> - 2001-01-05 04:40:37
|
> Fay John F Contr AAC/WMG wrote:
>
> I've taken a good look at the stack trace (below) and traced the flow of control from the main program (the SSG "viewer" program), through PUI (it's drawing a file picker widget and chokes on writing the name of the file "door.ase"), and into "puFont". It's in the "puFont :: drawString" method (line 11 of the stack trace) and has just called "glPushAttrib". It looks like it may be a Mesa problem; have you also spoken to them? Also, if there are any Mesa gurus on this mailing list I'm willing to work with them to try and track this down. I can get you through lines 11-19 of the stack trace; below 11 I don't have any source code.
THere have been persistant problems with Mesa's attrib stack - but AFAIK, the latest stable Mesa
has them all nailed down. What revision are you using?
--
Steve Baker HomeEmail: <sjb...@ai...>
WorkEmail: <sj...@li...>
HomePage : http://web2.airmail.net/sjbaker1
Projects : http://plib.sourceforge.net
http://tuxaqfh.sourceforge.net
http://tuxkart.sourceforge.net
http://prettypoly.sourceforge.net
|
|
From: Norman V. <nh...@ca...> - 2001-01-05 13:02:46
|
David Megginson writes: > > > Dave, what compiler do you use and do you know what Glut you have? > > FreeGlut or Mark Kilgards (sp?) Glut? > >Compiler: gcc version 2.95.2 19991024 (release) > >GLUT: libglut.so.3.7.0, bundled with tdfx_dri-4.0.00-3 (Voodoo3 DRI > driver for Linux). I think it's the version usually distributed > with Mesa, whichever that is. This is peculiar in that a perusal of the mesa sources yields /// FROM gl.h /// /* * Mesa 3-D graphics library * Version: 3.3 /// FROM glut.h /// #ifndef GLUT_API_VERSION /* allow this to be overriden */ #define GLUT_API_VERSION 3 #endif .......... #if (GLUT_API_VERSION >= 2) #define GLUT_ELAPSED_TIME 700 #endif ???? < disclaimer > I do not use Mesa except as a source reference < / > However after having said all of this We should probably be using a ulClock here Cheers Norman |
|
From: Fay J. F C. AAC/W. <joh...@eg...> - 2002-01-17 21:08:55
|
Sorry, Steve, you got caught in the "Terminally unable to use CVS from behind my firewall" problem. Those were my changes but Sebastian put them in for me. Sebastian put my name on them so that if somebody has a question about them he knows to ask me and not Sebastian. I apologize for the confusion. John F. Fay joh...@eg... "Et verbum caro factum est, et habitavit in nobis; et vidimus gloriam eius." -----Original Message----- From: Steve Baker [mailto:sjb...@ai...] Sent: Thursday, January 17, 2002 2:15 PM To: ud...@ha... Cc: pli...@li... Subject: Re: [Plib-devel] [Fwd: 9 Plib-cvs admin request(s) waiting] Sebastian Ude wrote: > > 1) It seems that (contrary to previous assertions) the emails from > > the CVS system *don't* appear to come from the person who committed > > the change. > > No ! It was me who commited the changes, so the mails came from my > Sourceforge e-mail adress: > > ud...@us... OK - now I'm confused. The comments in the CVS report say that the changes were committed by John Fay?!? <snip> |
|
From: Fay J. F C. AAC/W. <joh...@eg...> - 2003-07-17 18:04:54
|
Umm ... who are these guys, and why should we care about them? John F. Fay joh...@eg... -----Original Message----- From: Steve Baker [mailto:sjb...@ai...] Sent: Tuesday, July 15, 2003 7:08 PM To: pli...@li... Subject: [Plib-devel] [Fwd: Plib Website - HTML Code is NOT W3C conform] Dunno when the "w3c HTML OK" button appeared on the bottom of the PUI documents - but we're getting (justified) complaints: -------- Original Message -------- Subject: Plib Website - HTML Code is NOT W3C conform Date: Tue, 15 Jul 2003 20:39:42 +0200 From: kre...@gm... <kre...@gm...> Reply-To: kre...@gm... To: sjb...@ai... Hello, i checked your website (the Page about PUI) http://plib.sourceforge.net/pui/index.html with the w3c Validator because that page had a w3c banner on it. The results where, that the page is not w3c valid. So please correct it. Best Regards, Oliver C. -- ---------------------------- Steve Baker ------------------------- HomeEmail: <sjb...@ai...> WorkEmail: <sj...@li...> HomePage : http://www.sjbaker.org Projects : http://plib.sf.net http://tuxaqfh.sf.net http://tuxkart.sf.net http://prettypoly.sf.net -----BEGIN GEEK CODE BLOCK----- GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M- V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++ -----END GEEK CODE BLOCK----- ------------------------------------------------------- This SF.net email is sponsored by: VM Ware With VMware you can run multiple operating systems on a single machine. WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the same time. Free trial click here: http://www.vmware.com/wl/offer/345/0 _______________________________________________ plib-devel mailing list pli...@li... https://lists.sourceforge.net/lists/listinfo/plib-devel |
|
From: Steve B. <sjb...@ai...> - 2003-07-18 02:41:45
|
Fay John F Contr AAC/WMG wrote: > Umm ... who are these guys, and why should we care about them? I don't know who they are - and I don't care about them. What I do care about is that our PUI page has a button at the bottom that claims compliance with some standard that the checker says we most certainly DON'T comply with. We shouldn't lie. So, we either need to remove the button or fix the compatibility issues. ---------------------------- Steve Baker ------------------------- HomeEmail: <sjb...@ai...> WorkEmail: <sj...@li...> HomePage : http://www.sjbaker.org Projects : http://plib.sf.net http://tuxaqfh.sf.net http://tuxkart.sf.net http://prettypoly.sf.net -----BEGIN GEEK CODE BLOCK----- GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M- V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++ -----END GEEK CODE BLOCK----- |
|
From: Julian F. <jul...@bt...> - 2003-07-18 17:54:01
|
Steve Baker wrote: > > So, we either need to remove the button or fix the compatibility > issues. Only the first line is bad, because it is all lower-case: <!doctype html public "-//w3c//dtd html 4.0 transitional//en"> It validates OK if I tell the validator to assume "HTML 4.01 Transitional", or if I change the first line to: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> Perhaps you could check and commit this, as I don't have write access. I hope you did or will thank the guy for reporting the problem. - Julian |
|
From: Julian F. <jul...@bt...> - 2003-08-03 21:28:08
|
Julian Foad wrote: > Steve Baker wrote: > >> So, we either need to remove the button or fix the compatibility >> issues. > > Only the first line is bad, because it is all lower-case: > <!doctype html public "-//w3c//dtd html 4.0 transitional//en"> > > It validates OK if I tell the validator to assume "HTML 4.01 > Transitional", or if I change the first line to: > <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> > > Perhaps you could check and commit this, as I don't have write access. Will somebody with commit privileges fix this? - Julian |
|
From: Julian F. <jul...@bt...> - 2003-08-10 23:53:24
|
Julian Foad wrote: > Julian Foad wrote: > >> Steve Baker wrote: >> >>> So, we either need to remove the button or fix the compatibility >>> issues. >> >> Only the first line is bad, because it is all lower-case: ... > Will somebody with commit privileges fix this? I don't know whether I made a mistake in my analysis (above) or whether the page content has changed since then, introducing new errors. The page still does not validate but the "Valid HTML" button has been removed. This is a sufficient fix as far as I am interested in pursuing it. Thank you, whoever did that. And thank you, Oliver, for noticing and caring. - Julian |
|
From: Jones J. C C. AAC/W. <jam...@eg...> - 2003-07-17 18:16:20
|
The w3c is the standards body that is responsible for HTML, XHTML, XML, CSS,
XSLT, and things of that nature. Being w3c compliant means your web site
should be identical on all systems that attempt to view the page. Most web
browsers allow a certain amount of fudging of HTML code, but the fudging
produces different results on different browsers, so it's a good idea to
keep to standards.
This just means it's time to go and fix odd <FONT> calls or whatever's the
trouble. No big deal!
I'd do it, but my free time is sapped.
- James 'J.C.' Jones
Software Engineer
Jacobs Sverdrup/TEAS
Office: 850-729-6141
-----Original Message-----
From: Fay John F Contr AAC/WMG [mailto:joh...@eg...]
Sent: Thursday, July 17, 2003 1:05 PM
To: pli...@li...
Subject: RE: [Plib-devel] [Fwd: Plib Website - HTML Code is NOT W3C confor
m]
Umm ... who are these guys, and why should we care about them?
John F. Fay
joh...@eg...
-----Original Message-----
From: Steve Baker [mailto:sjb...@ai...]
Sent: Tuesday, July 15, 2003 7:08 PM
To: pli...@li...
Subject: [Plib-devel] [Fwd: Plib Website - HTML Code is NOT W3C conform]
Dunno when the "w3c HTML OK" button appeared on the
bottom of the PUI documents - but we're getting
(justified) complaints:
-------- Original Message --------
Subject: Plib Website - HTML Code is NOT W3C conform
Date: Tue, 15 Jul 2003 20:39:42 +0200
From: kre...@gm... <kre...@gm...>
Reply-To: kre...@gm...
To: sjb...@ai...
Hello,
i checked your website (the Page about PUI)
http://plib.sourceforge.net/pui/index.html
with the w3c Validator because that page had a w3c banner on it.
The results where, that the page is not w3c valid.
So please correct it.
Best Regards,
Oliver C.
--
---------------------------- Steve Baker -------------------------
HomeEmail: <sjb...@ai...> WorkEmail: <sj...@li...>
HomePage : http://www.sjbaker.org
Projects : http://plib.sf.net http://tuxaqfh.sf.net
http://tuxkart.sf.net http://prettypoly.sf.net
-----BEGIN GEEK CODE BLOCK-----
GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M-
V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++
-----END GEEK CODE BLOCK-----
-------------------------------------------------------
This SF.net email is sponsored by: VM Ware
With VMware you can run multiple operating systems on a single machine.
WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the
same time. Free trial click here: http://www.vmware.com/wl/offer/345/0
_______________________________________________
plib-devel mailing list
pli...@li...
https://lists.sourceforge.net/lists/listinfo/plib-devel
|
|
From: Fay J. F C. AAC/W. <joh...@eg...> - 2003-12-17 18:36:29
|
Yup! Good catch.
John F. Fay
joh...@eg...
-----Original Message-----
From: Steve Baker [mailto:sjb...@ai...]
Sent: Tuesday, December 16, 2003 5:50 PM
To: pli...@li...
Subject: [Plib-devel] [Fwd: PLib 1.7.0 (SG) bug?]
-------- Original Message --------
Subject: PLib 1.7.0 (SG) bug?
Date: Tue, 16 Dec 2003 16:50:35 +1000
From: Damian Trebilco <dtr...@au...>
To: sjb...@ai...
Just browsing the plib source when I came accross the point-> line distance
method in which I think there may be a mistake.
(plib 1.7.0)
(Assuming your are doing what I think you are doing - I am not familar with
the entire source tree)
Current code:
======================================================================
SGfloat sgDistSquaredToLineVec3 ( const sgLine3 line, const sgVec3 pnt )
{
sgVec3 r ; sgSubVec3 ( r, pnt, line.point_on_line ) ;
return sgScalarProductVec3 ( r, r ) -
sgScalarProductVec3 ( r, line.direction_vector ) ;
}
Suggested fix?:
======================================================================
SGfloat sgDistSquaredToLineVec3 ( const sgLine3 line, const sgVec3 pnt )
{
sgVec3 r ;
//Get the point relative to the point on line
sgSubVec3 ( r, pnt, line.point_on_line ) ;
//Get the relative point projected on to the direction vector (assumed to
be normalized)
float projectedDistance = sgScalarProductVec3 ( r, line.direction_vector
);
//Use C^2 - B^2 = A^2 in Pythagoras
return sgScalarProductVec3 ( r, r ) - (projectedDistance
*projectedDistance );
}
Auran disclaims responsibility for the contents of this e-mail unless it was
expressly authorised by Auran. This e-mail is a confidential communication.
To the extent permitted by law, Auran does not accept any liability for any
loss or damage suffered or incurred by you as a result of receiving, opening
or relying on this e-mail.
--
---------------------------- Steve Baker -------------------------
HomeEmail: <sjb...@ai...> WorkEmail: <sj...@li...>
HomePage : http://www.sjbaker.org
Projects : http://plib.sf.net http://tuxaqfh.sf.net
http://tuxkart.sf.net http://prettypoly.sf.net
-----BEGIN GEEK CODE BLOCK-----
GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M-
V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++
-----END GEEK CODE BLOCK-----
-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills. Sign up for IBM's
Free Linux Tutorials. Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
_______________________________________________
plib-devel mailing list
pli...@li...
https://lists.sourceforge.net/lists/listinfo/plib-devel
|
|
From: Fay J. F C. AAC/W. <joh...@eg...> - 2004-05-28 14:56:13
|
Tell him that if he can supply the code, we can put it into "jsWindows.cxx". I personally don't have any DirectX expertise, though. And in the meantime, let's get the revised JS code into CVS! How long has it been? Two months? Three? Four? John F. Fay joh...@eg... -----Original Message----- From: pli...@li... [mailto:pli...@li...]On Behalf Of Steve Baker Sent: Thursday, May 27, 2004 11:03 PM To: pli...@li... Subject: [Plib-devel] [Fwd: PLIB joystick support] I had this request from a guy where I work about support for Joysticks under Windows in PLIB. From: Brian Bolstad <bsb...@li...> > Steve, > > To date, we've been using the PLIB JS library for cross-platform > joystick support in SimuStealth. Recently, while trying to use a > Thrustmaster HOTAS Cougar joystick, I've run up against the Windows > Multimedia limitations due to the number of axes this joystick supports > (more than 8). I believe that DirectX support is required to take full > advantage of the capabilities of this joystick. Is there any chance > that DirectX joystick support is in progress for PLIB? What should I tell him? Can we support >8 axes under Windows? ---------------------------- Steve Baker ------------------------- HomeEmail: <sjb...@ai...> WorkEmail: <sj...@li...> HomePage : http://www.sjbaker.org Projects : http://plib.sf.net http://tuxaqfh.sf.net http://tuxkart.sf.net http://prettypoly.sf.net -----BEGIN GEEK CODE BLOCK----- GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M- V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++ -----END GEEK CODE BLOCK----- ------------------------------------------------------- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click _______________________________________________ plib-devel mailing list pli...@li... https://lists.sourceforge.net/lists/listinfo/plib-devel |
|
From: Steve B. <sjb...@ai...> - 2004-07-13 13:30:56
|
Erik Hofman wrote:
> Now that the latest changes have ended up in a stable release of plib I
> was wondering what the developers would think about working towards a
> 2.0 release.
Yes - I think that time is fast-approaching.
> Steve has already mentioned he wanted vertex-, and pixel shader support,
> others have mentioned multi-texturing, cube-mapping and impostors. Also
> some developers have worked towards implementing VBO's into plib.
The world of interactive 3D graphics has taken a sudden jump forward in
the last couple of years with all of this shader stuff. Shaders really
change *everything*. Thinks like multitexture are handled MUCH more
cleanly, and the whole business of state management changes beyond all
recognition.
However, the standards for Shaders just havn't been there. Initially,
we had a bunch of different and incompatible machine-code languages, then
we had nVidia's Cg (which is only semi-portable), and then we had a bunch
of GLslang vapourware. However, now we have GLSL...the fully approved
OpenGL Shader Language...accepted by all three major hardware vendors.
GLSL is *finally* going to become an official OpenGL standard and part of
the core API in the next month or so.
This (IMHO) offers us the opportunity to make the changes that PLIB needs
in a clear, concise and future proofed manner. For OpenGL 2.0, we need
PLIB 2.0.
Rewriting (at least) SSG to make use of shaders is a BIG move and I didn't
want to take that step until the standards and drivers were there to make
that change a lasting one.
As of today, there are Linux drivers containing GLSL for nVidia, ATI and
3DLabs. Only hardware from those three companies that's less than about
a year old is capable of supporting them though.
Hence, this new PLIB 2.0 won't run on a large fraction of the hardware
that's out there. However, if it's going to take a while to get it
done, we may expect a much larger proportion of people to have the
hardware in place by the time we get to the end of the work.
Clearly, adding shaders will break most applications - and dropping
support for so many graphics cards will break still more. However,
that is the way of the future.
A major version number change means that backwards compatibility is not
guaranteed. We can't make such changes very often - but I think the time
is coming to do that. However, if you are going to upset applications people,
by making a seriously incompatible change, you should do it all at once rather
than piecemeal.
Hence, in addition to SSG shader support, there are other drastic changes
that PLIB needs:
1) Rewrite SL.
Sound should be handled through OpenAL. SL should become
a music player and file loader on top of OpenAL. Audio should be
'known' to SSG so that sound sources can automatically be a part of
the 3D world. We can consider having an 'SL legacy' API that mimics
SL using OpenAL. I'd like to see an MP3 player (or probably an Ogg
player) inside the new SL.
2) PUI is converging on SSG.
Both API's are tree structured data with branches and leaves. Leaf nodes
cause rendering to happen and branch nodes control behavior with state
nodes doing stuff like colour and texture. Collision detection and
figuring out which button was clicked are also very similar activities.
PUI is in dire need of state management to allow it to use texture
and such like more cleanly. Merging those two systems into a single
API brings in very interesting possibilities for both API's and saves
us a bunch of maintenance (because both could share the same state
management and cull routines - you could even do things like building
your GUI pages in a 3D modeller).
3) Scripting SSG.
The behavior of nodes in SSG is hard-coded. These days, I think that
behavior could be scripted. All of the various types of transform
and selector nodes could be reduced to a single node type with very basic
scripting present to control them. In the end, each node has a transform
and a set of child nodes that may or may not wish to be rendered.
4) Simplifying Leaf Nodes:
We should reduce the variety of ssgLeaf nodes to a single type - that type
should allow arbitary per-vertex data.
5) ssgState nodes should be heavily shader-oriented.
6) Config.
We need some kind of configuration file management library...this should be
capable of providing uniform variables to SSG's shaders. An interactive
'control panel' tool to change these variables on-the-fly while a game is
running would be useful to shader developers.
Of course all of this needs considerable discussion - but this is the
vision I have.
> Fortunately one of the developers of FlightGear has improved plib's ssg
> library in many ways allowing a number of the mentioned requirements
> already, taking into account many of the other options.
No - that was a bad idea.
Rushing off and making a bunch of sweeping changes without significant
discussion of it on the developer list is a bad idea and likely to get
your work rejected for inclusion into the package.
The changes he did are not concordant with the future of OpenGL graphics
and actually make it harder to transition into the bright new future of
shaders and such.
I don't think I want those changes in PLIB.
---------------------------- Steve Baker -------------------------
HomeEmail: <sjb...@ai...> WorkEmail: <sj...@li...>
HomePage : http://www.sjbaker.org
Projects : http://plib.sf.net http://tuxaqfh.sf.net
http://tuxkart.sf.net http://prettypoly.sf.net
-----BEGIN GEEK CODE BLOCK-----
GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M-
V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++
-----END GEEK CODE BLOCK-----
|
|
From: Paolo L. <p.l...@ci...> - 2004-07-13 15:30:37
|
Is this a call-for-thoughts around Plib 2.0? Can anyone contribute with ideas? > -----Messaggio originale----- > Da: pli...@li...=20 > [mailto:pli...@li...] Per conto di=20 > Steve Baker > Inviato: marted=EC 13 luglio 2004 14.34 > A: Erik Hofman; pli...@li... > Oggetto: [Plib-devel] Re: [Fwd: Plib 2.0] >=20 >=20 > Erik Hofman wrote: >=20 > > Now that the latest changes have ended up in a stable=20 > release of plib=20 > > I was wondering what the developers would think about=20 > working towards=20 > > a 2.0 release. >=20 > Yes - I think that time is fast-approaching. >=20 > > Steve has already mentioned he wanted vertex-, and pixel shader=20 > > support, others have mentioned multi-texturing, cube-mapping and=20 > > impostors. Also some developers have worked towards=20 > implementing VBO's=20 > > into plib. >=20 > The world of interactive 3D graphics has taken a sudden jump=20 > forward in > the last couple of years with all of this shader stuff. =20 > Shaders really > change *everything*. Thinks like multitexture are handled MUCH more > cleanly, and the whole business of state management changes=20 > beyond all recognition. >=20 > However, the standards for Shaders just havn't been there. =20 > Initially, we had a bunch of different and incompatible=20 > machine-code languages, then we had nVidia's Cg (which is=20 > only semi-portable), and then we had a bunch of GLslang=20 > vapourware. However, now we have GLSL...the fully approved=20 > OpenGL Shader Language...accepted by all three major hardware vendors. >=20 > GLSL is *finally* going to become an official OpenGL standard=20 > and part of the core API in the next month or so. >=20 > This (IMHO) offers us the opportunity to make the changes=20 > that PLIB needs > in a clear, concise and future proofed manner. For OpenGL=20 > 2.0, we need > PLIB 2.0. >=20 > Rewriting (at least) SSG to make use of shaders is a BIG move=20 > and I didn't want to take that step until the standards and=20 > drivers were there to make that change a lasting one. >=20 > As of today, there are Linux drivers containing GLSL for=20 > nVidia, ATI and 3DLabs. Only hardware from those three=20 > companies that's less than about a year old is capable of=20 > supporting them though. >=20 > Hence, this new PLIB 2.0 won't run on a large fraction of the=20 > hardware that's out there. However, if it's going to take a=20 > while to get it done, we may expect a much larger proportion=20 > of people to have the hardware in place by the time we get to=20 > the end of the work. >=20 > Clearly, adding shaders will break most applications - and=20 > dropping support for so many graphics cards will break still=20 > more. However, that is the way of the future. >=20 > A major version number change means that backwards=20 > compatibility is not guaranteed. We can't make such changes=20 > very often - but I think the time > is coming to do that. However, if you are going to upset=20 > applications people, > by making a seriously incompatible change, you should do it=20 > all at once rather than piecemeal. >=20 > Hence, in addition to SSG shader support, there are other=20 > drastic changes that PLIB needs: >=20 > 1) Rewrite SL. >=20 > Sound should be handled through OpenAL. SL should become > a music player and file loader on top of OpenAL. Audio should be > 'known' to SSG so that sound sources can automatically be=20 > a part of > the 3D world. We can consider having an 'SL legacy' API=20 > that mimics > SL using OpenAL. I'd like to see an MP3 player (or=20 > probably an Ogg > player) inside the new SL. >=20 > 2) PUI is converging on SSG. >=20 > Both API's are tree structured data with branches and=20 > leaves. Leaf nodes > cause rendering to happen and branch nodes control=20 > behavior with state > nodes doing stuff like colour and texture. Collision=20 > detection and > figuring out which button was clicked are also very=20 > similar activities. >=20 > PUI is in dire need of state management to allow it to use texture > and such like more cleanly. Merging those two systems=20 > into a single > API brings in very interesting possibilities for both=20 > API's and saves > us a bunch of maintenance (because both could share the same state > management and cull routines - you could even do things=20 > like building > your GUI pages in a 3D modeller). >=20 > 3) Scripting SSG. >=20 > The behavior of nodes in SSG is hard-coded. These days,=20 > I think that > behavior could be scripted. All of the various types of transform > and selector nodes could be reduced to a single node type=20 > with very basic > scripting present to control them. In the end, each node=20 > has a transform > and a set of child nodes that may or may not wish to be rendered. >=20 > 4) Simplifying Leaf Nodes: >=20 > We should reduce the variety of ssgLeaf nodes to a single=20 > type - that type > should allow arbitary per-vertex data. >=20 > 5) ssgState nodes should be heavily shader-oriented. >=20 > 6) Config. >=20 > We need some kind of configuration file management=20 > library...this should be > capable of providing uniform variables to SSG's shaders. =20 > An interactive > 'control panel' tool to change these variables on-the-fly=20 > while a game is > running would be useful to shader developers. >=20 > Of course all of this needs considerable discussion - but=20 > this is the vision I have. >=20 > > Fortunately one of the developers of FlightGear has improved plib's=20 > > ssg library in many ways allowing a number of the mentioned=20 > > requirements already, taking into account many of the other options. >=20 > No - that was a bad idea. >=20 > Rushing off and making a bunch of sweeping changes without=20 > significant discussion of it on the developer list is a bad=20 > idea and likely to get your work rejected for inclusion into=20 > the package. >=20 > The changes he did are not concordant with the future of=20 > OpenGL graphics and actually make it harder to transition=20 > into the bright new future of shaders and such. >=20 > I don't think I want those changes in PLIB. >=20 > ---------------------------- Steve Baker ------------------------- > HomeEmail: <sjb...@ai...> WorkEmail: <sj...@li...> > HomePage : http://www.sjbaker.org > Projects : http://plib.sf.net http://tuxaqfh.sf.net > http://tuxkart.sf.net http://prettypoly.sf.net=20 > -----BEGIN GEEK CODE BLOCK----- GCS d-- s:+ a+ C++++$ UL+++$=20 > P--- L++++$ E--- W+++ N o+ K? w--- !O M- > V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++=20 > h--(-) r+++ y++++ -----END GEEK CODE BLOCK----- >=20 >=20 >=20 > ------------------------------------------------------- > This SF.Net email sponsored by Black Hat Briefings &=20 > Training. Attend Black Hat Briefings & Training, Las Vegas=20 > July 24-29 -=20 > digital self defense, top technical experts, no vendor pitches,=20 > unmatched networking opportunities. Visit www.blackhat.com=20 > _______________________________________________ > plib-devel mailing list > pli...@li...=20 > https://lists.sourceforge.net/lists/listinfo/p> lib-devel >=20 |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X