On Jul 25, 2013, at 2:11 PM, Qian Hong wrote:
> On Fri, Jul 26, 2013 at 2:52 AM, Ken Thomases wrote:
>> I think your Valgrind results are telling us that there's a bug in the game
>> where it's using an uninitialized stack variable.
>>
>> There's still a chance that it's something in Wine that'
On Fri, Jul 26, 2013 at 2:52 AM, Ken Thomases wrote:
> I think your Valgrind results are telling us that there's a bug in the game
> where it's using an uninitialized stack variable.
>
> There's still a chance that it's something in Wine that's using the
> uninitialized variable and passing a ga
Hi Qian,
On Jul 25, 2013, at 11:53 AM, Qian Hong wrote:
> On Thu, Jul 25, 2013 at 2:33 AM, Ken Thomases wrote:
>> Hmm. You may need to mark the dummy array as volatile to prevent it from
>> being optimized away. Worth trying. You might also increase the size of
>> the array.
>
> You are ri
Hi Ken,
On Thu, Jul 25, 2013 at 2:33 AM, Ken Thomases wrote:
> Hmm. You may need to mark the dummy array as volatile to prevent it from
> being optimized away. Worth trying. You might also increase the size of the
> array.
You are right, thanks! Increasing the size of the array helps, the
m
On Jul 24, 2013, at 12:49 PM, Qian Hong wrote:
> Hi Ken,
>
> On Sun, Jul 21, 2013 at 2:39 PM, Ken Thomases wrote:
>> Instead of enabling the trace, try replacing it with something like:
>>
>>char dummy[256];
>>memset(dummy, 0x55, sizeof(dummy));
>>
>> I bet the crash will change from a
Hi Ken,
On Sun, Jul 21, 2013 at 2:39 PM, Ken Thomases wrote:
> Instead of enabling the trace, try replacing it with something like:
>
> char dummy[256];
> memset(dummy, 0x55, sizeof(dummy));
>
> I bet the crash will change from a read access to 0x0001 to 0x.
>
Thanks for the
On Sat, Jul 20, 2013 at 2:21 AM, Marcus Meissner wrote:
> Or timing ... Also can you print out refcount there to see if the refcounting
> is good?
Thanks Marcus, yes, I tried replace the TRACE to printf, to my
surprise, the magic disappear.
In other words, if I replace the TRACE in d3d9_AddRef t
Hello,
Thanks everyone's help, sorry for delay, I was blocked by something else.
I've created http://bugs.winehq.org/show_bug.cgi?id=34125 to track
down this bug.
On Fri, Jul 19, 2013 at 10:06 PM, Henri Verbeet wrote:
> Well, it sounds a bit like some form of memory corruption. Sometimes
> WINED
On Jul 19, 2013, at 8:34 AM, Qian Hong wrote:
> I was debugging on a popular game [1] [2] (9 GB), it crashes on start.
>
> +relay,+seh,+tid log show that there are some calls to
> wined3d.wined3d_mutex_lock / wined3d.wined3d_buffer_map /
> wined3d.wined3d_mutex_unlock before crashing, so I turn o
On Fri, Jul 19, 2013 at 04:06:56PM +0200, Henri Verbeet wrote:
> On 19 July 2013 15:34, Qian Hong wrote:
> > Further tests show that the simplest hack to avoid crashing is
> > replacing line 71 to:
> > FIXME("anything %x\n", 0xdeadbeef);
> >
> > I have no idea what the real fix is, any suggestion
On 19 July 2013 15:34, Qian Hong wrote:
> Further tests show that the simplest hack to avoid crashing is
> replacing line 71 to:
> FIXME("anything %x\n", 0xdeadbeef);
>
> I have no idea what the real fix is, any suggestion what is the next
> step to debug?
>
Well, it sounds a bit like some form of
Hello,
I was debugging on a popular game [1] [2] (9 GB), it crashes on start.
+relay,+seh,+tid log show that there are some calls to
wined3d.wined3d_mutex_lock / wined3d.wined3d_buffer_map /
wined3d.wined3d_mutex_unlock before crashing, so I turn on +d3d9 trace
to get a new log in details.
To my
Am Dienstag, 16. Juni 2009 12:35:22 schrieb joerg-cyril.hoe...@t-systems.com:
> Hi,
>
> What is the recommended way not to use Wine's DirectX9 and fall back to
> DirectX8 instead? Some applications list DirectX 8.1 as their minimal
> graphics requirement, yet they come with Di
2009/6/16 :
> What is the recommended way not to use Wine's DirectX9 and fall back to
> DirectX8 instead?
> Some applications list DirectX 8.1 as their minimal graphics requirement,
> yet they come with DirectX9 on the CD and presumably use Wine's DirectX9.
>
You
7; of d3d9.
Roderick
On Tue, Jun 16, 2009 at 2:58 PM, Tom Wickline wrote:
> In the registry :)
>
> Tom
>
> On Tue, Jun 16, 2009 at 6:35 AM, wrote:
>> Hi,
>>
>> What is the recommended way not to use Wine's DirectX9 and fall back to
>> DirectX8 instead?
In the registry :)
Tom
On Tue, Jun 16, 2009 at 6:35 AM, wrote:
> Hi,
>
> What is the recommended way not to use Wine's DirectX9 and fall back to
> DirectX8 instead?
> Some applications list DirectX 8.1 as their minimal graphics requirement,
> yet they come with
Hi,
What is the recommended way not to use Wine's DirectX9 and fall back to
DirectX8 instead?
Some applications list DirectX 8.1 as their minimal graphics requirement,
yet they come with DirectX9 on the CD and presumably use Wine's DirectX9.
The author of the screenshot at
http://www
r161:
Register indeo codec harder; thanks to 414N for the tip.
r112:
Update directx9 to june 2008 release; thanks to Paul Drain for the tip.
r111:
Add non-activex flash plugin
r110:
Update ffdshow. Update version.
r107:
Add a little error checking, and missing quotes in one spot.
from /usr/bin/which on mac
- cope with redhat.com sending decompressed files
- use win2K when installing directx9 so it installs more stuff
r50:
- Added directx9 verb
Online as always at
http://kegel.com/wine/winetricks
or
http://winezeug.googlecode.com
/'username'/half-life2) and type the command there. HL2
should start fine as long as steam is running.
Roderick
> --- Ursprüngliche Nachricht ---
> Von: Evil <[EMAIL PROTECTED]>
> An: Fabian Bieler <[EMAIL PROTECTED]>
> Kopie: wine-devel@winehq.org
> Betreff: Re: D
Cool! It works without the dll overrides, and I can see the pages in
the store tab now. Thanks for the tip.
Now, I just need to figure out my performance bottleneck.
- Jesse
Fabian Bieler wrote:
>Execute regsvr32 mozctlx.dll in the directory where mozcontrol.tgz was
>extracted. (usually ~
For me steam works if I use transgaming's mozcontrol with wine:
http://downloads.transgaming.com/mozilla_control_downloads/
(freely available under the MPL)
However it is somewhat unstable.
Fabian
On Tuesday 25 October 2005 01:19, Ivan Gyurdiev wrote:
> Roderick Colenbrander wrote:
> >> How is it
Hello,
> The reason I was looking into all this is that the performance of hl2
> (atleast in the menus) is greatly reduced by all the FIXME's printed by
> GetData / Issue. As this makes the game unusable is it perhaps an option to
> turn it into a TRACE? Normally I don't like covering bugs like thi
The bug I am referring to, that prevents steam from running is:
http://bugs.winehq.org/show_bug.cgi?id=3293
Hmm. it looks like
---> CALL
0011:Call kernel32.VirtualAlloc(0080,2000,1000,0004)
ret=20d13a13
0011:Call
ntdll.NtAllocateVirtualMemory(,7fcae0fc,0
I gave Counter-Strike: Source a try under WINE tonight to see what kind
of results I get on my system (ATI9600XT w8.18 drivers, AMD2000+). It
was a pre-existing install that I had set up to run under both Windows
98 and Cedega.
After overriding the necessary DLLs, Steam gets past the logon... I'
If it stops for you while it upgrades itself (on 26%-27%). Then just kill wine
and restart steam. Eventually it will restart itself and continue from point
where it crashed.
That's a different bug...which, by the way was closed FIXED, and now I
don't think it was FIXED anymore - I ran into t
Monday, October 24, 2005, 5:19:43 PM, Ivan Gyurdiev wrote:
> Roderick Colenbrander wrote:
>>> How is it that you are able to get Steam to work?
>>>
>>> You don't run into:
>>> http://bugs.winehq.org/show_bug.cgi?id=3293
>>>
>>> Do you use any native dlls?
>>>
>>
>> Regarding steam I'm using a
Roderick Colenbrander wrote:
How is it that you are able to get Steam to work?
You don't run into:
http://bugs.winehq.org/show_bug.cgi?id=3293
Do you use any native dlls?
Regarding steam I'm using a native shlwapi and shdocvw for the rest all
native.
Strange... I can't get it to work
Roderick Colenbrander wrote:
Ignore my black screen comment aswell. The cause for it is likely some memory
corruption caused by my D3DERR_NOTAVAILABLE which isn't correct. Will submit
a small patch for the d3d9 CreateQuery bug and will look at other parts.
The reason I was looking into all thi
> Second I believe CreateQuery of d3d9 isn't correct. MSDN states that
> ppQuery can be NULL as explained above. Right now d3d9's CreateQuery
> returns D3DERR_INVALIDCALL when ppQuery is NULL. Further I'm not sure if
> wined3d's CreateQuery is correctly called from d3d9 as ppQuery isn't passed
> t
Ignore my black screen comment aswell. The cause for it is likely some memory
corruption caused by my D3DERR_NOTAVAILABLE which isn't correct. Will submit
a small patch for the d3d9 CreateQuery bug and will look at other parts.
The reason I was looking into all this is that the performance of hl
>
> This patch should fix the problem with Queries
> http://www.winehq.org/pipermail/wine-devel/2005-October/041237.html
>
This patch is not the same as the problem for halflife2. In case ppQuery is
NULL applications can detect if a certain query Type is supported. This
should indeed fail for un
> How is it that you are able to get Steam to work?
>
> You don't run into:
> http://bugs.winehq.org/show_bug.cgi?id=3293
>
> Do you use any native dlls?
Regarding steam I'm using a native shlwapi and shdocvw for the rest all
native.
Roderick
Roderick Colenbrander wrote:
Hi all,
Today I have been doing some experiments with halflife2 and the game works
(atleast if launched through steam in my case) but there are some issues
which I tried to address.
How is it that you are able to get Steam to work?
You don't run into:
http://bug
Hi,
--- Roderick Colenbrander <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> Today I have been doing some experiments with halflife2 and the game works
> (atleast if launched through steam in my case) but there are some issues
> which I tried to address.
>
> The game uses the D3D9 Query mechanism (Cre
Hi all,
Today I have been doing some experiments with halflife2 and the game works
(atleast if launched through steam in my case) but there are some issues
which I tried to address.
The game uses the D3D9 Query mechanism (CreateQuery/Issue/GetData) to
retrieve status information. HL2 uses this al
Simple solution... Announce Wine Release 2004mmdd will be the last "stable"
release and future downloads are at your own risk until further notice then
go ahead and break it. It saves parallel trees and/or branch maintenance
and allows developers to have their way. I would speculate that Wine wou
z which is not on the list and want to run it then it's my problem if
the next release breaks.
>
> From: Lionel Ulmer <[EMAIL PROTECTED]>
> Date: 2004/09/14 Tue PM 04:32:52 GMT
> To: [EMAIL PROTECTED]
> CC: [EMAIL PROTECTED]
> Subject: Re: Re: Directx9
>
&
> To be honest, Wine isn't going to be very useful and adopted until
> there is something that a user can install and know that if I have to update
> to a current verson and I pick the stable version that my apps that are
> running will continue to run.
Well, you perfectly summed up the 'tragedy'
As a user watching this thread here's my comments - Mike is correct. I understand
Wine is not to 1.0 yet (close at .9 ) but we need something that is stable and that
we can run while development is done in the unstable branch. To be honest, Wine isn't
going to be very useful and adopted until
On Tue, Sep 14, 2004 at 09:57:52AM +0100, Mike Hearn wrote:
> I'm reminded of the saying, "if not now then when? if not you then who?"
I think that once the API and the internal infrastructure are stable, the
preconditions for that change are in place.
> >Once Wine is declared to be ready for "or
Lionel Ulmer wrote:
Well, if you are ready to pay the price of stability (i.e. spend at least 4
or 5 hours a week re-installing your 4 or 5 favourite applications to test
for regression), fine :-)
The problem I see is that we do not have the developper manpower to do that.
However, it would be nice
I think that reasoning distracts from the real issue:
creating a stable and an unstable branch incurs an administrative overhead,
one which might simply be too much compared to the gain we'd have without that
overhead because we could concentrate on other things (things which are
still not implemen
On Tue, Sep 14, 2004 at 12:35:21PM +0300, Shachar Shemesh wrote:
> Also, I think the sooner we start treating wine as a mature product, the
> better. Declaring a making a product mature is a great step in making it
> one.
Well, if you are ready to pay the price of stability (i.e. spend at least 4
Hi,
On Tue, Sep 14, 2004 at 11:29:25AM +0100, Mike Hearn wrote:
> Having stable branches doesn't seem to hurt the kernel, X, gnome, kde,
> etc etc. Some people will use the stable branch, the rest will follow
> CVS and hack on that, same as always.
I think that reasoning distracts from the real
Since Lionel is doing the work on Direct X, then I think it's up to him
to decide how it should work and how to move it forward. He's doing it
because he's interested in it, not to make money or keep Wine users
happy. He's doing it because it's interesting and fun. Fun, remember.
I wasn't tal
Mike Hearn wrote:
While this point will come eventually, it has not been reached: ANNOUNCE
starts as follows:
I'm reminded of the saying, "if not now then when? if not you then who?"
Since Lionel is doing the work on Direct X, then I think it's up to him
to decide how it should work and how to m
Mike Hearn wrote:
I don't think it makes any sense to put it off indefinately on the
grounds that Wine is still a developers-only release. That's circular
logic.
Hear hear.
Also, I think the sooner we start treating wine as a mature product, the
better. Declaring a making a product mature is a g
While this point will come eventually, it has not been reached: ANNOUNCE
starts as follows:
I'm reminded of the saying, "if not now then when? if not you then who?"
Once Wine is declared to be ready for "ordinary users", the development
process should indeed change.
And when exactly is that?
"Read
> At *some* point we have to stop simply releasing CVS snapshots which may
> or may not work/run important apps/eat your hard disk and actually do
> proper releases that are, you know, tested'n'stuff.
Also consider that the time wasted on testing/releasing/branching will slow up
wine development,
On Mon, Sep 13, 2004 at 01:55:19PM +0100, Mike Hearn wrote:
> At *some* point we have to stop simply releasing CVS snapshots which may
> or may not work/run important apps/eat your hard disk and actually do
> proper releases that are, you know, tested'n'stuff.
While this point will come eventual
>Anyway, that wasn't really what I was getting at.. last spring Lionel
>had this to say about a wined3d library:
It does make sense to have common code all in the same place...
Ivan.
On Mon, 13 Sep 2004 17:21:51 +0200, Ivan Leo Puoti <[EMAIL PROTECTED]> wrote:
> Things in wine break all the time, users know it and are used to it, if d3d8
> breaks for 3 releases, people will just use an old version until things are
> fixed. Many people stayed at wine-20031212 for months because
> I don't think that a breakage in d3d can be an option now. Wine is an 'old'
> project also if not stable or mature, and breaking stuff now is a big
> problem to users.
Well, if that is the case, we need to recruit someone to do 'proper'
releases as there are no guarantees for now of any stabilit
On Mon, Sep 13, 2004 at 01:55:19PM +0100, Mike Hearn wrote:
> At *some* point we have to stop simply releasing CVS snapshots which may
> or may not work/run important apps/eat your hard disk and actually do
> proper releases that are, you know, tested'n'stuff.
Yes, but what should I care about t
Ivan Leo Puoti wrote:
> if things are broken for a while. A bit like the kernel with 2.4 stable
> and 2.5 full of broken/buggy stuff until 2.6 is ready, and so on. At least
> that's how most projects work.
It's also true that the kernel is not going to branch 2.7 anytime soon.
I don't think that
> If we as a project are committed to doing 0.9, 1.0+ releases it means we
> can't simply break code people are using to play their games for months
> at a time and shrug it off
After 1.0 there will be a stable and a development branch, the stable one for
users, and the development one for new st
Well, why could we not live with DX8 / DX9 breakage for some time ? At the
time D3D was resurected, it was broken for most of the time (and probably
still is :-) ).
And if someone disappears from development, it's just more motivations for
others to pick up the work and continue (which would be mor
> I'd appreciate thoughts before I start (especially Lionels, AJ's etc) - I'm
> only just getting back into wine programming again hence my interest.
I would be for solution 1) even if it means breaking somewhat D3D8 for some
time. Note that this was Raphael's plan (although his was even more
ambi
> This is the sort of thing we wanted arch for. Unfortunately, the way we
> use CVS means that we can't really do branching as only AJ commits. So,
> if it's not possible to do the migration without breaking things
> temporarily, there are three ways forward:
Well, why could we not live with DX
My other concern is if I start doing it and have to give up due to work or
other pressures, I could leave a half migrated setup. I assume its
relavitevly easy with cvs to back out changes if this occurs, and I hope it
wont, but it is a concern.
I'd appreciate thoughts before I start (especially Lio
Hello,
I've spoken with the wine-d3d people and noone is currently doing anything
on directx9 support. Originally Raphael was trying to merge things into a
new library, wined3d, using an interface which ddraw could also use. This
has not happened, and as we stand there is no progress being
62 matches
Mail list logo
