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-allocation,
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 let
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 the
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 more
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 Wine doesn't have a PA sound
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 be used through the alsa-pulse plugin
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 under the same name. That is a technical limitation
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,
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.
It seems
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:
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
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
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)
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 behavior as now
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
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 a custom patch
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 wrong.
[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
only
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
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
we'll
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(*dest, xchg, 8);
+
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 can't
hack F13.
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 described
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)) {
+
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
[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
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't have any problems at all with bad
sound
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
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
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,
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 left
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
.. 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:
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
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 small
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
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
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.
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 are
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:
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
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 on
[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 when
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'
section, now it falls through and in 'case SW_SHOWMINNOACTIVE'
SWP_NOACTIVATE
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 it
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
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
after
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-*),
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 see the slowdown when
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);
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 PHYSDEV in x11drv
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 through GDI? Or is it
somehow possible
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 'tom, no, this won't work
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! So my
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?
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
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 that fixes it for me, but it's probably better not
to create
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()
which causes snprintf() to write beyond the end of the buffer.
I've attached
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 someone
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 information
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 fonts made with
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, no text is
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 Executable based on sources from (.+) (.+)-(.+)-2006 in
`fontforge
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 the wrong place
for it. Configure warns you about
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, a
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 application will never pass NULL to this
function directly as otherwise
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 note
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 post it here, so that others could test
it. Perhaps you could merge
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
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?
$
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,
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 the
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 C source files, and even there the
definitions
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_LEFT ? Or is it because the spec
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 to find
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
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
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 messages into the console. When debugging
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: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 'wgl' ? So we would have 'opengl' for 'core' functions
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 see in the patch, I've put both SwapBuffers functions
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 and also
increased performance, from ~20fps to ~25fps.
Maybe
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-life 1(GL),
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 and also
increased performance, from ~20fps to ~25fps.
tom
Stefan Dösinger wrote:
Hi,
I have found a design flaw in ddraw and described it in my 'World of
Warcraft 0.10 Public Test Real (PTR)' thread. Why has nobody adressed
this issue? In my eyes it is a severe design flaw if an application
can't unload ddraw.dll without side effects (especially if
Vitaliy Margolen wrote:
Anything wrong with this patch? It does fix the stuck alt problem for
games I use alt+tab on.
I can confirm that this fixes the bug. This patch is very important for
me as I don't have to switch back and forth between desktop and WoW to
un-stuck they alt-key. This
I have found a design flaw in ddraw and described it in my 'World of
Warcraft 0.10 Public Test Real (PTR)' thread. Why has nobody adressed
this issue? In my eyes it is a severe design flaw if an application
can't unload ddraw.dll without side effects (especially if this
side-effect is that all
1 - 100 of 132 matches
Mail list logo
