Dave;<br><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Clever! </blockquote><div><br></div><div>I can't take any credit for being clever here; the only thing I did was poke around and be persistent about it, that's how I learn.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">This may not work on all graphics cards, as it's making<br>
assumptions about how the hardware does the tesselation.<br></blockquote><div><br></div><div>Ah, check. Well, I'm not burdened by any knowledge, the only thing I had to go on was what comes up on the screen. </div><div>
 </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
In practice though it's possible that they all have converged on this<br>
approach as the fastest. It works here anyway :)<br></blockquote><div><br></div><div>I'm on a fairly old Nvidia here. My Linux laptop is one that I got for free as nobody else in my circle of friends wanted it. Hardly bleeding edge material. If somebody on a Ati card could confirm that my "L" example runs I'll take it to be safe in practice. If not I'll quit doing this for portability reasons. </div>
<div> </div><div>I wouldn't be surprised if you were right, but since video cards are all about speed I think they would be better off just trying to ram the thing on the screen instead of trying to check whether every 'polygon corner is always convex at all corners. That would mean a fair amount of extra instructions for many shapes every frame without any real gains.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
The official approach from the OpenGL docs is that you shouldn't use<br>
polygons to draw concave shapes, and the fluxus docs should be<br>
consistent with this I think.<br></blockquote><div><br></div><div>Full agreement here.</div><div><br></div><div>I'm happy this is cleared up now. Last evening I was really wondering how it could be that we were going "yes you can", "no you can't", "yes you can" over this. You'll understand that I "knew" I was right but I also knew that you -unlike me- actually know what you are talking about... so it was slightly surreal to me.</div>
<div><br></div><div>I just ran another test. The tetris "s" shape was the most extreme case that should work according to the theory I had about possible shapes that I could come up with. Here is my test code;</div>
<div><br></div><div><div>(clear-colour (vector 0 0 0))</div><div>(clear)</div><div>(with-primitive</div><div>    (build-polygons 8 'polygon)</div><div>    (pdata-set! "p" 0 (vector  0  0 0))</div><div>    (pdata-set! "p" 1 (vector  0 -1 0))</div>
<div>    (pdata-set! "p" 2 (vector  1 -1 0))</div><div>    (pdata-set! "p" 3 (vector  1  1 0))</div><div>    (pdata-set! "p" 4 (vector  0  1 0))</div><div>    (pdata-set! "p" 5 (vector  0  2 0))</div>
<div>    (pdata-set! "p" 6 (vector -1  2 0))</div><div>    (pdata-set! "p" 7 (vector -1  0 0))</div><div>    (recalc-normals 1)</div><div>    (hint-wire)</div><div>    (wire-colour 0)</div><div>    (line-width 3)</div>
<div>    (colour (vector 1 0 0)))</div><div>)</div><div><br></div><div>On my card I can get away with this, but for me there is a slight glitch in this already. The two main rectangles that make up this shape are lit in slightly uneven ways. Going back to the "L", that one too has a (much more slight) uneven lighting with a diagonal running across it that I missed before. Apparently you can do this but clearly it's not "safe". Single polygons should not have discontinuities in lighting, I feel.</div>
<div><br></div><div>Phew! Illegal OpenGL code! Illegal Tetris is possible, so are single-polygon hearts.</div><div><br></div><div>Cheers,</div><div>Kas.</div></div></div>