> The only other option I'm aware of is to await the shader-based fixed
> function pipeline replacement which might contain an implementation of
> the D3DRS_VERTEXBLEND renderstates.
I worked on a pipeline replacement using GL_ARB_vertex_program a few months
ago but hit some roadblocks, so I never
This is a bit of an old topic, but it relates to two active bugs, 8357
(affecting Everquest) and 14608 (affecting Warhammer Online)
The rough summary of the situation is that these two games use d3dx9_30
and d3dx9_34 respectively, and at least the former uses
ConvertToIndexedBlendedMesh.
Anyway,
On Sun, 2009-01-04 at 20:49 -0600, Austin English wrote:
> On Sun, Jan 4, 2009 at 4:55 PM, Vitaliy Margolen
> wrote:
> > titon barua wrote:
> >> ---
> >> /* we don't care about the success or failure of this call */
> >> -write(*(This->fd), &event, sizeof(event));
> >> +/* print error
Vitaliy Margolen wrote:
> titon barua wrote:
>
>> ---
>> /* we don't care about the success or failure of this call */
>> -write(*(This->fd), &event, sizeof(event));
>> +/* print errors if they occur */
>> +if (write(*(This->fd), &event, sizeof(event)) == -1) perror ( NULL );
>>
Vitaliy Margolen wrote:
>> titon barua wrote:
>>> -write(*(This->fd), &event, sizeof(event));
>>> +if (write(*(This->fd), &event, sizeof(event)) == -1) perror ( NULL );
>> What's the point of your patch? What part of the comment isn't clear to you?
>
>GCC is complaining about the ignored re
On Sun, Jan 4, 2009 at 4:55 PM, Vitaliy Margolen
wrote:
> titon barua wrote:
>> ---
>> /* we don't care about the success or failure of this call */
>> -write(*(This->fd), &event, sizeof(event));
>> +/* print errors if they occur */
>> +if (write(*(This->fd), &event, sizeof(event)
titon barua wrote:
> ---
> /* we don't care about the success or failure of this call */
> -write(*(This->fd), &event, sizeof(event));
> +/* print errors if they occur */
> +if (write(*(This->fd), &event, sizeof(event)) == -1) perror ( NULL );
What's the point of your patch? What p
> On Sat, Jan 03, 2009 at 07:52:10PM +0100, Stefan Reimer wrote:
>> > On Fri, Jan 02, 2009 at 11:14:52PM +0100, Stefan Reimer wrote:
>> I am using gentoo hardened:
>>
>> gcc (Gentoo Hardened 4.3.2-r7 p1.5, ssp, fortify, pie-10.2.0) 4.3.2
glibc 2.8
>>
>> Using gcc -v gives:
>>
>> /usr/libexec/gcc/x
> On Sat, Jan 03, 2009 at 07:52:10PM +0100, Stefan Reimer wrote:
>> > On Fri, Jan 02, 2009 at 11:14:52PM +0100, Stefan Reimer wrote:
>> I am using gentoo hardened:
>>
>> gcc (Gentoo Hardened 4.3.2-r7 p1.5, ssp, fortify, pie-10.2.0) 4.3.2
>> glibc 2.8
>>
>> Using gcc -v gives:
>>
>> /usr/libexec/gc
titon barua wrote:
> ---
> /* we don't care about the success or failure of this call */
> -write(*(This->fd), &event, sizeof(event));
> +/* print errors if they occur */
> +if (write(*(This->fd), &event, sizeof(event)) == -1) perror ( NULL );
What's the point of your patch? What p
Thank you for your reply!
Yes, this workaround works. I was testing on EASy68k, the only program
I know that uses EM_PASTESPECIAL, and it was invoking CF_TEXT and
pasting garbage (question marks and plusses, but the same length as
the source text). When I treated them as CF_UNICODE, it pasted
perf
INeedAnime wrote:
>> ./configure --target=i686-unknown-gnu-linux
> What does that do? It's not listed in "./configure --help".
It was a thinko. I put the correct instructions up at
http://wiki.winehq.org/Wine64
- Dan
Hi, and welcome to Wine development!
Two notes on your patch:
1) does treating CF_TEXT as a CF_UNICODETEXT work?
2) you don't include a conformance test. Conformance
tests are really, really helpful. I bet you could write
one for this feature. Please give it a shot, and make
sure the test pass
Rob Shearman wrote:
> 2009/1/4 Michael Stefaniuc :
>> Hello guys,
>>
>> i guess that we need to change long to LONG in IDL files too, right?
>> Or would that be something that widl could/should do automatically?
>
> long/unsigned long are explicitly defined by the DCE/RPC standard to
> be 32-bit t
http://fringe.davesource.com/Fringe/Computers/Linux/Manifesto.txt
It's taken longer than he expected...
--- snip ---
WINE (the Linux
emulator for Windows) works to a fairly surprising degree. You can
run real Windows programs with it, but some of them don't look right,
and some of them just crash
"Rob Shearman" writes:
> 2009/1/4 Michael Stefaniuc :
>> Hello guys,
>>
>> i guess that we need to change long to LONG in IDL files too, right?
>> Or would that be something that widl could/should do automatically?
>
> long/unsigned long are explicitly defined by the DCE/RPC standard to
> be 32-b
2009/1/4 Michael Stefaniuc :
> Hello guys,
>
> i guess that we need to change long to LONG in IDL files too, right?
> Or would that be something that widl could/should do automatically?
long/unsigned long are explicitly defined by the DCE/RPC standard to
be 32-bit types. In an ideal world, I would
Nuvola is good, but I think Tango looks a lot nicer if it could be
available, and I think it blends with different platforms better - it's
designed specifically with that in mind. Nuvola looks very KDEish and
very very blue; not as good as Tango IMHO.
Does anyone know how gnome manages to handle t
titon barua writes:
> @@ -177,7 +177,8 @@ static void debug_usage(void)
> "Example: WINEDEBUG=+all,warn-heap\n"
> "turns on all messages except warning heap messages\n"
> "Available message classes: err, warn, fixme, trace\n";
> -write( 2, usage, sizeof(usage) -
Hello guys,
i guess that we need to change long to LONG in IDL files too, right?
Or would that be something that widl could/should do automatically?
bye
michael
20 matches
Mail list logo
