Hi,
Since a few days my nightly cxtest runs show crashes in the version:info test:
http://test.winehq.org/data/f74e312bf81032c46bd2ce080a5f6a33c7ac3ee3/wine_stefand-amd64/version:info.html
(Ubuntu 8.10, 64 bit build)
Test.winehq.org has more results, for this wine build I am seeing 3 more
timeo
> Yeah. A rather old one... ;-)
>
> I don't know this code much but I would say it is partly 2 and 3. Is a FIXME
> suitable then ? This would be much more informative that just GL errors.
I'd prefer if we could track down the real issue. There might still be some
confusion between texture stages
> +if (stage > (gl_info->limits.texture_stages-1))
> +{
> + ERR("Texture stage %d invalid (only %d availables)\n", stage,
> gl_info->limits.texture_stages);
> + return;
> +}
In which situations does this occur? I guess its on some older nvidia GPU.
I don't like the ERR
Am 28.12.2009 um 11:32 schrieb Henri Verbeet:
> 2009/12/28 Stefan Dösinger :
>> The patch looks ok to me, but out of curiosity: Do you intend to make this
>> function available to other wined3d code like context_acquire is, or is the
>> main motivation of the
Am 27.12.2009 um 19:57 schrieb Henri Verbeet:
> +/* Context activation is done by the caller. */
> +static void context_apply_state(struct wined3d_context *context,
> IWineD3DDeviceImpl *device, enum ContextUsage usage)
The patch looks ok to me, but out of curiosity: Do you intend to make this
f
Am 22.12.2009 um 19:23 schrieb Roderick Colenbrander:
> On Tue, Dec 22, 2009 at 6:44 PM, Henri Verbeet wrote:
>> 2009/12/22 Stefan Dösinger :
>>> +conv = ((FVF & WINED3DFVF_POSITION_MASK) == WINED3DFVF_XYZRHW ) ||
>>> (FVF & (WINED3DFVF_DIFFUSE |
Am 22.12.2009 um 18:32 schrieb Henri Verbeet:
> +SetFocus(This->focus_window);
> +
Is this correct for windowed rendering as well?
Am 22.12.2009 um 17:08 schrieb Roderick Colenbrander:
> On Tue, Dec 22, 2009 at 4:51 PM, Stefan Dösinger
> wrote:
>> We had a discussion in wine-devel a few days ago about which GL usage is
>> better. The red book also agrees with the GL wiki, but the GL 3.0 spec uses
Am 22.12.2009 um 17:06 schrieb Henri Verbeet:
> 2009/12/22 Stefan Dösinger :
>> -HeapFree(GetProcessHeap(), 0, This->conversion_shift);
>> +IWineD3DBuffer_UnLoad(iface);
>> +This->flags &= ~WINED3D_BUFFER_CREATEBO;
> UnLoa
ropped the optimization for full buffer maps for now. Oh, and some helper
functions, but beyond that it's the same.
Am 16.12.2009 um 14:39 schrieb Henri Verbeet:
> 2009/12/16 Stefan Dösinger :
>> Actually, since we're not going to Unmap-flush and PreLoad() the buffer(its
>>
Am 17.12.2009 um 20:20 schrieb Luke Benstead:
> Luke.
> <0001-ddraw-Fix-an-incorrect-refcount-test.txt>
This patch is correct. The test intends to test DDraw7, there's a DDraw4 test
below. So the variable name was wrong, not the macro.
Am 16.12.2009 um 13:44 schrieb Henri Verbeet:
> 2009/12/16 Stefan Dösinger :
>> The best way I see to merge those two tracking mechanisms is to organize
>> them as a list, and upload all modified ranges in PreLoad(), or if the
>> buffer is single buffered and dynamic,
Am 16.12.2009 um 12:50 schrieb Henri Verbeet:
> What you're doing (or should be doing) is extending the
> "lock_count/dirty_start/dirty_end" scheme to something more detailed.
> I don't think using two different schemes depending on whether the
> buffer is dynamic or not is a good idea.
Sounds gre
Am 16.12.2009 um 11:33 schrieb Henri Verbeet:
> 2009/12/15 Stefan Dösinger :
>> @@ -85,6 +85,21 @@ static void buffer_create_buffer_object(struct
>> wined3d_buffer *This)
> ...
>> +This->maps = HeapAlloc(GetProcessHeap(), 0,
>> sizeof(*This->maps
Am 16.12.2009 um 11:33 schrieb Henri Verbeet:
> 2009/12/15 Stefan Dösinger :
>> +/* buffer_get_sysmem can remove the BO from dynamic buffers */
> No, it can't?
Actually, that part slipped in form another patch I didn't send yet. It's
dropping dynamic VBO
Am 15.12.2009 um 10:08 schrieb Austin English:
> Hm. For that matter, it could do an install with XP, then use
> cabextract to get directplay/directmusic (winetricks already has an
> option for directplay) and regsvr32 them manually.
In CrossOver we offer two dx packages - DirectX(Legacy) installs
Am 15.12.2009 um 07:56 schrieb Austin English:
> Long story short, someone complained that 'winetricks directx9'
> crashes on OS X, but works if the windows version is set to xp instead
> of 2k.
Did you try setting mscoree to disabled?
> I've played around with it a bit, and it seems that using x
This looks correct to me, I'm just asking to make sure I understand this
correctly:
> +filter_messages = swapchain->filter_messages;
> +swapchain->filter_messages = TRUE;
> +
> SetWindowLongW(window, GWL_STYLE, style);
> SetWindowLongW(window, GWL_EXSTYLE, exstyle);
> SetWindo
> OpenAL supports per stream volume. The service is basically needed if an
> application wants to 'audio groups' all using the same sound card across
> processes, and be able to switch it to some different card with 1 command.
> Since I don't think the sessions are persistent, this requires a au
Am 11.12.2009 um 19:07 schrieb Maarten Lankhorst:
> Hi all,
>
> I believe most oconcerns about OpenAL have been addressed. One of the open
> questions was whether midi and wave would be synced. And I think the most
> likely answer is that they aren't, even on windows. On windows winmm midi
>
Am 11.12.2009 um 15:47 schrieb Henri Verbeet:
> It's really not that hard, you just call surface_is_offscreen() on the
> target. Arguably swapchain_init() shouldn't be screwing around with
> context creation in the first place, but that's really a separate
> issue, unless you're volunteering to cl
Am 11.12.2009 um 11:33 schrieb Henri Verbeet:
> "context_create(device, (IWineD3DSurfaceImpl *)swapchain->frontBuffer,
> window, FALSE /* pbuffer */, present_parameters);"
What is missing is access to the swapchain->render_to_fbo setting.
context_create could use the same logic as the swapchain_c
Am 10.12.2009 um 23:15 schrieb Henri Verbeet:
> 2009/12/10 Stefan Dösinger :
>> @@ -6304,7 +6304,7 @@ HRESULT create_primary_opengl_context(IWineD3DDevice
>> *iface, IWineD3DSwapChain *
> ...
>> -swapchain->context[0]->render_offscreen = swapchain->render_t
Am 10.12.2009 um 17:22 schrieb Paul Vriens:
> Well, the patch has been committed but the ok() message looks a bit strange
> now. Do you think it makes sense to change getdc_capable to a HRESULT and do
> something like the following instead:
>
> ok(hr == testdata[i].result ||
> testdata[i].alt
Am 10.12.2009 um 16:19 schrieb Paul Vriens:
> I'm not saying it's common practice in the code but we have multiple of these
> structs where the last one(s) is not set.
Ok
Am 10.12.2009 um 13:21 schrieb Paul Vriens:
> <0004-Fix-some-test-failures-on-Vista.patch>
> const char *name;
> DDPIXELFORMAT fmt;
> BOOL getdc_capable;
> +HRESULT alt_result;
> } testdata[] = {
You are setting the alt_result only for the 4 failing tests. I
Am 10.12.2009 um 09:57 schrieb Paul Vriens:
> On 09/05/2009 04:54 PM, Stefan Dösinger wrote:
>> This patch uses a d3d9-side filter in favor of adding a 2nd set of
>> getdc-capable format flags.
>>
>
> Hi Stefan,
>
> These tests have failures on Vista+ boxes:
Am 09.12.2009 um 09:36 schrieb 임은지:
> Thank you for your comments.
> I will cleanup the patch as you suggested and send it.
Did you contact the kernel maintainers regarding the kernel side of your
changes? I think including the Wine patch doesn't make sense until the kernel
developers accept the
> Author: Maarten Lankhorst
Am 08.12.2009 um 13:06 schrieb Robert Reif:
> Yes, a single ring buffer for all the software mixed direct
> sound buffers. A good driver implementation would
> have a ring buffer for every direct sound buffer. Therefore
> no requirement for any software mixing. That path is in
> the direct sound
Am 06.12.2009 um 23:21 schrieb Maarten Lankhorst:
> I wouldn't be surprised if this still was the case, we could keep the midi
> interfaces around and just report 0 wave in/out devices for
> oss/coreaudio/alsaa once we complete wine7audio.drv.
So you mean keeping the existing infrastructure arou
Am 06.12.2009 um 22:57 schrieb Roderick Colenbrander:
> Joysticks work using /dev/js or evdev these days. It was hard to find
> some info on MIDI for Vista but I believe it still works using WinMM.
> You really need oss or alsa for midi I think.
There's this:
http://www.jcabs-rumblings.com/Progra
> Though, how would MIDI be handled. I think that OpenAL doesn't handle MIDI...
Good question.
As far as I can see PulseAudio doesn't support MIDI either, but it is certainly
available in Alsa, CoreAudio and on Windows Vista, even though its more tricky
to activate HW midi on Vista.
Emulating M
Am 06.12.2009 um 20:20 schrieb Roderick Colenbrander:
> We would like to let the 'audio library' do
> all the mixing and hard work. Maarten advocated to use OpenAL as the
> audio library. This would allow us to get rid of all the different
> audio backends which would make maintenance easier. The
Am 06.12.2009 um 15:32 schrieb Roderick Colenbrander:
> This audio engine is quite similar to
> pulseaudio and it offers functionality like per stream volume which
> normal APIs like oss/alsa/openal don't offer, so these APIs would map
> better to a sound server than to a standard library.
I am wo
Am 06.12.2009 um 14:20 schrieb Reece Dunn:
>> * Supporting DirectSound 3D is easy - openal just has it available. No need
>> to reinvent the wheel. There are still a lot of dsound 3d games from WinXP
>> and earlier.
>
> This is good, as those older games will then sound better on
> Linux+Wine
Hi,
For those who didn't follow the big dsound argument thread, here is a quick
summary of the main points. I originally inteded this as a summary mail, but
while collecting the arguments I have instead taken the discussion off-list
accidentally. But here's the current state:
Pretty much everyo
Hi Dan,
in vg-ddraw-d3d.txt:
Conditional jump or move depends on uninitialised value(s)
at ??? (in /dev/zero)
by surface_load_ds_location (surface.c:4504)
by IWineD3DDeviceImpl_SetDepthStencilSurface (device.c:6273)
etc
It seems that this happens in a function that the compiler in
Am 05.12.2009 um 10:35 schrieb Chris Robinson:
> Except it also has API-provided 3D features that would be a big benefit for
> implementing DSound3D,
This is indeed a big plus for OpenAL - if we use our own sound system we'll
have to reimplement DSound3D features. It fits the "sit on the shoulde
Am 04.12.2009 um 18:51 schrieb Chris Robinson:
> Though you'll still need a way to talk to the hardware. Using ALSA/OSS/etc
> directly has proven problematic with not only the current design and upkeep,
> but properly implementing various features. Not that I'm advocating
> PulseAudio
> here,
Am 04.12.2009 um 16:00 schrieb Maarten Lankhorst:
> I'm NOT going to touch our winmm drivers any more apart from maintanance. I
> am willing to make 1 more, 'wine7audio' that forwards to IAudioClient, and
> does all bizarre things like looping wave packets, etc there, so our audio
> will be san
Am 04.12.2009 um 01:26 schrieb David Anderson:
> Thanks to James Mckenzie and Austin English for earlier hints. I've
> installed more stuff (ubuntu packages) and spent a bit more time with d3d8.
>
> I assume most people get these tests to work, so I'm a bit distressed I
> cannot seem to get
> t
Am 03.12.2009 um 11:19 schrieb Henri Verbeet:
> 2009/12/3 Stefan Dösinger :
>> It matters when reading back an offscreen render target if FBOs are enabled,
>> but FBO_blit is not supported. The readback function calls
>> glReadBuffer(device->offscreenBuffer) in this ca
Am 02.12.2009 um 22:10 schrieb Henri Verbeet:
>> switch(wined3d_settings.offscreen_rendering_mode) {
>> case ORM_FBO:
>> +This->offscreenBuffer = GL_COLOR_ATTACHMENT0;
> This change is probably correct, but note that if it matters you're
> probably doing something wrong.
It
Am 02.12.2009 um 22:10 schrieb Henri Verbeet:
> Btw, note that the surface being offscreen is the common case, and
> onscreen surfaces are the exception. Maybe surface_is_onscreen() makes
> more sense, but I'll leave that up to you.
I think its better to keep offscreen rendering the special case s
Am 02.12.2009 um 22:10 schrieb Henri Verbeet:
> IWineD3DDeviceImpl_Reset() suffers from similar issues in general, so
> maybe we just don't care, but if one of the updateSurfaceDesc() calls
> fails you're left with inconsistent surface sizes.
We don't care because by Microsoft's design Reset() lea
> I think this will break color_fill_fbo
I'll investigate that, but I think if it did it would break the d3d9 tests if I
force rendering to the FBO - which I did for testing.
> Out of curiosity, what would the performance impact be of always
> rendering to FBO?
I only tested it on my macs so far,
Am 24.11.2009 um 23:05 schrieb Michael Stefaniuc:
>>
> Stefan, let me guess, you just wanted to point him to
> http://wiki.winehq.org/USB ? ;)
Whaaa. Searching the wiki might have saved me lots of typing...
Am 24.11.2009 um 22:43 schrieb Charles Davis:
> This really belongs on the wine-users mailing list.
I'm not sure - I think from the context of the mail Chris is a coder himself,
and the answer to his question on wine-users would be "Wine currently cannot do
this".
I am not too involved into th
Am 23.11.2009 um 21:31 schrieb Roderick Colenbrander:
> On Mon, Nov 23, 2009 at 9:23 PM, Stefan Dösinger
> wrote:
>>
>> Am 23.11.2009 um 21:00 schrieb chris ahrendt:
>>> The test fails with :
>>>
>>> query.c:224: Test failed: IDirect3DQuery9_GetD
Am 23.11.2009 um 21:00 schrieb chris ahrendt:
> The test fails with :
>
> query.c:224: Test failed: IDirect3DQuery9_GetData a 2nd time on a ended query
> returned 0001
This is Windows, right? Which GPU/driver?
My guess is that its ok to modify the test to accept both results. Ie, ok(hr ==
Am 17.11.2009 um 12:16 schrieb Austin Lund:
>>> <0001-ddraw-tests-Fix-test-failure-for-D3DFMT_A2R10G10B10-.txt>
>> Where did this test fail? On Wine or Windows? If it was on windows, which
>> windows version and GPU did you use?
>>
>
> WinXP SP2 running in Virtual box 3.0.8 with guest additions
Am 17.11.2009 um 10:38 schrieb Austin Lund:
>
> <0001-ddraw-tests-Fix-test-failure-for-D3DFMT_A2R10G10B10-.txt>
Where did this test fail? On Wine or Windows? If it was on windows, which
windows version and GPU did you use?
Am 15.11.2009 um 20:55 schrieb Vincent Povirk:
>
>
> <0001-ddraw-tests-Add-test-for-refcounts-of-surface-object.txt>
I think we already have tests for that - see IFaceRefCount() in dsurface.c
Am 08.11.2009 um 13:28 schrieb Austin English:
On Sun, Nov 8, 2009 at 6:14 AM, Louis Lenders
wrote:
These are spawned at huge rate in World in Conflict demo
(http://bugs.winehq.org/show_bug.cgi?id=4)
It'd be quicker/cleaner to just change them to warn's instead, IMHO.
I think BeginEvent
Am 01.11.2009 um 13:28 schrieb Stefan Dösinger:
<0001-WineD3D-SetRT-viewport-param.txt>
Please use the other [1/5] patch - this one has a wrong patch
description in the file
Am 29.10.2009 um 21:29 schrieb Luis C. Busquets Pérez:
Dear all,
Since d3d10effect has advanced a lot during the latest weeks I was
wondering what are the next steps that you are planning to develop.
I'm still working on d3d9-related stuff only, no guarantees that the
following is correct
Am 28.10.2009 um 11:43 schrieb Henri Verbeet:
The patches are correct, I wrote tests for this for commits
508635ac4c290b00bd2aa97026e627a50d3c4cee,
58fcb06c07cbe4fd9cd94dc138d625cf08b82fb7 and
fbbbdc09a591d7e8deae3830400ac7ad1d2fca8e. I didn't submit those
though.
Ok
Am 27.10.2009 um 20:10 schrieb Rico Schüller:
Hi,
this patch series implements a couple of ID3D10EffectVariable::As*()
functions (patches 2-11).
Do we have any tests for the As* behavior?
Most conversions don't make any sense, so if the app wants a constant
buffer as a render target view
Am 25.10.2009 um 10:57 schrieb Scott Ritchie:
Many apps don't need to view the user folder for documents but also
employ programmable scripting engines - a good example are games. It
would be much more convenient to pass some sort of "sandbox me, allow
network, deny home folder access" switch t
Am 18.10.2009 um 16:24 schrieb Warren Dumortier:
I don't think it's worth to be tested, because if Xfire doesn't
crash (simply by not interacting with it) games are detected.
However i will try it, who knows! ;)
An easier way to test is probably to disable Xfire In-Game, if you
find out how
Am 18.10.2009 um 15:02 schrieb Warren Dumortier:
Xfire was working until version 1.104, but since then it crashed on
every Wine version, so the Xfire update broke it under Wine.
Here's the problem:
Xfire crashes every time you interact with it's GUI, well most of
the time...
When using the
Do I read this correctly that a double unlockrect call on a surface
fails, while a double unlockrect call on a texture succeeds? From the
context of the patch its a bit hard to read.
Here are some more test suggestions:
-> Create a texture, retrieve its surface, and call LockRect/
UnlockRec
Am 14.10.2009 um 05:42 schrieb Dmitry Timoshkov:
"Stefan Dösinger" wrote:
-HRESULT WINAPI DirectInput8Create(HINSTANCE hinst, DWORD
dwVersion, REFIID riid, LPVOID *ppDI, LPUNKNOWN punkOuter) {
+HRESULT WINAPI DECLSPEC_HOTPATCH DirectInput8Create(HINSTANCE
hinst, DWORD dwVersi
Am 14.10.2009 um 01:44 schrieb Roderick Colenbrander:
You should also patch make_opengl because openg32.spec is
automatically generated.
Ooops, I'll resend. This shouldn't break patches 5-10 though. Just
skip this one for now.
Am 13.10.2009 um 22:50 schrieb Nikolay Sivov:
Stefan Dösinger wrote:
This makes use of the gcc attribute added to gcc svn yesterday:
http://gcc.gnu.org/ml/gcc-cvs/2009-10/msg00319.html
Hi, Stefan. Could you explain me
Am 13.10.2009 um 09:20 schrieb Markus Stockhausen:
> + ok(1==0, "last bytes of szDriver string are %08x\n",
dddi2[0x7f]);
> + ok(1==0, "last bytes of szDescription string are %08x
\n", dddi2[0xff]);
Note that you can only test these parts if strlen(pddi.*) indicates
t
> diff --git a/dlls/ddraw/tests/visual.c b/dlls/ddraw/tests/visual.c
> index 450d231..645fa8d 100644
> --- a/dlls/ddraw/tests/visual.c
> +++ b/dlls/ddraw/tests/visual.c
The visual.c file doesn't seem quite right for this test. There's no
really matching file, but I think ddrawmodes.c is better,
Am 11.10.2009 um 17:44 schrieb Markus Stockhausen:
Did you compile this test with MSVC and the Microsoft headers on
Windows?
Am 11.10.2009 um 14:42 schrieb Markus Stockhausen:
Am Sonntag, den 11.10.2009, 13:18 +0200 schrieb Markus Stockhausen:
Then I'm somehow in trouble. How can one explain the following
error: Application calls IDirectDraw GetDeviceIdentifier of
DDRAW7 but only reserves memory with sizeof(DDEVICEI
Am 11.10.2009 um 12:40 schrieb Markus Stockhausen:
Hi,
as I did not find anything in the Wiki maybe a stupid question: If I
want an application to use DDRAW4 functions in Wine instead of DDRAW7,
how can I accomplish that?
You can't.
Except if you have the sourcecode. In that case you have to
Am 08.10.2009 um 09:46 schrieb Andrew Nguyen:
---
dlls/ddraw/ddraw.spec|2 +-
dlls/ddraw/main.c| 17 +
dlls/ddraw/tests/ddrawenum.c | 37 +
3 files changed, 51 insertions(+), 5 deletions(-)
<0003-ddraw-Implement-and
Am 02.10.2009 um 10:43 schrieb Henri Verbeet:
+/* Test a viewport with Width and Height bigger than the
surface dimensions
+ *
+ * TODO: Test Width < surface.width, but X + Width >
surface.width
+ * TODO: Test Width < surface.width, what happens with the
height?
+ */
Am 02.10.2009 um 10:44 schrieb Henri Verbeet:
2009/10/1 Stefan Dösinger :
+/* Finally, reset the viewport as the MSDN states. Tests
show that stateblock recording is ignored.
+ * the change goes directly into the primary stateblock.
+ */
+This->stateBl
Am 01.10.2009 um 13:47 schrieb Alexandre Julliard:
Stefan Dösinger writes:
Patches 2, 3 and 4 fix bug 19365. In the long run we want to get rid
of the dxVersion parameter that is used in this patch, but we haven't
agreed on a way to do this so far, so lets fix the bug first.
It do
Am 30.09.2009 um 16:22 schrieb Henri Verbeet:
I prefer that all d3d version specific behaviors in wined3d(ie,
those that
can't be handled by the client lib alone) are controlled by one
wined3d
parameter. I don't feel strongly about this though. I could as well
make
them a parameter of Crea
Am 29.09.2009 um 15:09 schrieb Markus Stockhausen:
Sorry for the incomplete topic of my first mail.
The patch looks ok to me
Am Sunday 20 September 2009 20:09:25 schrieb Henri Verbeet:
> pCaps->MaxVertexShaderConst = min(D3D9_MAX_VERTEX_SHADER_CONSTANTF,
> pCaps->MaxVertexShaderConst); +pCaps->NumSimultaneousRTs =
> min(D3D9_MAX_SIMULTANEOUS_RENDERTARGETS, pCaps->NumSimultaneousRTs); }
I think you also have to m
Am Monday 14 September 2009 17:28:13 schrieb joerg-cyril.hoe...@t-systems.com:
> Hi,
>
> the argument for including this code is based on symmetry: Every place in
> the Wine source tree (incl. ddraw, d3d9, wined3d) that handles L6V5U5 also
> handles X8L8V8U8 -- except for these two places. So I cl
Am Sunday 13 September 2009 08:15:19 schrieb Jaime Rave:
> More information about Intel cards:
> http://en.wikipedia.org/wiki/Intel_GMA#Table_of_GMA_graphics_cores_and_chip
>sets
+|| strstr(gl_renderer, "Intel®"))
I don't know if it is safe check for the ®. I think its not part of the
Am Saturday 12 September 2009 23:50:47 schrieb Henri Verbeet:
> 2009/9/12 Stefan Dösinger :
> > I wonder how this worked in the past, and why the compiler didn't
> > complain.
>
> It's pretty simple really, these functions don't need WINAPI because
> the
Am Saturday 12 September 2009 23:41:00 schrieb Stefan Dösinger:
> Am Saturday 12 September 2009 23:25:56 schrieb Stefan Dösinger:
>
> Oops: forgot the patch:
Er, never mind that patch - those functions aren't used directly in the
vtable. There are the FPUSetup and FPUPreserve w
Am Friday 11 September 2009 00:05:02 schrieb Henri Verbeet:
> I don't think SRGB_ANY is correct here. context_apply_fbo_entry() very
> much cares about which texture is attached to the FBO. If rendering to
> sRGB textures was supported properly this would depend on the sRGB
> write state, but since
hi,
I think its better to send these reports to wine-devel instead of wine-patches
Am Monday 07 September 2009 06:57:58 schrieb James McKenzie:
> There is or was a lurker here from AMD. Maybe you could forward your
> patches to them to get the extension fixed?
They already know - Henri and I talked to him earlier, he said they'll fix the
extension somewhen. No ETA though
Am Sunday 06 September 2009 22:27:14 schrieb Henri Verbeet:
> 2009/9/5 Stefan Dösinger :
> > +/* All GL_ATI_meminfo enums return 4 ints, even the
> > (undocumented) + * GL_TOTAL_PHYSICAL_MEMORY_ATI one, which
> > returns {mem, 0, 0, 0} */
Am Friday 04 September 2009 20:28:31 schrieb James Mckenzie:
> Interesting. I was going to comment that the EM_FORMATRANGE problem may be
> the cause, but this may be due to the CUPS implementation or some other
> reason on the Mac. Unfortunately, my only printer, which was an inkjet,
> would hav
Am Wednesday 02 September 2009 15:07:42 schrieb Henri Verbeet:
> > That said, I haven't seen a GL implementation yet that successfully
> > compiles and SW-emulates a program that exceeds the limits.
>
> It isn't necessarily a problem when this happens, it's more meant as a
> diagnostic while debugg
Am Wednesday 02 September 2009 09:27:58 schrieb Henri Verbeet:
> +GL_EXTCALL(glGetProgramivARB(GL_FRAGMENT_PROGRAM_ARB,
> GL_PROGRAM_UNDER_NATIVE_LIMITS_ARB, &native)); +
> checkGLcall("glGetProgramivARB()");
> +if (!native) WARN("Program exceeds native resource limits.\n");
Yay, Dplay work! A few suggestions though:
>From patch 1:
> +static HRESULT WINAPI DPWSCB_GetCaps( LPDPSP_GETCAPSDATA data )
> +{
> +TRACE( "(%d,%p,0x%08x,%p)\n",
> + data->idPlayer, data->lpCaps, data->dwFlags, data->lpISP );
>+return DP_OK;
> +}
Is there any reason this one wri
Am Thursday 27 August 2009 07:14:49 schrieb Chris Robinson:
> On Wednesday 26 August 2009 9:27:42 pm Vitaliy Margolen wrote:
> > Tested few games that had issues with native OpenAL from Creative (both
> > windows dll and thunked old Linux version): STALKER SoC, STALKER CS,
> > Psychonauts. So far s
I'll give it a try with my games. The old thunk from a while ago already
worked very will with those games.
OpenAL seems to have an extension system like opengl. If there is a function
that returns an extension string we'll want to remove any extension our thunk
doesn't know about. However, I c
Am Monday 24 August 2009 18:02:37 schrieb joerg-cyril.hoe...@t-systems.com:
> Hi,
>
> here's the patch not to report UNIX GL driver version numbers to MS-Windows
> apps, as suggested by Stefan and Roderick on 2009-05-25.
>
> On "early 2009" NVidia MacOS, it will remove
> err:d3d_caps:IWineD3DImpl_F
Am 21.08.2009 um 23:06 schrieb Matteo Bruni:
I'm trying to follow Juan Lang suggestions on how to structure the D3D
assembler patches. I'm not yet sure on how to proceed with the bulk of
the assembler, however these preparatory patches should be safe.
<0001-d3dx9-Add-D3DXAssembleShader-and-rela
I think it is better to separate the vtables first - ie, give
IDirectDrawSurface4, IDirectDrawSurface2 and IDirectDrawSurface their
own vtable
Also the last iteration of Michael Karcher's patches missed out some
getters, like IDirect3DDevice*::GetRenderTarget. There may be other
function
Am Wednesday 19 August 2009 15:09:03 schrieb Henri Verbeet:
> Sure, it's picky like that. IIRC most battlefield games need
> 800x...@60 to startup. Occasionally that's a problem on Windows as
> well. It seems to me that you should be looking at why
> EnumDisplaySettingsExW() didn't give you a refre
Am Wednesday 19 August 2009 14:51:44 schrieb Stefan Dösinger:
> > MSDN seems to disagree. "The value of 0 indicates an adapter default."
> 0 for D3DADAPTER_DEFAULT certainly makes sense. But 0 as advertised refresh
> rate does not. 0 probably makes sense as requested refres
Am Wednesday 19 August 2009 14:46:21 schrieb Henri Verbeet:
> 2009/8/19 Stefan Dösinger :
> > and its value(=0) is not sane
>
> MSDN seems to disagree. "The value of 0 indicates an adapter default."
0 as a refresh rate? Or in the sense of "this is the default adapt
Am Wednesday 19 August 2009 10:55:39 schrieb Henri Verbeet:
> This format is broken on some cards. Hide it until we figure out a reliable
> way to deal with it.
Didn't you consider breaking something the best way to get the driver
fixed? :-)
Fwiw, I reported this to linux-b...@nvidia.com, togethe
Am Wednesday 19 August 2009 04:02:37 schrieb Sun, Sunny:
> Hi Dösinger
> Have you done that?
Not yet. After Henri's objection I have decided to wait until either the spec
is fixed or you two reach an agreement.
601 - 700 of 2518 matches
Mail list logo
