Hello,
looking at the web page:
http://www.nabble.com/d3d:-Bug-in-handling-of-depth-stencil-surfaces,-and-potential-patch-td19907752.html
I read that there are problems with the ref count in d3d wine implementation.
Does there exist any plan to fix it? Or can we try to implement the Jim's idea
Am Sonntag, 5. April 2009 11:32:38 schrieb paulo lesgaz:
Hello,
looking at the web page:
http://www.nabble.com/d3d:-Bug-in-handling-of-depth-stencil-surfaces,-and-p
otential-patch-td19907752.html
I read that there are problems with the ref count in d3d wine
implementation.
Does there
http://forum.winehq.org/viewtopic.php?t=4403
Some highly impractical ideas, but certainly having the users throw
ideas around should inspire wine-devel (and Codeweavers) :-)
- d.
Here's what i done for now:
http://img227.imageshack.us/img227/8531/winecfgnew.png
Before continuing, i would like to know if it is acceptable?
Sorry is in french, but Options avancées means Advanced options. A
dialog will then pop up and let the user choose advanced options (video
memory size,
It's also affecting one of my bugs:
http://bugs.winehq.org/show_bug.cgi?id=15858
It's sort of random when a real crash occurs but the debugging revealed
that the object that is used was already freed by wined3d.
I can increase the probability of a crash by running a bunch of
memory-hungry apps
I'm not a favor of adding options as we try to autodetect everything. Users
shouldn't touch them using winecfg in general. If you check lets say appdb
you see a lot of tutorials recommending certain options while the authors
have no idea what the options do and I have seen various tutorials where
On Sun, Apr 5, 2009 at 2:36 PM, Roderick Colenbrander
thunderbir...@gmail.com wrote:
I'm not a favor of adding options as we try to autodetect everything. Users
shouldn't touch them using winecfg in general. If you check lets say appdb
you see a lot of tutorials recommending certain options
2009/4/5 Austin English austinengl...@gmail.com:
Again, the same argument can be made for native dlls. Tons of
tutorials recommend setting just about every dll to native, and
winecfg allows this. Should we not allow people to set more than 3
dlls to native?
You could certainly make an
After a discussion on #winehackers I want to add something for the archives:
This is a situation that cannot be solved in d3d9 alone, a fix has to involve
wined3d. This is because there is a hidden reference kept on every object
that is referenced in any stateblock, even the non-primary ones.
People, is adding a warning message not enough?
Here's what i set as message in the configuration window in my patch:
Only change these settings if you know what you're doing. Changing
these values may result in unexpected behaviors and unstability.
Any suggestions are welcome concerning the
People, is adding a warning message not enough?
Here's what i set as message in the configuration window in my patch:
Only change these settings if you know what you're doing. Changing
these values may result in unexpected behaviors and unstability.
Any suggestions are welcome concerning the
See http://bugs.winehq.org/show_bug.cgi?id=17938 for background.
Vitaliy closed this bug, saying it's an application bug that it
depends on seeing NTFS file system type for certian program features.
I don't think it should be a WONTFIX, as the only reason that change
was introduced was to enable
Austin English wrote:
See http://bugs.winehq.org/show_bug.cgi?id=17938 for background.
Sent reply direct to Austin. This may be outside of Wine's control due
to flaky NTFS support by some Linux distributions.
James McKenzie
Hans Breuer wrote:
From b89af7d06fc8cbf5210c61fd58ed62caeddad968 Mon Sep 17 00:00:00 2001
From: Hans Breuer h...@breuer.org
Date: Sun, 29 Mar 2009 18:27:29 +0200
Subject: implement PS_USERSTYLE handling, tested with Dia(win32) - see
http://hans.breuer.org/dia/dia-wine.htm
---
On Sun, Apr 5, 2009 at 4:51 PM, James McKenzie
jjmckenzi...@earthlink.net wrote:
Austin English wrote:
See http://bugs.winehq.org/show_bug.cgi?id=17938 for background.
Sent reply direct to Austin. This may be outside of Wine's control due
to flaky NTFS support by some Linux distributions.
2009/4/5 Stefan Dösinger ste...@codeweavers.com:
After a discussion on #winehackers I want to add something for the archives:
This is a situation that cannot be solved in d3d9 alone, a fix has to involve
wined3d. This is because there is a hidden reference kept on every object
that is
Am Sonntag, 5. April 2009 23:59:01 schrieb Henri Verbeet:
I don't know what was discussed on IRC, but essentially we need to
keep track of which resources (in a broad way, not just objects
derived from IWineD3DResource) are in use by a stateblock in wined3d,
and delay destroying the d3d9
2009/4/6 Stefan Dösinger ste...@codeweavers.com:
That was my suggestion. We already keep a wined3d-internal refcount for all
these objects(shaders, textures, ...), and my plan was a callback
function(maybe provided via a COM interface, similar to the
WineD3DDeviceParent one). Some time ago I
Personally I would've eliminated the implementation differences first
(the main difference is when the data is copied, unmap vs. preload),
and then just killed IWineD3DIndexBufferImpl once they were the same
from an implementation point of view. Eg., you can ignore the
conversion if you can prove
2009/4/4 Stefan Dösinger ste...@codeweavers.com:
-hr = IWineD3DDevice_CreateBuffer(This-wined3d_device, wined3d_desc,
-data ? data-pSysMem : NULL, (IUnknown *)object,
object-wined3d_buffer);
+hr = IWineD3DDevice_CreateBuffer(This-wined3d_device, 0 /* fvf */,
+
2009/4/4 Stefan Dösinger ste...@codeweavers.com:
+pDesc-Usage = pDesc-Usage;
+pDesc-Pool = pDesc-Pool;
+pDesc-Size = pDesc-Size;
This is just silly.
2009/4/4 Stefan Dösinger ste...@codeweavers.com:
+WINED3DRESOURCETYPE WineD3DRType;
TRACE((%p)-(%d, %d, %d, %08x, %d, %d)\n, This, Adapter, DeviceType,
AdapterFormat, Usage, RType, CheckFormat);
+switch(RType) {
+case D3DRTYPE_VERTEXBUFFER:
+case
Am Montag, 6. April 2009 00:30:31 schrieb Henri Verbeet:
2009/4/4 Stefan Dösinger ste...@codeweavers.com:
+pDesc-Usage = pDesc-Usage;
+pDesc-Pool = pDesc-Pool;
+pDesc-Size = pDesc-Size;
This is just silly.
Hmm Smells like copypaste
2009/4/6 Austin English austinengl...@gmail.com:
On Sun, Apr 5, 2009 at 4:51 PM, James McKenzie
jjmckenzi...@earthlink.net wrote:
Austin English wrote:
See http://bugs.winehq.org/show_bug.cgi?id=17938 for background.
Sent reply direct to Austin. This may be outside of Wine's control due
On Sunday 05 April 2009 5:35:36 pm Ben Klein wrote:
My suggestion is a drop-down box in the Advanced tab of Drives to
control filesystem type (separate from disk type, as is suggested in
Comment #7 on 17938). It shouldn't be important for floppies or even
CD-ROMs, but the options could be:
-
2009/4/6 Henri Verbeet hverb...@gmail.com:
2009/4/5 Austin English austinengl...@gmail.com:
Again, the same argument can be made for native dlls. Tons of
tutorials recommend setting just about every dll to native, and
winecfg allows this. Should we not allow people to set more than 3
dlls to
On Mon, Apr 6, 2009 at 2:52 AM, Chris Robinson chris.k...@gmail.com wrote:
On Sunday 05 April 2009 5:35:36 pm Ben Klein wrote:
My suggestion is a drop-down box in the Advanced tab of Drives to
control filesystem type
Why not make the default what the filesystem actually is?
Another option is
On Sun, Apr 5, 2009 at 7:35 PM, Ben Klein shackl...@gmail.com wrote:
If I interpret it correctly, the user reporting bug 17938 is trying to
use a native NTFS filesystem with Wine, which we already know is a bad
idea :)
No. The problem is that we _used_ to have NTFS reported as the default
file
On Mon, Apr 6, 2009 at 2:52 AM, Chris Robinson chris.k...@gmail.com wrote:
On Sunday 05 April 2009 5:35:36 pm Ben Klein wrote:
My suggestion is a drop-down box in the Advanced tab of Drives to
control filesystem type
Why not make the default what the filesystem actually is?
That may be a lot
2009/4/6 Chris Robinson chris.k...@gmail.com:
On Sunday 05 April 2009 5:35:36 pm Ben Klein wrote:
My suggestion is a drop-down box in the Advanced tab of Drives to
control filesystem type (separate from disk type, as is suggested in
Comment #7 on 17938). It shouldn't be important for floppies
On Sunday 05 April 2009 6:01:15 pm Ben Klein wrote:
Isn't that more-or-less what I suggested?
The biggest problem would be detecting what filesystem a given
directory is on (noting that wine's drives are not even mounted
partitions). Expert parsing of /etc/mtab would indicate it on Linux
2009/4/6 Chris Robinson chris.k...@gmail.com:
On Sunday 05 April 2009 6:01:15 pm Ben Klein wrote:
Isn't that more-or-less what I suggested?
The biggest problem would be detecting what filesystem a given
directory is on (noting that wine's drives are not even mounted
partitions). Expert
On Sun, Apr 5, 2009 at 8:45 PM, Ben Klein shackl...@gmail.com wrote:
2009/4/6 Chris Robinson chris.k...@gmail.com:
On Sunday 05 April 2009 6:01:15 pm Ben Klein wrote:
Isn't that more-or-less what I suggested?
The biggest problem would be detecting what filesystem a given
directory is on
On Sunday 05 April 2009 6:45:42 pm Ben Klein wrote:
That might be fine for mount points and mountable devices, but how
could you accurately determine the filesystem type for an arbitrary
directory like $HOME/.wine/drive_c?
Expand it (eg. $HOME - /home/user), resolve all symlinks, then see which
2009/4/6 Chris Robinson chris.k...@gmail.com:
On Sunday 05 April 2009 6:45:42 pm Ben Klein wrote:
That might be fine for mount points and mountable devices, but how
could you accurately determine the filesystem type for an arbitrary
directory like $HOME/.wine/drive_c?
Expand it (eg. $HOME -
On Sun, Apr 5, 2009 at 7:53 PM, Ben Klein shackl...@gmail.com wrote:
I agree with Henri here. UseGLSL and OffscreenRendering are
approaching the point where they don't need to be changed. Detecting
the amount of video memory should be preferred over setting it
manually. Most of these settings
2009/4/6 Austin English austinengl...@gmail.com:
On Sun, Apr 5, 2009 at 7:53 PM, Ben Klein shackl...@gmail.com wrote:
I agree with Henri here. UseGLSL and OffscreenRendering are
approaching the point where they don't need to be changed. Detecting
the amount of video memory should be preferred
Chris Robinson chris.k...@gmail.com wrote:
Why not make the default what the filesystem actually is? Eg. if the FS is
FAT32, report FAT32; if it's NTFS, report NTFS; if it's a unixfs, report
unixfs; etc. The registry/winecfg can then be used to override the per-drive
type if it causes
38 matches
Mail list logo
