Hi Roderick,
On Thursday 22 July 2010 22:26:39 Roderick Colenbrander
wrote:
> On Thu, Jul 22, 2010 at 10:14 PM, Stefan Dösinger
>
>
wrote:
> > Am 22.07.2010 um 21:13 schrieb Oldřich
Jedlička:
> >> DirectX 1 interface allowed creation of explicit back
buffers, so move
> >> the restrictive checks
Hi Roderick,
On Thursday 22 July 2010 22:26:39 Roderick Colenbrander wrote:
> On Thu, Jul 22, 2010 at 10:14 PM, Stefan Dösinger
>
> wrote:
> > Am 22.07.2010 um 21:13 schrieb Oldřich Jedlička:
> >> DirectX 1 interface allowed creation of explicit back buffers, so move
> >> the restrictive checks
On Thu, Jul 22, 2010 at 10:14 PM, Stefan Dösinger
wrote:
>
> Am 22.07.2010 um 21:13 schrieb Oldřich Jedlička:
>
>> DirectX 1 interface allowed creation of explicit back buffers, so move the
>> restrictive checks to DirectX 2+ implementations.
> It is still missing testing/handling of AddAttachedSu
Am 22.07.2010 um 21:13 schrieb Oldřich Jedlička:
> DirectX 1 interface allowed creation of explicit back buffers, so move the
> restrictive checks to DirectX 2+ implementations.
It is still missing testing/handling of AddAttachedSurface
sday 21 July 2010 20:51:49 Oldřich Jedlička wrote:
> >> Old DirectX interfaces allowed creation of explicit back buffers, so
> >> move the restrictive check to DirectX 7 implementation.
> >>
> >> This fixes bug #9008.
> >> ---
> >> dlls/ddraw/ddraw.
rds,
> Oldrich.
>
>
> On Wednesday 21 July 2010 20:51:49 Oldřich Jedlička wrote:
>> Old DirectX interfaces allowed creation of explicit back buffers, so move
>> the restrictive check to DirectX 7 implementation.
>>
>> This fixes bug #9008.
>> ---
>>
July 2010 20:51:49 Oldřich Jedlička wrote:
> Old DirectX interfaces allowed creation of explicit back buffers, so move
> the restrictive check to DirectX 7 implementation.
>
> This fixes bug #9008.
> ---
> dlls/ddraw/ddraw.c | 35 ---
> 1 fi
2010/7/20 Roderick Colenbrander :
> 2010/7/20 Oldřich Jedlička :
>> Hi Stefan,
>>
>> On Tuesday 20 July 2010 00:01:13 Stefan Dösinger wrote:
>>> Am 19.07.2010 um 21:24 schrieb Oldřich Jedlička:
>>> > Hi Stefan,
>>> >
>>> > On Monday 19 July 2010 20:56:35 Stefan Dösinger wrote:
>>> >> Allowing the c
2010/7/20 Oldřich Jedlička :
> Hi Stefan,
>
> On Tuesday 20 July 2010 00:01:13 Stefan Dösinger wrote:
>> Am 19.07.2010 um 21:24 schrieb Oldřich Jedlička:
>> > Hi Stefan,
>> >
>> > On Monday 19 July 2010 20:56:35 Stefan Dösinger wrote:
>> >> Allowing the creation of the surface is most likely not en
Hi Stefan,
On Tuesday 20 July 2010 00:01:13 Stefan Dösinger wrote:
> Am 19.07.2010 um 21:24 schrieb Oldřich Jedlička:
> > Hi Stefan,
> >
> > On Monday 19 July 2010 20:56:35 Stefan Dösinger wrote:
> >> Allowing the creation of the surface is most likely not enough, the
> >> backbuffer has to be us
Hi James,
On Tuesday 20 July 2010 03:43:39 James McKenzie wrote:
> Austin English wrote:
> > 2010/7/19 Oldřich Jedlička :
> >> The tests will be a problem, because I don't have the Windows machine as
> >> a reference. Also `make test` fails on DirectX tests for me because of
> >> r600 driver bug..
Hi Stefan,
On Tuesday 20 July 2010 00:01:13 Stefan Dösinger wrote:
> Am 19.07.2010 um 21:24 schrieb Oldřich Jedlička:
> > Hi Stefan,
> >
> > On Monday 19 July 2010 20:56:35 Stefan Dösinger wrote:
> >> Allowing the creation of the surface is most likely not enough, the
> >> backbuffer has to be us
Austin English wrote:
2010/7/19 Oldřich Jedlička :
The tests will be a problem, because I don't have the Windows machine as a
reference. Also `make test` fails on DirectX tests for me because of r600
driver bug...
When I write CreateSurface tests (for various interfaces), is there a way for
Am 19.07.2010 um 21:24 schrieb Oldřich Jedlička:
> Hi Stefan,
>
> On Monday 19 July 2010 20:56:35 Stefan Dösinger wrote:
>> Allowing the creation of the surface is most likely not enough, the
>> backbuffer has to be useable after it has been created. Specifically, when
>> the app attaches the ba
On Monday 19 July 2010 21:41:26 Henri Verbeet wrote:
> 2010/7/19 Oldřich Jedlička :
> > I will enhance the log message, no problem here. Should I consider the
> > referenced patch as being applied (so that I should base my patch on it)?
>
> Yeah.
Ok, I will update it according to your changes :-)
2010/7/19 Oldřich Jedlička :
> I will enhance the log message, no problem here. Should I consider the
> referenced patch as being applied (so that I should base my patch on it)?
>
Yeah.
> The tests will be a problem, because I don't have the Windows machine as a
> reference. Also `make test` fails
Hi Stefan,
On Monday 19 July 2010 20:56:35 Stefan Dösinger wrote:
> Allowing the creation of the surface is most likely not enough, the
> backbuffer has to be useable after it has been created. Specifically, when
> the app attaches the backbuffer to the frontbuffer(assuming this works,
> needs a t
2010/7/19 Oldřich Jedlička :
> The tests will be a problem, because I don't have the Windows machine as a
> reference. Also `make test` fails on DirectX tests for me because of r600
> driver bug...
>
> When I write CreateSurface tests (for various interfaces), is there a way for
> me to run the tes
Hi Henri,
On Monday 19 July 2010 20:07:08 Henri Verbeet wrote:
> 2010/7/19 Oldřich Jedlička :
> > This fixes bug #9008.
>
> Please provide a more descriptive log message, and consider writing a
> test. I'm also pretty sure this will conflict with
> http://source.winehq.org/patches/data/63676.
I
Allowing the creation of the surface is most likely not enough, the backbuffer
has to be useable after it has been created. Specifically, when the app
attaches the backbuffer to the frontbuffer(assuming this works, needs a test)
wined3d has to be made aware of the change - there's a SetFrontBack
2010/7/19 Oldřich Jedlička :
> This fixes bug #9008.
Please provide a more descriptive log message, and consider writing a
test. I'm also pretty sure this will conflict with
http://source.winehq.org/patches/data/63676.
* On Sun, 9 Apr 2006, James Hawkins wrote:
> * On 4/9/06, Dimi Paun wrote:
> >
> > Hasn't Alexandre added something recently that creates some fake DLLs
> > with proper version info in them?
>
> To make sure a fake dll is created in the system directory, add the
> dll name to tools/wine.inf under
On 4/9/06, Dimi Paun <[EMAIL PROTECTED]> wrote:
>
> Hasn't Alexandre added something recently that creates some fake DLLs
> with proper version info in them?
>
To make sure a fake dll is created in the system directory, add the
dll name to tools/wine.inf under the FakeDllsSection section. I guess
On Sun, 2006-04-09 at 10:03 +0200, Stefan Dösinger wrote:
> Most likly it uses some strange way to determine if directx is
> supported, like checking for the existance of a .dll file.
This is exactly it! This solved the problem:
[EMAIL PROTECTED] ~]$ touch .wine/drive_c/windows/system32/Ddraw.dll
Am Sonntag, 9. April 2006 03:45 schrieb Dimi Paun:
> I am not up-to-date with the latest DirectX news, can someone
> please tell me if we have any support for DirectX 7?
DirectX 7 is supported since quite a long time. I'm currently re-writing ddraw
and d3d7 support.
> I have
Hi folks,
I am not up-to-date with the latest DirectX news, can someone
please tell me if we have any support for DirectX 7?
I have a screensaver (Marine Aquarium) that I would like to run,
but it requires DirectX 7.
Is there any trick to get it to run?
Thanks!
--
Dimi Paun <[EMAIL PROTEC
of the states
could be supported
by using shaders.
I've only been working on wined3d because Stefan Dösinger has been working on
getting DirectX 7 to
work with wined3d and I'm testing a d3d8 wrapper for wined3d at the moment so
other versions of
DirectX should get the extra states
On Thu, Oct 27, 2005 at 02:59:36PM +0100, Oliver Stieber wrote:
> > can somebody give me a light on the directx stuff in wine? Maybe i am
> > wrong, but
> > isn't it true that in each version are very similar renderstates..
(snip)
> > Is somebody working on this?
Actually not really as these wa
--- Christian Gmeiner <[EMAIL PROTECTED]> wrote:
> Hi all..
>
> can somebody give me a light on the directx stuff in wine? Maybe i am
> wrong, but
> isn't it true that in each version are very similar renderstates..
>
> I want to fix some err: now...
> err:ddraw:set_render_state Unhandled dwRe
Hi all..
can somebody give me a light on the directx stuff in wine? Maybe i am
wrong, but
isn't it true that in each version are very similar renderstates..
I want to fix some err: now...
err:ddraw:set_render_state Unhandled dwRenderStateType
D3DRENDERSTATE_LINEPATTERN (000a) value :
30 matches
Mail list logo