Michael Karcher wrote:
> Am Dienstag, den 15.07.2008, 15:55 -0700 schrieb Dan Hipschman:
>> if (n < 0) n = 0;
>> size = 12 + min( 300, n * 5 );
>> -dst = res = funcs.get_temp_buffer( n * 5 + 7 );
>> +dst = res = funcs.get_temp_buffer( size );
> This looks like fixing an under-allo
Ben Hodgetts (Enverex) wrote:
> Just in-case anyone was ever curious about how well Wine performs with
> different C/XXFLAGs I did a test today with RC5 to see how much of a
> difference it makes with 3DMark 2001 SE, nothing major but if someone
> can think of a better benchmark to try, please l
Susan Cragin wrote:
> The new default pulseaudio in Hardy screws up every program that isn't gnome,
> delivering terrible sound.
> https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/198453
Applications that use ALSA should work fine with the alsa pulse plugin -
should. Unfortunately th
Vincent Povirk wrote:
> On Tue, Mar 4, 2008 at 12:53 PM, Alexander Nicolaysen Sørnes
> <[EMAIL PROTECTED]> wrote:
>> I'm not sure if we should remove the option for 'fully functional, requires
>> hacks'. A lot of people come to the AppDB to find out how they can make
>> their apps work, and are
Jan Zerebecki wrote:
> On Sun, Feb 24, 2008 at 12:05:46PM +0100, Tomas Carnecky wrote:
>> All wine apps are identified as 'ALSA plug-in [wine-preloader]' in the
>> PA daemon, so you can't set per-app volume and sinks since all wine apps
>> show up unde
Jan Zerebecki wrote:
> On Fri, Feb 22, 2008 at 01:50:09AM +0100, Tomas Carnecky wrote:
>> nifty features, like per-app volume, transparent sink switching
>> etc, some of which are impossible to emulate through the alsa
>> pulse plugin.
>
> Which features can't
Stefan Dösinger wrote:
> Am Freitag, 22. Februar 2008 01:50:09 schrieb Tomas Carnecky:
>> I switched my desktop to PA yesterday, got most apps working, and to my
>> surprise even flash (netscape 32bit plugin in a 64bit browser). All apps
>> that I need use PA natively, only W
This subject was discussed a few months ago (around 10/2007). But it was
rather a discussion about whether to make a PA sound driver or not. I
personally would love to see that happen, if not only because PA has
some very nifty features, like per-app volume, transparent sink
switching etc, some
James McKenzie wrote:
> Please also be aware that Wine will NOT build properly with any version
> of gcc 4.0
>
Can you elaborate? I have been building wine with gcc-4.* since forever
and never had any problems with that. Currently I'm using gcc 4.2.2
(Gentoo 4.2.2 p1.0).
tom
Stefan Dösinger wrote:
> Am Sonntag, 18. November 2007 17:13:20 schrieb Lionel Tricon:
>> Hi wine list,
>>
>> I am currently working for the next generation of the klik project (1
>> application = 1 file) and we actualy face some troubles with picasa which
>> is running under linux thanks to wine.
Reece Dunn wrote:
> I am interested in the Wine project, and my manager at work has
> accepted my request to work on it.
>
> I work for a company that develops Windows software, so as I have
> access to Visual Studio, and thus the sources for ATL, MFC and the
> msvc runtime (provided with the full
+
+hr = IDirect3DDevice9_Clear(device, 0, NULL, D3DCLEAR_TARGET,
0xff00ff00, 0.0, 0);
+ok(hr == D3D_OK, "IDirect3DDevice9_CreatePixelShader returned
%s\n", DXGetErrorString9(hr));
Is that worth changing?
tom
Maarten Lankhorst wrote:
> Last time I tried using alloca in alsa volume control it was rejected,
> so I'm just walking safe path.
Well the existing coded uses alloca() ... just saw this while compiling
wine (winealsa.drv):
waveout.c: In function 'wodOpen':
waveout.c:582: warning: the address of
Maarten Lankhorst wrote:
> Sanity check to see if device can be opened or not
Is alloca() not allowed in wine? (asking because you allocate hw_params
on the stack, but it's freed if the function exits, so it's only used
inside this one function).
tom
Chris Rankin wrote:
> With the update of dlls/winex11.drv/opengl.c from revision 1.103 to 1.104,
> World of Warcraft no
> longer starts in OpenGL mode. WoW complains that my graphics card does not
> have "dual-TMU
> support". (I have a Radeon R200 with Mesa 7.1)
http://bugs.winehq.org/show_bug.c
This type of construct seems popular in the wine source:
while (isspace(*GL_Extensions)) GL_Extensions++;
Start = GL_Extensions;
Or even worse (I've seen this in winex11.drv, and it took me quite a
long time until I understood it - it was part of a larger block with a
lot these constructs):
from the patch:
return physDev->current_pf;
+ TRACE("(%p): returns %d\n", physDev, physDev->current_pf);
}
What's the purpose of that TRACE() ?
tom
Vitaliy Margolen wrote:
Tomas Carnecky wrote:
This patch introduces a new registry key, "FocusDesktopWindow", that
can be used to specify whether wine should set the foreground window
to the desktop window after the last wine app looses focus. The
default is enabled (the same behav
Tomas Carnecky wrote:
The solution? Remove [1] (to process the FocusIn event) or remove
InputHint from WM_HINTS. That would fix around the missing sound.
Anyhow, 'sound while WoW lost focus' will be lost forever and I imagine
there's no way to make that possible again but using
Commit d836a5062141dd42293ed044debbaf25f914f383 broke sound in World of
Warcraft. Yes, it sound strange but after I analyzed the issue it makes
perfectly sense: a commit to dlls/winex11.drv/event.c broke sound.
According to the wine source and the ICCCM spec, wine uses either the
'Passive' or
Please don't apply, it's wrong. In the case when Wine was compiled with
OpenGL support but OpenGL isn't available at runtime these checks are
still needed in every function.
tom
Vitaliy Margolen wrote:
> Few notes:
> You constructed the array of some attributes which you never use. You
> don't check if those attributes match anything - the part you removed.
> When app will ask for something that can't be supported your code will
> return it to the app - which is plain wron
[EMAIL PROTECTED] wrote:
> The largest gaming site in Norway recently did an extensive review of gaming
> on
> Linux, but Wine was left out of the benchmark because "no FPS tool exists for
> Wine". Surely this can't be true?
>
I guess I could modify yukon [1] to not capture the actual frames but
Maarten Lankhorst wrote:
> - Remove the queuing thread and use Lock() and Unlock() instead.
There has to be a thread somewhere: for buffers that are DSBPLAY_LOOPING.
tom
Scott Ritchie wrote:
On Thu, 2007-03-01 at 20:57 +0100, Tomas Carnecky wrote:
Luis C. Busquets Pérez wrote:
I understand that for some people the mailing list is a far better
thing. May be for some other, a forum is better.
Why not trying both systems?
This question has already been
Luis C. Busquets Pérez wrote:
I understand that for some people the mailing list is a far better
thing. May be for some other, a forum is better.
Why not trying both systems?
This question has already been answered.. anyway: if you have both a ML
and a forum, you effectively split the commu
Lei Zhang wrote:
> Setting the Exec= line in a .desktop file to: WINEPREFIX=foo wine bar
> worked in KDE. In Gnome, it works if "run from the terminal" is set.
>
> Unfortunately the Freedesktop spec for desktop entries does not
> specify a way to add environment variables. So yes, it looks like
>
Alessandro Pignotti wrote:
> Hi,
> this is my first patch i hope it's well formatted
formating is good.
> From Microsoft DirectX SDK Documentation it seems that directplay should
> initialize the instance guid on session creation, this trivial patch does
> that.
Two questions:
1. Does window
Dmitry Timoshkov wrote:
> And one more...
>
> "Damjan Jovanovic" <[EMAIL PROTECTED]> wrote:
>
>> +__int64 interlocked_cmpxchg64( __int64 **dest, __int64 *xchg, __int64
>> *compare )
>> +{
>> +_lwp_mutex_lock( &interlocked_mutex );
>> +if (memcmp(*dest, compare, 8) == 0)
>> +memcpy
Peter Seebach wrote:
> In message <[EMAIL PROTECTED]>, "Dmitry Timoshkov" writes:
>> Usually xmodmap is used to redefine keys behaviour in X11, no need for 3rd
>> party
>> apps.
>
> If xmodmap could do this, I'd agree.
>
> Xmodmap can't map "F13" to "Control-F1", though, and many Windows apps ca
Chris Robinson wrote:
> +for (i = 0; i < GL_LIMITS(texture_stages); i++) {
> +/* Note the WINED3DRS value applies to all textures, but GL has one
> + * per texture, so apply it now ready to be used!
> + */
> +if (GL_SUPPORT(ARB_MULTITEXTURE)) {
> +GL_
darckness wrote:
> First off, the D3D (DX9) runs MUCH better (faster and more smoothly)
> than the OGL mode. Big kudos to you guys; last time I played, the D3D
> mode was completely unusable because there was no D3D support in wine.
> Very impressive.
>
The GLX_ARB_vertex_buffer_object is descri
Maarten Lankhorst wrote:
Instead of using asynchronous callbacks that uses signals, use a
seperate thread that can be cancelled, this prevents deadlock issues.
Basically we use snd_pcm_wait() that tells us when enough room is free
to commit another buffer, then we commit the previous buffer and
For your convenience.. http://dbservice.com/ftpdir/tom/dsound-alsa.patch
You have to enable 'ALSA' and full hardware acceleration, no emulation.
Don't know if it works with other applications than World of Warcraft
though...
Note that this patch is _full_ of non-important changes that could be
re
Stefan Dösinger wrote:
> Am Donnerstag 07 Dezember 2006 22:20 schrieb Tomas Carnecky:
>> I can give you my dsound/alsa patches if you want. I've changed the
>> dsound code to use 'native' alsa buffers/mixer instead of the one
>> implemented in dsound and I don
[EMAIL PROTECTED] wrote:
> Can anyone help me get this baby compiled as i want to play my games
> without the nasty audio glitches and don't care if i have to be
> root/sudo/whatever.
I can give you my dsound/alsa patches if you want. I've changed the
dsound code to use 'native' alsa buffers/mixer
Andreas Mohr wrote:
>
> Would be nice to have many more people (e.g. those who don't feel like
> programming things but still want to contribute somehow) offering
> such dedication towards getting their personal goals in various
> OSS projects reached.
>
GNOME has a 'bounties' webpage, http://ww
James Hawkins wrote:
> +@ stdcall pcap_setbuff(ptr long) wine_pcap_setbuff
>
> As I said before, you don't need to forward these, just name the APIs
> like they are in the spec file and it should work.
>
You can see that wine_pcap_close() calls pcap_close() which is a
function implemented in the
Byeong-Sik Jeon wrote:
> I think xorg people knows this problem already.
> https://bugs.freedesktop.org/show_bug.cgi?id=1182
>
Won't this be fixed in the next Xlib version (1.1)? XLib-1.1 will use
XCB which is said to be truly MT safe.
If we just wait until everybody has updated XLib to 1.1 then
David Kowis wrote:
> Alexandre Julliard wrote:
>> What's new in this release:
>> - Support for multiple monitors using Xinerama.
>
> W00t! Now if I could get it to build in amd64 :(
Now if you posted the error message or tried to describe what exactly
fails :(
tom
Tomas Carnecky wrote:
So.. now that the cause is known, what would be the right solution? Do
you still think it's the WMs fault? Or should wine be changed?
The patch in the attachment removes update_key_state() from mouse.c -
the decision whether this is the right approach or not is le
That is _really_ annoying, but nobody seems to know what it causes. So,
I once again started to investigate it. The culprit is the
'update_key_state' function in mouse.c, which modifies the global
'key_state_table' without telling the application that the keystate has
changed. A patch that was
James Courtier-Dutton wrote:
As Direct Sound does not know anything about periods, I don't really
know how you will be able to get it to work well with ALSA. I expect
that some sort of double buffer will be required.
Does Direct Sound have a concept of position of the ADC, and also a
concept of
.. another small update, now tries to create the buffer size as close as
possible to what the app requested.
The whole patch is available at the same URL, I also created a patch of
only ./dlls/winmm/winealsa/audio.c to make it easier to read the patch,
the patch is here: http://dbservice.com/ftp
James Courtier-Dutton wrote:
I have place some documentation on the ALSA wiki site:
https://bugtrack.alsa-project.org/wiki/wikka.php?wakka=ALSAresampler
It tries to explain the constraints that the current ALSA resampler
works under.
You might like to read it as I think it will have impact on
Tomas Carnecky wrote:
I'm fairly sure this all could be done in a WoW-independent way, eg.
configure the hardware as the application requests it (by passing
LPCDSBUFFERDESC to the low-level driver etc) and keeping track of the
read/write positions could also be done in a better way.
A
My ultimate goal was to solve the dsound underruns which were so
horrible that I had to disable sound in World of Warcraft. While I
managed to get the sound working flawlessly (really... I never heard
such clear sound under wine) in WoW, it required WoW-specific hacks so
my patch will never mak
Jan Zerebecki wrote:
As explained in the mail refrenced above the main problem is that
in wine the alsa callback signal (that we currently use) won't
work properly without special care, but the fd based method (for
example with select) should work as expected.
Why won't it work without special
Jan Zerebecki wrote:
To fix bug #4093 we need to replace the currently used signal
callback method (very complex to make signals work properly [in
Wine], thus we should avoid it) with I guess a fd based method
for example with select. The alsa-api documentation about this
looks pretty usable.
Tomas carnecky wrote:
This is not the correct way of loading opengl functions or deciding
whether they are available or not. According to the
GLX_ARB_get_proc_address spec, we need to check _only_
glXQueryExtensionsString() and glXQueryVersion()
The spec: http://www.opengl.org/registry/specs
Roderick Colenbrander wrote:
There's this check:
if ((!WineGLInfo.glxDirect && !strcmp("1.2", WineGLInfo.glxServerVersion))
||
(WineGLInfo.glxDirect && !strcmp("1.2", WineGLInfo.glxClientVersion)))
This is not the correct way of loading opengl functions or deciding
whether they
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
Testing with World of Warcraft, the game runs fine, but I see this in
the console:
err:wgl:wglGetPixelFormatAttribivARB Unable to convert iPixelFormat 0 to
a GLX one, expect problems!
tom
[EMAIL PROTECTED] wrote:
> No, they have added this regressions after a little patch-set.
> So they can fix it.
> And as we can't download a playable demo ...
>
Interesting.. if MacOSX has a similar memory layout as linux, maybe we
could get Blizzard to include a workaround that is only active w
Mike Hearn wrote:
> It's a bug in WoW itself, it relies upon the exact way NT maps memory
> which is different to how Linux does it. I guess they are storing
> information in the high bits of a pointer somewhere or some similar
> trick.
>
Since WoW also runs on MacOSX, how does the memory layout
Dmitry Timoshkov wrote:
> "Tomas Carnecky" <[EMAIL PROTECTED]> wrote:
>
>> The problem seems to be the SWP_NOACTIVATE that is now added to 'swp' in
>> case of SW_MINIMIZE. Before your patch, SW_MINIMIZE has it's own 'case'
>&
Dmitry Timoshkov wrote:
> Could you try to identify which piece of the patch caused the regression?
>
It wasn't that hard after all.. ;)
The problem seems to be the SWP_NOACTIVATE that is now added to 'swp' in
case of SW_MINIMIZE. Before your patch, SW_MINIMIZE has it's own 'case'
section, now i
Tomas Carnecky wrote:
> Minimizing: I started the game, minimized it and then the log starts:
> maximize it and minimize it.
>
I'm sorry, this is the wrong description. ALT-TAB switches the active
window, like under Windows, it does not minimize!
Even without your patch I can se
Dmitry Timoshkov wrote:
> If you could minimize the failure to a small test case that would help
> a lot.
>
Unfortunately, I have neither Windows nor the required knowledge to
write windows applications :(
I did two logs when switching workspace (winpos-*) and two when
minimizing (minimize-*), a
Dmitry Timoshkov wrote:
> Hello,
>
> this patch makes all the recently added ShowWindow tests pass in Wine,
> and is aimed to fix the bug #4960.
>
> Although this patch creates a regression for popup windows created with
> WS_MAXIMIZED style set and calling ShowWindow( SW_SHOWMAXIMIZE ) right
> a
Kuba Ober wrote:
> Patches to configure are redundant. configure is autogenerated. Change the
> source file, namely configure.ac.
Thanks, modifying configure.ac was easier than I thought ;)
If someone wants to pick up the development from here, feel free to take
the patches. The last patch for c
After submitting the patches last night, I got some feedback on IRC. It
seems that adding new exports to gdi32.dll is bad (it apparently tends
to break applications, those using safedisc2 seem to be good
candidates), so I had to look for another solution.
Everything that follows here is under the
... and here the patch
diff --git a/dlls/gdi/driver.c b/dlls/gdi/driver.c
index 9f40a8d..012d882 100644
--- a/dlls/gdi/driver.c
+++ b/dlls/gdi/driver.c
@@ -194,6 +194,33 @@ #define GET_FUNC(name) driver->funcs.p##
GET_FUNC(StrokePath);
GET_FUNC(SwapBuffers);
GET_FUNC(Wide
Tomas Carnecky wrote:
> This patch adds an WineGL interface to the GDI driver and creates
> wrapper functions for them. If the wgl function takes a HDC, the wrapper
> extract the PHYSDEV and prepends it to the driver-function argument
> list. This way we have direct access to the PHYSD
Alexandre Julliard wrote:
> Tomas Carnecky <[EMAIL PROTECTED]> writes:
>> As far as I understand, the only way to access x11drv is through GDI
>> (which implements ExtEscape), would your proposed change require new
>> functions for opengl32 <-> x11drv communication
Alexandre Julliard wrote:
> What we probably want is to move a lot more of the glX code into
> x11drv, and export the various wgl functions from there. That escape
> mechanism is beginning to be seriously abused.
>
Even is the functions were implemented in x11drv.. wglMakeCurrent()
still takes a
Tomas Carnecky wrote:
> comments?
>
Why do I have the impression that when it comes to x11drv/opengl nobody
wants to take the responsibility. I won't submit a patch until someone
says 'tom, your approach looks good, improve this and then submit a
patch to wine-patches' or
In wglMakeCurrent(), when the HDC type is OBJ_MEMDC you activate the
frontbuffer for drawing. PBuffers' type is also OBJ_MEMDC, but changing
the drawbuffer in that case is wrong.
Is there a way to find out if the HDC is a PBuffer? I have some patches
in my local tree but I took the freedom to put
Mike Hearn wrote:
> (yeah i'm bored :/)
>
> Seems the WoW appdb page (apart from being a great example of what an
> appdb entry should be like!) recommends users patch their Wine to run WoW
> properly.
>
> The patch is this one, which I am SURE we discussed before but I can't
> find the thread! S
Bill Medland wrote:
> I have just noticed that configure is telling me
> "Warning: Freetype or Fontforge is missing"
>
> Why does it think that?
>
> (freetype-devel version 2.1.9 is installed)
>
What about fontforge? Is that installed?
Jesse Allen wrote:
> On 4/17/06, Tomas Carnecky <[EMAIL PROTECTED]> wrote:
>> Jesse Allen wrote:
>>> On 4/17/06, Tomas Carnecky <[EMAIL PROTECTED]> wrote:
>>>> Wine doesn't crash in this function, sorry, it's a bug in pf_vsnprintf()
>>
Jesse Allen wrote:
> On 4/17/06, Tomas Carnecky <[EMAIL PROTECTED]> wrote:
>> Wine doesn't crash in this function, sorry, it's a bug in pf_vsnprintf()
>> which causes snprintf() to write beyond the end of the buffer.
>>
>> I've attached a patch th
Wine doesn't crash in this function, sorry, it's a bug in pf_vsnprintf()
which causes snprintf() to write beyond the end of the buffer.
I've attached a patch that fixes it for me, but it's probably better not
to create such large buffers on the stack.
Anyone with a better fix?
tom
diff --git a/dl
These circumstances being if it tries to load an invalid lua file, more
specifically a lua file which contains the invalid lua string (not
character!) "\342\200\260".
I don't know what this function does and there isn't a TRACE() in that
function, so could someone please review if the function is
Segin wrote:
> Mike Hearn wrote:
>> On Sat, 15 Apr 2006 23:37:17 -0400, Mike Frysinger wrote:
>>
>>> if wine is built with --disable-trace or --disable-debug, then using
>>> WINEDEBUG
>>> will accept the respective options without complaining and without actually
>>> showing any useful inform
Mike Hearn wrote:
> Why would anybody build without tracing anyway? I would be *very*
> surprised if it led to any noticable/real world performance improvement.
Because of the exact same reason NVidia doesn't want to add yet another
dispatch table to linux's OpenGL libraries (as proposed by someon
Kai Blin wrote:
> * Tomas Carnecky <[EMAIL PROTECTED]> [10/04/06, 15:01:00]:
>
>> At least now this information is in the README file, I saw the patch
>> just after I've sent that email :)
>
> It's not. Alexandre convinced me that the README file is t
Mike McCormack wrote:
>
> Tomas Carnecky wrote:
>
>> maybe the configure script should check the fontforge version, to be at
>> least from 2006.
>> My fontforge: "Executable based on sources from 20:17 6-Apr-2006-ML.".
>> Checking for "Executab
Vitaliy Margolen wrote:
> Sunday, April 9, 2006, 4:15:22 PM, Alexander N. Sørnes wrote:
>> Hello,
>
>> I have found some font problems recently with Wine. First of all, the
>> text of most richedit objects started displaying as rectangles since
>> around Wine 0.9.9, and now, with current CVS, n
Alexander Nicolaysen Sørnes wrote:
> Vitaliy Margolen skrev:
>
>> Sunday, April 9, 2006, 4:15:22 PM, Alexander N. Sørnes wrote:
>>
>>
>>
>> I'm sorry, but are you reading this mailing list at all? To sum it up:
>> 1. You need fontforge.
>> 2. You need _working_ fontforge.
>> 3. You need Wine's f
Mike McCormack wrote:
>
> Tomas Carnecky wrote:
>
>>> * Another (missing NULL ptr check in LoadTypeLibEx) is right, but, I
>>> don't
>>> think we want to add lots of missing NULL arg checks in the public
>>> API implementations. An app
Mike Hearn wrote:
>
> * Another (missing NULL ptr check in LoadTypeLibEx) is right, but, I don't
> think we want to add lots of missing NULL arg checks in the public API
> implementations. An application will never pass NULL to this function
> directly as otherwise it'd not work at all, so
Con Kolivas wrote:
>
> Ok. This is not a shot in the dark by the way because you mentioned pipes and
> I had a quick look at the wine sound code. I committed some changes to the
> cpu scheduler in 2.6.17-rc1 that change the way it views sleeping on pipes...
>
Works _much_ better with 2.6.17-rc
Leon Freitag wrote:
> Am Dienstag, 4. April 2006 14:49 schrieb Tomas Carnecky:
>> Leon Freitag wrote:
>>>> BadMatch in X_GLXCreateGLXPixmap is a known problem, I've submitted a
>>>> patch but it was rejected.
>>> Well, try to resubmit it :) Or
Leon Freitag wrote:
>> BadMatch in X_GLXCreateGLXPixmap is a known problem, I've submitted a
>> patch but it was rejected.
>
> Well, try to resubmit it :) Or post it here, so that others could test it.
> Perhaps you could merge this one-liner into it and then resubmit it.
>
Yep, here it is. But
Willie Sippel wrote:
> Am Sonntag, 2. April 2006 16:44 schrieb Leon Freitag:
>> Someone mentioned earlier that the code in wgl.c in DescribeDrawable()
>> violates the GLX specification and therefore causes bogus return values for
>> the visualid. However this code has been already present before th
Robert Shearman wrote:
>
> You might want to find out why you have to add anything to LDFLAGS. I
> don't know about other distributions, but on 64-bit Ubuntu passing the
> -m32 flag to gcc will make it automatically add the standard 32-bit lib
> directories to the lib path (i.e. /lib32, /usr/lib32
Robert Shearman wrote:
> This is a bug with the artsc-config utility, not with Wine. All of these
> types of utilities are fundamentally broken on 64-bit distributions when
> trying to compile as 32-bit.
>
And what about fixing first wine instead of complaining about third
party utilities?
$ ./
Alexandre Julliard wrote:
> Tomas Carnecky <[EMAIL PROTECTED]> writes:
>
>> This patch doesn't change any logic or C sourcecode, it only moves the
>> X11DRV escape code definition to one common header file. Currently the
>> definitions are spread over several
Huw D M Davies wrote:
> On Mon, Mar 27, 2006 at 05:05:23PM +0100, Huw D M Davies wrote:
>> Ah right, glDrawBuffer alters the rendering state, that's bad. We
>> should presumably be calling glXSwapBuffers here (but only in the
>> GLXPixmap case).
>
> Which of course won't work either.
>
> We need
Huw D M Davies wrote:
> On Sat, Mar 25, 2006 at 02:23:01AM +0100, Tomas Carnecky wrote:
>> GL_FRONT and GL_FRONT_LEFT mean the same unless the drawable is stereo.
>> And I don't think PBuffers or Pixmaps can be stereo, so is there any
>> special reason to use GL_FRONT_L
This patch implements 'WGL_PBUFFER_LOST_ARB'. It creates a new field in
'X11DRV_PDEVICE' which is used to store flags (currently only one:
X11DRV_FLAG_DAMAGED). This flag indicates that the drawable (PBuffer) is
damaged and no longer valid. As soon as the x11 driver receives the
GLX_DAMAGED event i
Tony Lambregts wrote:
> Tomas Carnecky wrote:
>> ok.. here is a patch, but I can't make it work. Maybe someone else sees
>> the bug.
>>
> What is the problem. this is from a log of Google using your patch and
> WINEDBUG="+wgl,+opengl"
As you maybe s
Lionel Ulmer wrote:
> On Fri, Mar 24, 2006 at 08:48:16PM +0100, Tomas Carnecky wrote:
>> so.. what about splitting 'opengl' up into 'opengl' (all the opengl
>> functions) and 'oglsetup' with the setup/wgl/pbuffer etc. functions ?
>
> Why not &#x
GL_FRONT and GL_FRONT_LEFT mean the same unless the drawable is stereo.
And I don't think PBuffers or Pixmaps can be stereo, so is there any
special reason to use GL_FRONT_LEFT ? Or is it because the spec sais so?
tom
Lionel Ulmer wrote:
> On Fri, Mar 24, 2006 at 08:20:08PM +0100, Tomas Carnecky wrote:
>> When debugging opengl applications, I'm usually not interested in the
>> *Swap*Buffers() functions, but in context creation, pbuffers stuff etc.
>> It just writes unnecessary messa
Lionel Ulmer wrote:
>> Oh, and this patch creates a new debug-channel 'swapbuffers' and puts
>> both opengl swapbuffers functions into it.
>
> What is the reason for this change ?
>
When debugging opengl applications, I'm usually not interested in the
*Swap*Buffers() functions, but in context cr
Stefan Dösinger wrote:
> Hi,
>> So.. in this attachment you'll find a patch that does what I've just
>> described. I can't test it on anything else than WoW, so if someone
>> would please review it and test with outher opengl/d3d applications it
>> would be great.
> No effects noticed with Half-lif
Tomas Carnecky wrote:
> Changelog:
> - fail if the drawable and context Visual IDs don't match.
>
> why? because this will produce a BadMatch and crash the application so
> instead of the crash rather return GL_FALSE and let the application
> handle it.
Please don
Tomas Carnecky wrote:
> Tomas Carnecky wrote:
>> Mike Hearn wrote:
>>> Mike Hearn <[EMAIL PROTECTED]>
>>> Optimize thunks by storing GL context in the thread environment block
>>>
>> good job. this fixed the BadMatch error in World of Warcraft a
1 - 100 of 138 matches
Mail list logo
