I made some progress. As I mentioned last time a .msstyles theme is just a
resource file wrapped into a dll. Windows tools try to edit real themes or
create themes by injecting resource data into a blank dll.
In order to obtain a resource file I used a tool called resource hacker to
retrieve o
This summer Maarten Lankhorst did some basic work on win64 support but for the
rest no work has been done it for a long time. I'm not sure what Maarten
exactly did but but there is a lot of work to be done before it will run even a
basic app.
Roderick
> Hi, i'd like to know if anyone knows the
Hi,
The way to go for Wine theming is to use Windows XP themes. Unfortunately the
file format itself is not documented. Based on Wine its uxtheme code (BTW our
uxtheme is quite complete) and an analysis of some 'free' XP themes like
'ClearLook' I was able to write my own theme template.
First
Hi,
I have the feeling that some of the drawing code is not correct and should use
information which is buried inside the theme file. Things like content margins,
text positions and things like that. I think it also requires test cases on
what has to be done when a property isn't set in the the
7; right now. (which is fine anyway as
for plain coloring we don't have to request uxtheme to render the controls
which will be a lot faster)
Roderick
> 2008/11/4 Roderick Colenbrander <[EMAIL PROTECTED]>:
> > Hi,
> >
> > The way to go for Wine theming is to u
Hi,
Note that Vmware its 3D support makes use of the opengl drivers of the host
system. In other words the crash could indeed be a bug inside the vmware 3d
drivers but it could even be related to the opengl drivers on your Linux system.
Roderick
> Hi,
>
> FYI.
>
> I had to disable "Accelerat
The registry key isn't bad. There should also come a key to override the pci
id. By default we will use the table and I plan to fix that one properly soon.
I talked about it to Henri and I thought that the name 'Display' is used in
several places and that likely we need to get the driver name fr
e and
> description in every situation, so I think this can be solution for some
> bugs now, and later we can improve it with better driver detection, but
> registry settings should be there even then.
>
> Mirek
>
> Roderick Colenbrander napsal(a):
> >> 2008/11/7 Mir
> 2008/11/7 Mirek Slugeň <[EMAIL PROTECTED]>:
> > Hi, Fallout 3 and maybe other games or D3D apps need such special
> settings,
> > this patch should be ok, it is well tested.
> >
> > This patch is not hack!
> >
> > New wine registry settings:
> > VideoDriver
> > VideoDescription
> >
> > Patch is f
> Sergey Novosyolov ha scritto:
> >
> > I've already started working on it about 3 months ago and released some
> > functions inside DIB Engine. But now we're thinking about release DIB
> inside
> > GDI32 as Detlef Riekenberg proposed:
> > On 9/29/08, Sergey Novosyolov <[EMAIL PROTECTED]> wrote:
> В сообщении от Thursday 13 November 2008 13:22:07 Massimo Del
> Fedele
> написал(а):
> > Sergey Novosyolov ha scritto:
> > > I've already started working on it about 3 months ago and released
> some
> > > functions inside DIB Engine. But now we're thinking about release DIB
> > > inside GDI32 as
> On Fri, Nov 14, 2008 at 9:43 AM, Branan Riley <[EMAIL PROTECTED]> wrote:
> > On Fri, Nov 14, 2008 at 5:54 AM, Joel Holdsworth
> > <[EMAIL PROTECTED]> wrote:
> >> Hi All,
> >>
> >> I notice that some of Wine's icons have been changed in recent
> releases.
> >> In principle I think updating the ico
A real small test app if possible as a wine test is needed to demonstrate it is
really correct. Sorry it can be a pain but it is to prevent issues in other
apps which might be very hard to debug if an incorrect patch enters Wine.
Roderick
> I know this isn't a coded test, bot The Sims 2 behave
The look of the website has improved a lot and it feels a lot more modern.
Personally I don't like the front page much. I find it a bit empty. I would
like to see what Wine is. I would suggest to look at http://www.go-mono.com the
website of the Mono project. On their website your directly see o
The Wine design would focus more on users. The 'banner' would be about running
your Windows programs on Linux/FreeBSD/Mac and would mention office apps, games
and so on. The highlights would show features e.g. support for Win3.1-XP,
DirectX capability and so on.
Roderick
Hi,
I don't know much about the current shader code but is this the right way to go
thinking about GL_EXT_texture_swizzle + GL_ARB_texture_rg? For instance Nvidia
drivers will soon get the swizzle extension and for that you don't have to
fixups anymore. Is moving this way the right approach, so
>
> Hi,
>
> I have a huge amount of Windows code that I'm porting to Linux.
>
> Wine is turning out to be a read godsend, thank you guys!
>
> Anyway, I've had tons of luck including the directory
> /include/wine/windows in my include path. All my Windows types are
> there and
> everything is w
> Joel Holdsworth writes:
>
> > Yes I agree it would be good for the icons to get some improvement. Some
> > of the ones there currently are pretty poor. We really need to try and
> > get as much consistency as we can. I really would encourage you to go
> > for tango if you can. It's served React
> > Joel Holdsworth writes:
> >
> > > Yes I agree it would be good for the icons to get some improvement.
> Some
> > > of the ones there currently are pretty poor. We really need to try and
> > > get as much consistency as we can. I really would encourage you to go
> > > for tango if you can. It'
> > Joel Holdsworth writes:
> >
> > > Yes I agree it would be good for the icons to get some improvement.
> Some
> > > of the ones there currently are pretty poor. We really need to try and
> > > get as much consistency as we can. I really would encourage you to go
> > > for tango if you can. It'
rom 73b14244008b5541c7f92f290c4b4e4e51bb6f50 Mon Sep 17 00:00:00 2001
From: Roderick Colenbrander
Date: Wed, 17 Dec 2008 23:20:02 +0100
Subject: [PATCH] Add GL_ARB_texture_rg / GL_EXT_texture_swizzle support. These extensions are needed for more efficient R32F/RG32F support.
---
dlls/wined3d/directx.c|2 ++
d
ensions to the extension list
> without making use of them. I think this should be done in one patch.
>
>
> > -Original Message-
> > From: wine-devel-boun...@winehq.org [mailto:wine-devel-
> > boun...@winehq.org] On Behalf Of Roderick Colenbrander
> > Sent: Wedne
though. Just a general note, the
> patch
> itself looks ok)
>
>
> > -Original Message-
> > From: wine-patches-boun...@winehq.org [mailto:wine-patches-
> > boun...@winehq.org] On Behalf Of Roderick Colenbrander
> > Sent: Thursday, December 18, 2008 1
> Von: "Dan Kegel"
> An: "Wine Devel"
> Betreff: wow, there are more win64 apps than I thought...
> I updated http://wiki.winehq.org/Wine64 with a list
> of some win64 apps. There are lots more than I
> expected.
>
I guess it is time to make 64-bit Photoshop CS4 a requirement for Wine 1.2 ;)
> Dan Kegel a écrit :
> > I updated http://wiki.winehq.org/Wine64 with a list
> > of some win64 apps. There are lots more than I
> > expected.
> >
> >
>
> From the Wiki:
>
> "One of the major differences is the size of the "long" type, which is
> 64 bit in Linux but 32 bit in Windows"
>
>
>
>
> Reece Dunn-2 wrote:
> >
> > Thoughts? Ideas?
> >
>
> I'm just a user, not a dev, so forgive me if this sounds stupid, but it
> seems to me like it would be simpler to just create some sort of layer
> that
> forwards all calls to the Win32 theming API to Qt, and make Wine dependent
> on Q
> Say, http://www.kronenberg.org/darwine/ seems to be a popular source
> of nearly up to date wine builds for the mac. How about we link to it
> from http://winehq.org/download/ ?
>
> Furthermore, are his packages good enough to support?
> If so, how 'bout we ask him to add links to bugzilla and
> > On Sunday 21 December 2008 07:48:58 pm Damjan Jovanovic wrote:
> >> The heuristic isn't "app works on this Windows version", it's "app is
> >> designed for this Windows version".
> >
> > Should that matter? Plenty of Win95 apps will work in WinXP.
>
> ... because WinXP has such a version heuri
> As my DIB engine is becoming usable (I already use it on Autocad for my
> job), I'm thinking to publish the patches.
> As it's still not complete, I'm thinking to add a way to enable it on
> demand with registry and environment variable :
>
> export WINEDIB=ON activates it
> export WINEDIB=OFF
We have both a glDrawPixels and texture backend. You can switch to a different
backend using the RenderTargetLockMode registry key. It has values readdraw
(readpixels + drawpixels), readtex (readpixels + texture rendering) and some
others (textex and texdraw).
I plan on making readtex default a
> Hi folks,
> it seems odd to me that Wine doesn't have a tool like
> dxdiag yet. We often have people complain that
> graphics aren't working, and we have to ask them
> to do things like run glxgears as diagnostics.
> Would it make sense to implement our own
> dxdiag.exe program?
> This seems li
> On Sun, Dec 28, 2008 at 6:24 AM, Henri Verbeet wrote:
> > ... I think the main use of such an application would be
> > dumping information like supported caps, texture formats, etc in case
> > of D3D and supported extensions, pixelformats, various limits, drivers
> > strings, etc. for OpenGL.
>
> On Sun, Dec 28, 2008 at 7:43 AM, Roderick Colenbrander
> wrote:
> >> Also, isn't it annoying that native dxdiag always says
> >> the graphics card is X Windows? Why is that, and
> >> should we change Wine so that the true card's info
> >> is
> > > Also, isn't it annoying that native dxdiag always says
> > > the graphics card is X Windows? Why is that, and
> > > should we change Wine so that the true card's info
> > > is reported by native dxdiag?
> > >
> > I don't know, but if I were to guess I'd say it probably doesn't get
> > that i
> On Sun, Dec 28, 2008 at 8:43 AM, Roderick Colenbrander <
> thunderbir...@gmx.net> wrote:
>
> > Native dxdiag is checking the name of the display driver which in our
> case
> > winex11.drv and I guess this is just the identifier of Winex11.drv.
> Inside
> &g
> On Sunday 28 December 2008 07:43:57 am Roderick Colenbrander wrote:
> > Native dxdiag is checking the name of the display driver which in our
> case
> > winex11.drv and I guess this is just the identifier of Winex11.drv.
> Inside
> > winex11.drv we don't really
> Wine on Windows is an idea of real-world usefulness, as newer versions
> of Microsoft Windows increasingly fail to support apps Wine still
> supports.
>
> I've started a wiki page: http://wiki.winehq.org/WineOnWindows
>
> This covers my experiments with the three main POSIX layers (Cygwin,
> Mi
> Sketchup seems to be working pretty well, so I just posted
> http://digg.com/linux_unix/Google_Sketchup_7_working_in_Wine_1_1_11
> to see if I could attract some real sketchup users
> to find more bugs.
>
> If folks agree that's a good idea, they can support it
> by digging it so it can show up
> I haven't still any clue if the way I started the DIB engine has the
> correct approach, I mean if I should follow this way with the hope to
> have it included in main tree or not Can please somebody tell me
> something about ?
>
> Ciao
>
> Max
>
I would recommend you to visit #wineh
> Juan Lang wrote:
> >> so I just cutted icons from other toolbars' bitmaps;
> >>
> >
> > Which other toolbars, specifically? You can't grab copyrighted work,
> you know.
> > --Juan
> >
> >
> Yeah, I know. All bitmaps were from Wine itself (comctl32 etc).
Why not use icons from the tango
> On Sat, Jan 3, 2009 at 5:19 PM, Andrey Turkin
> wrote:
> > James Hawkins wrote:
> >
> > On Sat, Jan 3, 2009 at 3:07 PM, Andrey Turkin
> > wrote:
> >
> >
> > I _love_ this idea, and icons look very nice, but here can be some legal
> > troubles. The icons are under Creative Commons - Share Alike
> > Why not use icons from the tango project?
>
> There's also the nuvola icon theme, which, conveniently, is already LGPL:
> http://www.icon-king.com/projects/nuvola/
> --Juan
I believe windows contains some generic icons build into shell32 and some other
dlls but theme files can override them.
>
> Does anyone know how to get the libaudioio.h and libaudioio.so files
> needed by the wineaudioio driver?
>
> This driver is supposed to specifically be for Solaris but I could not
> find either files on the Solaris 10u5 DVD, nor on the 200807 Solaris 10
> companion CD.
>
> Has audioio bee
Hi Vitaliy,
Peter Hutterer has submitted a draft specification of Xinput2 to the xorg
mailinglist. As you know it will offer relative mouse movements. He is asking
for feedback. Since I have no experience with Xinput you might want to review
it and see if it works out for Wine.
Roderick
-
Hi Henri,
Just a suggestion for a future patch. The current autogenmipmap code isn't
correct. Even when this capability isn't supported the function might not
return D3DERR_INVALIDCALL IF CheckDeviceFormat returns D3DOK_NOAUTOGEN for this
usage flag. I stumbled on this when I started improving
> On Sat, Nov 15, 2008 at 8:37 AM, Reece Dunn
> wrote:
> > 2008/11/15 Dan Kegel :
> >> On Sun, Nov 2, 2008 at 10:58 PM, Reece Dunn
> wrote:
> >>> .. the first step for Wine is making the
> >>> uxtheme/msstyles support work well so that it can be used by
> >>> distributions to theme Wine.
> >>
> >
> 2009/1/15 Roderick Colenbrander :
>
> > A while ago when I looked at how XP theme files worked I also took a
> look at this theme. I don't think any package should ship this theme the same
> for other XP themes. The problem is that all XP theme 'creators'
> After STALKER: Clear Sky failed to generate viable sound output using
> the existing drivers (in GIT head as of a few days back), I started
> looking for solutions and stumbled over this thread:
> http://www.nabble.com/RFC:-OpenAL-Winmm-driver-and-OpenAL32.dll-thunk-was-Re:-OpenAL-and-DirectSound
> I tried to play Supreme Commander using pbuffer option instead of fbo. I
> was quite happy with it, since I gained quite a bunch of performance (I
> mean, something I really COULD see), but after a while, the performance
> dropped dramatically, to ~4-5 fps.
>
> I tested quite a few thing, and
> Roderick Colenbrander a écrit :
> >> I tried to play Supreme Commander using pbuffer option instead of fbo.
> I
> >> was quite happy with it, since I gained quite a bunch of performance (I
> >> mean, something I really COULD see), but after a while, the performa
> 2009/1/25 Massimo Del Fedele :
> > The engine is disabled by default; can be changed by environment
> variable :
> >
> > export WINEDIB=ON (or ENABLE or ENABLED or TRUE) enables it
> > export WINEDIB=OFF (or DISABLE or DISABLED or FALSE) disables it
> >
> > or by registry key :
> >
> > HKCU/Sof
> 2009/1/27 Massimo Del Fedele :
> > Any opinion about this one ? Could it be a good candidate for inclusion
> > in wine tree ?
>
> Hi,
>
> I have used this with StarCraft, running it with and without the DIB
> engine enabled. I find the environment variable makes it very easy to
> switch between
Hi,
The XEMBED stuff in Wine is different than what you need. This code is inside
wine's x11 driver and has the purpose of integrating the Wine system tray with
KDE/Gnome. It is for internal wine usage and can't be used for your purpose.
You could search for the kde reaktivate project. It was d
> Hi,
>
> I am using wine to play World of warcraft (this game is using opengl, and
> is
> threaded - 2/3 threads IIRC). I did recently find a reproductable
> performance regression on versions 0.9.24+.
>
> Under the same conditions (always difficult to get in an MMORPG game, but
> this is reprod
Hi,
I'm not sure if checking for the GLX extension is such a good idea as it is
possible to use OpenGL without having the GLX extension. For instance when
plain Mesa is used.
Regards,
Roderick
--
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
Ideal für Modem und ISDN: htt
thing to do is to
'test' the OpenGL implementation by making a GLX call like glXQueryVersion or
whatever. Errors can be caught using a X11DRV_expect_error. I fear that
something like this is the only way.
Roderick
> On Sunday 24 December 2006 10:12, Roderick Colenbrander wrote:
&
se it calls glXGetProcAddress).
>
> In the end this patch makes sure that only functions which start with a
> 'w' are passed to the winex11.drv code in the other cases a warning is
> printed that the function wasn't found.
>
> Regards,
> Roderick Colenbrand
> On Sunday 31 December 2006 00:12, you wrote:
> > AFAIK there is no technical problems, only political ones. Wine no
> > longer allows subwindows to be X11 windows. I've heard Alexandre
> > Julliard won't accept such patches.
>
> These wouldn't be Win32 subwindows as X11 child windows (as I heard
> > These wouldn't be Win32 subwindows as X11 child windows (as I heard Wine
> > doesn't do), but rather, a child window of the main window used solely
> for
> > showing OpenGL on. I can't, in my admittedly limited knowledge, think of
> > why
> > it wouldn't work, and it should also help clear the
Original-Nachricht
> > TRACE(" make current for dis %p, drawable %p, ctx %p\n",
> gdi_display, (void*) drawable, ctx->ctx);
> > +X11DRV_expect_error(gdi_display, error_catcher, NULL);
> > ret = pglXMakeCurrent(gdi_display, drawable, ctx->ctx);
> > +
Hi,
Why are you using a lookup table and not just a log10(x) and 10^(x) for the
gain <-> dB conversions? That's how it should be done I think like 10x
corresponding to 20dB (assuming signal gain). In your tests it is just:
2000*log10(gain) - 9630 for going to that dB-like scale.
Regards,
Roderi
> On Wednesday 24 January 2007 21:51, Ken Thomases wrote:
> > +WineGLInfo.glExtensions = strdup((const char *)
> pglGetString(GL_EXTENSIONS));
>
> Shouldn't this be free'd somewhere? What about the other strings?
>
The problem with this string is that it depends on the presence of a
Use this patch which I made a while ago. I still need to fix some things in it
but it handles the conversion using fragment shaders. You need to set the
DirectDrawRenderer to opengl and RenderTargetLockMode to readtex. I hope to
clean it up soon.
Roderick
> I'm working on some direct draw code
> http://bugs.winehq.org/show_bug.cgi?id=4273 points to a
> patch set that implements 32 bit per pixel cursors
> and a bunch of other cursor stuff.
>
> Looks like the patch got dropped by the author, though,
> and since it makes server changes, it's going to be hard
> to get past Alexandre.
>
> I
>
> OpenGL: I don't really know of the windowed opengl state, and the wined3d
> ->
> wgl move. Still planned?
>
OpenGL needs to get proper windowed opengl rendering support. The best route to
that seems to be by using opengl child windows. There's a patch for it but it
needs cleanups and then
While the functionality you mentioned might be broken at the moment the
following might also be useful: http://wiki.winehq.org/Debug_trace_toggle_key
The patch adds a key using which you can enable/disable debugmessages.
> It looks like programs/taskmgr/taskmgr used to let
> you edit debug chann
wing
things on the grid, the objects quickly disappear. There's some buffer swapping
issue I guess. The same happens without the child window patch and using ulrich
his patch. So the issue is not related to child windows.
Regards,
Roderick Colenbrander
--
"Feel free" - 10 GB Mail
The previous version contained a bug in the GLX context creation code of
wglShareLists. The error led to a BadMatch in demos which work using upcoming
patches.
Roderick
On Thursday 26 July 2007 20:52, Roderick Colenbrander wrote:
> This patch enables the newly added offscreen formats for
On Monday 30 July 2007 22:28, H. Verbeet wrote:
> On 30/07/07, James Hawkins <[EMAIL PROTECTED]> wrote:
> > Compile fails for me with today's git:
> >
> > opengl.c: In function 'ConvertAttribWGLtoGLX':
> > opengl.c:676: error: 'GLX_RGBA_FLOAT_BIT_ARB' undeclared (first use in
> > this function)
> >
Could you update to the latest GIT? :)
Roderick
On Monday 30 July 2007 23:39, Dan Kegel wrote:
> I just did a git pull, and compilation is failing with
> opengl.c:676: error: 'GLX_RGBA_FLOAT_BIT_ARB' undeclared (first use in
> this function)
> I think that symbol reference was added just today:
>
Ignore this patch. I'll write a better version.
Roderick
On Wednesday 01 August 2007 19:54, Roderick Colenbrander wrote:
> Hi,
>
> According to the specs wglChoosePixelFormatARB returns the number of
> matching pixelformats. This number can be different than the size of the
>
Don't apply this one yet as noted by Chris Robinson it isn't fully correct
yet.
Roderick
On Wednesday 01 August 2007 22:22, Roderick Colenbrander wrote:
> Hi,
>
> According to the specs wglChoosePixelFormatARB returns the number of
> matching pixelformats. This number can
> 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):
>
> if (cond) do_sth();
> do_sth_else();
>
I think you are speaking about the opengl code there. There are quite a number
o
Both are 'fake' WGL extensions. I agree that no string should be displayed in
either case and that we don't need a check for NV_texture_rectangle.
The loading of the NV vertex array range stuff depending on the presence of
the GL extension of which it is part is fine. Yes, GL extensions are cont
I would like to keep this GL_RENDERER/GL_VENDOR stuff around although it might
not be 100% correct in all cases (on some cards there's indeed a difference
between direct and indirect rendering). To be correct also add similar code
to the glx context creation code.
Roderick
On Friday 10 August
On Saturday 11 August 2007 13:07, Dan Kegel wrote:
> Why are all our new bugs cc'd to [EMAIL PROTECTED]
> I suspect that's a default that needs to be removed...
In the #winehackers channel there's now a bot which notifies of bugzilla
changes. It could be related to that.
Roderick
Allow building of ddraw/ddrawex on mingw. By default the dxguid from mingw is
used which doesn't work for us as it is outdated.
Regards,
Roderick Colenbrander
From 686af597215164e3c20a3c5e86620fc875fa0838 Mon Sep 17 00:00:00 2001
From: Roderick Colenbrander <[EMAIL PROTECTED]>
Date:
Hi,
I think I got my mingw from the debian packages. Others also suggested that
the dxguid version in mingw was outdated.
Roderick
On Sunday 12 August 2007 22:01, Stefan Leichter wrote:
> Am Sunday 12 August 2007 15:17 schrieb Roderick Colenbrander:
> > Allow building of ddraw/ddrawex
ll changes are done the ifdef will be removed. I add it now to
> prevent large patches.
>
> Regards,
> Roderick Colenbrander
Wouldn't it be cleaner to cache the double buffering property in the
WineGLPIxelFormat and set the gdi cap in there? That would skip another
unneeded function.
Roderick
Err, the patch is correct. I somehow missed that a test was part of it. Sorry.
On Tuesday 14 August 2007 11:08, Roderick Colenbrander wrote:
> Wouldn't it be cleaner to cache the double buffering property in the
> WineGLPIxelFormat and set the gdi cap in there? That would skip another
On Thursday 16 August 2007 12:06, Maarten Lankhorst wrote:
> Makes it cross-compilable to produce a windows binary.
I don't think this is the right way. It appears that native dxguid doesn't
define some of the uuids needed for directdraw / directsound. You need to
check where the missing guids a
The decision on what to do for a big part depends on what OpenGL 3.0 actually
is. From carefully reading the latest OpenGL 3.0 announcements and their
forums I come to the conclusion which I'll explain below.
There are basically two new OpenGL versions named respectively: Longs Peak,
and Mt. E
On Saturday 18 August 2007 13:59, H. Verbeet wrote:
> What it comes down to is that there are two things we have to make a
> decision about:
> - Do we want to support GL3 in the existing wined3d?
> - Do we want to support D3D10 on top of the existing wined3d?
>
> I've got a slight preference to
complicated.
In order to be able to use wine functions you need to (re)compile parts of
your program using Winelib (e.g. winegcc/wineg++). Your program will depend
on Wine but you will be able to use the win32 dll.
Regards,
Roderick Colenbrander
disabled
> in the patch since it's for testing offscreen rendering, but it's simple to
> re-enable).
Demos like DX9 swap chains / 3DMark are heavily GPU limited e.g. they push the
card to its limits. Normal programs are most of the time cpu limited. They
are GPU limited ofcourse if you run the program on a system which the program
considers lowend.
Regards
Roderick Colenbrander
On Wednesday 22 August 2007 20:57, H. Verbeet wrote:
> > This solution is the best way to go. Luckily Microsoft made similar
> > changes in Vista.
>
> Conceptually its probably correct, but I think the speed hit is pretty
> large, and it's not like we've got a lot of performance to spare. As
> for
On Wednesday 22 August 2007 21:10, H. Verbeet wrote:
> On 22/08/07, Roderick Colenbrander <[EMAIL PROTECTED]> wrote:
> > There are two distinct cases. You have programs that use a toplevel for
> > GL/D3D rendering (in general this is the case for games). Further you
> &g
On Monday 27 August 2007 19:37, H. Verbeet wrote:
> On 27/08/07, Martijn Berger <[EMAIL PROTECTED]> wrote:
> > +WINE_DEFAULT_DEBUG_CHANNEL(d3d10);
>
> That's not a good idea. Also, since the dll isn't actually called
> d3dx9.dll, how do you intend to handle the different versions?
There is an orig
On Tuesday 28 August 2007 16:11, Ed Sutter wrote:
> >>Anyway, if it makes more sense for me to just report problems that I have
> >>with uCon when running it on wine, that's fine with me. Bottom line is
> >>I will do whatever is most appropriate/helpful/efficient to get it
> >> running and that in
On Thursday 30 August 2007 00:35, Jakob Eriksson wrote:
> Now that GDIplus is shaping up, is there a chance of implementing .forms
> support in mono with it?
>
> regards,
> Jakob
Mono contains its own version of gdiplus for rendering system.drawing and in
the end Windows.Forms. Though on windows
On Thursday 30 August 2007 17:49, Jakob Eriksson wrote:
> Roderick Colenbrander wrote:
> > On Thursday 30 August 2007 00:35, Jakob Eriksson wrote:
> >> Now that GDIplus is shaping up, is there a chance of implementing .forms
> >> support in mono with it?
> >>
&
On Thursday 30 August 2007 18:41, Jakob Eriksson wrote:
> Roderick Colenbrander wrote:
> > O
> > I think the incompatibilities you mean are for instance that in case of
> > Mono you can mix Windows.Forms with win32 calls. If you don't like the
> > behavior of s
On Thursday 30 August 2007 19:05, Jakob Eriksson wrote:
> Roderick Colenbrander wrote:
> > The main issues were related to using Wine as a sort of 'plugin'. They
> > didn't want to use standard winelib. The Mono hack they proposed for it
> > wasn't accepted
We use this mechanism on purpose. We can't have hundreds of cards in
the database. The real name isn't that important it is mostly
cosmetic, so it is not a real bug.
Roderick
On Sat, Oct 31, 2009 at 5:37 PM, JesusFreke wrote:
>
>
> On Sat, Oct 31, 2009 at 11:00 AM, Vitaliy Margolen
> wrote:
>>
>> JesusFreke wrote:
>> > ---
>> > dlls/winex11.drv/mouse.c | 1 +
>> > 1 files changed, 1 insertions(+), 0 deletions(-)
>> >
>> > diff --git a/dlls/winex11.drv/mouse.c b/dl
Hi Peter,
I didn't see this patch before because I was away at that time. The
SourceConstantAlpha part looks correct to me. It might make sense to
calculate blendfn.SourceConstantAlpha / 255 before the loop, so that
it isn't recalculated each time.
The other half of your patch is a separate chang
Hi Marcus,
A couple of hours ago I submitted a patch rewrites the function. It
suffers from the same 'issue'. This and any other wgl function are
called from gdi32/opengl.c which perform magic to arrive here and in
case of wglsharelists it also performs the filtering.
Roderick
On Sun, Nov 15, 20
Hi Anders,
Your patch changes to two different dlls in one patch. In general a
patch should only change one thing. It would be nice if you could
separate it because else I'm not sure if it will be added.
Roderick
On Sun, Nov 15, 2009 at 9:12 PM, Anders Jonsson
wrote:
> Fixes some typos in comc
On Mon, Nov 16, 2009 at 11:02 AM, Marcus Meissner wrote:
> On Sun, Nov 15, 2009 at 10:37:27PM +0100, Roderick Colenbrander wrote:
>> Hi Marcus,
>>
>> A couple of hours ago I submitted a patch rewrites the function. It
>> suffers from the same 'issue'. This and
401 - 500 of 694 matches
Mail list logo
