2009/1/30 Dan Kegel :
> Do you see any harm in using nasm? I can't imagine
> it would be hard to update our list of build dependencies,
> and if anybody doesn't have it for some reason, no harm done...
>
Would gas work?
2009/2/14 Stefan Dösinger :
> +const char *debug_surflocation(DWORD flag) {
> +switch(flag & SFLAG_LOCATIONS) {
> +case SFLAG_INSYSMEM:return "SFLAG_INSYSMEM";
> +case SFLAG_INDRAWABLE: return "SFLAG_INDRAWABLE";
> +case SFLAG_INTEXTURE: return "SFLAG_INTEXTURE";
2009/2/14 Stefan Dösinger :
> +SRGB_DONTKNOW = 0,/* Uses the cached
> value(e.g. external calls) */
SRGB_ANY or SRGB_EITHER is probably a nicer name. Do the enum elements
need explicit values? You can probably drop the typedef as well, I
don't think it adds anythi
2009/2/18 Jérôme Gardou :
> Out of curiosity, would moving to this sort of architecture
> http://msdn.microsoft.com/en-us/library/ms799715.aspx be possible? That
> may give manufacturer the possibility to develop wine-direct3d drivers
> and support what wine does not support. This would require a m
2009/2/19 Stefan Dösinger :
> Am Donnerstag, 19. Februar 2009 17:03:37 schrieb Henri Verbeet:
>
> I haven't looked at all the different formats yet, just a general question:
> Why did you choose to keep the WINED3D formats and not use the DXGI formats
> in wined3d? I'
2009/2/23 Austin English :
> +STDMETHOD(ApplyStateBlock)(THIS_ DWORD_PTR Token) PURE;
> +STDMETHOD(CaptureStateBlock)(THIS_ DWORD_PTR Token) PURE;
> +STDMETHOD(DeleteStateBlock)(THIS_ DWORD_PTR Token) PURE;
> +STDMETHOD(CreateStateBlock)(THIS_ D3DSTATEBLOCKTYPE Type,DWORD_PTR *
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 :
>
> +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" :
> 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 :
> 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 :
> 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?
2009/3/11 Stefan Dösinger :
> 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 tests on Win2K
2009/3/11 Allan Tong :
> On Wed, Mar 11, 2009 at 5:18 AM, Henri Verbeet
> wrote:
>
>> @@ -4051,10 +4097,11 @@ static void WINE_GLAPI diffuse_d3dcolor(const void
>> *data)
>> static void WINE_GLAPI specular_d3dcolor(const void *data)
>> {
>> DWOR
2009/3/12 Michael Stefaniuc :
> 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 enough.
>
My EeeP
2009/3/12 Erik Inge Bolsø :
> 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
shader_glsl_select()
2009/3/14 Stefan Dösinger :
> 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 if we have 11 sam
2009/3/14 Mirek Slugeň :
> 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 would be ok, b
2009/3/18 Roderick Colenbrander :
>> 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 of it but I
2009/3/22 James Hawkins :
> ---
> 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 find_gl_pshader() in
2009/3/23 Chris Robinson :
> 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, things sometimes myst
2009/3/23 Tobias Jakobi :
>
> +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:
DWORD fixup = pro
2009/3/23 Tobias Jakobi :
> +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 :
> 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 :
> + 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 :
> 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 from fixed function attr
2009/3/26 Stefan Dösinger :
> 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 :
> Fixes bug 16846.
>
Could you include the test as well?
2009/3/25 Allen Hair :
> 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 work on
> releasin
2009/3/27 Allan Tong :
>> + 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",
>> + debug_d3dformat(gl_
2009/3/28 Stefan Dösinger :
> 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 function s
2009/3/29 Paul TBBle Hampson :
> 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 :
> Its probably a reasonable goal to get this in, but disabled
2009/3/29 David Adam :
> + hrc =
> IWineD3DDeviceParent_CreateDepthStencilSurface(This->device_parent,
> + NULL,
> + pPresentationParameters->BackBufferWidth,
> + pPresentationParameters->BackBufferHeight,
> + pPresentationPar
2009/3/29 David Adam :
> -return WINED3DERR_INVALIDCALL;
> + HRESULT hrc;
You're still using 9 space indentation.
2009/3/30 John Whitlock :
> 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 you didn't write
2009/3/30 Paul TBBle Hampson :
> 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 to be properly inte
2009/3/30 Stefan Dösinger :
> -hr = IWineD3DDevice_CreateBuffer(This->wined3d_device, &wined3d_desc,
> -(IUnknown *)object, &object->wined3d_buffer);
> +hr = IWineD3DDevice_CreateBuffer(This->wined3d_device, desc->ByteWidth,
> +desc->Usage, 0, WINED3DFMT_UNKNOWN, WIN
2009/4/3 Austin English :
> 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 thise
before it's act
2009/4/3 Austin English :
> On Fri, Apr 3, 2009 at 3:06 PM, Henri Verbeet wrote:
>> 2009/4/3 Austin English :
>>> I'm not sure what the dwbuildnumber should be, I can't find that
>>> information anywhere...Anywho, this should work.
>>>
>>
2009/4/5 Austin English :
> 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 argument for not allowing
2009/4/5 Stefan Dösinger :
> 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 referenced in any statebl
2009/4/6 Stefan Dösinger :
> 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 thought you weren't
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 i
2009/4/4 Stefan Dösinger :
> -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 */,
> +WINED3DFMT_V
2009/4/4 Stefan Dösinger :
> +pDesc->Usage = pDesc->Usage;
> +pDesc->Pool = pDesc->Pool;
> +pDesc->Size = pDesc->Size;
This is just silly.
2009/4/4 Stefan Dösinger :
> +WINED3DRESOURCETYPE WineD3DRType;
> TRACE("(%p)->(%d, %d, %d, %08x, %d, %d)\n", This, Adapter, DeviceType,
> AdapterFormat, Usage, RType, CheckFormat);
>
> +switch(RType) {
> +case D3DRTYPE_VERTEXBUFFER:
> +case D3DRTYPE_INDEXBUFFER:
> +
2009/4/7 John Whitlock :
> +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 do the autodetection
2009/4/7 Vincent Povirk :
> On Mon, Apr 6, 2009 at 9:15 PM, Chris Robinson wrote:
>> On Monday 06 April 2009 6:58:31 pm Vincent Povirk wrote:
>>> On Mon, Apr 6, 2009 at 8:53 PM, Chris Robinson wrote:
>>> > Isn't that the python test's fault, then? Why can't c:\bin\sh exist?
>>>
>>> On a real wind
2009/4/9 Stefan Dösinger :
> +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 :
> @@ -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;
> pDesc->Type
2009/4/9 Stefan Dösinger :
> 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 prevent this.
>
If th
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 :
> +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 :
> 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 addressing here *
2009/4/8 Vincent Povirk :
> 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 of
> unnecessary co
2009/4/12 Stefan Dösinger :
> 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 constant fixups
2009/4/15 Stefan Dösinger :
> +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;
> +}
> +}
> +
> +if(inc) {
>
2009/4/15 Stefan Dösinger :
> Am Mittwoch, 15. April 2009 09:36:46 schrieb Henri Verbeet:
>> 2009/4/15 Stefan Dösinger :
>> > +void record_const_read(DWORD reg, unsigned int *array, int *num) {
>> > + int r;
>> > + BOOL inc = TRUE;
>> > + for(r
2009/4/18 Ben Klein :
>
> 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 sure the D3D devs
2009/4/19 Stefan Dösinger :
> 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 :
> @@ -760,6 +760,8 @@ IDirect3DViewportImpl_AddLight(IDirect3DViewport3 *iface,
> lpDirect3DLightImpl->activate(lpDirect3DLightImpl);
> }
>
> +IDirect3DLight_AddRef(lpDirect3DLight);
> +
> LeaveCriticalSection(&ddraw_cs);
> return D3D_OK;
> }
2009/4/20 James McKenzie :
> 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 __attribute__((unused))
#else
#defin
2009/4/20 Detlef Riekenberg :
> Support for compiler specific features should be tested during
> configure.
>
What would that look like, approximately?
2009/4/21 Tobias Jakobi :
> +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 to determine if
2009/4/22 Tobias Jakobi :
>> - 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 makes sense
2009/4/22 Tobias Jakobi :
> 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 ess
2009/4/23 Tobias Jakobi :
> 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 :
> 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 with shader
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);
> }
> +pCaps->Max
2009/4/27 ace102 :
> 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 :
>
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 :
> +/* 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
> + */
So how ar
2009/4/28 Stefan Dösinger :
> 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
2009/4/28 Stefan Dösinger :
> 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 far as I understand
2009/4/29 Massimo Del Fedele :
> 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 d3d10 is b
> +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 calculat
2009/5/5 Stefan Dösinger :
> + * 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 it's broken also avoids
2009/5/6 Francois Gouget :
> 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 post
2009/5/6 Stefan Dösinger :
> 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 predictabl
2009/5/6 Henri Verbeet :
> 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
2009/5/7 Stefan Dösinger :
> 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-uni
2009/5/9 Remco :
> 2009/5/9 Ben Klein :
>> 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 those mails are like 4 days
2009/5/9 Nicklas Börjesson :
>>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?
>
You also need to f
2009/5/11 Robert Key :
> 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 HD4000 ATI cards.
2009/5/11 Kai Blin :
> 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 :
> 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. Personally, that means
2009/5/11 Scott Ritchie :
> Henri Verbeet wrote:
>>
>> 2009/5/11 Joerg Mayer :
>>>
>>> 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
2009/5/12 Stefan Dösinger :
> 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 declare Tx in ps_1_4 and
2009/5/12 Stefan Dösinger :
> 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?
2009/5/22 Tony Wasserka :
> 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,
> UpdateTexture and Stretc
2009/5/25 Remco :
> 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 of core d
2009/5/26 Pavel Prochazka :
> +»··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 :
>
> Am 30.05.2009 um 07:24 schrieb Dmitry Timoshkov:
>
>> "Rico Schüller" wrote:
>>
>>> - /* version info? */
>>> - skip_dword_unknown(&ptr, 2);
>>> + /* Compiled target version (e.g. fx_4_0=0xfeff1001,
>>> fx_4_1=0xfeff1011). */
>>> + read_dword(&ptr, &e->v
think 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
Date: Tue Jun 2 15:
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
c
2009/6/4 Paul Vriens :
> 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 expect the tests to
fail on
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 0x00
2009/6/6 Kovács András :
> 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 ES:007b FS:0033 GS
2009/6/6 James McKenzie :
> 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 and for the framerate to
2009/6/6 Jeff Zaroyko :
> + Register 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 :
> On Sat, Jun 6, 2009 at 7:00 PM, Henri Verbeet wrote:
>> 2009/6/6 Jeff Zaroyko :
>>> + Register an account on the Wine bugzilla with the email address you
>>> use to send patches.
>>
>> Why would I do that?
>>
>
> Jus
1 - 100 of 1497 matches
Mail list logo
