Okay finally after using a pen and paper to draw some pictures I've gotten
compressed textures to work with Neverwinter nights!!
http://www.skynet.ie/~airlied/patches/dri/i830_texcmp.diff
Now I can get back to playing it :-)
It also proves you probably don't need the docs most of the time,
Thomas Winischhofer wrote:
Would you DRI guys mind adding a #define for DRI_VERSION_CURRENT in the
same style as XORG_VERSION_CURRENT so that changes like the types from
drmHandle - drm_handle_t can be handled smoothly with the C
preprocessor for older versions?
Point being: I would like to
Thomas Winischhofer wrote:
Jens Owen wrote:
Thomas Winischhofer wrote:
Would you DRI guys mind adding a #define for DRI_VERSION_CURRENT in
the same style as XORG_VERSION_CURRENT so that changes like the types
from drmHandle - drm_handle_t can be handled smoothly with the C
preprocessor for
Jens Owen wrote:
Thomas Winischhofer wrote:
If it is complicated for the DRI folks, why not keep such a version
#definition in the x.org tree which is updated each time a merge from
the DRI tree happens?
For example, in xf86drm.h just add
#define DRI_DATE 20040616
That would solve my particular
Jens Owen wrote:
Thomas Winischhofer wrote:
Would you DRI guys mind adding a #define for DRI_VERSION_CURRENT in
the same style as XORG_VERSION_CURRENT so that changes like the types
from drmHandle - drm_handle_t can be handled smoothly with the C
preprocessor for older versions?
Point being: I
Jens Owen wrote:
Thomas,
Versioning has always been a tricky issue for DRI developers, and
consequently keeping version numbering simple and up to date is
important.
I'd encourage you to considering using/enhancing the existing DRI and
DRM versioning. For example, I'm wondering if the runtime
Jens Owen wrote:
Perhaps it's time to bump the XORG_VERSION_CURRENT string to
differentiate between the last release of X.org and the next. Would
that help you?
The big dri merge seems a good time to label snapshot 6.7.0.90 or
however we want to start identifying the pre-6.7.1 snapshots. (How
Hi,
just a reminder: the tdfx driver is broken for six month now (there
still don't show up any textures - like described by ajax in May - on my
3dfx Voodoo5 5500). In this state the driver it's practically useless.
I'm still desperately waiting for someone being able to repair it...
Ignaz
--
Please do not reply to this email: if you want to comment on the bug, go to
the URL shown below and enter your comments there.
http://freedesktop.org/bugzilla/show_bug.cgi?id=760
[EMAIL PROTECTED] changed:
What|Removed |Added
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thursday 17 June 2004 15:26, Ignaz Forster wrote:
Hi,
just a reminder: the tdfx driver is broken for six month now (there
still don't show up any textures - like described by ajax in May - on my
3dfx Voodoo5 5500). In this state the driver
Please do not reply to this email: if you want to comment on the bug, go to
the URL shown below and enter your comments there.
http://freedesktop.org/bugzilla/show_bug.cgi?id=760
--- Additional Comments From [EMAIL PROTECTED] 2004-06-17 12:59 ---
~$
Dave Airlie wrote:
Okay finally after using a pen and paper to draw some pictures I've gotten
compressed textures to work with Neverwinter nights!!
http://www.skynet.ie/~airlied/patches/dri/i830_texcmp.diff
Ok, I've updated my patch.
I've converted the r200 and radeon driver to use I8 internal format for
GL_INTENSITY, GL_LUMINANCE and GL_ALPHA formats (so that bug with
conversion to GL_LUMINANCE_ALPHA wouldn't get triggered in the first
place now...), the textures are stored by mesa in mesa_texformat_i8,
-l8, and -a8
Ian Romanick wrote:
Log message:
Add client-side GLX protocol support for GL_ARB_texture_compression. The
extensions are *not* currently enabled. This is for several reaons. First,
the server-side does not support texture compression, so there's no
advantage to supporting it (yet) on
14 matches
Mail list logo
