On Sat, Feb 09, 2002 at 05:03:31AM +0000, Keith Whitwell wrote:
Thanks for your reply.
> My solution to this would be to always produce Clip coordinates from Model
> coordinates using the ModelProject matrix ....
Ok. Done.
> Secondly, we need to investigate the software path - is unwanted additional
> precision somehow sneaking in? It's often appealing to allow GLdouble
I've been looking through _mesa_transform_tab[] et al since I posted I
can't see anything that doesn't use GLfloat in the MESA_NO_ASM=1 path
(and the generated asm didn't show anything obvious at a glance)
similary in the X86 path (dunno about 3DNOW as I've no idea what the
instructions mean)
> I think some investigation of the demo is required to see if it is expecting
> something unreasonable or not.
Ok, I think I've glanced at this 'open gl invariance' thing on a web
site, I'll grab the docs and read it in more detail....probably look at
why RTCW has problems and see if that's really somewhere else.
Can I change this thread to get your wisdom on another problem?
(chess.c exhibits this)
Scenario : Application is generating a display list firing a lot of
vertices in a loop something like :-
glBegin(QUAD_STRIP or similar)
for (...) {
Normal
Vertex3f(...)
..
..
Vertex3f(....)
}
glEnd()
Ok, if the last Vertex() of the loop forces a _tnl_flush_immediate
because the IM is full the first slot of the next Immediate will get the
_END.
Problem : When you later execute the list the code considers the last n
vertices of IM 1 should be copied forward and since slot 3 of IM
2 has the first VERT_END, it then tries to render just those n vertices.
Thing is, the emit() loops have unsigned counters, so a check like j<
count - 3) becomes j < 2^32-1 (also nr+= nr - count is
zero) (when count = 2 for example)
I figure these vertices ideally wouldn't be copied, unless it
happened in the middle of the for loop, since the next call is glEnd()
The real problem is not knowing the glEnd() is coming next in advance.
This gives a few possible solutions :
a) Fix the j, nr loops. Sounds like fixing the symptom - unless there
are valid scenarios where the infinite loop may hit.
b) Change the logic in fixup_compiled_primitives (or perhaps earlier in
_tnl_copy_immediate_vertices) to throw away these vertices if IM slot 3
is an end, they'll have already been rendered afaict.
c) change the front end api so things like _tnl_Vertex/VERTEXn instead of being
count = IM->Count++
store vertex[count]
check if IM is full
flush_immediate
it checks and flushes first
check if full
flush_immediate
store vertex[IM->Count++]
I haven't completely thought this one through, but I'm assuming that as
216 is a nice multiple of 2,3, 4 and 6 that currently the chances of an
IM being flushed exactly before a glEnd() call is high, whereas if there
is another vertex when IM->Count==216, we really are in the middle of
something - hmm, but it needs a mechanism to get that IM and
things that stick in the current slot, like Normal()s could be messy
(well they'd need to flush).
d) something completely different? ...
--
Michael.
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
