> certainly worth a try to see if it fixes the game. It'll involve
There should be a "You'll still need a test case though." somewhere in
that line.
2008/7/24 Andrew Fenn <[EMAIL PROTECTED]>:
> Any suggestion on where to go from here? Does this need more discussion
> elsewhere or should a simple return WINED3DERR_INVALIDCALL do it?
>
> I'm having trouble understanding where I should be checking for this error
> and returning an the invalid call
Any suggestion on where to go from here? Does this need more discussion
elsewhere or should a simple return WINED3DERR_INVALIDCALL do it?
I'm having trouble understanding where I should be checking for this error
and returning an the invalid call.
On Mon, Jul 21, 2008 at 9:28 PM, Stefan Dösinger
Vitaliy Margolen wrote:
> Chris Ahrendt wrote:
>> Ok I ran make test and got the failure without running Everquest2.exe
>> let me attach the output of maketest. I guess thats a start eh?
>>
> You getting off-topic too far here. Make test have nothing to do with
> your game. Especially that you at
On Wednesday 23 July 2008 21:48:59 Chris Robinson wrote:
> But extracting the mask offset and size from the actual mask takes a bit of
> time,
Extracting mask is called once or twice per channel conversion. I.e. in case
of converting a8r8g8b8->a1r5g5b5 mask should be calculated only 8 times, no
> Unfortunately we can't make it a different function in the shader
instruction table because the difference between MOV and ARL is decided
with the dest register.
Sure you can, it seems that this MOV/MOVA specific stuff all belongs in
vshader_hw_mov (both sides of the MOV if statement can be
I've been trying to track some of the errors that I get with different
games. To do that I've added some extra traces and this is what I see:
fixme:d3d_surface:read_from_framebuffer_texture glReadBuffer(0x405) was
0x8ce0 > GL_INVALID_ENUM (0x500) @
../../../wine.git/dlls/wined3
Chris Ahrendt wrote:
> Ok I ran make test and got the failure without running Everquest2.exe
> let me attach the output of maketest. I guess thats a start eh?
>
You getting off-topic too far here. Make test have nothing to do with your
game. Especially that you attached complete output of everyt
2008/7/23 Markus Hitter <[EMAIL PROTECTED]>:
>
> Am 23.07.2008 um 02:25 schrieb Reece Dunn:
>>
>> +/* last error -- NT: E_INVALIDARG, 9x/Vista: unchanged */
>> +/* ret is FALSE on XP and earlier but TRUE on Vista, therefore
>> it cannot be tested for */
>> +ok((GetLastError() == E_INVAL
Hi Reece,
> (Vista does not set the last error on success for the functions used
> in protectdata).
In that case, it seems to me we should just remove those tests, as
it's unlikely an app can depend on the last error being set on
success.
--Juan
On Wednesday 23 July 2008 10:29:37 am Victor wrote:
> 0) initial patch used "mask size" + "mask offset", but was rewritten to use
> mask value when Stefan Dösinger requested that. I don't want to rewrite it
> back to use mask size + mask offset.
> 1) mask size and offset can be extracted from mask
Hi Markus,
> A more general question: Is it Wine's policy to just ignore
> differences in behaviour between different Windows versions?
No, we wish to accept most Windows versions. Not quite all, because
in some cases old versions of Windows are clearly broken. That's what
we have the handy bro
On Wednesday 23 July 2008 21:18:57 Chris Robinson wrote:
> Maybe it would be better if the table was changed to have a bit offset and
> a mask size, instead of the actual mask.
0) initial patch used "mask size" + "mask offset", but was rewritten to use
mask value when Stefan Dösinger requested tha
On Wednesday 23 July 2008 09:10:02 am Stefan Dösinger wrote:
> The patch looks reasonably, just one small thing: There is a count_bits
> function implemented in utils.c, which as far as I can see does the same as
> getMaskSize. Can you check if you can reuse it?
Maybe it would be better if the tab
On Wednesday 23 July 2008 20:10:02 Stefan Dösinger wrote:
> Actually, one more idea:
>
> It will be extra-slow, but we could implement a general all-to-all format
> by converting the source format to A32R32G32B32F(float values), and then
> write code to convert this format to all possible destinati
This patch collides with Victor Eremin's general convertor I think. We may
still want both, because the special function is faster than code that attempts
to handle all potential formats.
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:wine-patches-
> [EMAIL PROTECTED] On Behalf
> Ok I did a clean install.. rebuilt wine from the base 1.1.1 code put
> the above patch into the context.c and reran EverQuest2.exe I put
> export WINEDEBUG=+d3d,+sed before running and am attaching the trace.
> (If you need more just send me a message and I will retry it.
> I still get the card
The patch looks reasonably, just one small thing: There is a count_bits
function implemented in utils.c, which as far as I can see does the same as
getMaskSize. Can you check if you can reuse it?
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:wine-patches-
> [EMAIL PROTECTED] On
Actually, one more idea:
It will be extra-slow, but we could implement a general all-to-all format by
converting the source format to A32R32G32B32F(float values), and then write
code to convert this format to all possible destination formats. The from->to
table lookup could be replaced by code
Here's a warning that seems to pop up if you type
or mouse or something during the kernel32/console test.
I first saw it last year, but it popped up again once last month
and again today:
http://kegel.com/wine/valgrind/logs/2008-07-23-07.18/vg-kernel32_console.txt
Syscall param writev(vector[...
Hi Dan,
I have send patches fixing some of the valgrind warnings. I'll look over rest
of them when the patches are accepted and valgrind logs updated.
Regards,
Piotr
"Rob Shearman" <[EMAIL PROTECTED]> writes:
> 2008/7/23 Dan Hipschman <[EMAIL PROTECTED]>:
>> This isn't the most efficient implementation, but it works, and it should
>> not be difficult to tweak. Hence, I'd rather get this version in and add
>> the optimizations one at a time, in little patches.
Hi Dan,
2008/7/23 Dan Hipschman <[EMAIL PROTECTED]>:
> This isn't the most efficient implementation, but it works, and it should
> not be difficult to tweak. Hence, I'd rather get this version in and add
> the optimizations one at a time, in little patches. "Get it working first..."
Yes, I thin
2008/7/22 David Adam <[EMAIL PROTECTED]>:
> +b = pow(D3DXVec3Dot(&difference, praydirection), 2);
Maybe I'm just bad at math, but shouldn't that just be
b = D3DXVec3Dot(&difference, praydirection);
(The test case doesn't really help there)
> +ok(result == TRUE, "expected FALSE, received TR
Am 23.07.2008 um 02:25 schrieb Reece Dunn:
>
> +/* last error -- NT: E_INVALIDARG, 9x/Vista: unchanged */
> +/* ret is FALSE on XP and earlier but TRUE on Vista, therefore
> it cannot be tested for */
> +ok((GetLastError() == E_INVALIDARG || GetLastError() ==
> 0xdeadbeef),
> +
2008/7/21 Juan Lang <[EMAIL PROTECTED]>:
> Hi Reece,
>
> thanks for looking into failures on Vista.
>
>> To me, without understanding this in any more detail, it looks as if
>> Vista is broken here (and thus the Vista return parts should be marked
>> as broken()). However, Vista may be doing the ri
Gerald Pfeifer <[EMAIL PROTECTED]> writes:
> In ISO C, operations involving both signed and unsigned types are
> using signed. If the case of ui = ui OP si is really ment to make
> use of this (despite the result being stored in an unsigned type),
> we'd need to handle this via two casts, but I
27 matches
Mail list logo
