This gets me excited. I've been working on a Windows->Linux migration
project that uses shader API in a mandatory library that we don't have
source code for, and in a few months I'll most likely be helping to get
this to work.
--
Coleman Kane
IntelliTree Solutions llc.
w if this might translate down to a D3D call
or not that does a size transform at the time of Blit.
If you'd like, I'd be willing to help out if I can on getting this
working better. Sounds like you've gotten a head start on it.
--
Coleman Kane
IntelliTree Solutions llc.
On Wed, 20
my code
so I can't fix it. Would the above mentioned BltFast/CopyRect patches
deal with code that attempts to provide this feature?
--
Coleman Kane
IntelliTree Solutions llc.
r which this is the
case... perhaps that is a source of your slowness?
--
coleman kane
> Ananth M wrote:
> >
> >
> > On 2/10/06, *Ananth M* <[EMAIL PROTECTED]
> > <mailto:[EMAIL PROTECTED]>> wrote:
> >
> > The wine source code was compiled in the Xeon
Despite this, the DLLs just expose a cross platform API. The code inside
opengl32.dll and glut32.dll will probably still be very windows-centric.
I think the glut32.dll.so built by WINE actually calls into libGL.so,
libGLU.so, and libglut.so in linux/BSD/etc...
--
Coleman Kane
Perhaps build a configurable option to use canonicalize_file_name if it
exists, and fall back on realpath if it doesn't... realpath is supposed
to be safe if you use necessary precautions...
On Wed, 2006-02-01 at 17:45 +0100, Michael Jung wrote:
> Hi Gerald,
>
> On Wednesday 01 February 2006 16:2
on moving the d3d8 code over to
> wined3d. If you have time to help out, all help is usefull :)
> One of the usefull things to do before starting to hack on shaders is to
> finish the d3d8/d3d9 merge as both can then share the same shader code.
>
> Roderick
>
>
> On T
organizing this effort here?
--
Coleman Kane
