/'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
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
41 matches
Mail list logo
