[EMAIL PROTECTED] wrote on 20-OCT-1999 03:11:18.11 :
>We are starting to try and integrate the latest CVS sources into our
>MGL graphics library, but are having a hell of a time getting the
>code to compile properly. Specifically we are building the code using
>the Watcom C++ 11.0 compiler, an
Hi,
Last night patches to GLU solved at first sight my problems when using it
with the text3d demo of xlockmore.
Jouk
Ceterum censeo tertium millennium post Christum natum anno MMI incepturum esse
>--<
Hi,
Keith wrote:
>There's been a couple of posts on the glx list re. GL_CALLOC_STRUCT, which
>apparently invokes calloc with only one argument, where it should have
>two
I commited a patch to the obvious typo this morning.
Jouk
Ceterum censeo tertium millennium post Christum natum
Hi,
>> The new tess_heap.c seems to solve the crashing of the text3d demo
>> of xlockmore. Now it gets into some infinite loop at startup.
>
>Yeah, that was one of those _really_ late night coding bugs :) Can you give
>me some more info on the infinite loop? I guess the easiest thing would be
Gareth wrote:
>> The new tess_heap.c seems to solve the crashing of the text3d demo
>> of xlockmore. Now it gets into some infinite loop at startup.
>
>Yeah, that was one of those _really_ late night coding bugs :) Can you give
>me some more info on the infinite loop? I guess the easiest thing
Hi,
>Nasty :) I'll track this down - I've had this problem before, so I =
>probably
>broke the fix when I removed my debugging memory allocation on the =
>weekend.
The new tess_heap.c seems to solve the crashing of the text3d demo of
xlockmore. Now it gets into some infinite loop at startup.
Hi All,
My VMS compiler choked on all the in the tess_winding.h. So I commited
a patch to remove them all.
However the new GLU seems not to work with the text3d demo (using libGLTT).
I get the following crash just after starting:
olka-jj) xlock -inwindow -nice 0 -modelist allgl
%SYSTEM-F-ACCVI
Hi all,
In the latest CVS in vbxform.c a procedure gl_flush is added. This gives a
conflict on those systems (like VMS) which have a case insensitive linker with
the procedure gl_Flush in misc.c. One of the two should get another name.
I do not know which one should be selected.
J
Hi all,
Testing the latest CVS-version with the latest version of xlockmore from
ftp://ftp.tux.org./pub/tux/bagleyd/xlockmore/
I experienced on my VMS system the folowing problems:
-pipes mode : none of the valves connections and meters are visible.
(Same problem was reported las
Hi Folks,
Keith's last patches did solve a lot of problems from which I was suffering
on my VMS system. Only one remains:
in the pipes mode of xlockmore (latest alpha) the pipes are drawn well except
that for all extention (connections /meters) the extention is omitted and the
pipes contain a ho
Brian wrote :
>[EMAIL PROTECTED] wrote:
>> I have some problem recreating the directory Mesa/vms. The CVS-repository
>> seems to create the directory in a strange location where I cannot put
>> anything in it
>> or remove it. I get the following:
>>
>> sm43-jj) cvsmesa add Mesa/vms
>
>I'm not su
Hi all,
I have some problem recreating the directory Mesa/vms. The CVS-repository seems to
create the directory in a strange location where I cannot put anything in it
or remove it. I get the following:
sm43-jj) cvsmesa add Mesa/vms
? Mesa/vms/analyze_map.com
? Mesa/vms/xlib.opt
? Mesa/vms/xl
Hi folks,
After a month of holidays and conferences I'm back. So I tried to login at
the CVS, but no success at all. I get :
sm43-jj) cvsmesa login
(Logging in to [EMAIL PROTECTED])
CVS password:
cvs [login aborted]: unrecognized auth response from cvs.mesa3d.org: E Fatal er.
sm43-jj)
Is some
Hi
While I was checking in some changes in the make file of VMS (sharable
image support for VMS/ALPHA) the CVS-server locked on me. It probably needs
another reset.
Jouk
Ceterum censeo tertium millennium post Christum natum anno MMI incepturum esse
>--
Hi all,
The latest changes to the CVS (since May 10) give a weird effect on the
sproingies mode of xlockmore (has this to with lightning?)
Maybe it is related to a problem that occurs rarely (so I do not have a good
reproducer for you) on my VMS machine.
I get an floating over flow in module SHA
[EMAIL PROTECTED] wrote:
>[EMAIL PROTECTED] wrote:
>>
>> I have still one problem on both my VMS and AIX systems : the rendering with
>> the gltt (and freetype) libraries. The programs seem not to crash but give
>> very ugly/wrong results. Probably this also has to do since the first object
>> dr
Hi all,
Brian wrote:
[snip]
>This beta release will only work on Unix, BeOS R4 and VMS (Jouk?).
>The Windows and other OS project/makefiles haven't been updated, yet.
The makefiles for VMS are up to date. I'm not realy sure if the current version
is "crash-proof". The VMS-version seems to be v
Hi,
I just commited this small patch(see below). For me it helped avoiding some
applications crashing.
I still have problems with programs using the GLTT library. IMHO there is
still some initialization problem, since the rendereing errors never occur
for the firtst character in the string
Since Eero does not have write access to the CVS, I did the commit of this
patch. It also solved some problems I was strugeling with this morning.
>I fixed the problem by changing the function call to be
>(pipeline.c:439):
>
> (ctx->NormalTransform[tmp])(&ctx->ModelView,
>
Hi Folks,
I committed the following
src/descrip.mms : Updates for the new source files
src/enums.c : Included to avoid warnings on strcmp.
renamed the variable index to index1 to avoid conflicts
with
src/FX/fxcva.c : Added the "#if defined(FX)"
Hi Folks,
I observed problems when the gltt library is used with the latest Mesa
(mesa3.0 and the one before kw3 was patched in seemed to be ok)
What do you need to test:
gltt-library:
http://home.worldnet.fr/~rehel/gltt/gltt.html
freetype library:
http://www.freetype.org/
In the g
Hi all,
[EMAIL PROTECTED] wrote:
>> [EMAIL PROTECTED] wrote:
>> >OK - found the problem, I think. Similar to the original problem where
>> >there are two sources of culling information, but for now for normals
>> >rather than post-clip vertices. I'm committing a fix as I type this.
>> This one
Hi,
[EMAIL PROTECTED] wrote:
>OK - found the problem, I think. Similar to the original problem where
>there are two sources of culling information, but for now for normals
>rather than post-clip vertices. I'm committing a fix as I type this.
This one seems to fix one of the two errors. The lame
HI,
[EMAIL PROTECTED] wrote:
>[EMAIL PROTECTED] wrote:
>> Keith wrote:
>> >I've just committed a more comprehensive fix which allows us to skip the
>> >offending vertices in the window transform and in FX/fxvsetup. It also
>> >clears up a longstanding wierdness introduced into clipping (the CLIP
[EMAIL PROTECTED] wrote:
>> This patch solves also most of the overflow/invalid float problems I had with
>> the GL-modes in xlockmore. Two are still remaining (in the stairs and lament
>> modes). Probably they result from simmilar "initialization" errors, which up
>> to now I could not locate. I
Hi,
I just committed the patch [EMAIL PROTECTED] made (but did not commit) to get
rid of the overflow problem in the gears demo.
>*** clip_tmp.h.old Mon Mar 8 15:40:00 1999
>--- clip_tmp.h Mon Mar 8 15:57:58 1999
>***
>*** 43,48
>--- 43,52
>tmpAndMask &= mask;
[EMAIL PROTECTED] wrote:
>Keith Whitwell <[EMAIL PROTECTED]> writes:
>
>> [EMAIL PROTECTED] wrote:
>>
>> > I did apply it but it did not solve the problem of the floating exception on
>> > my VMS system.
>>
>> Is the execption still apparent in the transform_points_3d_no_rot, or
>> has it moved
[EMAIL PROTECTED] wrote:
>[EMAIL PROTECTED] wrote:
>
>> I did apply it but it did not solve the problem of the floating exception on
>> my VMS system.
>
>Is the execption still apparent in the transform_points_3d_no_rot, or
>has it moved to other parts? Is 0x0 a valid float on VMS? I expect
>the
[EMAIL PROTECTED] asked:
>So, please try this patch:
>
>
>diff -c -r3.7 vb.c
>*** vb.c1999/02/25 14:12:32 3.7
>--- vb.c1999/03/07 13:29:33
>***
>*** 87,92
>--- 87,96
>gl_init_vector4f( &vb->Eye, 2, VEC_WRITABLE, 0 );
>gl_init_vector4f( &vb
[EMAIL PROTECTED] wrote:
>[EMAIL PROTECTED] writes:
>
>> To me the problem looks that (in xform_tmp.h notation) the from[*] array seems
>> to be overwriten/not realy initialized in some parts, which causes "random"
>> numbers to appear.
>
>The problem seems to be with the bounding box culling. Th
Hi,
>Compiling the new transformation code on IRIX caught a few problems.
>
>First, a subscript out of range:. I'm not sure how to fix it after
>just a quick look. Keith W?
>
>"shade_tmp.h", line 803: warning(1172): subscript out of range
> gl_shade_func_tab[IDX|SHADE_RGBA_SPEC] = TAG(shade
Hi
I still have problems with the kw3 patches on VMS. I suspect that they are
sometimes not noted on other systems since they are tolerant to floating
overflow problems.
When I run the GEARS demo and resize the window such that a part of the object
is below the lower border of the window. Gears c
Hi,
In the glu.h file of the CVS this excerpt gives compilation problems:
typedef struct GLUquadric GLUquadricObj;
typedef struct GLUtesselator GLUtriangulatorObj;
typedef struct GLUnurbs GLUnurbsObj;
Why was this changed from the version in beta1 which was:
typedef struct GLUquadr
Hi all,
I think Keith has to do some work before going to ski : His changes are able
to let the the Demos crash on my VMS system (the version I got the day before
yesterday did not have the problem. If I run i.e. gears. I can play a bit
with the window size. Then it crashes with the following dum
34 matches
Mail list logo
