question created 16-bit dibsections after I
unlocked more depths and the color of text was wrong.
Roderick
On Mon, Aug 3, 2009 at 8:47 AM, Henri Verbeet wrote:
> 2009/8/2 Roderick Colenbrander :
>> Hi,
>>
>> The text color of a physdev is in 24-bit r8g8b8 independent of the
>&
On Wed, Aug 5, 2009 at 2:35 PM, Dan Kegel wrote:
> On Wed, Aug 5, 2009 at 2:49 AM, Ben A L
> Jemmett wrote:
>>> [Visual Studio 2005]
>>> Repainting after scrolling was a bit lazy, and creating a new
>>> project still requires ie6, but it was a nice surprise all the same.
>>
>> I wouldn't be too sur
key for it and disable it perhaps on 'modern
drivers'). What do you guys think?
Regards,
Roderick Colenbrander
On Mon, Aug 10, 2009 at 10:24 AM, Henri Verbeet wrote:
> 2009/8/9 Roderick Colenbrander :
>> I would perhaps suggest that we should perhaps drop XShm support (or
>> at least add a registry key for it and disable it perhaps on 'modern
>> drivers'). What do you guy
On Mon, Aug 10, 2009 at 11:17 PM, Yuriy Kaminskiy wrote:
> On 10.08.2009 12:24, Henri Verbeet wrote:
>>> at least add a registry key for it and disable it perhaps on 'modern
>>> drivers'). What do you guys think?
>> Could you do some benchmarking? You can disable XShm support by
>> passing "--witho
On Thu, Aug 13, 2009 at 6:59 PM, Stefan Dösinger wrote:
> Am Wednesday 12 August 2009 10:04:10 schrieb Sun, Sunny:
>
>> I think you can first detect GL_ATI_meminfo in
>> glGetString(GL_EXTENSIONS); if GL_ATI_meminfo exists, then you can use
>> glGetIntegerv(GL_VBO_FREE_MEMORY_ATI, param) to get the
When I last checked this extension
months ago the total amount of memory wasn't in the spec, it might
make sense to update the spec.
Regards,
Roderick Colenbrander
The best test case I think for that is ddraw-gl. A lot of 2D games use
partial locking.
Roderick
On Sun, Aug 16, 2009 at 10:43 PM, Henri Verbeet wrote:
> Actually, do you have an application that needs partial texture
> updates? I implemented it, but I need something to test against.
>
>
>
> The libmpg123 library is not shipped in any rpmfusion repository for Fedora
> 10, and possibly for other distros. This means anyone who wants mp3 support
> would need to install libmpg123 from source. However, rpmfusion for Fedora
> 10 has libmad, lame and twolame.
>
> --
> perl -e '$x=2.3;printf
On Wed, Aug 19, 2009 at 11:26 PM, Matteo Bruni wrote:
> 2009/8/19 Roderick Colenbrander :
>>> The libmpg123 library is not shipped in any rpmfusion repository for Fedora
>>> 10, and possibly for other distros. This means anyone who wants mp3 support
>>> would need to
If you are considering to write an additional backend, I would advise
to add a fallback path to directshow. When the gstreamer code enters
mp3 can then easily be added. If directshow for gstreamer isn't
around, just use libmpg123 or use libmpg123 by default and directshow
as a fallback.
Roderick
I'm sure what will happen to the GL_ATI_meminfo but perhaps it makes
sense to unify it with WGL_AMD_gpu_association ?
Roderick
On Fri, Sep 4, 2009 at 7:04 PM, Dylan Smith wrote:
> On Wed, Sep 2, 2009 at 12:15 PM, wrote:
>> Hi,
>>
>> although wine in MacOSX works generally good enough (see test.winehq.org
>> about
>> release 1.1.28), I recently visited the print menu in notepad and wordpad to
>> see whether printing would
Regarding the zero source DC, what happens visually?
On Wed, Sep 9, 2009 at 1:30 PM, Nikolay Sivov wrote:
> Bug http://bugs.winehq.org/show_bug.cgi?id=18041 shows this commented crash.
> I'm not sure how to fix it, but I think this call can't do anything
> without source context.
>
> Another quest
In a next patch ComputeChannelShift will be called from outside
palette.c and for this reason I made it non-static.
Roderick
On Thu, Sep 10, 2009 at 5:58 PM, Francois Gouget wrote:
> ---
> dlls/winex11.drv/palette.c | 115
> ++--
> dlls/winex11.drv/x11d
Recently Nikolay Sivov wrote some tests for this call. His tests
didn't make it in yet but I think those should enter and then based on
those results changes should be made.
Roderick
On Thu, Sep 10, 2009 at 10:56 PM, Markus Stockhausen
wrote:
> Hi,
>
> http://bugs.winehq.org/show_bug.cgi?id=1804
Just one minor thing make sure the right email address is configured
in your git repository, so that the correct email address is set in
the patch
Roderick
On Sun, Sep 13, 2009 at 8:15 AM, Jaime Rave wrote:
> More information about Intel
> cards: http://en.wikipedia.org/wiki/Intel_GMA#Table_of_G
Hi,
I'm not sure if we should skip the glXMakeCurrent(null, null) call in
GLX as in case of GLX it doesn't hurt. Second I'm not sure if we need
to put the SetLastError code in winex11 or in gdi32/opengl.c. I think
it should be in there as we don't need any X11 info.
Roderick
2009/9/18 Rico Schül
As of XP themes can specify their own icons. For some dlls I believe
shell32 they need to provide their own shellapi.dll or whatever it is
called. I think that would be the way to proceed. I would suggest to
make Tango the base theme as it integrates well with KDE/Gnome and
also OSX. Using themes (
ldsworth
wrote:
> On Mon, 2009-09-21 at 16:02 +0200, Roderick Colenbrander wrote:
>> As of XP themes can specify their own icons. For some dlls I believe
>> shell32 they need to provide their own shellapi.dll or whatever it is
>> called. I think that would be the way to proce
As shown on the screenshots here from windowblinds it is able to
override shell icons. I have no idea how it is doing that though.
http://frogboy.joeuser.com/article/150608
Roderick
On Tue, Sep 22, 2009 at 12:35 AM, Roderick Colenbrander
wrote:
> I think I read somewhere that shellstyle.
> BTW. Do you plan to reregister all user32 classes on comctl32 load? How
> could this be done at user32 side - testing for something like
> IsThemeActive() while loading user32?
>
I have been toying with this a bit and trying to figure out how it
works. From MSDN info and info from a site which h
When the Xserver crashes the bug in question is a bug in the display
drivers. Wine itself or any other X app won't bring the Xserver down
(they can't). Though knowing what changes in Wine triggered this
(probably glsl / fbo stuff) could help the intel developers fixing the
issue but as I said the i
On Fri, Oct 2, 2009 at 6:49 PM, Nikolay Sivov wrote:
> Frank Richter wrote:
>>
>> On 02.10.2009 00:27, Joel Holdsworth wrote:
>>
>>>
>>> Does anyone have any thoughts about what might be going on here, and
>>> what I should do with my tests?
>>>
>>
>> If the manifest is set up dynamically I would
Esstentially what happens is that using the SendMessage in
internal_SetPixelFormat we call 'set_win_format' in window.c. I can't
say why it fails perhaps no parent window is up yet..
Roderick
On Tue, Oct 6, 2009 at 6:02 PM, a qi wrote:
>
> Hi,All
>
> I try to run a 3D application named "Unity
On Fri, Oct 9, 2009 at 2:25 PM, Markus Stockhausen
wrote:
> Am Freitag, den 09.10.2009, 14:15 +0200 schrieb Paul Vriens:
>
>> If that sz99 (or now sz128) came from "looking at internal behaviour",
>> I'm not sure if that would raise some eyebrows.
>>
>
> As I said "looking at internal behaviour" a
Hi,
First of all wine-patches is the list to which patches are submitted
for inclusion in Wine, it is not meant as a user discussion list.
Questions like the one you asked belong on wine-devel.
Bug 6971 is an old Wine bug and is hard to fix. Now that xserver 1.7
is out, there is finally Xinput 1.
No, it won't break OSX and other systems since we have to support both
xinput 1.2 and the legacy code.
Roderick
On Mon, Oct 12, 2009 at 4:00 AM, James McKenzie
wrote:
> Roderick Colenbrander wrote:
>> Hi,
>>
>> First of all wine-patches is the list to which pa
You should also patch make_opengl because openg32.spec is
automatically generated.
Roderick
On Tue, Oct 13, 2009 at 10:04 PM, Stefan Dösinger
wrote:
>
>
Hi,
I don't know much about the cd-rom stuff on osx but I expect there are
much more issues of which some are more severe than this (and the
solution might fix all the issues). I believe that on osx there is no
such thing as direct cd-rom access (anymore) and due to this I think
wine can't read au
It might work for some basic tasks but it is mostly incomplete.
Roderick
On Friday, October 16, 2009, Paul Janoski wrote:
> Can anybody please tell me how complete the DirectMusic wine emulation is on
> Linux.
>
> Thank You,
> Paul Janoski
>
>
>
>
On Sat, Oct 17, 2009 at 5:22 PM, Dan Kegel wrote:
> On Sat, Oct 17, 2009 at 6:31 AM, Jeremy White wrote:
>> Alexandre wanted a version check when asked a different question. That
>> question
>> was when would we prefer an available native Richedit over the builtin one.
>> (i.e. in the LoadLibrar
On Mon, Oct 19, 2009 at 12:45 AM, Austin English
wrote:
> On Sun, Oct 18, 2009 at 1:50 PM, James McKenzie
> wrote:
>> Ove Kaaven wrote:
>>> This makes it possible to work around bug 10080 without having to patch
>>> the source code.
>>>
>> This is a hack to allow a work around to function. Much
On Mon, Oct 19, 2009 at 10:03 AM, Roderick Colenbrander
wrote:
> On Mon, Oct 19, 2009 at 12:45 AM, Austin English
> wrote:
>> On Sun, Oct 18, 2009 at 1:50 PM, James McKenzie
>> wrote:
>>> Ove Kaaven wrote:
>>>> This makes it possible to work around bug
On Mon, Oct 19, 2009 at 1:08 PM, Ove Kaaven wrote:
> Roderick Colenbrander skrev:
>> On Mon, Oct 19, 2009 at 12:45 AM, Austin English
>> wrote:
>>> On Sun, Oct 18, 2009 at 1:50 PM, James McKenzie
>>> wrote:
>>>> Ove Kaaven wrote:
>>>>
try to improve it by fixing winealsa and other parts.
Regards,
Roderick Colenbrander
--
Echte DSL-Flatrate dauerhaft für 0,- Euro*!
"Feel free" mit GMX DSL! http://www.gmx.net/de/go/dsl
e of the platforms supports a usefull feature which
isn't supported by the others. If this is the case it might be
better to move all GLX / WGL / AGL specific code to
wined3d_agl.c / wined3d_glx.c / wined3d_wgl.c. This would
directly fix the 'linking' issues.
Regards,
Roderick
> On 5/15/06, Roderick Colenbrander <[EMAIL PROTECTED]> wrote:
> >
> > Are you sure it is this patch that causes the regression and not
> Vitaly's
> > latest one? This patch changes the way dinput8 objects are created and
> it
> > does this similar to wi
> On 5/15/06, Roderick Colenbrander <[EMAIL PROTECTED]> wrote:
>
> >
> > Yes, that's the reason. I forgot that I still need to send the patch for
> the
> > registry settings. Basicly what you need to add is this:
>
>
> What about bf798030-483a
> On 5/15/06, Roderick Colenbrander <[EMAIL PROTECTED]> wrote:
> >
> > I think the issue is that CoInitialize isn't called from
> DirectInput8Create
> > main. I think I missed this because my test app did this for me. Try to
> add
> > a CoI
der states it uses, I guess it
might be used D3DRS_SRCBLENDALPHA/DESTBLENDALPHA and friends. A while ago I
submitted a patch for it but it wasn't accepted (I will clean it up this
weekend). http://www.winehq.org/pipermail/wine-patches/2005-November/021821.html
Regards,
Roderick Colenbrander
--
Bis zu 70% Ihrer Onlinekosten sparen: GMX SmartSurfer!
Kostenlos downloaden: http://www.gmx.net/de/go/smartsurfer
than
integrating an x86 emulator in wine and second wine with a builtin emulator
might be as fast as an optimized qemu.
So wine can be used on ppc/linux using qemu and a real port is way too
complicated.
Regards,
Roderick Colenbrander
--
Echte DSL-Flatrate dauerhaft für 0,- Euro*!
"Fee
(I even wrote a dinput8->native dinput8
wrapper and verified it there). I was planning to contact Core Design about
this.
Regards,
Roderick Colenbrander
> Sorry I doesn't atteched the patch.
> Hi,
>
> I implemented (taken from wine's dinput directory, modified) dinput
SFLAG_GLCKEY && !(This->CKeyFlags & DDSD_CKSRCBLT)) ||
> /* Reload: vice versa OR */
> (!(This->Flags & SFLAG_GLCKEY) && !This->CKeyFlags & DDSD_CKSRCBLT) ||
>
> The third '!' was removed as indicated by the comment this fixes color
>
verything is mappable to Direct3D in some cases an
> extension from lets say Nvidia can be used but it is not really worth it.
> If there's no OpenGL cap the minimum required values as required by the
> shader specs are used.
>
> Regards,
> Roderick Colenbrander
--
"
arlier today. The previous patch added draw
> buffers support and fixed a gl_FragData bug. This patch fixes another case
> where we incorrectly use gl_FragData.
>
> Regards,
> Roderick Colenbrander
--
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
Ide
Hi,
One small comment regarding your patch make sure that you use the same
indentation as the rest of the ddraw code. The ddraw code seems to use 4 spaces
for a tab and I think your editor is configured to use tabs.
Regards,
Roderick Colenbrander
> The new test cases crashes under wine
uffer and wglChoosePixelFormat to work with the new pixelformats yet (that's
why you see a line WoW hack). I will fix that part when you guys think that the
patch is correct.
Regards,
Roderick Colenbrander
--
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
The issue is that the line isn't error in all cases. Most of the time only
iPixelFormat 1 and the offscreen formats are valid values. But for some queries
like how much pixelformats exist a program can pass garbage aswell. This
processing is done at a later stage because of this, it could be cha
All capability detection should be based on opengl extensions. In most cases
when there's no opengl extension which can provide the functionality we can't
support it. Recently I have improved our capability reporting quite a bit. Some
of the caps from the page you pointed to are now reported but
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
if I install wine into a standard
/usr/local prefix, winedbg works ok aswell. It shows the correct information
and the SymLoadModule lines don't fail either.Most likely there's some path
issue in dbghelp.
I have tried to look at the code but it is a big maze to me. Perhaps you ha
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
> 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
> 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
> Hello
> > Your pixel format patches caused a regression in half-life 1 for me with
> > the fglrx drivers.
>
> The same happend to me with opensource Intel drivers on a:
> $ lspci | grep VGA
> 00:02.0 VGA compatible controller: Intel Corporation 82852/855GM
> Integrated
> Graphics Device (rev 0
> 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
> > 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
> Hello
>
> > Both of you try to remove the following code from
> src/winex11.drv/opengl.c:
> > /* Aux buffers */
> > pglXGetFBConfigAttrib(gdi_display, cfgs[fmt_index],
> GLX_AUX_BUFFERS,
> > &value); if (ppfd->cAuxBuffers && !value) {
> > goto choose_exit;
> > }
>
> Is this co
I think they can't be distributed. Game developers ship some directx installer
which installs them. Distribution of these dlls is a bit tricky.
Perhaps if we really need them it might be an option to work together with
Transgaming. It are basicly utility libraries which don't touch any of the
r
> Hi,
>
> I've recently tried to play Heroes of Might and Magic IV under Wine,
> which has very poor performance and this message it printed out many,
> many times after the game is started:
>
> fixme:bitblt:X11DRV_BitBlt potential optimization - client-side DIB
> copy
>
> After doing some diggi
I have attached a tarball containing two logs one in case it works (log.works)
and one in which it fails (log.fails). When it worked wine was installed
in /usr/local and in the other case in /emul/ia32-linux/usr.
In the working case I executed 'WINEDEBUG=+dbghelp winedbg notepad' and piped
the
Hi,
What program are you using? Could you also attach a log 'WINEDEBUG=+wgl,
+opengl wine program.exe'?
Roderick
On Thursday 24 August 2006 22:47, Chris Rankin wrote:
> Hi,
>
> I have just updated my wine installation from CVS, and my OpenGL game is
> now crashing:
>
> X Error of failed request:
Could you also try a log of glxinfo?
Roderick
On Friday 25 August 2006 08:43, Chris Rankin wrote:
> --- Roderick Colenbrander <[EMAIL PROTECTED]> wrote:
> > What program are you using? Could you also attach a log 'WINEDEBUG=+wgl,
> > +opengl wine program.exe'?
&
I moved back to the standard dri drivers on my laptop and noticed the problem
aswell. I have a fix for it which I'll submit soon.
Roderick
> --- Roderick Colenbrander <[EMAIL PROTECTED]> wrote:
> > What program are you using? Could you also attach a log 'WINEDEB
Yesterday I posted a patch to wine-patches which should fix the issue in case
you are using the game in opengl mode. Try it and you'll see that it will work:
http://www.winehq.org/pipermail/wine-patches/2006-August/030123.html
If you get it in Direct3d9 mode the issue is way more complicated to
Yikes, I forgot to add the spec file changes to the patch.
Thanks for noting it,
Roderick
> Message d'origine
> >Date: Tue, 29 Aug 2006 01:39:49 +0200
> >De: "Roderick Colenbrander" <[EMAIL PROTECTED]>
> >A: [EMAIL PROTECTED]
> >
> "Elijah Newren" <[EMAIL PROTECTED]> wrote:
>
> > Ugh. Apparently, I busted our fullscreen handling in metacity>=2.14.x
> > in lots of cases in addition to problems we've being talking about in
> > this thread. See http://bugzilla.gnome.org/show_bug.cgi?id=343115#c6
> > if you're curious. Anyw
> hiho
>
> i am currently running Mike's (?) mmbranch git version of wine and
> beside some games are working without problems (or at least no new
> problems) Richard Burns Rally and Live For Speed quit instantly with the
> more or less same message, that there are no valid display modes
> availab
Hmm, strange.
Could you run the programs using WINEDEBUG=+wgl appname.exe and post me the
logs?
Roderick
> On Wed, Sep 06, 2006 at 07:42:03PM +0200, Roderick Colenbrander wrote:
>
> Hi Roderick,
>
> > The WGL patches which are in mike's tree are different ones. They mo
Hi,
Could you run your app this way: WINEDEBUG=+wgl,+opengl wine appname.exe and
pipe the output to a log file. This way I can figure out what's going on.
Further the output of glxinfo would be aswell.
Thanks,
Roderick
> Hi, i'm having lots of troubles running games with current git. First of
> Roderick Colenbrander wrote:
> > There's this check:
> > if ((!WineGLInfo.glxDirect && !strcmp("1.2",
> WineGLInfo.glxServerVersion)) ||
> > (WineGLInfo.glxDirect && !strcmp("1.2",
> WineGLInfo.glxClientVersion))
Ati doesn't advertise GLX_SGIX_fbconfig. They only advertise a GLX client
version of 1.3. Because the Xserver only supports 1.2, the reported version is
also 1.2 (only the client version number is 1.3, the rest not).
Roderick
> Roderick Colenbrander wrote:
> > The issue is that
The problem is that I'm not sure (and I think it is Alexandre his issue aswell)
whether this patch is a workaround or a real fix. I think that wined3d created
a GLX context in lets say thread '1' and that it wants to create lets say
another one in a different thread. If this is the case it could
Hi,
I had a little amount of time to look at the issue and have posted a fix to
the list. It appeared that the GLX context did still exist when
X11DRV_InitOpenGLInfo got called the second time from a different thread.
This most likely turned wined3d in a multithreaded OpenGL app which doesn't
This time with a patch.
> Hi,
>
> This is a resubmit of the previous font moving patch against the latest
> cvs/git version. The old version didn't apply anymore to winex11.drv. For the
> rest the patch is the same.
>
> Regards,
> Roderick Colenbrander
> --
&g
This should indeed be changed. I quickly checked a GL extension database and it
appears that mainly 3dlabs and Nvidia are advertising the extension. We could
just drop the extension check as glBlendColor and friends are part of OpenGL
1.1 or move to GL_EXT_blend_color and friends. I think droppi
Hi,
> > Roderick, Mesa calls the extension "GL_EXT_blend_minmax", and so does
> > the spec. I don't know what exactly uses the min_max form. Is this a
> > typo?
> Apart from the blend_minmax typo, it appears to be me this patch has
> some other problems.
>
> >> This patch changes the detecti
extensions.
Roderick
> On Tuesday 26 September 2006 03:21, Roderick Colenbrander wrote:
> > Vendors should still
> > advertise GL_ARB_imaging for backwards compatibility if they do support
> 1.4
> > or higher but ATI and friends don't :(
>
> Compliant implementatio
> On 28/09/06, James Hawkins <[EMAIL PROTECTED]> wrote:
> > Why should someone have to install glx to run Wine if they don't care
> > about using wined3d, or if they do need to use wined3d they don't care
> > about using glx? Wine should at least be able to compile in
> > circumstances such as the
and hope it is right then.
Thanks,
Roderick
> On Thu, Sep 28, 2006 at 08:20:51PM +0200, Roderick Colenbrander wrote:
> > Again as mentioned by Huw, the gdi32.spec file wasn't correct.
> > It should be correct this time.
>
> No. Your gdi32.spec was fine. It was the
Hi,
Right now I'm busy moving all GLX code over to winex11.drv. The
WGL_ARB_render_texture code was one of the pieces of code which I moved over
already. I haven't written the old code but it appeared more or less complete
in case GLX_ATI_render_texture is around. A few parts are implemented wh
Hi,
The plan is to get all the X-specific opengl code into winex11.drv and to get
rid of things like ExtEscape. I also want to avoid using WineGLContext in
opengl32.dll as I plan to change this too. A call like SyncCurrentDrawable
should in the end be placed inside winex11.drv.
I haven't looke
> Am Freitag, 6. Oktober 2006 15:26 schrieb Ulrich Czekalla:
> > From our discussions at wineconf we concluded that overriding the
> various
> > functions such as glViewport and glScissor will get us there for most
> > applications.
> >
> > The only thing this will not do is handle the case where
> What platform does not have MMX instructions and is now supported, is it
> problem to detect if CPU have MMX and use it if is it possible? Because
> speed improvment is always wantable.
>
> Mirek
Think about non-x86 CPUs on which Wine(lib) is used too.
Roderick
--
Der GMX SmartSurfer hilft
> I was reading through dlls/dsound/mixer.c and I came across the function
> DSOUND_MixerVol() that really stood out. The purpose of the code it to
> apply a volume amplification by multiplying the channel data by the
> amplification factor. What *really* struck me was the parallelism that
> could
Hi,
Myself I have written similar code before just for testing but something like
this can't be easily added to Wine. First of all adding new ExtEscape calls is
not an option, second in the near future I will drop all X code from wined3d. I
was planning to add videoram detection code once I'm d
ure that you work on the CVS/GIT version of Wine as it might already
contain a fix.
Regards,
Roderick Colenbrander
--
GMX DSL-Flatrate 0,- Euro* - Überall, wo DSL verfügbar ist!
NEU: Jetzt bis zu 16.000 kBit/s! http://www.gmx.net/de/go/dsl
> Hi Roderick,
>
> > This patch reimplements opengl32's wglGetProcAddress. The endresult is
> > a more reliable function which doesn't directly call X functions.
>
> I have tested this patch against current GIT and still i dont get any of
> my games running. one thing i tried - as i assumed maybe
> Hi,
>
> This is an updated version of the previous patch. I forgot to attach the
> changes to the make_opengl script which created the opengl_ext / opengl_norm
> source code.
>
> Regards,
> Roderick Colenbrander
>
>
> > Hi,
> >
> > This is a part o
> On 11/1/06, Bertrand Coconnier <[EMAIL PROTECTED]> wrote:
> > Hi,
> >
> > The last release of Wine 0.9.24 contains an error in the code of
> opengl32.dll.so
> > under X11 : Wine tries to get the address of "wglGetIntegerv" (line 608
> of
> > dlls/opengl32/wgl.c) before the extensions of WGL have
> Roderick Colenbrander wrote :
> >> On 11/1/06, Bertrand Coconnier <[EMAIL PROTECTED]> wrote:
> >>> Hi,
> >>>
> >>> The last release of Wine 0.9.24 contains an error in the code of
> >> opengl32.dll.so
> >>> under
> Roderick Colenbrander wrote:
> >> Roderick Colenbrander wrote :
> >>
> >>>> On 11/1/06, Bertrand Coconnier <[EMAIL PROTECTED]> wrote:
> >>>>
> >>>>> Hi,
> >>>>>
> >>>>
> Roderick Colenbrander wrote:
> >> Roderick Colenbrander wrote :
> >>
> >>>> On 11/1/06, Bertrand Coconnier <[EMAIL PROTECTED]> wrote:
> >>>>
> >>>>> Hi,
> >>>>>
> >>>>
> On Thu, Nov 02, 2006 at 05:46:07PM +0100, Christoph Frick wrote:
>
> > > Hmm, if that is indeed the case this patch could work for them. The
> > > whole issue is new for me, I'll see what I can do about it. Right now
> > > there's some GLX code in opengl32 which creates an opengl context. I
> >
> Hi,
>
> After investigating a bit in the Wine code, it seems that the flickering
> bug of WoW in OpenGL mode is due to wglGetPbufferDCARB that returns a DC
> which type is OBJ_MEMDC while it should return a DC which type is
> OBJ_DC. And since in the current git tree, the DC type of a Pbuffer
> Roderick Colenbrander wrote :
> >> Hi,
> >>
> >> After investigating a bit in the Wine code, it seems that the
> flickering
> >> bug of WoW in OpenGL mode is due to wglGetPbufferDCARB that returns a
> DC
> >> which type is OBJ_MEMDC while
> > Roderick Colenbrander wrote :
> > >> Hi,
> > >>
> > >> After investigating a bit in the Wine code, it seems that the
> > flickering
> > >> bug of WoW in OpenGL mode is due to wglGetPbufferDCARB that returns a
> > DC
> &
> Roderick Colenbrander wrote :
>
> > Or perhaps a testcase isn't needed at all. I think the use of
> CreateCompatibleDC in wglGetPbufferDCARB is incorrect. According to MSDN this
> function creates a memory device context. Perhaps something like this works:
> > HDC
> Roderick Colenbrander wrote :
> >> Roderick Colenbrander wrote :
> >>
> >>> Or perhaps a testcase isn't needed at all. I think the use of
> >> CreateCompatibleDC in wglGetPbufferDCARB is incorrect. According to
> MSDN this
> >> funct
101 - 200 of 694 matches
Mail list logo
