Eric added some new code to check if offset < obj_size before computing
_MaxElement but my original code was still present afterward and it
clobbered the _MaxElement value.
Not sure if this came from a bad merge or what.
Based on a patch by Xavier Chantry <chantry.xavier@gmail.com>:
If x+width or y+height is negative, then maxx or maxy will get a bogus value
when converting that to unsigned. Fix this by setting 0 as minimal value.
This was also triggered by teeworlds, but only with some combination of
resolution and map section. For example upper part of dm2 at 1280x1024.
commit 53174afeeb introduced a portability change that converted GLint x,y
to GLuint. That breaks when x and y are negative, which seems to be allowed,
and which at least one game uses : teeworlds.
Rather than simply reverting the change, it seems possible to convert the
16bit unsigned to GLint so that comparisons are made between signed integers
instead. This hopefully does not break anything while keeping MSVC happy.
Signed-off-by: Xavier Chantry <chantry.xavier@gmail.com>
Signed-off-by: Brian Paul <brianp@vmware.com>
This is faster and ensures that NaN floats get stored properly.
Before, NaN values (which might be used with UP2H, UP2US, UP4B and
UP4UB) weren't getting stored properly with gcc -O3.
This is the second part of the fix for the piglit fp-unpack-01 failure
(bug 25973).
The UP2H, UP2US, UP4B and UP4UB instructions interpret the float
registers as integers. With gcc -O3 some bits were getting mixed up
somewhere. This is part of the fix for the piglit fp-unpack-01 test
failure (bug 25973).
The previous memory leak fix didn't always work properly.
Now check the xm_buffer::smh field (now documented!) to
see if the buffer points to shared memory.
Depending on first/last provoking vertex either the first or last
element/index may have the extra DRAW_PIPE_x flags. Mask off those
bits for all vertex elements to be safe (esp. for the quad case).
This may be overly cautious, but it's a cheap operation.
Fixes a segfault caused by large/bogus vertex indexes otherwise.
This is a minimum change to keep things building and running minimally -- it
might cause applications to fail to allocate buffers due to out of
GMR memory.
A proper update will be commited later.
Brian Paul