Hi Roderick,
Your pixel format patches caused a regression in half-life 1 for me with the
fglrx drivers. It refuses to start in opengl mode and
reports "ChoosePixelFormat failed", and then comes up in software(ddraw)
mode. The d3d mode still works fine. This problem also does not occur with
the
Hi,
> Problem with WineD3D on top of WGL is that we lost many of usefull APIs
> I think WineD3D on top of x11drv (as WGL on top of x11drv) should a the
> better way
WineD3D on top of WGL has the advantage that we can use our D3D libraries in
windows too. This can be useful for testing(no other lib
Am Montag 21 August 2006 19:22 schrieb Paul Vriens:
> On Mon, 2006-08-21 at 15:13 +0200, Sebastian Schlingmann wrote:
> > Hi everybody,
> >
> > I noticed yesterday that the gothic 1/2 demos don't work anymore.
> >
> > Console output is the following:
> >
> > ...
> > err:ntdll:RtlpWaitForCriticalSec
Hi,
How does wine work/perform with other opensource X servers, like nano Xserver.
Thanks,
VJ
> The biggest issue I had when porting was the OpenGL extensions. All
> extensions
> had to be called through the wgl thunks to get the calling conventions
> right,
> but that isn't hard, just a little extra initial work.
>
> - Aric
>
>
I have done the same a while ago. The calling convention
Monday, August 21, 2006, 8:45:02 PM, Juan Lang wrote:
> Hi folks, I'm trying to debug an access (by native userenv.dll in my case,
> but also by MS Money 2006) to address 0x7ffe02c0. This is my
> understanding so far:
> The TEB is at 0x7ffe, so, according to winternl.h, offset 0x02c0
> within
"Colin Pitrat" <[EMAIL PROTECTED]> wrote:
How is it easier to do
cvs -z3 -d:pserver:[EMAIL PROTECTED]:/home/wine co -P wine
than
git clone git://source.winehq.org/git/wine.git wine
In both case, you just have to copy/paste the command line from the web
page.
Right. But if you compare the si
Raphael club-internet.fr> writes:
> > This would solve the issues. I was also thinking about layering WineD3D on
> > top of WGL also for the sake of portability and it will allow us to use
> > WineD3D on Windows for testing purposes. It would be usefull if our opengl
> > can atleast handle windowe
Hi folks, I'm trying to debug an access (by native userenv.dll in my case,
but also by MS Money 2006) to address 0x7ffe02c0. This is my
understanding so far:
The TEB is at 0x7ffe, so, according to winternl.h, offset 0x02c0
within it is in the middle of GDI_TEB_BATCH. That doesn't make any se
Nick Law wrote:
> Hi Tony / Chris
>
> Is there someway of storing a patch on the winehq/appdb domain so that
> I can put a link on the APPDB page to it, rather than use links to
> other places like thehandofagony (which doesn't look like the sort of
> place we should be using). I've been using rapi
> >-if (HIWORD(function->entry.pszOID &&
> >- !strcasecmp(function->entry.pszOID, pszOID)))
> >
> >
>
> Looks like HIWORD(function->entry.pszOID is just missing a closing
> bracket to me.
Hee hee! Thanks.
--Juan
Juan Lang wrote:
This seems like voodoo to me too, but the combined condition if statement
would always fail for me, while two distinct if statements succeed.
ChangeLog:
- add a couple traces to make following execution easier
- expand an if condition to work around an apparent gcc bug
-
On Monday 21 August 2006 21:22, Jeff Latimer wrote:
> Mike I suppose that the problem is that wrapping your mind around git
> and working out how to handle patches, especially as it takes time to
> get them accepted, revert them and manage trees etc is difficult.
The way git does version control
* On Mon, 21 Aug 2006, EA Durbin wrote:
>
> > How is it easier to do
> > cvs -z3 -d:pserver:[EMAIL PROTECTED]:/home/wine co -P wine
> >
> > than
> > git clone git://source.winehq.org/git/wine.git wine
>
> because git doesn't seem to work on my machine,
EA, so this simply means my notes on taki
On Mon, 2006-08-21 at 15:13 +0200, Sebastian Schlingmann wrote:
> Hi everybody,
>
> I noticed yesterday that the gothic 1/2 demos don't work anymore.
>
> Console output is the following:
>
> ...
> err:ntdll:RtlpWaitForCriticalSection section 0x7fe90020 "heap.c: main
> process heap section" wait
Hi everybody,
I noticed yesterday that the gothic 1/2 demos don't work anymore.
Console output is the following:
...
err:ntdll:RtlpWaitForCriticalSection section 0x7fe90020 "heap.c: main
process heap section" wait timed out in thread 000f, blocked by 0009,
retrying (60 sec) err:ntdll:RtlpWaitFor
How is it easier to do
cvs -z3 -d:pserver:[EMAIL PROTECTED]:/home/wine co -P wine
than
git clone git://source.winehq.org/git/wine.git wine
because git doesn't seem to work on my machine, and I've never had problems
with the tried and trusted CVS, I'm familiar with CVS as are the majority of
EA Durbin wrote:
>
> if your not going to be submitting any patches its easier to get wine
> from CVS than GIT.
>
How is it easier to do
cvs -z3 -d:pserver:[EMAIL PROTECTED]:/home/wine co -P wine
than
git clone git://source.winehq.org/git/wine.git wine
In both case, you just have to copy/paste
Jeff Latimer wrote:
Mike I suppose that the problem is that wrapping your mind around git
and working out how to handle patches, especially as it takes time to
get them accepted, revert them and manage trees etc is difficult. I
don't know about other but I have had a number of perplexing and
If CVS goes, is there another way to see what patches have been applied to
the tree? The git does not seem to do that for me and cvs.winehq.org is a
fairly easy lookup.
Jeff
You can view the [EMAIL PROTECTED] over newsreader, but I still like the
web interface for CVS to view APPDB code
> In case of non-Nvidia users the indirect rendering
> > > context which shouldn't be needed for pbuffers is very bad, as most
> > drivers
> > > don't accelerate indirect rendering yet. The glxpixmap code should be
> > > rewritten using pbuffers or perhaps there's a different way.
> >
> > what abo
On 8/21/06, Jeff Latimer <[EMAIL PROTECTED]> wrote:
If CVS goes, is there another way to see what patches have been applied to
the tree? The git does not seem to do that for me and cvs.winehq.org is a
fairly easy lookup.
Jeff
To visualize the history just do something like this.
$ gitk -
Mike McCormack wrote:
Jeff Latimer wrote:
If CVS goes, is there another way to see what patches have been
applied to the tree? The git does not seem to do that for me and
cvs.winehq.org is a fairly easy lookup.
If you have a local git tree, "git whatchanged" will give you the
complete c
Jeff Latimer wrote:
If CVS goes, is there another way to see what patches have been applied
to the tree? The git does not seem to do that for me and cvs.winehq.org
is a fairly easy lookup.
If you have a local git tree, "git whatchanged" will give you the
complete commit history.
There's
Alexandre Julliard wrote:
Michael Stefaniuc <[EMAIL PROTECTED]> writes:
Are there any plans to get rid of CVS? I would guess keeping the CVS
tree sync from the git tree is low maintanance so it can be kept around
"forewever".
Yes, as long as it doesn't require any maint
Michael Stefaniuc <[EMAIL PROTECTED]> writes:
> But i also guess that he likes to receive more patches than less. For
> the casual/new Wine patch submitter CVS is easier to use. If those
> submitters do more Wine work they will see the light anyway and migrate
> to git ;)
More patches are good, b
On Mon, Aug 21, 2006 at 11:33:28AM +0200, Michael Stefaniuc wrote:
> > My changes to the website reflect that support for CVS may not last
> > forever...
> Are there any plans to get rid of CVS? I would guess keeping the CVS
> tree sync from the git tree is low maintanance so it can be kept
> arou
Mike McCormack wrote:
>
> Robert Shearman wrote:
>
>> I think we should leave the reference to the CVS tree page (but still
>> add a link to the Git tree). Some people find it easier to work with
>> CVS than Git.
>
>
> I think Alexandre would prefer to receive patch submissions in Git
> format,
In case of non-Nvidia users the indirect rendering
> > context which shouldn't be needed for pbuffers is very bad, as most
> drivers
> > don't accelerate indirect rendering yet. The glxpixmap code should be
> > rewritten using pbuffers or perhaps there's a different way.
>
> what about a flag for
On 21/08/06, Jan Zerebecki <[EMAIL PROTECTED]> wrote:
(I forgot if I verified this, but) I think that when a state is
beeing set This->stateBlock->renderState[State] has the previous
value and only Value has the one to be set. From a quick glance
it seems the code for this renderstate (and maybe
On Saturday 19 August 2006 17:26, Roderick Colenbrander wrote:
> There's one big issue regarding windowed opengl rendering and pbuffers. A
> while ago Huw added some code for bitmap rendering using GLX Pixmaps. In
> the end our wglMakeCurrent checks whether the DC is used for offscreen
> rendering
31 matches
Mail list logo
