Mapping colorop to pixelshader is necessary because misc_state_template
defines a pixel shader handler. We have to use the same representative
in all pipeline parts.
Wined3d_cs_exec_set_texture dirtifies the pixel shader state when the
fixup of a texture changes. Atifs no longer needs a pixel shader handler
on its own since vertex shader updates aren't delayed any more when the
pixel shader state is dirty.
The abilities of this hardware is too limited to support generic sign /
swizzle fixups. A generic handler would consume 4 of the 8 available
color instruction slots and 2 alpha instruction slots.
The bump mapping handler code has its own way of handling the color
fixups. It merges the fixup into the perturbation calculation without
requiring extra shader instructions. In theory this is possible for the
majority of d3d texture ops as well, but I don't think this is worth the
effort. I expect that this code will only be used for the ddraw signed
format test in practice.
OS X doesn't have the same concept of maximized windows as Windows does.
There's no mode that prevents a normally-movable window from being moved. If
a window is "zoomed", it mostly fills the screen but the user can still move
or resize it, at which point it ceases to be in the zoomed state. So, users
are confused and frustrated when they can't move a window that's maximized.
To get similar behavior while still respecting Win32 semantics, we detect when
the user tries to move a maximized window. When they start, a request is
submitted to the app to restore the window. Unless and until the window is
restored, we don't actually allow the window to move.
The user expects to move the window from its current (maximized) position. It
should not jump to its normal position upon being restored. So, we set the
window's normal position to its current position before restoring it.
OS X doesn't have the same concept of maximized windows as Windows does.
There's no mode that prevents a normally-resizable window from being resized.
If a window is "zoomed", it mostly fills the screen but the user can still
move or resize it, at which point it ceases to be in the zoomed state. So,
users are confused and frustrated when they can't resize a window that's
maximized.
To get similar behavior while still respecting Win32 semantics, we now let the
user try to resize maximized windows. (The resize cursors are shown at the
edges of the window frame.) When they start, a request is submitted to the app
to restore the window. Unless and until the window is restored, we don't
actually allow the window to change its size.
The user expects to resize the window from its current (maximized) position.
It should not jump to its normal position upon being restored. So, we set the
window's normal position to its current position before restoring it.
Notice that I'm using floats instead of doubles in the new function,
mostly to be able to use struct wined3d_matrix and multiply_matrix().
At a rough estimate the precision should still be good enough.
Stefan Dösinger