On Mon, Jan 25, 2010 at 2:20 AM, Brian Paul <brian.e.p...@gmail.com> wrote: >> >> What exactly is the issue with teeworlds? I haven't seen a bug report. >>
Searching for noclip in teeworlds forums show at least five reports of a similar issue. For example : http://www.teeworlds.com/forum/viewtopic.php?id=4174 Everytime gfx_noclip was suggested as a workaround. And this simply disables gl scissor. Since it was a good workaround, maybe no one ever bothered to report the issue upstream. However it seems all these reports are from radeon users. It would be good to know if the issue is really fixed now and what commit fixed it. I just had a look at "git log -p src/mesa/drivers/dri/radeon/radeon_common.c" and found several scissor fixes but hard to know if one fixed the problem. That radeon code uses signed int so it was apparently a different problem than in gallium. What seems to cause problems is that teeworlds does not do any sanity checks on the values given to glScissor. 1) x and y are very often negative, this was enough to make st/mesa blow up and end up with a "null space" scissor, which prevented any clearing and cause funny graphics and screenshots, as seen above. 2) This is still very obscure to me, probably caused my lack of opengl knowledge, but from what I understood, some maps (e.g. dm2) apparently have several layers of background, which are not always visible depending on the map section. A glScissor call is made anyway for each background or layer, including non visible one. In that case x+width and/or y+height is negative, which st/mesa did not like either. Just a side-note, the source and binaries are easily available : http://teeworlds.com/?page=downloads Easy enough to build : http://teeworlds.com/?page=docs&wiki=CompilingEverything And the development seems quite open with everything on trac : http://www.teeworlds.com/trac/teeworlds/wiki And it's a very cool and original game :) This is just an invitation for anyone interested to either test its glscissor code against mesa, or to review it. >> I can apply the first part of your bounds-check patch which adds some >> _mesa_debug() calls, but the rest is invalid. > Actually I just moved the mesa_debug before the mesa_error. I saw that viewport.c did it this way, and I thought it made sense to show the glScissor call and argument values before checking height/width and possibly returning an error. Nothing important. > Forgot: the second patch to prevent bogus int->uint values is the > right idea. I'll just clean it up a little. Thanks. > Perfect, then everything is actually sorted out from my side. As long as gallium/softpipe and gallium/nouveau works, I am happy :) ------------------------------------------------------------------------------ Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
