> > I did that, I created a new field in the PDEVICE structure and used two
> > new ExtEscape codes (SET_FLAGS/GET_FLAGS), but Alexandre doesn't want to
> > add new ExtEscape codes..
> > That's why I hacked even more on wine and moved the wgl implementation
> > to x11drv... and there they are, my o
> I did that, I created a new field in the PDEVICE structure and used two
> new ExtEscape codes (SET_FLAGS/GET_FLAGS), but Alexandre doesn't want to
> add new ExtEscape codes..
> That's why I hacked even more on wine and moved the wgl implementation
> to x11drv... and there they are, my old patches
Roderick Colenbrander wrote:
> If we could set a pbuffer flag in there and retrieve it in wglMakeCurrent it
> would work. I fear that this can only be done in a clean way if it code would
> be in x11drv :(
>
I did that, I created a new field in the PDEVICE structure and used two
new ExtEscape
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
> 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
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
> 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
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 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
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 or not. If
offscreen rendering is used (there's no distinction betwe
On Monday 14 August 2006 19:57, you wrote:
> Hi Raphael,
Hi Roderick,
sorry for late response i was in holidays (and before that a long moving to my
new apartment)
> I'm not sure how well you are monitoring the wine-devel lists these days,
> so I'm also directing this mail directly to you. I ha
11 matches
Mail list logo
