2008/8/21 Rico Schüller <[EMAIL PROTECTED]>:
> +/* Set the scissor rect values */
> +scissor.left=0;
> +scissor.right=ThisDevice->ddraw_width;
> +scissor.top=0;
> +scissor.bottom=ThisDevice->ddraw_height;
> +IWineD3DDevice_SetScissorRect(device, &scissor);
> +
Are you sure y
2008/8/21 Stefan Dösinger <[EMAIL PROTECTED]>:
> These changes may be correct, but they need a test. Take a look at
> dlls/d3d9/tests/device.c to see how the other tests look. I guess the changes
> are likely to be correct, but they have to be tested
>
Not in its current form, there's a C++ comme
2008/8/15 Hans Leidekker <[EMAIL PROTECTED]>:
>
> +HINTERNET alloc_handle( object_header_t *hdr )
> +{
> +object_header_t **p;
> +ULONG_PTR handle = 0, num;
> +
> +list_init( &hdr->children );
> +
> +EnterCriticalSection( &handle_cs );
> +if (!max_handles)
> +{
> +nu
The d3d9 one is probably a driver bug, not sure about the ddraw one.
If it's much of an issue, it might be worth to run the tests using
Mesa instead.
2008/8/13 Michael Karcher <[EMAIL PROTECTED]>:
> Yes, but if wine runs on a 64 bit kernel, the kernel does not handle the
> request, as it only recognizes the 64 bit request, if I understood
> Vitaliy correct. I consider that a kernel bug.
>
I'd say so, yeah.
2008/8/12 Dan Kegel <[EMAIL PROTECTED]>:
> d3d9:visual.c
What kind of failures are you seeing there, and with which drivers?
(The test should at least pass with recent Mesa versions as long as
the GLSL extensions are disabled)
2008/8/13 Vitaliy Margolen <[EMAIL PROTECTED]>:
> While debugging some force-feedback issues ran into an interesting problem.
> The size of one struct from include/linux differs between 32-bit and 64-bit.
> That wouldn't be a major problem except that size is the part of the ioctl()
> request. Whic
2008/8/8 Stefan Dösinger <[EMAIL PROTECTED]>:
>
>> Very likely but you run into the following:
>> 1. Windows programs are written for the x86 processor. Is there an
>> x86 emulator for the ARM arch?
> You could run wince / windows mobile apps which are often ARM native.
>
Unfortunately WinCE isn'
2008/8/5 David Adam <[EMAIL PROTECTED]>:
> Hi,
>
> some remarks
>
> +if (((*poutscale).x==0)||((*poutscale).y==0)||((*poutscale).z==0))
> should be
> +if ((poutscale->x==0)||(poutscale->y==0)||(poutscale->z==0))
>
To add to that, you really should test your error paths in your test case.
A
2008/8/5 Luis Busquets <[EMAIL PROTECTED]>:
> +static const D3DVERTEXELEMENT9 lc={0xFF,0,D3DDECLTYPE_UNUSED,0,0,0};
What do you use this for?
> +while ((pdecl+i)->Stream!=0xFF)
> +{
> +i++;
You might as well increment pdecl itself.
Also keep in mind that Alexandre won't be back be
2008/8/4 Stefan Dösinger <[EMAIL PROTECTED]>:
> and will be done in another patch wave.
>
About those... could you spread them out a bit? It's quite a bit of
code to review, and right now I probably don't look as close as I
probably should.
2008/8/4 Stefan Dösinger <[EMAIL PROTECTED]>:
> +if(CheckDepthStencilCapability(Adapter, AdapterFormat, CheckFormat))
> return TRUE;
This is redundant, the depthstencil formats should already be caught
by the CheckTextureCapability() call. I think you should set this up
the same way as WINED3D
2008/8/4 Stefan Dösinger <[EMAIL PROTECTED]>:
> +/* No checkGLcall here to avoid locking the lock just for checking a
> call that hardly ever
> + * fails
> + */
I think explaining why there's no ENTER_GL()/LEAVE_GL() is more important there.
2008/8/4 Luis Busquets <[EMAIL PROTECTED]>:
> +#include "d3d9.h"
...
> +#define module(vx,vy,vz) sqrt((vx)*(vx)+(vy)*(vy)+(vz)*(vz))
...
> +#include "stdio.h"
You don't really need those.
2008/8/4 Stefan Dösinger <[EMAIL PROTECTED]>:
>> This is mostly for correctness, in practice we should always be able to
>> avoid using CTXUSAGE_BLIT for offscreen targets when FBO ORM is used.
> Not always actually. With my upcoming patches to perform YUV conversion in
> Blt I'll have to avoid the
2008/8/3 Alexander Dorofeyev <[EMAIL PROTECTED]>:
> H. Verbeet wrote:
>
>> +IWineD3DDeviceImpl_MarkStateDirty(This,
>> STATE_RENDER(WINED3DRS_SCISSORTESTENABLE));
>> +
>> +glDisable(GL_BLEND);
>> +IWineD3DDeviceImpl_MarkStateDirty(This,
2008/8/3 Stefan Dösinger <[EMAIL PROTECTED]>:
> The code uses __stdcall, not WINAPI, if USE_WIN32_OPENGL is defined, thus
> I've used __stdcall here too
>
What code? The exports in opengl32.dll are WINAPI. (It would only
really make a difference for Win64, I guess)
2008/8/3 Stefan Dösinger <[EMAIL PROTECTED]>:
> +/* glFinish and glFlush are always loaded from opengl32.dll, this the always
> have
> + * __stdcall calling convention
> + */
In theory WINAPI could be something else than __stdcall.
2008/8/3 Stefan Dösinger <[EMAIL PROTECTED]>:
> +src_rect->x1 -= offset.x; dst_rect->x2 -=offset.x;
Why are you modifying dst_rect here?
2008/8/2 Andrew Fenn <[EMAIL PROTECTED]>:
> After doing a recent git pull I noticed that it now crashes at a different
> place in the code. Here's the backtrace (I haven't had a look yet, this is
> more of a heads up)..
>
> Backtrace:
> =>1 0x7e49089b hash_table_destroy+0xb(table=0x17, free_value=0
2008/7/31 Stefan Dösinger <[EMAIL PROTECTED]>:
> +if(Adapters[0].opengl) {
Shouldn't you be checking the adapter for which the caps are requested instead?
You'll need to modify stretch_rect_fbo() as well.
2008/7/30 Reece Dunn <[EMAIL PROTECTED]>:
> SetMaterial crashes when passed a NULL argument.
>
If you're going to do that, you might as well remove the entire test.
I think this test has caused trouble before.
2008/7/30 Stefan Dösinger <[EMAIL PROTECTED]>:
> DeviceLoadTest is quite big, does splitting up make sense? Otherwise, what
> you say is fair enough - I do not care too much about code beauty in the
> tests as long as the tests work(since one hardly ever reads the test or does
> lots of work on it,
2008/7/30 Aric Stewart <[EMAIL PROTECTED]>:
> ---
> dlls/wined3d/surface_base.c | 122
> +++
> 1 files changed, 65 insertions(+), 57 deletions(-)
>
Looks reasonable to me, although you might want to wait for Stefan to
look it over as well.
2008/7/30 Chris Ahrendt <[EMAIL PROTECTED]>:
> What do you mean ?
>
The code doesn't actually do what you say it does.
2008/7/30 David Adam <[EMAIL PROTECTED]>:
> I forgot to add a change recommended by Henri.
> Now, everything should be fine.
>
Oops, missed that myself as well :-)
Looks ok to me.
I just looked the patch over quickly since you mentioned d3d9, but
here are a few things I noticed:
> +hr = IDirect3DSurface9_LockRect(info->lpSurf, &lock, NULL,
> D3DLOCK_DISCARD);
> +assert(hr == S_OK);
...
> +hr = IDirect3DDevice9_Clear(This->d3d9_dev, 0, NULL, D3DCLEAR_TARGET,
>
2008/7/30 Chris Ahrendt <[EMAIL PROTECTED]>:
> I thought of moving the if statement which is at the bottom of the function
> to the begining as I am not sure why you would want to reassign the same
> value then check to see if it was the same..
>
> Why are you doing it that way?
>
Please be more ca
Looks good in principle, but I've still got a few comments:
> +if ( praydirection->x >= 0.0f )
> +{
> + tmin = ( pmin->x - prayposition->x ) / praydirection->x;
> + tmax = ( pmax->x - prayposition->x ) / praydirection->x;
> +}
...
> +if ( tmax < 0.0f ) return FALSE;
This w
2008/7/29 Alexandre Julliard <[EMAIL PROTECTED]>:
> It doesn't work here:
>
> ../../../tools/runtest -q -P wine -M d3d9.dll -T ../../.. -p d3d9_test.exe.so
> visual.c && touch visual.ok
> visual.c:8465: Tests skipped: D3DFMT_G16R16F textures not supported
> visual.c:8465: Tests skipped: D3DFMT_G32
2008/7/29 Vitaliy Margolen <[EMAIL PROTECTED]>:
> H. Verbeet wrote:
>> This should prevent setting an incorrect draw buffer when an FBO is active.
>>
>
> This patch breaks Psychonauts and possibly other multi-threaded games with
> OffscreenRendering=FBO on Nvidia har
2008/7/28 David Adam <[EMAIL PROTECTED]>:
> + ortho = D3DXVec3Dot(praydirection, &normal[i]);
> + if ( ortho && D3DXVec3Subtract(&difference, &point, prayposition) )
> + {
> + t = D3DXVec3Dot(&difference, &normal[i]) / ortho;
While correct, due to the fact that the box is axis-alig
2008/7/28 Aric Stewart <[EMAIL PROTECTED]>:
> I am unsure if you are thinking i should be concerned about the mirrored or
> flipped destinations as i will admit I have no idea what that entails.
>
I seem to remember that Blt allowed top > bottom and left > right in
the source and destination rectan
2008/7/28 Aric Stewart <[EMAIL PROTECTED]>:
> +if (Src != This)
> +{
> +xdst.top = 0;
> +xdst.bottom = DestRect->bottom - DestRect->top;
> +xdst.left = 0;
> +xdst.right = DestRect->right - DestRect->left;
> +}
This will still b
2008/7/28 Chris Ahrendt <[EMAIL PROTECTED]>:
> Problem with this is if any of the above values change for whatever reason
> then it breaks the verification. I agree for the most part that testing
> the range makes sense but I think in this case it is safer to do it this
> way. But if the general
2008/7/28 H. Verbeet <[EMAIL PROTECTED]>:
> 2008/7/27 David Adam <[EMAIL PROTECTED]>:
>> + ortho = D3DXVec3Dot(praydirection, &normal[i]);
>> + if ( ortho )
>> + {
>> + t = D3DXVec3Dot(praydirection, &normal[i]) / ortho;
> This
2008/7/27 David Adam <[EMAIL PROTECTED]>:
> + ortho = D3DXVec3Dot(praydirection, &normal[i]);
> + if ( ortho )
> + {
> + t = D3DXVec3Dot(praydirection, &normal[i]) / ortho;
This doesn't make much sense, t will always be close to zero this way.
> +rayposition.x = -3.0f; rayposi
2008/7/28 Chris Ahrendt <[EMAIL PROTECTED]>:
> Please comment on the attached patch and let me know what you think..
Almost all of my comments on the original patch still stand. In
addition, you're adding trailing spaces, and you've got an unnecessary
whitespace change in there.
2008/7/28 Stefan Dösinger <[EMAIL PROTECTED]>:
>> This enables the replacement pretty much unconditionally... do we want
>> that?
> I'd say so, unless we have evidence that it's a bad idea to do enable it
> somewhere, and the drawback isn't fixable.
>
I don't mind having it on by default, but I thi
2008/7/28 Stefan Dösinger <[EMAIL PROTECTED]>:
> Mostly because I've written this code before you mentioned them to me. I
> think it can't hurt to ask Alexandre if bitfields are ok to use in Wine.
> How's the support among compilers(older gcc versions? Non-gcc compilers like
> icc and msvc?)
>
Afai
2008/7/27 Stefan Dösinger <[EMAIL PROTECTED]>:
> Unfortunately, even despite the preparations in the last patches, this patch
> is still kinda huge because I have to replace all the fragment processing at
> once.
>
This enables the replacement pretty much unconditionally... do we want
that? It also
Is there any particular reason you're not simply using the compiler's
support for bit-fields?
2008/7/27 Chris Ahrendt <[EMAIL PROTECTED]>:
> Oh I also forgot... I believe that set render state is primarily called
> at the init of the app so should not overly effect the performance of
> the application.
Well, no, it pretty much gets called all the time.
> + /* Valid Values are betw
2008/7/27 Chris Ahrendt <[EMAIL PROTECTED]>:
> I did not copy and paste from MSDN.. I used the rules defined in the
> statelemt.. I can remove the comment if that is what you are talking
> about? But the code itself I did myself...
>
Documentation is copyrighted.
> --- device_old.c2008-07-25 11:42:25.0 -0400
> +++ device.c2008-07-26 21:07:45.0 -0400
Unrelated to the patch, but if you intend to work on Wine, I'd
strongly recommend you setup git first.
> +#define D3DBLEND_INVSRCCOLOR 4
You shouldn't use d3d8 or d3d9 definitions in win
2008/7/26 Allan Tong <[EMAIL PROTECTED]>:
> You could try the attached hack patch to see if it fixes the problem
> you're seeing. It completely ignores FBO cleanup, but it should avoid
> the driver bug.
>
It's not *that* easy. You'll need to adjust the code in
apply_fbo_state() as well. fbo_color_
2008/7/26 Vitaliy Margolen <[EMAIL PROTECTED]>:
> So if we need to create an fbo for each thread, does that mean that
> everything needs to be rebound to it on the context switch?
>
It would mostly mean that apply_fbo_state() would need to track things
per-context rather than per-device. I guess th
2008/7/25 Vitaliy Margolen <[EMAIL PROTECTED]>:
> Ok I think I see the problem:
> 0045:trace:d3d_surface:surface_load_ds_location before bind_fbo
> 0045:trace:d3d:bind_fbo 0x14f474 -> 0
> 0045:trace:d3d:bind_fbo glGenFramebuffersEXT() -> 2 @
> ../../../wine.git/dlls/wined3d/device.c:6084 call ok
>
2008/7/25 Vitaliy Margolen <[EMAIL PROTECTED]>:
> BTW this is a driver crash in libglcore.so with what appears to be a
> null-pointer dereference. I'm trying to play with your code to see how to
> "fix" it.
>
Thanks.
2008/7/25 Aric Stewart <[EMAIL PROTECTED]>:
> -IWineD3DSurface_LockRect(iface, &dlock, NULL, 0);
> +IWineD3DSurface_LockRect(iface, &dlock, DestRect, 0);
> dfmt = This->resource.format;
> slock = dlock;
I don't think you can simply insert DestRect there, unless it's
> The backtraces of the crash are attached in 12929 which is a general
> catch all for the ATI issues.
Well, no. 12929 is about a rather specific problem where fglrx crashes
when trying to use GL_ATI_envmap_bumpmap or GL_ATI_separate_stencil.
(And for what it's worth, that bug won't go anywhere unt
2008/7/24 Vitaliy Margolen <[EMAIL PROTECTED]>:
> side affects. But the full version of Psychonauts crashes after initial
> videos. Same as it did when we had problems with multi-threaded games.
>
Is that a regression introduced by the patch?
2008/7/23 David Adam <[EMAIL PROTECTED]>:
> +#include
> +#include
> +#include
> +#include
> +
> +#define NONAMELESSUNION
...
> +#include
I don't think you need those. (I should've noticed this in the first
patch, sorry for that.)
2008/7/24 Vitaliy Margolen <[EMAIL PROTECTED]>:
> 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
> 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
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
Right now it's simply broken of course. The extension being defined in
the header is no guarantee the driver actually supports it.
2008/7/21 Andrew Fenn <[EMAIL PROTECTED]>:
> Here's my uneducated idea about what's happening, it's calling the
> USER_SetWindowPos() in /user32/winpos.c to an x and y of 0 which goes off to
> SendMessageW.
>
> SendMessageW calls send_message which in turn calls call_window_proc. At
> this point so
2008/7/21 Andrew Fenn <[EMAIL PROTECTED]>:
> fixme:d3d9:IDirect3DDevice9Impl_Reset RESET DEVICE
> fixme:d3d_shader:shader_glsl_free FREE SHADER
> fixme:d3d:IWineD3DDeviceImpl_Reset BEFORE, hr: 0x
> fixme:d3d:IWineD3DDeviceImpl_Reset AFTER, hr: 0x
> fixme:d3d9:IDirect3DDevice9Impl_Re
2008/7/21 Stefan Dösinger <[EMAIL PROTECTED]>:
> Is the shader backend recreated properly after the reset?
>
Just to clarify, in dlls/wined3d/device.c, IWineD3DDeviceImpl_Reset(),
line 7355 there's a call to shader_alloc_private(). This call is
supposed to recreate This->shader_priv.
2008/7/17 Andrew Fenn <[EMAIL PROTECTED]>:
> Here's what I got from the debug log.
>
> Backtrace:
> =>1 0x7e43e9b3 shader_glsl_free+0x23(iface=0x19c4b8)
> [/home/andrew/wine/wine/dlls/wined3d/glsl_shader.c:3491] in wined3d
> (0x0032e918)
> 2 0x7e41f318 IWineD3DDeviceImpl_Reset+0x198(iface=0x19c4b
2008/7/17 Andrew Fenn <[EMAIL PROTECTED]>:
> Not sure, I just figured it was the program that was doing it? I'll try and
> figure it out and reply back to you as soon as I can.
>
Obvious candidates would be Reset or Uninit3D in device.c, but at
first sight those appear to be safe to call multiple t
2008/7/17 Andrew Fenn <[EMAIL PROTECTED]>:
> I noticed this function gets called twice when doing an alt+enter to full
> screen.
>
>From where?
2008/7/17 Andrew Fenn <[EMAIL PROTECTED]>:
> I added a check to make sure This->shader_priv wasn't null. Before
> Everquest2.exe would crash when I tried to alt+enter from windowed mode.
> This stops it crashing wine.
>
This->shader_priv shouldn't be NULL. It probably means the backend was
already
2008/7/16 Ivan Gyurdiev <[EMAIL PROTECTED]>:
> I don't know about that - a pointer called "is__supported"
> seems just as readable to me.
>
There's certainly the option to use that instead in the future, but
for the moment I think the single extension check should work well
enough for the majority
2008/7/14 Stefan Dösinger <[EMAIL PROTECTED]>:
>> As you note in your comment, most of this should go into wined3d. I
>> also think this should for the most part use the same code that is
>> used for CheckDeviceFormat in dlls/wined3d/directx.c. Roderick would
>> probably be able to help you best th
2008/7/14 Tobias Jakobi <[EMAIL PROTECTED]>:
> Hi there,
>
> this patchset fixes conformance of volumes/volumetextures creation (plus
> locking) in d3d8 and d3d9. Currently creating volumes/volumetextures
> always succeeds regardless of the usage and pool type specified.
>
> A testcase for both d3d
2008/7/10 James Hawkins <[EMAIL PROTECTED]>:
> If more people knew the answer to your question, it would probably be
> implemented by now :-) Usually the reason to move something into the
> server is to share common functionality, with each frontend (X11,
> quartz) augmenting that common backend w
Looks ok to me.
2008/7/7 Tobias Jakobi <[EMAIL PROTECTED]>:
>
The test doesn't get run this way. If it did it would fail of course,
so you should either submit the test after your second patch, or put
the ok that tests the pool type inside a todo_wine block and remove it
again in your second patch.
Looks good to me. You should probably start submitting it bit by bit,
see if any regression come up, although it looks pretty safe to me.
2008/7/3 Maarten Lankhorst <[EMAIL PROTECTED]>:
> - * Copyright 2007-2008 Stefan Dösinger for CodeWeavers
> + * Copyright 2007-2008 Stefan D�singer for CodeWeavers
You shouldn't be changing Stefan's name though.
2008/7/1 Massimo Del Fedele <[EMAIL PROTECTED]>:
> + if(NtCurrentTeb()->glContext == NULL)
> +return NULL;
> +
Alexandre said on IRC that you should probably use
wglGetCurrentContext() there, rather than using NtCurrentTeb()
directly.
2008/6/23 Roderick Colenbrander <[EMAIL PROTECTED]>:
> Hi,
>
> I don't think we should implement it this way. For instance on GeforceFX
> cards blending is performed in software. Not too long ago (before 1.0) I also
> sent a patch for this e.g. by doing an extension check. I think I checked for
2008/6/20 Tobias Jakobi <[EMAIL PROTECTED]>:
> However I think the comment should stay there. I don't think the MSDN
> docs are updated in the near future, at least what D3D9 is concerned
> (now that D3D10 is more and more used). So in case someone is wondering
> why the implementation of wine diff
2008/6/20 Tobias Jakobi <[EMAIL PROTECTED]>:
> Patch fixes a problem with the IDirect3DDevice8::CreateImageSurface
> implementation (wrong pool type of the returned surface object). This fixes
> savegame screenshot bugs (black images instead of game scenes) in both Max
> Payne and Max Payne 2.
>
>
2008/6/2 Stefan Dösinger <[EMAIL PROTECTED]>:
> Am Montag, 2. Juni 2008 21:12:54 schrieb H. Verbeet:
>> This fixes a rather major regression when using FBOs for offscreen
>> rendering. Since we destroy the GL texture associated with the
>> surface, and INDRAWABLE and
2008/6/2 Vitaliy Margolen <[EMAIL PROTECTED]>:
> This reverts commit 0de167db9e2ef6c62ba48b050bc3d0ba2638467f.
> Fixes bug 12794 and probably others related to the black screen with enabled
> FBO.
> ---
> dlls/wined3d/surface.c | 11 ++-
> 1 files changed, 2 insertions(+), 9 deletions(-)
2008/5/29 Stefan Dösinger <[EMAIL PROTECTED]>:
> However, windows has a DLL which allows apps to disable Aero manually, I think
> that's wdm.dll.
>
dwmapi.dll, iirc.
2008/5/26 Dmitry Timoshkov <[EMAIL PROTECTED]>:
> "Kai Blin" <[EMAIL PROTECTED]> wrote:
>
>> > > +{FROM_PROTOCOL_INFO, FROM_PROTOCOL_INFO},
>> > > };
>> >
>> > Although it was the case before, it's a mistake to have a comma after
>> > the last struct member initializer.
>>
>> It is? K&R seems
2008/5/24 Stefan Dösinger <[EMAIL PROTECTED]>:
> Am Samstag, 24. Mai 2008 10:33:42 schrieb H. Verbeet:
>> The color_match() function which this test introduces should be used
>> for the other visual tests that require an approximate match as well,
>> but doing this i
2008/5/21 Stefan Dösinger <[EMAIL PROTECTED]>:
> But I personally prefer installing the full runtime over copying the selected
> DLLs, because it provides a proper setup for the libraries, like
> self-registration, other libs like dplay, etc. Self-registration is
> especially important for directpl
2008/5/21 Stefan Dösinger <[EMAIL PROTECTED]>:
> I think the proper thing to do is to install the DirectX runtime /
> redistributable. It installs all the DLLs and registers them in the registry
> etc.
>
Isn't that what we're trying to avoid?
2008/5/21 Dan Kegel <[EMAIL PROTECTED]>:
> So... lots of people are going around installing
> all of directx, and maybe all they needed was, say,
> d3d9x_35. That's not good. This sounds like
> a job for winetricks!
> But I know nothing about direct3d. Could somebody
> have a look at this draft
2008/4/24 Stefan Dösinger <[EMAIL PROTECTED]>:
>
FWIW, for my texop test I wrote a function to do this in a generic
way. I'll probably submit that in the next few days.
On 22/04/2008, Austin English <[EMAIL PROTECTED]> wrote:
> -/* Declare loop registers aLx */
> +/* Declare loop registers alx */
> for (i = 0; i < reg_maps->loop_depth; i++) {
> shader_addline(buffer, "int aL%u;\n", i);
> shader_addline(buffer, "int tmpInt%u;\n", i);
On 19/04/2008, David Adam <[EMAIL PROTECTED]> wrote:
> This time, with tests for d3d8 and d3d9.
>
> David Adam
>
Looks mostly ok, but you do need a \n at the end of these ok messages:
> +ok(hr == D3DERR_INVALIDCALL, "Expected D3DERR_INVALIDCALL, got %s",
> DXGetErrorString8(hr));
> +ok(h
On 19/04/2008, David Adam <[EMAIL PROTECTED]> wrote:
> The Sting Demo calls the function
> IDirect3DDeviceImpl_7_SetMaterial (in ddraw/device.c) with
> Mat=NULL.
> Then, this makes the function IWineD3DDeviceImpl_SetMaterial (in
> wined3d/device.c) crashes in the line
> This->updateStateBlock->mate
On 19/04/2008, Stefan Dösinger <[EMAIL PROTECTED]> wrote:
> Am Samstag, 19. April 2008 02:36:39 schrieb H. Verbeet:
>
> > On 18/04/2008, Alexander Dorofeyev <[EMAIL PROTECTED]> wrote:
> > > Fixes massive slowdown in games like Aliens vs Predator 2.
> >
On 18/04/2008, Alexander Dorofeyev <[EMAIL PROTECTED]> wrote:
> Fixes massive slowdown in games like Aliens vs Predator 2.
>
If you care about performance you should always run with
WINEDEBUG="-all" anyway.
On 15/04/2008, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> +#ifndef __WINE_D3DX9TEX_H
> +#define __WINE_D3DX9TEX_H
...
> +#endif /* __WINE_D3DX9CORE_H */
I didn't look at the rest of the patch in detail, but the comment
there doesn't match the actual #ifndef.
On 12/04/2008, Stefan Dösinger <[EMAIL PROTECTED]> wrote:
> But since D3D vertex shaders always read the numbered arrays and fixed
> function always reads the named arrays the named arrays get de-facto replaced
> as far as we're concerned.
>
Which is completely irrelevant for classifying the oper
On 12/04/2008, Stefan Dösinger <[EMAIL PROTECTED]> wrote:
> Am Samstag, 12. April 2008 04:27:07 schrieb H. Verbeet:
> > Anything that gets ignored when a vertex shader is active gets put in
> > the vertex states, anything that gets ignored when a fragment shader
> >
On 12/04/2008, Stefan Dösinger <[EMAIL PROTECTED]> wrote:
> We have to face that driver bugs are reality. I think we are having more
> issues in form of user complaints due to the driver<->wined3d connection than
> the wined3d<->application one. I doubt Apple is going to fix their vertex
> shad
On 12/04/2008, Stefan Dösinger <[EMAIL PROTECTED]> wrote:
> > > 2) We want a fixed function vertex and fragment pipeline replacement
> > > with ARB and GLSL
> >
> > Only GLSL is a requirement for me. ARB could be nice, but is probably
> > redundant.
>
> Intel cards? Also GLSL has the problem
On 11/04/2008, Stefan Dösinger <[EMAIL PROTECTED]> wrote:
> 1) The state table should be selectable based on the available opengl
> features
> and possibly registry settings. I think we all agree on that
>
Up to the level of being able to use different state handlers in
different situations. I d
On 11/04/2008, Stefan Dösinger <[EMAIL PROTECTED]> wrote:
> Not really, many games check the MaxSimultaneousTextures cap and use that
> value even if they are using pixel shaders. E.g. HL2 fails in dxlevel 81 with
> that with ARB shaders because it checks that cap if it finds SM 1.x, and Age
> o
1 - 100 of 702 matches
Mail list logo
