On Mar 7, 2013, at 9:39 AM, C.W. Betts wrote:
> It looks like if GL_ARB_shader_objects is defined, then the OS X GLhandleARB
> isn't typedef'd.
I think a better approach is to define __gltypes_h_ just to no-op that whole
header. Does that fix compilation for you? If so, please submit it as a
It looks like if GL_ARB_shader_objects is defined, then the OS X GLhandleARB
isn't typedef'd.
On Mar 6, 2013, at 1:16 PM, Ken Thomases wrote:
> On Mar 6, 2013, at 1:58 PM, C.W. Betts wrote:
>
>> It seems like there's conflicting types for GLhandleARB, one defined by
>> Wine, the other by OS X,
On Mar 6, 2013, at 1:58 PM, C.W. Betts wrote:
> It seems like there's conflicting types for GLhandleARB, one defined by Wine,
> the other by OS X, on Mountain Lion. I assume that the #define __gl_h_ is a
> try to work around the issue, but OS X's gltypes.h still gets included.
Ugh. Thanks for
s/winemac.drv/cocoa_opengl.m
> create mode 100644 dlls/winemac.drv/opengl.c
>
> <0001-winemac-Implement-OpenGL-support.patch>
AddressARB((const GLubyte *)
> "glXGetSyncValuesOML");
> + }
> +
> X11DRV_WineGL_LoadExtensions();
>
> wine_tsx11_unlock();
> @@ -2281,6 +2289,11 @@ static void WINAPI X11DRV_wglGetIntegerv(GLenum pname,
> GLint* params)
> wine_tsx11_unlock();
>
nt* params)
wine_tsx11_unlock();
}
+/* For offscreen-rendered (child) windows, this copies the window
+ * content into to the onscreen window. The caller must have
+ * performed any OpenGL flushing to ensure the gl_drawable is
+ * up-to-date
+ */
void flush_gl_drawable(X11DRV_PDEVICE *phys
> Thanks for looking, both of you!
>
> I'm looking at the GLX1.3 spec at:
> http://www.lri.fr/~mbl/ENS/IG2/docs/glx1.3.pdf
>
> "Sequentiality" has:
> "glXSwapBuffers is in the OpenGL stream if and only if
> the display and drawable are those belonging to the ca
d=25912
>> Long story short, I think the implementation of OpenGL child rendering
>> needs a small update.
>>
>> As a reminder, this is how an OpenGL child window is setup:
>>
>> static BOOL set_win_format( HWND hwnd, XID fbconfig_id ) {
>> gl_dra
Il 08 febbraio 2012 18:19, Brian Bloniarz ha scritto:
> Hi all,
>
> I could use a little help fixing a window lag and screen corruption
> issue in SketchUp:
> http://bugs.winehq.org/show_bug.cgi?id=25912
> Long story short, I think the implementation of OpenGL child renderi
Hi all,
I could use a little help fixing a window lag and screen corruption
issue in SketchUp:
http://bugs.winehq.org/show_bug.cgi?id=25912
Long story short, I think the implementation of OpenGL child rendering
needs a small update.
As a reminder, this is how an OpenGL child window is setup
I guess if you can reproduce the same exact frames, then probably you
can get real FPS your videocard might crunch, duplicated operation and
maybe improve/exclude paths of code which slow down the 'real' rendering?
Cheers
On 30/09/11 21:15, Henri Verbeet wrote:
On 30 September 2011 22:07, Ema
On 30 September 2011 22:07, Emanuele Oriani wrote:
> This might be useful to understand where some bottlenecks of wined3d might
> be?
> What do you think?
>
Yeah, I'm aware of apitrace, through Mesa. I haven't used it for
debugging wined3d so far, but I probably will at some point. I'm not
sure it
Dear all,
Just wanted to bring to your attention ApiTrace 2.0,
http://zrusin.blogspot.com/2011/09/apitrace-20.html .
Apparently this tool is quite fast and should allow to play back GL
commands, to analyse performance and replay commands.
This might be useful to understand where some bottleneck
way on the wined3d side, and just not exposing any GL based
blitters or 3D rendering.
>>> It will make it impossible to run some apps out of the box(e.g. the ones
>>> currently affected by bug 2082, and old QuickTime versions). That's fine
>>> with
>> I'm not s
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 31.08.2011 um 12:29 schrieb Henri Verbeet:
> On 31 August 2011 10:58, Stefan Dösinger wrote:
>> This will break 2D-only apps in situations where OpenGL is not available. It
> Well, DirectDraw 2D-only applications, but yes. All thr
On 31 August 2011 10:58, Stefan Dösinger wrote:
> This will break 2D-only apps in situations where OpenGL is not available. It
Well, DirectDraw 2D-only applications, but yes. All three people in
that situation should either install a software GL renderer or
explicitly set the "DirectDraw
> surface implementation switching code every time I try to fix something in
> ddraw.
This will break 2D-only apps in situations where OpenGL is not available. It
would be a good idea to use SURFACE_GDI automatically in those situations.
(I'm not sure if ddraw without GL works at all
capitalisation follows the 550 renderer, using "Ti"
> rather than "TI", and the advertising supports the capital-T lowercase-i
> version.
>
> Now, some questions.
> 1) Can anyone confirm that the GTX 560 Ti is detected correctly via the
> OpenGL renderer string,
In dlls/wined3d/directx.c video cards are identified by string comparisons
to the OpenGL renderer string. I recently added support for the GTX 550 Ti,
so I spent a bit of time perusing the code. The GTX 560 Ti is identified by
the string "GeForce GTX 560 TI" but noticed that on my s
Microsoft Windows 7 Professional.
The test profiles used had included OpenArena, Urban Terror, Warsow,
Nexuiz, Lightsmark, Unigine Sanctuary, Unigine Tropics, and Unigine
Heaven. The OpenGL renderer was used with all of them...
>From this first round of 2010 Wine vs. Ubuntu vs. Windows 7 testing it
is t
On Wed, Jul 28, 2010 at 3:12 PM, Dan Kegel wrote:
> Siggraph happens to be a stone's throw from my house
> this year, and one of the presenters was my frosh roommate :-),
> so I'm heading over to the opengl BOF to listen in.
> ( http://www.khronos.org/news/events/d
Siggraph happens to be a stone's throw from my house
this year, and one of the presenters was my frosh roommate :-),
so I'm heading over to the opengl BOF to listen in.
( http://www.khronos.org/news/events/detail/siggraph-la-2010/#topengl_bof )
Email me or google chat me if you want me
On 14 April 2010 11:08, Florian Köberle wrote:
> You have worked on quite a few bugs I have voted for. Would be buying
> Crossover Games (again) the correct way to support your work?
>
In principle, yes. Though in all fairness it should also be noted that
Wine is the work of many people, not all o
Hello Henri,
your patch fixes bug 12611:
http://bugs.winehq.org/show_bug.cgi?id=12611
Thanks for your great work!
You have worked on quite a few bugs I have voted for. Would be buying
Crossover Games (again) the correct way to support your work?
Best regards,
Florian
On Wed, Mar 3, 2010 at 4:55 AM, Stefan Dösinger wrote:
>
> Am 02.03.2010 um 18:39 schrieb Henri Verbeet:
>> (I also still haven't seen anyone make a *convincing* argument for why
>> we'd want to have a "somewhat working, but not quite" wined3d if we
>>
Am 02.03.2010 um 18:39 schrieb Henri Verbeet:
> (I also still haven't seen anyone make a *convincing* argument for why
> we'd want to have a "somewhat working, but not quite" wined3d if we
> don't have OpenGL in the first place.)
In the past there have been tw
;> do is. Due to it our wglGetProcAddress won't function because it
>> relies on glXGetProcAddress.
>>
>> Our use of wglGetProcAddress isn't correct (but it works on WINE :))
>> in the sense that officially an OpenGL context must be around. Perhaps
>> I should fix this b
s on glXGetProcAddress.
>
> Our use of wglGetProcAddress isn't correct (but it works on WINE :))
> in the sense that officially an OpenGL context must be around. Perhaps
> I should fix this behavior in gdi32 and in wined3d. It would allow for
> a nicer fix than adjusting the USE_
n't seen anyone make a *convincing* argument for why
we'd want to have a "somewhat working, but not quite" wined3d if we
don't have OpenGL in the first place.)
t works on WINE :))
in the sense that officially an OpenGL context must be around. Perhaps
I should fix this behavior in gdi32 and in wined3d. It would allow for
a nicer fix than adjusting the USE_GL_FUNC macro.
I'm not sure about the shader backend part of the patch (I don't know
that code w
On Thu, 17 Sep 2009, Saulius Krasuckas wrote:
[...]
> Could these be of any use for our graphic guys -- Stefan and co.?
It might be the other way around; that is maybe our graphics guys can
help the Glean and Piglit developpers.
Quite often they discover some bug in OpenGL. But if neither Gl
2009/9/18 Austin English :
> On Thu, Sep 17, 2009 at 3:16 PM, Henri Verbeet wrote:
>> Possibly, but it would have to be in the context of a larger framework
>> like e.g. CxTest or Appinstall.
>
> Would it actually be useful? I can take a look, but not if it's going
> to be a lot of effort for litt
On Thu, Sep 17, 2009 at 3:16 PM, Henri Verbeet wrote:
> 2009/9/17 Saulius Krasuckas :
>
>> Then there is PerceptualDiff utility I found some time ago [3]. Guessed,
>> could it also usefull for finding visual regressions of Wine? Probably
>> not, as it seems to be used for testing video codecs (b
* On Thu, 17 Sep 2009, Henri Verbeet wrote:
> * 2009/9/17 Saulius Krasuckas :
> >
> > Could these be of any use for our graphic guys -- Stefan and co.?
>
> Well, they're mostly useful when you're maintaining an OpenGL driver.
> Mesa already uses these.
And what
2009/9/17 Saulius Krasuckas :
> Today I saw two similar projects related to OpenGL:
>
> [1]:
>
>> glean is a suite of tools for evaluating the quality of an OpenGL
>> implementation and diagnosing any problems that are discovered. glean
>> also has the ability to comp
Today I saw two similar projects related to OpenGL:
[1]:
> glean is a suite of tools for evaluating the quality of an OpenGL
> implementation and diagnosing any problems that are discovered. glean
> also has the ability to compare two OpenGL implementations and highlight
> the
to a MS-Windows program?
No, it doesn't, and I don't think we're doing anything useful right now with
the parsed driver version. We only use the parsed OpenGL version, which is
the same format everywhere.
Once upon a time we passed that version to the windows game, but as you said,
On Mon, May 25, 2009 at 12:18 PM, wrote:
> Hi,
>
> as of wine-1.1.21, wine does not recognize the "early 2009" Mac Mini
> OpenGL version string from nVidia:
> err:d3d_caps:IWineD3DImpl_FillGLCaps Invalid nVidia version string: "2.0
> NVIDIA-1.5.44"
&
Hi,
as of wine-1.1.21, wine does not recognize the "early 2009" Mac Mini
OpenGL version string from nVidia:
err:d3d_caps:IWineD3DImpl_FillGLCaps Invalid nVidia version string: "2.0
NVIDIA-1.5.44"
The string probably originates from XQuartz' X11.2.3.3.2. The wine
so
Am Mittwoch, 8. April 2009 16:16:06 schrieb John Whitlock:
> For my curiosity, why can't we use /proc for card detection?
Because it isn't portable. Wine runs not only on Linux, but also on Solaris,
Mac OS X, *BSD, ...
,
>
> First of all this are basically two changes in one patch. Keep the vendor
> one separated from the device string. Second the opengl renderer string
> shouldn't be directly returned. In short d3d apps can query the pci id and
> opengl doesn't expose it (we aren't
Hi John,
First of all this are basically two changes in one patch. Keep the vendor
one separated from the device string. Second the opengl renderer string
shouldn't be directly returned. In short d3d apps can query the pci id and
opengl doesn't expose it (we aren't allowed to use
Hi John,
Unfortunately this patch isn't correct. If we report a different string we
have to report the right strings like in case of the vendor the right driver
name e.g. for Nvidia that is 'nv4_disp.dll'. In case of the board name we
also need to report the right string (the name of the board we
Chris Robinson a écrit :
> On Saturday 21 February 2009 2:00:26 pm Jérôme Gardou wrote:
>
>> according to
>> http://msdn.microsoft.com/en-us/library/dd374387(VS.85).aspx,
>> wglMakeCurrent proceeds a flush before switching.
>>
> glXMakeCurrent also forces a flush:
> http://www.opengl.org/do
On Saturday 21 February 2009 2:00:26 pm Jérôme Gardou wrote:
> according to
> http://msdn.microsoft.com/en-us/library/dd374387(VS.85).aspx,
> wglMakeCurrent proceeds a flush before switching.
glXMakeCurrent also forces a flush:
http://www.opengl.org/documentation/specs/man_pages/hardcopy/GL/html/gl
Le Friday 26 December 2008 22:35:18 Vincent Pelletier, vous avez écrit :
> I'm not sure where to add it. I've added some line in
> d3d9/tests/visual.c:pointsize_test (attached too). As I wrote that
> test to succeed on wine and did not run it on any windows version, I
> would be happy if someone co
Le Friday 26 December 2008 22:35:18 Vincent Pelletier, vous avez écrit :
> As I guess IWineD3DDeviceImpl_CreateTexture should then return a
> failure code, I patched it and made the test give up if texture
> allocation failed. (patch attached)
Updated to test previous return code, instead of acces
Woops, re-sending to list this time...
On Wed, Dec 24, 2008 at 4:01 PM, Stefan Dösinger
wrote:
> I think henri sent a reply. He recommended to clamp the new pointsize
> instead of leaving the old one set.
Found it. Wasn't subscribed here at that time (only to -patches).
New version of previous
q.org] On Behalf Of Vincent Pelletier
> Sent: Tuesday, December 23, 2008 7:31 PM
> To: wine-devel@winehq.org
> Subject: [RFC] wined3d: Avoid triggering OPENGL errors when setting
> point size
>
> (Resent, originally sent to -patches... Sorry)
>
> If WINED3DRS_POINTSCALEENABLE
(Resent, originally sent to -patches... Sorry)
If WINED3DRS_POINTSCALEENABLE is false and WINED3DRS_POINTSIZE render state is
set to an invalid size, glPointSize will fail.
This happens in "Black & White 2", causing log/stderr to be flooded with
opengl errors.
I'm not sur
2008/12/23 Vincent Pelletier :
> If WINED3DRS_POINTSCALEENABLE is false and WINED3DRS_POINTSIZE render state is
> set to an invalid size, glPointSize will fail.
> This happens in "Black & White 2", causing log/stderr to be flooded with
> opengl errors.
>
> I'm
Hi Dmitry,
Dmitry Timoshkov schreef:
> "Maarten Lankhorst" wrote:
>
>> Needed to get +relay working in wine64
>
> You should have used CDECL instead of __cdecl, have a look how it's
> done in msvcrt.dll.
In msvcrt both were used, so that doesn't really help. I guess that
confused me a little. se
Maarten Lankhorst writes:
> @@ -33,9 +33,9 @@
> WINE_DEFAULT_DEBUG_CHANNEL(bitmap);
>
>
> -static HGDIOBJ BITMAP_SelectObject( HGDIOBJ handle, HDC hdc );
> -static INT BITMAP_GetObject( HGDIOBJ handle, void *obj, INT count, LPVOID
> buffer );
> -static BOOL BITMAP_DeleteObject( HGDIOBJ hand
"Maarten Lankhorst" wrote:
> Needed to get +relay working in wine64
You should have used CDECL instead of __cdecl, have a look how it's
done in msvcrt.dll.
--
Dmitry.
Huw Davies <[EMAIL PROTECTED]> writes:
> Ok, I'll send in a patch with todo_wine and let you decide.
>
> My feeling was that without opengl support we should skip the opengl32
> tests, hence the skip in the original patch. The todo_wine was to
> flag Wine's Choose
rs without glX. The
> > win_skip results in a test failure. My patch was intended to mark
> > this as a todo_wine.
>
> We could have a todo_wine around the win_skip, though I'm not quite
> convinced that having the opengl32 test succeed without opengl support
> is
his as a todo_wine.
We could have a todo_wine around the win_skip, though I'm not quite
convinced that having the opengl32 test succeed without opengl support
is the right thing to do.
--
Alexandre Julliard
[EMAIL PROTECTED]
ies <[EMAIL PROTECTED]>
> Date: Fri Dec 5 14:19:25 2008 +
>
> opengl/tests: Skip tests if we can't find a pixel format.
>
> ---
>
> dlls/opengl32/tests/opengl.c |9 -
> 1 files changed, 8 insertions(+), 1 deletions(-)
>
> diff --git
On Fri, Dec 05, 2008 at 03:25:56PM +0100, Paul Vriens wrote:
> This looks a bit strange:
>
> +if(iPixelFormat == 0)
> +{
> +todo_wine ok(iPixelFormat > 0,
>
>
> Is it your intention to just throw up a failed message in all cases?
Hi Paul,
It was my intention to thro
Huw Davies wrote:
> ---
> dlls/opengl32/tests/opengl.c |8
> 1 files changed, 8 insertions(+), 0 deletions(-)
>
>
>
>
>
Hi Huw,
This looks a bit strange:
+if(iPixelFormat == 0)
+{
+
Hello Chris Robinson,
A long time ago you wrote in
http://www.winehq.org/pipermail/wine-devel/2007-October/059550.html
that you got my example program running:
"If I force offscreen rendering and add the flag, the demo works."
Could you have a look at the following bug report and may explain how
On Tuesday 30 September 2008 02:11:17 am Florian Köberle wrote:
> A long time ago you wrote in
> http://www.winehq.org/pipermail/wine-devel/2007-October/059550.html
> that you got my example program running:
>
> "If I force offscreen rendering and add the flag, the demo works."
>
> Could you have a
t; "Creation of an OpenGL 3.0 context failed!\n");
I'm not sure it should be considered a test failure if GL3 isn't supported..
Hi,
2008/7/24 Michael Karcher <[EMAIL PROTECTED]>:
>
> What is the advantage of that compared to
>major = strtol(gl_string, &gl_string_cursor,10);
> ?
>
> Or even replace the whole scanning code by
>
>if(sscanf(gl_string, "%d.%d", &major, &minor) != 2)
>ERR_(d3d_cap
Am Donnerstag, den 24.07.2008, 00:55 +0800 schrieb Huang, Zhangrong:
> Hi,
> I tried run World of Warcraft on Mac OS X with X11 and NVIDIA card,
> got the following error messages:
>
> err:d3d_caps:IWineD3DImpl_FillGLCaps Invalid nVidia version string:
> "1.5 NVIDIA-1.5.24"
> err:d3d_caps:IWineD3D
(64-bit Ubuntu -> 32-bit app,
>> Linux environment -> Windows libraries, Linux build platform ->
>> Windows binaries), making my setup pretty fragile.
>
> 64-bit Linux should run 32-bit Windows binaries fine with Wine.
> OpenGL apps,
> too. Of course you'll need
virtual machine running the real thing.
> There are so many levels of abstraction (64-bit Ubuntu -> 32-bit app,
> Linux environment -> Windows libraries, Linux build platform ->
> Windows binaries), making my setup pretty fragile.
64-bit Linux should run 32-bit Windows bi
Am 17.07.2008 um 01:04 schrieb Stefan Dösinger:
>> -lopengl32 -lglu32 -o OpenGLBase.exe OpenGLBase.cpp
>> /tmp/cclajgrA.o:OpenGLBase.cpp:(.text+0x10e): undefined reference to
>> [EMAIL PROTECTED]'
> I think this is in gdi32.dll
Thanks for the suggestion. Tried to add them, but it doesn't ma
Am 17.07.2008 um 00:56 schrieb Chris Robinson:
> On Wednesday 16 July 2008 03:38:37 pm Markus Hitter wrote:
>> maybe I'm just missing the obvious, but I can't get my small one-file
>> app to link. As I've just built Wine from scratch on this box,
>> everything should be installed, including libGL
> -lopengl32 -lglu32 -o OpenGLBase.exe OpenGLBase.cpp
> /tmp/cclajgrA.o:OpenGLBase.cpp:(.text+0x10e): undefined reference to
> [EMAIL PROTECTED]'
I think this is in gdi32.dll
On Wednesday 16 July 2008 03:38:37 pm Markus Hitter wrote:
> maybe I'm just missing the obvious, but I can't get my small one-file
> app to link. As I've just built Wine from scratch on this box,
> everything should be installed, including libGL... in /usr/lib32:
Try linking with MinGW's libs, not
Hello all,
maybe I'm just missing the obvious, but I can't get my small one-file
app to link. As I've just built Wine from scratch on this box,
everything should be installed, including libGL... in /usr/lib32:
[EMAIL PROTECTED]:~/Wine Apps/GPWiki Framework$ make
i586-mingw32msvc-g++ -pipe -mw
tion handler is the
right way anyway, but i lack knowledge of opengl, so i'll shut up for now ;) )
__
Not happy with your email address?.
Get the one you really want - millions of new email addresses available now at
Yahoo! http://uk.docs.yahoo.com/ymail/new.html
n a glGetString(),
> which accepts a scalar value and returns a static string pointer.
> No dynamic data, no bad pointers outside it.
> So it must be a crash INSIDE opengl code.
> It's called (wrongly) without an opengl context, but that's how autocad
> installer does, so
Chris Robinson ha scritto:
> On Saturday 28 June 2008 07:51:53 am Massimo Del Fedele wrote:
>> Roderick Colenbrander ha scritto:
>>> Hi,
>>>
>>> I don't think we want to go this way. First of all we want to emulate
>>> win32 opengl. If windows doe
On Saturday 28 June 2008 07:51:53 am Massimo Del Fedele wrote:
> Roderick Colenbrander ha scritto:
> > Hi,
> >
> > I don't think we want to go this way. First of all we want to emulate
> > win32 opengl. If windows does this we MIGHT have to do something like
>
Hi,
I don't think we want to go this way. First of all we want to emulate win32
opengl. If windows does this we MIGHT have to do something like this. Second
all opengl calls hit ENTER_GL / LEAVE_GL and these few extra calls affect
performance.
Personally I think that when you are hitting
On Sat, May 10, 2008 at 12:46 AM, Roderick Colenbrander
<[EMAIL PROTECTED]> wrote:
>> On a whim, I tried the oldest SPEC OpenGL benchmark, SPECviewperf 6.
>>
>> SPECViewperf 6.1.2 lives here:
>> http://www.spec.org/gwpg/pastissues/Feb2_02/opc.static/opcview.htm
Jeff Zaroyko wrote:
Roderick Colenbrander gmx.net> writes:
On a whim, I tried the oldest SPEC OpenGL benchmark, SPECviewperf 6.
On one machine,
$ cd ".wine/drive_c/Program Files/SPECopc/SPECviewperf 6.1.2"
$ wine cmd /c RunLight04.bat
produced a proud 3 frames per second
Roderick Colenbrander gmx.net> writes:
>
> > On a whim, I tried the oldest SPEC OpenGL benchmark, SPECviewperf 6.
> > On one machine,
> > $ cd ".wine/drive_c/Program Files/SPECopc/SPECviewperf 6.1.2"
> > $ wine cmd /c RunLight04.bat
> > produce
> On a whim, I tried the oldest SPEC OpenGL benchmark, SPECviewperf 6.
>
> SPECViewperf 6.1.2 lives here:
> http://www.spec.org/gwpg/pastissues/Feb2_02/opc.static/opcview.htm
> It's also downloadable from
> ftp://spec.it.miami.edu/dist/gpc/opc/viewperf/specviewperf612is01.e
On a whim, I tried the oldest SPEC OpenGL benchmark, SPECviewperf 6.
SPECViewperf 6.1.2 lives here:
http://www.spec.org/gwpg/pastissues/Feb2_02/opc.static/opcview.htm
It's also downloadable from
ftp://spec.it.miami.edu/dist/gpc/opc/viewperf/specviewperf612is01.exe
So far, the two tests
; The visual.c's are skipping properly now for me, but there's a
> regression in opengl/opengl.c.
>
> ../../../tools/runtest -q -P wine -M opengl32.dll -T ../../.. -p
> opengl32_test.exe.so opengl.c && touch opengl.ok
> err:wgl:X11DRV_wglCreateContext Cannot get F
[opengl32/tests/__test__] Error 2
make[2]: *** [msg.ok] Error 24
make[1]: *** [user32/tests/__test__] Error 2
make: *** [dlls/__test__] Error 2
The visual.c's are skipping properly now for me, but there's a
regression in opengl/opengl.c.
../../../tools/runtest -q -P wine -M opengl3
Am Freitag, 22. Februar 2008 23:31:43 schrieb Roderick Colenbrander:
> Hi,
>
> In the default backbuffer based renderer in WineD3D the front and
> backbuffer share the same pixel format while D3D itself decouples them. A
> lot of applications use alpha on the backbuffer, so make sure we have
> alph
On 05/02/2008, Stefan Dösinger <[EMAIL PROTECTED]> wrote:
> Am Dienstag, 5. Februar 2008 09:34:50 schrieb H. Verbeet:
> > On 05/02/2008, Stefan Dösinger <[EMAIL PROTECTED]> wrote:
> >
> > I was aware of this issue, but technically these resources should be
> > stored in the shader backend, not the
Am Dienstag, 5. Februar 2008 09:34:50 schrieb H. Verbeet:
> On 05/02/2008, Stefan Dösinger <[EMAIL PROTECTED]> wrote:
>
> I was aware of this issue, but technically these resources should be
> stored in the shader backend, not the device.
Well, the textures are per device, and for now the shader ba
On 05/02/2008, Stefan Dösinger <[EMAIL PROTECTED]> wrote:
>
I was aware of this issue, but technically these resources should be
stored in the shader backend, not the device.
so filter "extensions"
imported from higher opengl base versions
signature.asc
Description: This is a digitally signed message part.
The clearest way to do this would probably be to simply do the
disabling in a separate loop over the disabled extensions string,
similarly to how we detect the extensions.
g strstr to check
for an opengl extension in an extension list is discourage because it can
find false positives. Especially in this case, if you have, say:
wined3d_settings.disabled_extensions = "GL_NV_texture_shader3
GL_NV_vertex_program2_option GL_NV_vertex_program3"
Then if you chec
"Juan Lang" <[EMAIL PROTECTED]> writes:
> So please, do log that bug, and include the commit that broke it.
it's been reported as bug 10234.
--alex--
--
| I believe the moment is at hand when, by a paranoiac and active |
| advance of the mind, it will be possible (simultaneously with |
| au
> should i attach the backtraces to the bug submission?
Yes, attach them as text file attachments to the bug. Thanks very much!
--Juan
"Juan Lang" <[EMAIL PROTECTED]> writes:
> So please, do log that bug, and include the commit that broke it.
should i attach the backtraces to the bug submission?
--alex--
--
| I believe the moment is at hand when, by a paranoiac and active |
| advance of the mind, it will be possible (simulta
> i thought somebody else who knows more about this might find the traces
> of interest. i didn't simply just post back traces, i spent a whole day using
> git-bisect and recompiling wine until i found the commit that broke things
> for me.
Yes, I know you did more than _just_ post backtraces. Bu
"Juan Lang" <[EMAIL PROTECTED]> writes:
>> wine: Unhandled page fault on read access to 0x at address
>> 0x7da22648 (thread 0014), starting debugger...
>> Unhandled exception: page fault on read access to 0x in 32-bit code
>> (0x7da22648).
>
> Gah, please stop spamming us with fu
> wine: Unhandled page fault on read access to 0x at address 0x7da22648
> (thread 0014), starting debugger...
> Unhandled exception: page fault on read access to 0x in 32-bit code
> (0x7da22648).
Gah, please stop spamming us with full back traces. And if you think
this is a Wine
Alex Romosan <[EMAIL PROTECTED]> writes:
> this was on my thinkpad t40 with a radeon r250 (mobility firegl 9000)
> card using the open source drivers. the program also crashes on my
> desktop with an nvidia card using the proprietary nvidia drivers but i
> don't know if it's the same problem. i'll
Chris Robinson writes:
> On Sunday 28 October 2007 08:00:19 pm Alex Romosan wrote:
>> somewhere between release 0.9.46 and 0.9.47 of wine i started having
>> problems with applications that use opengl. using git-bisect i found
>> that commit 00633e37bcc8da1032f34ea2d87814739
On Sunday 28 October 2007 08:00:19 pm Alex Romosan wrote:
> somewhere between release 0.9.46 and 0.9.47 of wine i started having
> problems with applications that use opengl. using git-bisect i found
> that commit 00633e37bcc8da1032f34ea2d87814739de07db4 (winex11: Use an
> offscree
1 - 100 of 416 matches
Mail list logo
