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++ comment
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 you
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)
+{
+num =
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 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. Which
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 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/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't
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 before
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.
Also:
+
2008/8/3 Alexander Dorofeyev [EMAIL PROTECTED]:
H. Verbeet wrote:
+IWineD3DDeviceImpl_MarkStateDirty(This,
STATE_RENDER(WINED3DRS_SCISSORTESTENABLE));
+
+glDisable(GL_BLEND);
+IWineD3DDeviceImpl_MarkStateDirty(This,
STATE_RENDER(WINED3DRS_ALPHABLENDENABLE));
Don't you need
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/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]:
+/* 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 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
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/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/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/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.
You'll need to modify stretch_rect_fbo() as well.
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?
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 will break if
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 careful
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,
Looks ok to me.
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 :-)
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 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 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, and
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 hardware.
I thought you said
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_G32R32F
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?)
Afaik
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 think it
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/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; rayposition.y =
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 doesn't make much sense, t will always be close to zero this way
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 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 break the
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 rectangles,
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-aligned, this
--- 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
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.
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 between 0
Is there any particular reason you're not simply using the compiler's
support for bit-fields?
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/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 that
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.
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
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
same
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/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.
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 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_INVALID_ENUM (0x500) @
2008/7/23 David Adam [EMAIL PROTECTED]:
+#include stdio.h
+#include stdlib.h
+#include stdarg.h
+#include assert.h
+
+#define NONAMELESSUNION
...
+#include assert.h
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]:
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/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 TRUE\n);
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/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_Reset
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 something
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/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/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]:
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
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=0x19c4b8,
2008/7/16 Ivan Gyurdiev [EMAIL PROTECTED]:
I don't know about that - a pointer called is_something_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
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 d3d8 and
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 there, but
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 with
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 ok to me.
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 differs
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 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(-)
I've
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 INTEXTURE are the same for offscreen
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? KR seems to use both, so I preferred
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 is outside the scope of this patch.
Dan
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 and see
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 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 directplay,
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);
As can be
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-material =
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(hr ==
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 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.
If you care about performance you should always run
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:
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
is active should be part
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
On 11/04/2008, Stefan Dösinger [EMAIL PROTECTED] wrote:
Am Freitag, 11. April 2008 00:31:13 schrieb Stefan Dösinger:
The drawback of this is that now the workaround for the mesa atifs bug
minimally affects nvidia cards too. It's a bit tricky to design around
driver bugs :-/
Use this
On 11/04/2008, Stefan Dösinger [EMAIL PROTECTED] wrote:
This patch doesn't make sense at all. Wasn't ATIFS supposed to be an
implementation of fixed function fragment processing for ATI cards? In
that case it doesn't make sense to only use it on cards that don't
support ARB or GLSL.
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
of
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 don't
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 with the link
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
shader bugs
1 - 100 of 665 matches
Mail list logo
