Re: [Mesa3d-dev] vertex program & vertex arrays

[Brian Paul <brian@tu...>]

Karl Rasche wrote:
> When running some arb_vp tests, I ran into a hiccup where things would run
> just find when submitting with glVertex/Normal/etc, but when using
> DrawElements(), nothing would show up.
> 
> After a little debugging, it appears that the same vertex attribs were
> being used each time the program is run, and the attribute values are
> those from the first element in the array which was to be drawn.
> 
> It looks like the problem might be in _tnl_vb_bind_arrays()
> [t_array_import.c]. When we hit the vp case, we look through the vertex
> attrib arrays to grab elements. Thats find if our attributes that are
> coming from an array specified using EnableVertexAttribArrayARB(), but I
> think it ignores cases where the array is specified with regular vertex
> arrays.
> 
> I tried sticking in a few cases that tests which arrays are enabled, to
> handle the aliasing/priority between generic attribs and specific vertex
> attribs. If the attrib array isn't enabled, it falls back to grabbing the
> specific array. This seems to fix the problem, but this might interfere
> with the aliasing/no-aliasing from NV_vp...
> 
> As I'm not really familiar with the tnl guts, I figured I'd ping the list
> to see if this was on the right track...

I modified progs/test/vparray.c a bit and I think I'm seeing the same 
problem.  I'll take a look.

-Brian

Re: [Mesa3d-dev] GLU and client-server

[Brian Paul <brian@tu...>]

Evgeny Kotsuba wrote:
> Hi,
> 
> I am in process of developing (well, with tortoise's speed) some analog 
> of X client-server Mesa's implementation. I look at GLX client and 
> server sides as promt and find that GLU library is not used in the same 
> manner as all other stuff.
> Any ideas ?

The GLU library is implemented in terms of (i.e. layered on) the GL 
functions.

-Brian

[Mesa3d-dev] vertex program & vertex arrays

[Karl Rasche <rkarl@vr...>]

When running some arb_vp tests, I ran into a hiccup where things would run
just find when submitting with glVertex/Normal/etc, but when using
DrawElements(), nothing would show up.

After a little debugging, it appears that the same vertex attribs were
being used each time the program is run, and the attribute values are
those from the first element in the array which was to be drawn.

It looks like the problem might be in _tnl_vb_bind_arrays()
[t_array_import.c]. When we hit the vp case, we look through the vertex
attrib arrays to grab elements. Thats find if our attributes that are
coming from an array specified using EnableVertexAttribArrayARB(), but I
think it ignores cases where the array is specified with regular vertex
arrays.

I tried sticking in a few cases that tests which arrays are enabled, to
handle the aliasing/priority between generic attribs and specific vertex
attribs. If the attrib array isn't enabled, it falls back to grabbing the
specific array. This seems to fix the problem, but this might interfere
with the aliasing/no-aliasing from NV_vp...

As I'm not really familiar with the tnl guts, I figured I'd ping the list
to see if this was on the right track...

Thanks.

Karl

[Mesa3d-dev] GLU and client-server

[Evgeny Kotsuba <evgen__k@ra...>]

Hi,

I am in process of developing (well, with tortoise's speed) some 
analog of X client-server Mesa's implementation. I look at GLX client 
and server sides as promt and find that GLU library is not used in the 
same manner as all other stuff.
Any ideas ?

SY,
Evgeny Kotsuba

Re: [Mesa3d-dev] Strange rendering using swrast?

[Brian Paul <brian@tu...>]

Matt Sealey wrote:
> I'm trying to track something down we experienced trying to run
> Blender over a plain software Mesa - we got some weird black
> vertical stripes over the display at very regular and predictable
> intervals.
> 
> After a few weeks of trials, tests and tweaks, I found a strange
> occurance trying to find which part of Mesa was causing it. If
> you modify init() in the GLUT gears demo so that it has:
> 
> 	glEnable(GL_POLYGON_SMOOTH);
> 	glHint(GL_POLYGON_SMOOTH_HINT, GL_FASTEST);
> 
> (note, no blending, all it does is smudge the edges and run slow)
> 
> And then resize the window to be some 640x480 kind of size, there
> is a hard black line down the middle of the window, and to the
> right of that line, triangles "disappear" from the gears at
> certain points.
> 
> If you size the window to 300x200 it doesn't seem to make any
> difference. The gears are drawn normally. Incrementally sizing
> it by 50 or so pixels at a time in both directions shows that
> the "culling" only occurs after a certain horizontal distance
> in the window, and always at the SAME horizontal distance,
> regardless of window size (it seems to be about 400 pixels
> here) which is why smaller windows aren't affected.
> 
> Can anyone reproduce this under Linux or so (software Mesa only)
> and if so, can they explain it in terms of OpenGL standards (i.e.
> am I doing something wrong here that causes this? Enabling the
> polygon smooth functions shouldnt cause this kind of culling,
> surely?)
> 
> This has been driving me mental for a few weeks now :)

I modified gears as you indicated and tried all different window sizes 
and never saw anything funny.

I tested Mesa 5.0.2 and the CVS trunk on Linux.

Have you tried compiling Mesa with different levels of optimization 
(just a hunch)?

-Brian

Re: [Mesa3d-dev] Strange rendering using swrast?

[Eric Plante <eric.plante@di...>]

> This has been driving me mental for a few weeks now :)

I'm on something myself right now, I don't know if it's related... I 
have a soup of quad strips and triangle strips, and I'm getting some 
incorrect pixels ( black dots in the middle of white areas and vice 
versa). I'm in the process of reproducing it outside our big fat app, 
please keep the list posted if you find anything. I will do the same as 
soon as (if) I find something. Maybe it's related, maybe it isn't...


-- 
eric plante, software developer, discreet
"Before employing any captured artifacts or machinery, I will
carefully read the owner's manual."
-- The Top 100 Things I'd Do If I Ever Became An Evil Overlord

[Mesa3d-dev] Strange rendering using swrast?

[Matt Sealey <matt@ki...>]

I'm trying to track something down we experienced trying to run
Blender over a plain software Mesa - we got some weird black
vertical stripes over the display at very regular and predictable
intervals.

After a few weeks of trials, tests and tweaks, I found a strange
occurance trying to find which part of Mesa was causing it. If
you modify init() in the GLUT gears demo so that it has:

	glEnable(GL_POLYGON_SMOOTH);
	glHint(GL_POLYGON_SMOOTH_HINT, GL_FASTEST);

(note, no blending, all it does is smudge the edges and run slow)

And then resize the window to be some 640x480 kind of size, there
is a hard black line down the middle of the window, and to the
right of that line, triangles "disappear" from the gears at
certain points.

If you size the window to 300x200 it doesn't seem to make any
difference. The gears are drawn normally. Incrementally sizing
it by 50 or so pixels at a time in both directions shows that
the "culling" only occurs after a certain horizontal distance
in the window, and always at the SAME horizontal distance,
regardless of window size (it seems to be about 400 pixels
here) which is why smaller windows aren't affected.

Can anyone reproduce this under Linux or so (software Mesa only)
and if so, can they explain it in terms of OpenGL standards (i.e.
am I doing something wrong here that causes this? Enabling the
polygon smooth functions shouldnt cause this kind of culling,
surely?)

This has been driving me mental for a few weeks now :)

-- 
Matt Sealey <matt@...> 

Re: [Mesa3d-dev] Run-time roblem with current (trunk) CVS version

[<joukj@hr...>]

keith@... wrote on 28-NOV-2003 15:33:45.80

>> -SYSTEM-F-FLTINV, floating invalid operation, PC=00000000013484C8, PS=0000001B
>> %TRACE-F-TRACEBACK, symbolic stack dump follows
>>   image    module    routine             line      rel PC           abs PC
>>  libMesaGL  SS_TRIANGLE  triangle_twoside_rgba
>>                                         51965 0000000000002C88 00000000013484C
>Which line does this refer to?

Seems to be an empty line. Probably the optimized code does not show the
right line. I'll try monday with the optimizer off.

               Jouk


Bush : All votes are equal but some votes are more equal than others.

>------------------------------------------------------------------------------<

  Jouk Jansen
		 
  joukj@...

  Technische Universiteit Delft        tttttttttt  uu     uu  ddddddd
  Nationaal centrum voor HREM          tttttttttt  uu     uu  dd    dd
  Rotterdamseweg 137                       tt      uu     uu  dd     dd
  2628 AL Delft                            tt      uu     uu  dd     dd
  Nederland                                tt      uu     uu  dd    dd
  tel. 31-15-2782272                       tt       uuuuuuu   ddddddd

>------------------------------------------------------------------------------<

Re: [Mesa3d-dev] Run-time roblem with current (trunk) CVS version

[Keith Whitwell <keith@tu...>]

Jacob (=Jouk) Jansen wrote:
> keith@... wrote on 28-NOV-2003 10:55:59.80
> 
> 
>>Jacob =Jouk Jansen wrote:
>>
>>>Hi all,
>>>
>>>I tried the current CVS version of Mesa to run some of the demo's of the
>>>package xlockmore on my OpenVMS system. In some modes (i.e. cage,morph3d,
>>>stairs ) I get a crash (traceback is at the end of this mail). The line 51887
>>>of ss_triangle.c can also be 51889 and points to line 146-148 of ss_tritmp.h:
>>>
>>>146	    if (VB->SecondaryColorPtr[0]) {
>>>145	       GLfloat (*vbspec)[4] = VB->SecondaryColorPtr[0]->data;
>>>146	       SS_SPEC(v[0]->specular, vbspec[e0]);
>>>147	       SS_SPEC(v[1]->specular, vbspec[e1]);
>>>148	       SS_SPEC(v[2]->specular, vbspec[e2]);
>>>
>>>A "floating invalid" may indicate that VB->SecondaryColorPtr[0]->data is
>>>allocated but not initialized. It may contain rubish instead of zero's.
>>>Can that be the case? and if yes where should it be repaired?
>>
>>Jouk,
>>
>>Please try the most recent cvs commit & let me know if this fixes it.
> 
>  with some problems I got it (The anonymous CVS on my VMS box seems not to
> be able to get the new ss_tritmp.h, Even a CVS from scratch gives me the
> "old" one so I use a linux system and my own username)

Hmm.  This is probably the sourceforge 'backup CVS server' problem which we 
had such a bad time with on the DRI project.

> The new file is much better. Most xlockmore modes work now correctly, except
> the invert mode. It gives a"floating invalid" in triangle_twoside_rgba.

...

> polka-jj) xlock -inwindow -modelist invert -nice 0
> %SYSTEM-F-HPARITH, high performance arithmetic trap, Imask=00000000, Fmask=00400000, summary=02, PC=00000000013484C8, PS=0000001B
> -SYSTEM-F-FLTINV, floating invalid operation, PC=00000000013484C8, PS=0000001B
> %TRACE-F-TRACEBACK, symbolic stack dump follows
>   image    module    routine             line      rel PC           abs PC
>  libMesaGL  SS_TRIANGLE  triangle_twoside_rgba
>                                         51965 0000000000002C88 00000000013484C8

Which line does this refer to?

Keith

Re: [Mesa3d-dev] Run-time roblem with current (trunk) CVS version

[<joukj@hr...>]

keith@... wrote on 28-NOV-2003 10:55:59.80

>Jacob =Jouk Jansen wrote:
>> Hi all,
>> 
>> I tried the current CVS version of Mesa to run some of the demo's of the
>> package xlockmore on my OpenVMS system. In some modes (i.e. cage,morph3d,
>> stairs ) I get a crash (traceback is at the end of this mail). The line 51887
>> of ss_triangle.c can also be 51889 and points to line 146-148 of ss_tritmp.h:
>> 
>> 146	    if (VB->SecondaryColorPtr[0]) {
>> 145	       GLfloat (*vbspec)[4] = VB->SecondaryColorPtr[0]->data;
>> 146	       SS_SPEC(v[0]->specular, vbspec[e0]);
>> 147	       SS_SPEC(v[1]->specular, vbspec[e1]);
>> 148	       SS_SPEC(v[2]->specular, vbspec[e2]);
>> 
>> A "floating invalid" may indicate that VB->SecondaryColorPtr[0]->data is
>> allocated but not initialized. It may contain rubish instead of zero's.
>> Can that be the case? and if yes where should it be repaired?
>
>Jouk,
>
>Please try the most recent cvs commit & let me know if this fixes it.
 with some problems I got it (The anonymous CVS on my VMS box seems not to
be able to get the new ss_tritmp.h, Even a CVS from scratch gives me the
"old" one so I use a linux system and my own username)

The new file is much better. Most xlockmore modes work now correctly, except
the invert mode. It gives a"floating invalid" in triangle_twoside_rgba.

                       Jouk
		       


polka-jj) xlock -inwindow -modelist invert -nice 0
%SYSTEM-F-HPARITH, high performance arithmetic trap, Imask=00000000, Fmask=00400000, summary=02, PC=00000000013484C8, PS=0000001B
-SYSTEM-F-FLTINV, floating invalid operation, PC=00000000013484C8, PS=0000001B
%TRACE-F-TRACEBACK, symbolic stack dump follows
  image    module    routine             line      rel PC           abs PC
 libMesaGL  SS_TRIANGLE  triangle_twoside_rgba
                                        51965 0000000000002C88 00000000013484C8
 libMesaGL  SS_TRIANGLE  quadfunc_twoside_rgba
                                        52084 0000000000003F60 00000000013497A0
 libMesaGL  T_VB_RENDER  _tnl_render_quad_strip_verts
                                        51091 00000000000085AC 0000000001384B4C
 libMesaGL  T_VB_RENDER  run_render     51683 000000000000A44C 00000000013869EC
 libMesaGL  T_PIPELINE  _tnl_run_pipeline
                                        48922 0000000000000414 0000000001369724
 libMesaGL  T_SAVE_PLAYBACK  _tnl_playback_vertex_list
                                        49785 000000000000041C 000000000137304C
 libMesaGL  DLIST  execute_list         53757 0000000000011D74 00000000011C7224
 libMesaGL  DLIST  _mesa_CallList       54725 0000000000014BA4 00000000011CA054
 xlock  i_linkage  invert_draw          39133 00000000000004A4 000000000036E414
 xlock  INVERT  draw_invert             39373 000000000000076C 000000000036CC0C
 xlock  XLOCK  justDisplay              41476 0000000000003BA4 00000000001F3BA4

 xlock  XLOCK  main                     42529 0000000000006848 00000000001F6848
 xlock  XLOCK  __main                       0 000000000000006C 00000000001F006C
 xlock                                      0 00000000003B2E48 00000000003C2E48
 PTHREAD$RTL                                0 000000000003F0D0 000000007BCE10D0
 PTHREAD$RTL                                0 000000000001C31C 000000007BCBE31C
                                            0 FFFFFFFF8028359C FFFFFFFF8028359C


Bush : All votes are equal but some votes are more equal than others.

>------------------------------------------------------------------------------<

  Jouk Jansen
		 
  joukj@...

  Technische Universiteit Delft        tttttttttt  uu     uu  ddddddd
  Nationaal centrum voor HREM          tttttttttt  uu     uu  dd    dd
  Rotterdamseweg 137                       tt      uu     uu  dd     dd
  2628 AL Delft                            tt      uu     uu  dd     dd
  Nederland                                tt      uu     uu  dd    dd
  tel. 31-15-2782272                       tt       uuuuuuu   ddddddd

>------------------------------------------------------------------------------<

Re: [Mesa3d-dev] Re: gen_matypes maintained?

[Keith Whitwell <keith@tu...>]

Daniel Borca wrote:
> Keith Whitwell writes:
> 
>>
>> Hmm. Built it up (after converting from DOS).  All I get (with either 
>> new or old) software Mesa is a black box.  Does something happen later 
>> on?
> 
> 
> GLXS is intented as a stress test for videocards :)
> If you tried SW renderer, you'll have to be patient!
> Very patient! If you're not, try to use spacebar to
> skip to next scene! Also, I think 'a' speeds the demo
> up, while 'z' slows it down!

OK.  It'll be a little while before I can look at this then.

Keith

[Mesa3d-dev] Re: gen_matypes maintained?

[Daniel Borca <dborca@3d...>]

Keith Whitwell writes: 

> 
> Hmm. Built it up (after converting from DOS).  All I get (with either new 
> or old) software Mesa is a black box.  Does something happen later on? 
> 

GLXS is intented as a stress test for videocards :)
If you tried SW renderer, you'll have to be patient!
Very patient! If you're not, try to use spacebar to
skip to next scene! Also, I think 'a' speeds the demo
up, while 'z' slows it down! 

Regards,
Daniel Borca 

Re: [Mesa3d-dev] Re: gen_matypes maintained?

[Keith Whitwell <keith@tu...>]

Daniel Borca wrote:
> Keith Whitwell writes:
> 
>>> Quick hint: there is a GLUT-compilable sourcecode for GLEXcess at
>>> http://www.glexcess.com/
>>
>>
>> Where abouts?  I can only see the windows versions...
> 
> 
> Ok, I uploaded a cleaner version at
> http://www.geocities.com/dborca/mesa/glxmesa.tgz

Hmm. Built it up (after converting from DOS).  All I get (with either new or 
old) software Mesa is a black box.  Does something happen later on?

Keith

Re: [Mesa3d-dev] Run-time roblem with current (trunk) CVS version

[Keith Whitwell <keith@tu...>]

Jacob =Jouk Jansen wrote:
> Hi all,
> 
> I tried the current CVS version of Mesa to run some of the demo's of the
> package xlockmore on my OpenVMS system. In some modes (i.e. cage,morph3d,
> stairs ) I get a crash (traceback is at the end of this mail). The line 51887
> of ss_triangle.c can also be 51889 and points to line 146-148 of ss_tritmp.h:
> 
> 146	    if (VB->SecondaryColorPtr[0]) {
> 145	       GLfloat (*vbspec)[4] = VB->SecondaryColorPtr[0]->data;
> 146	       SS_SPEC(v[0]->specular, vbspec[e0]);
> 147	       SS_SPEC(v[1]->specular, vbspec[e1]);
> 148	       SS_SPEC(v[2]->specular, vbspec[e2]);
> 
> A "floating invalid" may indicate that VB->SecondaryColorPtr[0]->data is
> allocated but not initialized. It may contain rubish instead of zero's.
> Can that be the case? and if yes where should it be repaired?
> 
> 
>                 Jouk

Thanks, Jouk,

I'll look into this.

Keith

[Mesa3d-dev] Run-time roblem with current (trunk) CVS version

[<joukj@hr...>]

Hi all,

I tried the current CVS version of Mesa to run some of the demo's of the
package xlockmore on my OpenVMS system. In some modes (i.e. cage,morph3d,
stairs ) I get a crash (traceback is at the end of this mail). The line 51887
of ss_triangle.c can also be 51889 and points to line 146-148 of ss_tritmp.h:

146	    if (VB->SecondaryColorPtr[0]) {
145	       GLfloat (*vbspec)[4] = VB->SecondaryColorPtr[0]->data;
146	       SS_SPEC(v[0]->specular, vbspec[e0]);
147	       SS_SPEC(v[1]->specular, vbspec[e1]);
148	       SS_SPEC(v[2]->specular, vbspec[e2]);

A "floating invalid" may indicate that VB->SecondaryColorPtr[0]->data is
allocated but not initialized. It may contain rubish instead of zero's.
Can that be the case? and if yes where should it be repaired?


                Jouk


Trace back of the crash:

polka-jj) xlock -inwindow -modelist allgl -nice 0
%SYSTEM-F-HPARITH, high performance arithmetic trap, Imask=00000000, Fmask=02000
000, summary=02, PC=0000000001349F18, PS=0000001B
-SYSTEM-F-FLTINV, floating invalid operation, PC=0000000001349F18, PS=0000001B
%TRACE-F-TRACEBACK, symbolic stack dump follows
  image    module    routine             line      rel PC           abs PC
 libMesaGL  SS_TRIANGLE  triangle_twoside_rgba
                                        51887 00000000000046D8 0000000001349F18
 libMesaGL  SS_TRIANGLE  quadfunc_twoside_rgba
                                        51919 0000000000004DF0 000000000134A630
 libMesaGL  T_VB_RENDER  _tnl_render_quads_verts
                                        51051 00000000000083D8 0000000001387FD8
 libMesaGL  T_VB_RENDER  run_render     51683 000000000000A44C 000000000138A04C
 libMesaGL  T_PIPELINE  _tnl_run_pipeline
                                        48922 0000000000000414 000000000136CD84
 libMesaGL  T_VTX_EXEC  _tnl_flush_vtx  49093 0000000000000DBC 000000000139617C
 libMesaGL  T_VTX_API  _tnl_FlushVertices
                                        50538 0000000000007184 0000000001394564
 libMesaGL  MATRIX  _mesa_Translatef    45508 0000000000000F54 00000000012AD724
 xlock  STAIRS  draw_stairs_internal    41269 000000000000109C 000000000034485C
 xlock  STAIRS  draw_stairs             41456 0000000000000000 0000000000000000
 xlock  MODE  call_callback_hook        25835 0000000000000304 00000000001FAA24
 xlock  RANDOM  draw_random             25863 0000000000001688 000000000037E798
 xlock  XLOCK  justDisplay              41485 0000000000003C34 00000000001F3C34
 xlock  XLOCK  main                     42529 0000000000006848 00000000001F6848
 xlock  XLOCK  __main                       0 000000000000006C 00000000001F006C
 xlock                                      0 00000000003B2E48 00000000003C2E48
 PTHREAD$RTL                                0 000000000003F0D0 000000007BCE10D0
 PTHREAD$RTL                                0 000000000001C31C 000000007BCBE31C
                                            0 FFFFFFFF8028359C FFFFFFFF8028359C


Bush : All votes are equal but some votes are more equal than others.

>------------------------------------------------------------------------------<

  Jouk Jansen
		 
  joukj@...

  Technische Universiteit Delft        tttttttttt  uu     uu  ddddddd
  Nationaal centrum voor HREM          tttttttttt  uu     uu  dd    dd
  Rotterdamseweg 137                       tt      uu     uu  dd     dd
  2628 AL Delft                            tt      uu     uu  dd     dd
  Nederland                                tt      uu     uu  dd    dd
  tel. 31-15-2782272                       tt       uuuuuuu   ddddddd

>------------------------------------------------------------------------------<

[Mesa3d-dev] Re: gen_matypes maintained?

[Daniel Borca <dborca@3d...>]

Keith Whitwell writes: 

>> Quick hint: there is a GLUT-compilable sourcecode for GLEXcess at
>> http://www.glexcess.com/
> 
> Where abouts?  I can only see the windows versions...

Ok, I uploaded a cleaner version at
http://www.geocities.com/dborca/mesa/glxmesa.tgz 

Regards,
Daniel Borca 

Re: [Mesa3d-dev] NV vert program

[Brian Paul <brian@tu...>]

Michal Krol wrote:
> Hello
> 
> Are NV vertex programs are going to be supported?

GL_NV_vertex_program (and GL_NV_v_p_1_1) has been supported for quite 
a while.


> I think about vp1.1 
> and vp2.0. Is there anyone who works on this? Brian?

I haven't looked too closely at GL_NV_v_p_2_0 and have no plans at 
this time to implement it.  I'd want to get NVIDIA's OK before doing so.

-Brian

Re: [Mesa3d-dev] Windows build broken :/

[Keith Whitwell <keith@tu...>]

Matt Sealey wrote:
> f:\Mesa-newtree\src\mesa\tnl\t_save_api.c(1353): error C2440: '=' : cannot convert from 'void (__cdecl *)(GLint)' to 'void
> (__stdcall *)(GLint)'
> 
> (and so on :)
> 
> What's the problem here? The code is basically assigning functions into
> the GLvertexformat structure, surely they (the structure pointers) should
> all be under the C calling convention anyway since it's all internal stuff?

Those functions eventually end up in the dispatch table so aren't really 
internal.  I'd prefer to have someone with access to windows fix this, but 
basically a lot of those functions are going to require a GLAPIENTRY deconation.

It's all greek to me (conveniently...), but it shouldn't be too hard to create 
a patch for this.

Keith

[Mesa3d-dev] Windows build broken :/

[Matt Sealey <matt@ki...>]

f:\Mesa-newtree\src\mesa\tnl\t_save_api.c(1353): error C2440: '=' : cannot convert from 'void (__cdecl *)(GLint)' to 'void
(__stdcall *)(GLint)'

(and so on :)

What's the problem here? The code is basically assigning functions into
the GLvertexformat structure, surely they (the structure pointers) should
all be under the C calling convention anyway since it's all internal stuff?

--
Matt Sealey <matt@...>

[Mesa3d-dev] =?iso-8859-2?Q?NV_vert_program?=

[<iunknown@tl...>]

Hello

Are NV vertex programs are going to be supported? I think about vp1.1=20
and vp2.0. Is there anyone who works on this? Brian?

Pozdrawiam,
Michal Krol

[Mesa3d-dev] Re: gen_matypes maintained?

[Daniel Borca <dborca@3d...>]

Sorry for the previous email! The archive I was using is:
http://www.glexcess.com/files/glxsglut.rar 

Regards,
Daniel Borca 

Re: [Mesa3d-dev] Re: gen_matypes maintained?

[Daniel Borca <dborca@3d...>]

>> I know...
>> Quick hint: there is a GLUT-compilable sourcecode for GLEXcess at
>> http://www.glexcess.com/
>
>Where abouts?  I can only see the windows versions...

The demo link is:
http://www.glexcess.com/files/glexcess.tar.gz
Tis an "older" version, not the latest, but (almost) compiles with GLUT!
It has some unnecessary #include <windows.h> which you can get rid of!
I cleaned up the sourcecode, but have it at home! I can upload it somewhere
tomorrow!



-------------------------------------------------------

Xnet scaneaza automat toate mesajele impotriva virusilor folosind RAV AntiVirus.

Xnet automatically scans all messages for viruses using RAV AntiVirus.



Nota: RAV AntiVirus poate sa nu detecteze toti virusii noi sau toate variantele lor.

Va rugam sa luati in considerare ca exista un risc de fiecare data cand deschideti

fisiere atasate si ca MobiFon nu este responsabila pentru nici un prejudiciu cauzat

de virusi.



Disclaimer: RAV AntiVirus may not be able to detect all new viruses and variants.

Please be aware that there is a risk involved whenever opening e-mail attachments

to your computer and that MobiFon is not responsible for any damages caused by

viruses.

Re: [Mesa3d-dev] Re: gen_matypes maintained?

[Keith Whitwell <keith@tu...>]

Daniel Borca wrote:
> Keith Whitwell writes:
> [snip]
> 
>>> Hehe! I was eager beaver to see the new vtx code in action!
>>
>>
>> When you're able, bug reports would be helpful.  The set of 
>> applications I've been testing with works fine, but that doesn't mean 
>> that there
>> aren't bugs lurking elsewhere...
> 
> 
> I know...
> Quick hint: there is a GLUT-compilable sourcecode for GLEXcess at
> http://www.glexcess.com/

Where abouts?  I can only see the windows versions...

Keith

[Mesa3d-dev] Re: gen_matypes maintained?

[Daniel Borca <dborca@3d...>]

Keith Whitwell writes: 

[snip]
>> Hehe! I was eager beaver to see the new vtx code in action!
> 
> When you're able, bug reports would be helpful.  The set of applications 
> I've been testing with works fine, but that doesn't mean that there
> aren't bugs lurking elsewhere...

I know... 

Quick hint: there is a GLUT-compilable sourcecode for GLEXcess at
http://www.glexcess.com/
The third scene, with lotsa triangles. Perhaps it's something wrong with
the clipping! Really, I was unable to dig further... 

Regards,
Daniel Borca 

Re: [Mesa3d-dev] gen_matypes maintained?

[Keith Whitwell <keith@tu...>]

Daniel Borca wrote:
> Ian Romanick wrote:
> 
>> Brian Paul wrote:
>>
>>> Ian Romanick wrote:
>>>
>>>> Is x86/gen_matypes.c actively maintained?  I tried to compile it 
>>>> today, and it seems to reference a bunch of old fields in structs.  
>>>> I updated it to compile, and a bunch of the offsets (all of the 
>>>> CTX_* offsets) have changed.  Should I commit a new gen_matypes.c 
>>>> and a new matypes.h?
>>>
>>>
>>> Feel free.  I haven't touched it in a long time.
>>
>>
>> Looks like Daniel Borca beat me to it. :)
> 
> 
> Hehe! I was eager beaver to see the new vtx code in action!
> Speaking of which, I ran into many problems with almost all games/demos
> that used to work before. But the problem is not x86-related, because the
> bugs were still there, even with a pure software driver, with all x86 code
> disabled! Unfortunately, I had to get some sleep :P so I couldn't dive
> deeper into the issue!

When you're able, bug reports would be helpful.  The set of applications I've 
been testing with works fine, but that doesn't mean that there aren't bugs 
lurking elsewhere...

Keith