2009/2/23 Austin English austinengl...@gmail.com:
+STDMETHOD(ApplyStateBlock)(THIS_ DWORD_PTR Token) PURE;
+STDMETHOD(CaptureStateBlock)(THIS_ DWORD_PTR Token) PURE;
+STDMETHOD(DeleteStateBlock)(THIS_ DWORD_PTR Token) PURE;
+STDMETHOD(CreateStateBlock)(THIS_
FWIW, I think the right way to fix this would be to use a handle table
like for shaders.
2009/2/24 Stefan Dösinger ste...@codeweavers.com:
+static void shader_glsl_gen_sample_code(const SHADER_OPCODE_ARG *arg, DWORD
sampler, const char *coord_reg,
+const glsl_sample_function_t
*sample_function, const char *dst_swizzle,
+
2009/3/3 Luis C. Busquets Pérez luis.busqu...@ilidium.com:
I have seen that Henri Verbeet has begun the implementation of
ID3D10Effect. Since there is a ID3DX9Effect interface I wonder of the
possibility of creating something like wined3deffect and refer
ID3DXEffect and ID3D10Effect
2009/3/3 James McKenzie jjmckenzi...@earthlink.net:
Can you please use standard compression programs with standard extensions.
Your file extension, .bin will not work here.
Although application/octet-stream might not be the best content type,
it's just text.
2009/3/9 Stefan Dösinger ste...@codeweavers.com:
Am Montag, 9. März 2009 14:36:57 schrieb Henri Verbeet:
- int VBO; /* Vertex buffer object this data is in */
+ unsigned int VBO; /* Vertex buffer object this data is in */
Wouldn't the really correct type be GLuint?
Yes
2009/3/11 Stefan Dösinger ste...@codeweavers.com:
Am Mittwoch, 11. März 2009 12:07:27 schrieb Paul Vriens:
+ ok(hr == D3D_OK ||
+ broken(hr == D3DERR_SCENE_IN_SCENE), /* W2K */
+ IDirect3DDevice7_BeginScene failed with %08x\n, hr);
I don't like that one. I think I wrote those
2009/3/11 Allan Tong acton...@gmail.com:
On Wed, Mar 11, 2009 at 5:18 AM, Henri Verbeet hverb...@codeweavers.com
wrote:
@@ -4051,10 +4097,11 @@ static void WINE_GLAPI diffuse_d3dcolor(const void
*data)
static void WINE_GLAPI specular_d3dcolor(const void *data)
{
DWORD specularColor
2009/3/12 Michael Stefaniuc mstef...@redhat.com:
I sent the patch out to provoke a better patch from somebody more
knowledgeable in that domain. Of course only if it's worth the effort;
until the advent of the netbooks with their odd screen size assuming
that 1024x768 will just work was good
2009/3/12 Erik Inge Bolsø knan-w...@anduin.net:
Hello!
I'd like a review of this patch - does the approach look reasonable? (Not
my code, but it fixes a bug I reported.)
Not in this form, although enabling GL_VERTEX_PROGRAM_POINT_SIZE is
something we should do. It needs to go either into
2009/3/14 Stefan Dösinger ste...@codeweavers.com:
The if check isn't that correct either.
If MAX_COMBINED_SAMPLERS = 8 + 3 everything's fine too. d3d9 only supports 8
fixed function frag samplers and 3 vertex samplers at max, so even if we
can't use all GL samplers together, we're still fine
2009/3/14 Mirek Slugeň thunde...@email.cz:
Hi, Fallout 3 and maybe other games or D3D apps needs such special
settings, this patch should be ok, it is well tested.
This patch is not hack!
You're leaking wined3d_settings.video_description and
wined3d_settings.video_driver.
Having an override
2009/3/18 Roderick Colenbrander thunderbir...@gmx.net:
Your email left me confused because you say implementing D3DXMesh is
small however towards the end of your email say it is a large job.
Surely having something small is good for SoC projects, no?
D3DX is huge and D3DXMesh is a small part
2009/3/22 James Hawkins trui...@gmail.com:
---
dlls/wined3d/vertexshader.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
I guess the nicer way to make Coverity shut up would be to replace
if(shader-gl_shaders) { with if (shader-num_gl_shaders).
Wouldn't the code in
2009/3/23 Chris Robinson chris.k...@gmail.com:
I wouldn't recommend this patch as being very safe. Having dealt with ffmpeg,
my experience has been that it's ABI is not stable (the .so version number
increments often, forcing recompilations). And when trying to update to new
lib versions,
2009/3/23 Tobias Jakobi liquid.a...@gmx.net:
+if (prog-ps_args.texrect_fixup) {
+for (i = 0; i MAX_FRAGMENT_SAMPLERS; ++i) {
Using something like the following would avoid checking the entire
prog-rectFixup_location array when only the first few samplers are
used:
2009/3/23 Tobias Jakobi liquid.a...@gmx.net:
+if (!use_ps(stateblock) ||
(stateblock-wineD3DDevice-shader_backend != glsl_shader_backend)) {
Checking which backend is used is pretty ugly.
2009/3/24 Florian Köberle flor...@fkoeberle.de:
Pointers can get invalid when the table gets moved in memory.
This can happen when the table grows.
Did you actually see this happen? The table is only supposed to grow
when there are no free handles.
2009/3/24 Florian Köberle flor...@fkoeberle.de:
+ if (handle_idx 0 || handle_idx = schan_handle_count)
handle_idx can't be 0 because it's unsigned. Printing an ERR if the
handle is out of range is probably ok, but I think crashing is better
than just returning NULL.
2009/3/26 Stefan Dösinger stefandoesin...@gmx.at:
I think position2 and normal2 are used with fixed function tweening.
Yes, but that's not actually implemented. If we ever do implement that
in a shader we'll need to fit it into the existing 16 attributes. We'd
probably have to make the mapping
2009/3/26 Stefan Dösinger stefandoesin...@gmx.at:
Doesn't that mix up named and numbered attributes?
No, not really. The only reason the code had to use named attributes
before was that there were more named attributes than could be indexed
through the array.
2009/3/27 David Adam david.adam.c...@gmail.com:
Fixes bug 16846.
Could you include the test as well?
2009/3/25 Allen Hair allen.h...@gmail.com:
Attached is a patch that will add our code to the source tree. This
patch is not meant to be
committed, but should provide a demonstration of the application so
far. Any feedback would be
appreciated, I will try to incorporate any suggestions as I
2009/3/27 Allan Tong acton...@gmail.com:
+ if (check_fbo_compat(gl_info,
gl_formats_template[src].glInternal))
+ {
+ TRACE(Internal format of %s not supported as FBO target,
using render target internal instead\n,
+
2009/3/28 Stefan Dösinger stefandoesin...@gmx.at:
Am Samstag, 28. März 2009 14:58:28 schrieb Stefan Dösinger:
Am Samstag, 28. März 2009 14:39:15 schrieb David Adam:
+ hrc = IWineD3DDeviceImpl_CreateSurface(iface,
...
+ This-parent);
You'll have to use a callback
2009/3/29 Paul TBBle Hampson paul.hamp...@pobox.com:
fixme:d3d_surface:surface_upload_data GL_INVALID_VALUE
(0x501) from glTexSubImage2D @ ../../../dlls/wined3d/surface.c / 349
These are a problem, I think.
2009/3/29 Stefan Dösinger stefandoesin...@gmx.at:
Its probably a reasonable goal to
2009/3/29 David Adam david.adam.c...@gmail.com:
+ hrc =
IWineD3DDeviceParent_CreateDepthStencilSurface(This-device_parent,
+ NULL,
+ pPresentationParameters-BackBufferWidth,
+ pPresentationParameters-BackBufferHeight,
+
2009/3/29 David Adam david.adam.c...@gmail.com:
-return WINED3DERR_INVALIDCALL;
+ HRESULT hrc;
You're still using 9 space indentation.
2009/3/30 John Whitlock john-whitl...@ieee.org:
This patch adds the ability to specify the name and driver for the video
card using registry keys (Current_user/Software/Wine/Direct3D). This is
similar to existing code in wined3d, and has been used since 1.1.8 to get
Fallout 3 working.
Either
2009/3/30 Paul TBBle Hampson paul.hamp...@pobox.com:
Any suggestions on the work that is needed? Apart from the above
GL_INVALID_VALUE, I'm unaware of any failures apart from it being slow.
I'd need to do a proper review, but eg. can_convert_d3dcolor is
something that needs a bit more thought
2009/3/30 Stefan Dösinger ste...@codeweavers.com:
-hr = IWineD3DDevice_CreateBuffer(This-wined3d_device, wined3d_desc,
-(IUnknown *)object, object-wined3d_buffer);
+hr = IWineD3DDevice_CreateBuffer(This-wined3d_device, desc-ByteWidth,
+desc-Usage, 0,
2009/4/3 Austin English austinengl...@gmail.com:
I'm not sure what the dwbuildnumber should be, I can't find that
information anywhere...Anywho, this should work.
RC1 was 0x1b9c, I think. The final build number isn't known yet, of
course, which is also a reason why it doesn't make sense to add
2009/4/3 Austin English austinengl...@gmail.com:
On Fri, Apr 3, 2009 at 3:06 PM, Henri Verbeet hverb...@gmail.com wrote:
2009/4/3 Austin English austinengl...@gmail.com:
I'm not sure what the dwbuildnumber should be, I can't find that
information anywhere...Anywho, this should work.
RC1
2009/4/5 Austin English austinengl...@gmail.com:
Again, the same argument can be made for native dlls. Tons of
tutorials recommend setting just about every dll to native, and
winecfg allows this. Should we not allow people to set more than 3
dlls to native?
You could certainly make an
2009/4/5 Stefan Dösinger ste...@codeweavers.com:
After a discussion on #winehackers I want to add something for the archives:
This is a situation that cannot be solved in d3d9 alone, a fix has to involve
wined3d. This is because there is a hidden reference kept on every object
that is
2009/4/6 Stefan Dösinger ste...@codeweavers.com:
That was my suggestion. We already keep a wined3d-internal refcount for all
these objects(shaders, textures, ...), and my plan was a callback
function(maybe provided via a COM interface, similar to the
WineD3DDeviceParent one). Some time ago I
Personally I would've eliminated the implementation differences first
(the main difference is when the data is copied, unmap vs. preload),
and then just killed IWineD3DIndexBufferImpl once they were the same
from an implementation point of view. Eg., you can ignore the
conversion if you can prove
2009/4/4 Stefan Dösinger ste...@codeweavers.com:
-hr = IWineD3DDevice_CreateBuffer(This-wined3d_device, wined3d_desc,
-data ? data-pSysMem : NULL, (IUnknown *)object,
object-wined3d_buffer);
+hr = IWineD3DDevice_CreateBuffer(This-wined3d_device, 0 /* fvf */,
+
2009/4/4 Stefan Dösinger ste...@codeweavers.com:
+pDesc-Usage = pDesc-Usage;
+pDesc-Pool = pDesc-Pool;
+pDesc-Size = pDesc-Size;
This is just silly.
2009/4/4 Stefan Dösinger ste...@codeweavers.com:
+WINED3DRESOURCETYPE WineD3DRType;
TRACE((%p)-(%d, %d, %d, %08x, %d, %d)\n, This, Adapter, DeviceType,
AdapterFormat, Usage, RType, CheckFormat);
+switch(RType) {
+case D3DRTYPE_VERTEXBUFFER:
+case
2009/4/7 John Whitlock john-whitl...@ieee.org:
+HeapFree(GetProcessHeap(), 0, wined3d_settings.video_driver);
+HeapFree(GetProcessHeap(), 0, wined3d_settings.video_description);
This should be part of the first patch. (And if you're going to resend
anyway, I think it makes more sense to
2009/4/7 Vincent Povirk madewokherd+8...@gmail.com:
On Mon, Apr 6, 2009 at 9:15 PM, Chris Robinson chris.k...@gmail.com wrote:
On Monday 06 April 2009 6:58:31 pm Vincent Povirk wrote:
On Mon, Apr 6, 2009 at 8:53 PM, Chris Robinson chris.k...@gmail.com wrote:
Isn't that the python test's
2009/4/9 Stefan Dösinger ste...@codeweavers.com:
+hr = IWineD3DDevice_SetIndices(This-wineD3DDevice, This-indexbuffer,
+ WINED3DFMT_R16_UINT /* d3d7 uses uints
*/);
The comment is inconsistent with the code (and probably redundant to
begin with).
2009/4/9 Stefan Dösinger ste...@codeweavers.com:
@@ -197,7 +197,6 @@ static HRESULT WINAPI
IDirect3DVertexBuffer9Impl_GetDesc(LPDIRECT3DVERTEXBUFFER9
pDesc-Usage = desc.Usage;
pDesc-Pool = desc.Pool;
pDesc-Size = desc.Size;
-pDesc-FVF = desc.FVF;
2009/4/9 Stefan Dösinger ste...@codeweavers.com:
Please do not apply this patch without patches 5, 6, 7 and 8. In some
circumstances, this patch can step on the toes of inefficient MacOS drivers
or old fglrx versions. The additional patches give wined3d knowledge of these
driver problems to
There are a couple of things I don't like about this patch.
- I don't like how much information specific to constant fixups the
table contains.
- The apple field is weird. If you're going to have a callback
function you might as well match that information there, if
appropriate. On the other hand,
2009/4/9 Stefan Dösinger ste...@codeweavers.com:
+unsigned max_constantsF;
This is valid C, of course, but would the extra 4 characters for int
really hurt?
2009/4/9 Stefan Dösinger ste...@codeweavers.com:
if(pshader) {
-max_constantsF = GL_LIMITS(pshader_constantsF) - (MAX_CONST_B /
4) - MAX_CONST_I - 2;
-max_constantsF = min(This-baseShader.limits.constant_float,
max_constantsF);
+/* No indirect
2009/4/8 Vincent Povirk vinc...@codeweavers.com:
This should fix bug 15789.
Stefan tells me that we're supposed to update the screen when the front
buffer is unlocked, as that means it could have changed. Instead, we do it
when any buffer in the swapchain is unlocked. This makes for a lot
2009/4/12 Stefan Dösinger ste...@codeweavers.com:
I accidentally deleted the mail in my inbox, so that reply is without a proper
in-reply-to tag. Here's the archive for reference:
http://www.winehq.org/pipermail/wine-devel/2009-April/074718.html
- I don't like how much information specific to
2009/4/15 Stefan Dösinger ste...@codeweavers.com:
+void record_const_read(DWORD reg, unsigned int *array, int *num) {
+int r;
+BOOL inc = TRUE;
+for(r = 0; r *num; r++) {
+if(array[r] == reg) {
+inc = FALSE;
+break;
+}
+}
+
+
2009/4/15 Stefan Dösinger ste...@codeweavers.com:
Am Mittwoch, 15. April 2009 09:36:46 schrieb Henri Verbeet:
2009/4/15 Stefan Dösinger ste...@codeweavers.com:
+void record_const_read(DWORD reg, unsigned int *array, int *num) {
+ int r;
+ BOOL inc = TRUE;
+ for(r = 0; r *num; r
2009/4/18 Ben Klein shackl...@gmail.com:
Right now, there's one thing bugging me: bug 14939. If Dan (or others)
would like to implement a method of deferring S3TC texture
decompression to the appropriately licensed GPU, assuming there are no
legal issues with this, I'd be ecstatic. But I'm
2009/4/19 Stefan Dösinger stefandoesin...@gmx.at:
the code checked out currently, so I can't check. Maybe the calls and the
implementation match and just the .idl prototype is different.
Yeah, only the idl was wrong (but compatible).
2009/4/19 Christian Costa titan.co...@wanadoo.fr:
@@ -760,6 +760,8 @@ IDirect3DViewportImpl_AddLight(IDirect3DViewport3 *iface,
lpDirect3DLightImpl-activate(lpDirect3DLightImpl);
}
+IDirect3DLight_AddRef(lpDirect3DLight);
+
LeaveCriticalSection(ddraw_cs);
return
2009/4/20 James McKenzie jjmckenzi...@earthlink.net:
What compiler was complaining about the static inline problem? Your
solution may cause problems with other compilers.
More specifically, you need to protect this with an #ifdef.
E.g.:
#ifdef __GNUC__
#define __WINE_ATTR_UNUSED
2009/4/20 Detlef Riekenberg wine@web.de:
Support for compiler specific features should be tested during
configure.
What would that look like, approximately?
2009/4/21 Tobias Jakobi liquid.a...@gmx.net:
+struct ps_np2fixup_t {
+unsigned char idx[MAX_FRAGMENT_SAMPLERS]; /* indices to the real
constant */
+GLfloat*const_cache; /* constant cache for fast reloading
(without readback) */
+WORDswz; /* bitfield used
2009/4/22 Tobias Jakobi liquid.a...@gmx.net:
- Why is this in struct ps_compiled_shader? This really looks like
something that should be internal to the backend.
No, that's definitely not the case.
The struct's data is used both in GLSL and ARB mode (I'll submit the ARB
patches later) - so it
2009/4/22 Tobias Jakobi liquid.a...@gmx.net:
Henri Verbeet wrote:
Sure, but it's still internal bookkeeping of the backends. Everything
the backend needs from the outside world is the np2_fixup field from
struct ps_compile_args.
For ARB mode this is essential since something like
2009/4/23 Tobias Jakobi liquid.a...@gmx.net:
ps_np2fixup_t is still stored in ps_compiled_shader and I have no intention
to change this, since the ARB code is going to use the exact same structure.
NAK
2009/4/24 Stefan Dösinger stefandoesin...@gmx.at:
Am Freitag, 24. April 2009 09:21:23 schrieb Henri Verbeet:
Did you test this? What if the shader starts with a comment?
It doesn't make sense to try and parse a shader before knowing what
version it is. Besides, this is consistent
Not my preferred fix, but I suppose it works.
@@ -359,6 +359,7 @@ static HRESULT WINAPI
IDirect3DDevice8Impl_GetDeviceCaps(LPDIRECT3DDEVICE8 iface
if(pCaps-VertexShaderVersion D3DVS_VERSION(1,1)){
pCaps-VertexShaderVersion = D3DVS_VERSION(1,1);
}
+
2009/4/27 ace102 mgav...@juno.com:
Is this by design or just something that slipped through the cracks?
Thought I should alert someone just in case.:)
That's broken, but fortunately we don't use it. I'll write a patch,
thanks for mentioning this.
2009/4/28 Stefan Dösinger ste...@codeweavers.com:
I think this is getting pretty rediculous. I think we should either
just always print the infolog, or give the infolog its own debug
channel and make this a WARN.
2009/4/28 Stefan Dösinger ste...@codeweavers.com:
+/* What good are texrect grad functions? I don't know,
but GL_EXT_gpu_shader4 defines them.
+* There is no GL_ARB_shader_texture_lod spec yet, so I
don't know if they're defined there
+
2009/4/28 Stefan Dösinger ste...@codeweavers.com:
Am Dienstag, 28. April 2009 17:24:55 schrieb Henri Verbeet:
I think this is getting pretty rediculous. I think we should either
just always print the infolog, or give the infolog its own debug
channel and make this a WARN.
I disagree. Having
2009/4/28 Stefan Dösinger ste...@codeweavers.com:
Google magic. There's a blog entry on the OpenGL page describing the aim of
the extension, and there are other pages hinting that the functions work the
same way as those in GL_EXT_gpu_shader4, just with an ARB suffix instead of
an EXT.
As
2009/4/29 Massimo Del Fedele m...@veneto.com:
I didn't look at Direct3d 10, but I guess he don't affect zillions
of apps, does it ? DX10 -- Vista, and (AFAIK) most DX apps still use
9.
D3D10 itself isn't used that much yet, most current D3D10 applications
also have a D3D9 renderer. However, our
+reg_maps-constf = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY,
+ sizeof(*reg_maps-constf) * (constf_size /
(sizeof(*reg_maps-constf) * 8) + 1));
This is flawed, it will allocate too much memory. You essentially want
(bit_count + 31) / 32 to calculate the
2009/5/5 Stefan Dösinger ste...@codeweavers.com:
+ * quirk only enables point sprites on the first texture unit. This keeps
point sprites working in
+ * most games, but avoids the crash
...and on the other ones it will create hard to diagnose / explain
bugs. Just disabling the extension if
2009/5/6 Francois Gouget fgou...@free.fr:
On Wed, 6 May 2009, Henri Verbeet wrote:
[...]
I also *still* think us working around AMD's bugs is the wrong
approach. Of course it would also help if AMD took these kind of
things seriously, or at least replied to my posts
(http://www.phoronix.com
2009/5/6 Stefan Dösinger ste...@codeweavers.com:
Am Mittwoch, 6. Mai 2009 10:10:07 schrieb Henri Verbeet:
...and on the other ones it will create hard to diagnose / explain
bugs. Just disabling the extension if it's broken also avoids the
crash, and will at least have predictable behaviour
2009/5/6 Henri Verbeet hverb...@gmail.com:
Mesa (that includes e.g. the intel and radeon drivers) is generally
responsive to bug reports, as is NVIDIA. It's really just AMD and
Apple that are problematic wrt. getting bugs fixed.
Just for the record, I'm not trying to just make AMD look bad
2009/5/7 Stefan Dösinger stefandoesin...@gmx.at:
Am Donnerstag, 7. Mai 2009 16:39:19 schrieb Henri Verbeet:
I don't see an issue with the code in this patch, but did you find out
anything new regarding the geforce 8 immval handling in the Nvidia driver?
Remember the issue where my more
2009/5/9 Remco remc...@gmail.com:
2009/5/9 Ben Klein shackl...@gmail.com:
Still not your problem? Still feeling bullied, but this time by the
mailing list server?
I don't believe your earlier mains have been resent. I certainly
haven't received them.
My Gmail account tells me that all
2009/5/9 Nicklas Börjesson nicklas.borjes...@ws.se:
When you're not subscribed to the list, your posts have to go through
moderation. Sometimes that can take a while.
I do subscribe to the list(and did, from the beginning).
Or maybe subscription is more than registering to the mailing list?
2009/5/11 Robert Key hpestile...@gmail.com:
Changelog:
* This adds a quirk to change the default max varying value from
68 to 48 on ATI dx10 cards that use fglrx because a declaration
of 17 varying vec4s causes shaders not to render and using
48 (12 varyings vec4s) works for HD2000 to
2009/5/11 Kai Blin kai.b...@gmail.com:
I seriously dislike the tone this mailing list keeps taking recently.
In case it means anything to anyone, I agree.
2009/5/11 Joerg Mayer jma...@loplof.de:
As I think that Alexandre has stated his preference (and I can understand
him taking a long term view), I want to ask the packagers for the distros
out there: Would it be OK for you to add the necessary patch into the
code that you distribute.
2009/5/11 Scott Ritchie sc...@open-vote.org:
Henri Verbeet wrote:
2009/5/11 Joerg Mayer jma...@loplof.de:
As I think that Alexandre has stated his preference (and I can understand
him taking a long term view), I want to ask the packagers for the distros
out there: Would it be OK for you
2009/5/12 Stefan Dösinger ste...@codeweavers.com:
ps_1_3 uses Tx to pass in texture coordinates, but also as temporary
registers. ps_1_4 and ps_2_0 only use them for texture coordinates. This patch
gets rid of the Tx = fragment.texcoord[x] assign in all shader versions, and
doesn't even
2009/5/12 Stefan Dösinger stefandoesin...@gmx.at:
Am Dienstag, 12. Mai 2009 21:17:10 schrieb Henri Verbeet:
I'm probably missing something obvious, but with pre-1.4 texcoord
registers being read-write, what happens when you write to the
register before using it to sample a texture?
Nothing
2009/5/22 Tony Wasserka tony.wasse...@freenet.de:
Hi everyone,
I'm working on implementing D3DXLoadSurfaceFromFileInMemory right now,
but I've got a problem. The function
most convert a loaded surface's data to a user specified surface format
(I did not yet find a way to do it elsehow,
2009/5/25 Remco remc...@gmail.com:
Oh great, now there is poison on slashdot:
http://tech.slashdot.org/article.pl?sid=09/05/24/2044239
Let's not fork, shall we?
Out of pure curiosity, does anyone know if this Elektroschock guy
has a real name?
Personally I don't see a lot of dissatisfaction
2009/5/26 Pavel Prochazka proch...@inf.upol.cz:
+»··int i=1;
+
+»··/*it moves all backbuffers by 1 to left form id = 1,
+»··the backbuffer swap to frontbuffer and frontbuffer swaps to the end
of chain
+»··Something like this:
2009/5/30 Stefan Dösinger stefandoesin...@gmx.at:
Am 30.05.2009 um 07:24 schrieb Dmitry Timoshkov:
Rico Schüller kgbric...@web.de wrote:
- /* version info? */
- skip_dword_unknown(ptr, 2);
+ /* Compiled target version (e.g. fx_4_0=0xfeff1001,
fx_4_1=0xfeff1011). */
+
this would be better as inline functions, at least
until it stabilizes. We don't want to change the libwine interface any
more than strictly necessary.
How about something like the attached patch?
commit 2d1c3777494fe7bf31283c4c51ced3ea83093d2c
Author: Henri Verbeet hverb...@codeweavers.com
Date
Alexandre Julliard wrote:
Yes, that looks fine. It would probably look nicer to merge the
allocator and the compare function into a single structure, and just
store a pointer to it like a vtbl; but that's a minor detail.
It's easy enough to store a pointer to the allocator instead of making a
2009/6/4 Paul Vriens paul.vriens.w...@gmail.com:
Is there another way you can detect whether some XP (and up) tests can
be run? We generally try not to use GetVersion() in our tests.
Just a guess, but XP's screen color depth of 32bpp might be
significant here. If that's the case you'd also
Alexandre Julliard wrote:
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:7572: Tests skipped: Card has unconditional pow2 support, skipping
conditional NP2 tests
visual.c:9686: Test failed: Input
2009/6/6 Kovács András and...@csevego.net:
wine: Unhandled page fault on read access to 0x0018 at address
0x7c71fb02 (thread 0009), starting debugger...
Unhandled exception: page fault on read access to 0x0018 in 32-bit
code (0x7c71fb02).
Register dump:
CS:0073 SS:007b DS:007b
2009/6/6 James McKenzie jjmckenzi...@earthlink.net:
This appears to be a revisit of the deadlocking issue as reported in bug
14746, but according to another triage person, this is not so. I would like
to know if code has been moved from x11drv.c to d3d9_main.c that would cause
this error
2009/6/6 Jeff Zaroyko jeffzaro...@gmail.com:
+ liRegister an account on the Wine bugzilla with the email address you use
to send patches.
Why would I do that?
2009/6/6 Jeff Zaroyko jeffzaro...@gmail.com:
On Sat, Jun 6, 2009 at 7:00 PM, Henri Verbeethverb...@gmail.com wrote:
2009/6/6 Jeff Zaroyko jeffzaro...@gmail.com:
+ liRegister an account on the Wine bugzilla with the email address you
use to send patches.
Why would I do that?
Just so that
2009/6/6 Jerome Leclanche adys...@gmail.com:
Would it be a good/stupid idea to check for fglrx during wineboot, and
set OSRM to a different value than fbo?
That's essentially what blacklisting EXT_framebuffer_object would do,
although during wined3d initialization, not wineboot. We want to
2009/6/6 Stefan Dösinger stefandoesin...@gmx.at:
Hmm. Does fglrx support this extension at all?
http://bugs.winehq.org/attachment.cgi?id=21581
That's attached to bug 18794.
2009/6/6 Milan Kostić smoki00...@gmail.com:
Deafulting to fbo is good, but it should be more good to leave also
prior working support for backbuffer on older cards who not have
EXT_framebuffer_object. Reverting to
OffscreenRenderingMode=backbuffer is not working as expected for
me on r200
I think the actual patch is missing.
2009/6/7 Stefan Dösinger ste...@codeweavers.com:
+/* Not reentrant! */
+static inline const int *get_int_const(const struct
wined3d_shader_instruction *ins, IWineD3DBaseShaderImpl *This, DWORD idx)
+{
+BOOL vshader =
1 - 100 of 1460 matches
Mail list logo
