Dan Kegel wrote:
Still a lot of NULL ptr migration issues which suck
to fix, but well.
709 DEADCODEDEVENUM_ReadPinTypesdevenum/createdevenum.c
717 FORWARD_NULLDEVENUM_ReadPinTypesdevenum/createdevenum.c
NULL-dereference may be a false positive from the way memory
Henri Verbeet wrote:
2008/9/2 Alexander Dorofeyev [EMAIL PROTECTED]:
I don't think this is possible yet, the variable is also used for some
window/screen and upside-down coordinate magic. I do suspect that the code
doing
so may need to be fixed or removed, because it looks inconsistent
Henri Verbeet wrote:
2008/8/31 Alexander Dorofeyev [EMAIL PROTECTED]:
Handled in ActivateContext, must be remains of pre-context management code.
---
dlls/wined3d/surface.c | 10 --
1 files changed, 0 insertions(+), 10 deletions(-)
If you're going to remove those glDrawBuffer
Henri Verbeet wrote:
2008/8/31 Alexander Dorofeyev [EMAIL PROTECTED]:
This prevents shader path from being entered for an offscreen surface when
there is p8 render target and fixes failures in ddraw visual test (with
opengl rendering and RTL_READDRAW mode) and visual glitches in Red Alert
Any reason this isn't tested? I don't know about this function in
particular, but there have been games that were confused by NOT clearing
output to NULL on error (not in GetDepthStencilSurface though).
Also regardless of setting or not-setting to NULL, the warning may have
its uses when
Rico Schüller wrote:
Hi,
the attached patch solves a hard crash on my ati mobility 9600/9700
card. The code behind the c style comments let the application crash.
The code between /* */ crash the hole system. Probably there have to be
another check for supported cards/extensions.
This
H. Verbeet wrote:
+IWineD3DDeviceImpl_MarkStateDirty(This,
STATE_RENDER(WINED3DRS_SCISSORTESTENABLE));
+
+glDisable(GL_BLEND);
+IWineD3DDeviceImpl_MarkStateDirty(This,
STATE_RENDER(WINED3DRS_ALPHABLENDENABLE));
Don't you need to also dirtify STATE_SCISSORRECT there?
Stefan Dösinger wrote:
skip(No cubemap support\n);
if you return right after that you wouldn't have to change the indention on
all the rest of the code
There are some tests after that block not related to cubemap which I don't want
to skip. Other options are moving cubemap block of code to
Michael Karcher wrote:
Am Donnerstag, den 17.07.2008, 20:24 +0300 schrieb Alexander Dorofeyev:
+do
+{
+hr = IUnknown_Release(pUnkInner);
+} while (hr);
Release returns a ULONG, not a HRESULT. Do we ignore the difference in
Wine?
I usually do not, but that's how
Stefan Dösinger wrote:
I think there's code that does that for render targets. It would be good if
those are combined, or the render target flag adjustment just removed if it
is not needed any longer
I found some code to that effect in IDirectDrawImpl_CreateNewSurface, but there
the logic
Paul Vriens wrote:
Hi,
RegDeleteTreeW is only available on Vista. (Were these tests run on
Windows to
verify?).
Yes most of it was tested on XP, except this final registry cleanup
thing, sorry my mistake. Also it ran without errors with previous
version of your patch on XP here.
This
Paul Vriens wrote:
I've checked this on W2K3 and WinXP-SP3 and it only creates that one
registry
key with one value (Default) underneath. There is another key created which
isn't deleted:
HKEY_CURRENT_USER\Software\Microsoft\ActiveMovie\devenum\{guid}
This key has 4 values.
This key is
I have seen this too, on a real XP machine with nvidia card. But it doesn't
happen on some others, like a win98 machine I tried it on.
If I remember it correctly from the time I tried to debug it, one of the calls
to TransformVertices there seemed to overflow the buffer on the stack it writes
Jens Albretsen wrote:
Changelog:
Fixed Failure when texture was loading onto itself.
Fixes in part d3d7 regression bug #13277.
Still need to find a way to make d3d7 stay alive after the game releases the
interface.
Did you check what native does when asked to Load texture from itself?
Jens Albretsen wrote:
I have no way of testing what is does native? Only got windows at work.
However I can see that the game expects to be allowed to copy the surface, so
I must presume that windows is doing the same else the game would not run
under windows. Anyway it makes sense that it
Vitaliy Margolen wrote:
Alexander Dorofeyev wrote:
Fixes http://bugs.winehq.org/show_bug.cgi?id=12890 that affects several
games locking front buffer when using readtex RT lock mode.
---
-ActivateContext(device, device-render_targets[0], CTXUSAGE_BLIT);
+ActivateContext(device
Vitaliy Margolen wrote:
James McKenzie wrote:
Vitaliy Margolen wrote:
Several latest releases introduced lots and lots of regressions to a
point that no games run as-is. Considering that we are at the code
freeze, I'd like to see all patches that cause regressions, and all
patches that
Vitaliy Margolen wrote:
If developer can not tell if this is a hi risk or not, then such patch
have to be marked as hi risk and should not be accepted while we are in
the code freeze. Unless number of people test this patch on different
hardware with different software and verify it's
Vitaliy Margolen wrote:
Alexander Dorofeyev wrote:
---
dlls/ddraw/device.c | 24 ++--
1 files changed, 14 insertions(+), 10 deletions(-)
What is this patch fixing? Do you have tests? Do you have a bug # showing
the problem? Please explain why parts of the code needs
Hi.
I would like to have rights to change bug status. I fix some bugs myself and
also occasionally do some bug-triaging, so it would be handy. Thanks.
James Hawkins wrote:
On Sat, Apr 12, 2008 at 5:14 PM, Kai Blin [EMAIL PROTECTED] wrote:
Hi folks,
I seem to have done something wrong referring a user to a closed bug report
that seemed to be related to the problem he was having. (See bug 11639 for
more context)
So in order to avoid me
Hi.
There was a problem found recently in a fan-made mod of Forsaken (game), that
certain input combinations were slowing wine very seriously. Holding down a
keyboard button and moving mouse was found to be especially devastating to
performance (200 fps to 10fps in a matter of 10-20 seconds).
programs, right?
Could you add to that bug a short description of what games etc needed to
reproduce these problems?
Allan Tong wrote:
On Sun, Apr 6, 2008 at 5:06 PM, Alexander Dorofeyev [EMAIL PROTECTED] wrote:
Prevents calling ActivateContext while holding gl lock, e.g. when
preloading texture
There's a little problem with consistency about these things. In various
related
routines and paths, there were (and still are) both places that check isInDraw
and places that don't check it. read_from_framebuffer and
IWineD3DSurfaceImpl_BindTexture that can be called from LoadLocation are
Stefan Dösinger wrote:
Am Sonntag, 6. April 2008 23:05:52 schrieb Alexander Dorofeyev:
Stops it from producing misleading messages in apps that don't use d3d8/9
style palettes.
Is there no other way to do this? In my opinion dxVersion checks are ugly and
dxVersion should go away
Hi.
Sounds like a good idea. Unfortunately, it's too late to rework that patch as
it
seems to be in git by now. I suggest you send this improvement as a patch under
your name.
Allan Tong wrote:
Perhaps the call to ActivateContext should be moved outside of the if
block since there are other
, 28. März 2008 20:34:11 schrieb Alexander Dorofeyev:
ENTER_GL();
+if (This-resource.format == WINED3DFMT_P8 || This-resource.format ==
WINED3DFMT_A8P8) {
+ for (i = 0; i This-baseTexture.levels; i++) {
+if(palette9_changed((IWineD3DSurfaceImpl *)This-surfaces[i
Why, I checked what routines get called from that ENTER_GL/LEAVE_GL block in
PreLoad, and they all seem to be pretty safe. LoadTexture doesn't do gl calls
itself, but it calls LoadLocation. Other calls made in PreLoad like
AddDirtyRect
also don't do gl calls but may call LoadLocation. So it
Hi.
There's a regression in IDA Pro disassembler. Nothing is added to the taskbar
at
all, furthermore, when you are starting debugger, before there was a window
appearing that asks pass control to the application or not. Now it's not
appearing, and can't be found because there's nothing on
Stefan Dösinger wrote:
Am Sonntag, 23. März 2008 00:59:48 schrieb Alexander Dorofeyev:
Native can handle zero primitive count both when using old interfaces
(execute buffers etc) and when using d3d8 interface. Wine can crash in
drawprim.c routines like drawStridedSlow and possibly others too
Stefan Dösinger wrote:
Am Sonntag, 16. März 2008 14:44:37 schrieb [EMAIL PROTECTED]:
This fixes a crash in a game called Autobahnverfolgungsjagd Total
(not in AppDB).
I think it would be better to set pal = NULL if there is no wined3d palette
returned a few lines above the place you're
Roderick Colenbrander wrote:
First of all it appears that this patch contains multiple patches (e.g. the
direct3d9 getdc p8 check is one). I'll mention some others below. The p8 code
is very sensitive to bugs and those are most of the time very hard to fix, so
I'm quite strict. Various
in IWineD3D*Texture::PreLoad. I guess
the palette9_changed call could simply be moved to PreLoad and it would
accomplish something like that.
Stefan Dösinger wrote:
Am Sonntag, 9. März 2008 15:10:54 schrieb Alexander Dorofeyev:
Fixes problems with properly updating wine's P8 textures, when
one game - CC Red
Alert 1 - enters that codepath, so care is needed.
The comment is just a reminder that the code may need further work.
Stefan Dösinger wrote:
Am Montag, 18. Februar 2008 02:37:00 schrieb Alexander Dorofeyev:
/*can ddraw and d3d 8 surfaces use device's palette (d3d = 8
be any use in adding
such test to ddraw/tests/visual.c?
Stefan Dösinger wrote:
Am Montag, 7. Januar 2008 07:55:08 schrieb Alexander Dorofeyev:
D3DTBLEND_MODULATE Modulate texture-blending is supported. In this mode,
the RGB values of the texture are multiplied with the RGB values that would
Hi.
I found some problems with D3DRENDERSTATE_TEXTUREMAPBLEND state =
D3DTBLEND_MODULATE in ddraw and handling the alpha channel. This old state is
currently mapped to texture stage states, with alpha part done as
IWineD3DDevice_SetTextureStageState(This-wineD3DDevice, 0,
WINED3DTSS_ALPHAARG1,
Stefan Dösinger wrote:
Am Mittwoch, 2. Januar 2008 12:44:24 schrieb Stefan Dösinger:
Am Mittwoch, 2. Januar 2008 13:38:57 schrieb Alexander Dorofeyev:
In case of colorkey emulation for a texture, if the application wants to
select alpha from diffuse color at stage 0, a fixup to modulate
OK, thanks a lot. Regarding vertex structure - I'm afraid I can't reuse struct
vertex/nvertex, because I need a very specific format for this test
(D3DFVF_XYZRHW | D3DFVF_DIFFUSE). I could probably reuse sVertexT from fogtest,
but then I'll also have to set specular, that I don't really need. I
Stefan Dösinger wrote:
You can also try to QueryInterface old IDirect3DDevice* versions from
IDirect3DDevice7, but I think this doesn't work as the COM theory says on
Windows. I haven't yet tested the restrictions and implemented them because I
haven't seen a game yet that depends on them.
, before I
submit more wrong stuff (esp. considering that I'm also trying to write a test
for another issue with Aliens vs Predator 1 that I want to fix). I'm attaching
the zero rhw test.
Stefan Dösinger wrote:
Am Montag, 31. Dezember 2007 12:43:37 schrieb Alexander Dorofeyev:
The thing
to
obtain DX6 docs?
Stefan Dösinger wrote:
Am Montag, 31. Dezember 2007 03:04:02 schrieb Alexander Dorofeyev:
I think there's a bug here. If pal == NULL that implies (because of
preceding code) that wine_pal == NULL. So it's setting a NULL wined3d
palette to the destination wined3d surface, yet
I don't have this game, so I can't check myself, but I think that the reason of
slowdown may be not only that a err message is printed, but also because it
exists with error, and that means it will have to do slower, software blit. But
in older versions in this situation it would try hardware
WineD3D: p8 palette in alpha fix 2/2 [attempt 2]
WineD3D: fix p8 GL_EXT_paletted texture bug 1/2 [attempt 2]
Submitted something like 5 day ago, but I think they didn't make it to
git? They are needed to fix some bugs, like this:
http://bugs.winehq.org/show_bug.cgi?id=10797
Roderick, maybe you
Hi.
I think it may be the same regression I also saw in another app. At least it
seems to be in that place too. Can you check if this patch helps?
Maxime Bellengé wrote:
Hi Stephan,
Since this patch has been commited to git I have a big regression in the
game Syberia.
helps. I guess it will be a better fix then.
Stefan Dösinger wrote:
Am Donnerstag, 27. Dezember 2007 07:27:21 schrieb Alexander Dorofeyev:
Hi.
Colorkey emulation by alpha test should be disabled when game sets no
texture (or texture without colorkey) and reenabled when needed. Dirtifying
Yeah these calculations are a headache. I could probably write
now start_time || now = start_time + dwTimeout
to at least avoid a hang if GetTickCount counter overflows. This won't solve
not waiting the required time if, say, start_time + dwTimeout overflows, and
that can also be a problem
Hi.
Yes, exactly, the AVP1 game is using p8 textures and color keys on some of them
for transparency.
The thing is, the index_in_alpha hack DOES get enabled on its P8 3D textures,
and that's the problem I'm trying to fix. I don't see the primary render target
is p8 check in the code, instead it
Yes your patch fixes most problems (there are some remaining issues but they
were not fixed by mine either).
Roderick Colenbrander wrote:
Hi.
Yes, exactly, the AVP1 game is using p8 textures and color keys on some of
them
for transparency.
The thing is, the index_in_alpha hack DOES get
Hi.
Unfortunately, Skype stopped working in git wine, it crashes shortly after
start. Commit found via bisect:
http://source.winehq.org/git/wine.git/?a=commit;h=e2a366ce338d5b6b0f3c8962d70134f8d4e87f3b
kernel32: Forward interrupts in 32-bit code to winedos too
last messages with +io,+int:
with some diff options or combine 3 5.
Stefan Dösinger wrote:
Am Montag, 17. Dezember 2007 04:56:14 schrieb Alexander Dorofeyev:
---
dlls/wined3d/device.c | 162
dlls/wined3d/wined3d_private.h |
3 +
2 files changed, 165 insertions
Hi.
Stefan Dösinger wrote:
Am Samstag, 15. Dezember 2007 12:19:36 schrieb Alexander Dorofeyev:
This seems to be specific to front buffer. Maybe
glFlush really should be called in BltOverride (or clearing subroutine) if
the target is front buffer?
Yes, glFlush() has to be called when writing
overhead and direct implementation access. The function could be inlined as
well, but I am not sure if that works across .c files.
From 017f0600dccb3fd99af61b941676a6aa2b18d733 Mon Sep 17 00:00:00 2001
From: Alexander Dorofeyev [EMAIL PROTECTED]
Date: Sat, 15 Dec 2007 01:56:44 -0800
Subject: [PATCH
Hello.
I've spent some time trying to get into this stuff and what can be improved in
IWineD3DSurfaceImpl_BltOverride. Code that does glDrawBuffer in the Colorfill
path and possibly elsewhere indeed appears to be redundant to ActivateContext
and probably should go. That's in theory :), in
software emulation fixme - I'll probably submit this to bugzilla).
Stefan Dösinger wrote:
Am Montag, 10. Dezember 2007 18:39:49 schrieb Alexander Dorofeyev:
Hello.
I was recently experimenting with a fix that involved ActivateContext and
needed to figure out whether it is ok if ActivateContext
with this patch applied for a
substantial time, no problems noticed. Sorry for the noise, if you've already
seen it.
Alexandre Julliard wrote:
Alexander Dorofeyev [EMAIL PROTECTED] writes:
I'm not sure what would be a proper fix, although I did find out that
commenting
out this line in peek_message
Hello.
I was recently experimenting with a fix that involved ActivateContext and
needed
to figure out whether it is ok if ActivateContext is called inside
ENTER_GL()... LEAVE_GL() (also if recursive ENTER_GL is ok). At first I tried
to
look for example code in wined3d/surface.c, which
Hello.
I get freezes in Jagged Alliance 2 (seems to be tied to moving the mouse). It
used to work in older versions. The game doesn't lock up totally (the music and
sounds continue to play normally, for example), but the screen doesn't redraw
and it doesn't respond to input. Activating some other
Hi. Thanks for your input. I did download this application, and, yeah, it
appears that my patch regresses it. However, I did a bit of debugging of my own
and I don't think that the real problem in RAdmin case is not sending the
message to the parent, just like it isn't in DCPlusPlus, the real
From what I've seen in +tooltips,+toolbar,+msg logs and from running the apps
in IDA Pro disassembler, it works like follows:
* TOOLTIPS_GetTipText calls TOOLTIPS_GetDispInfoA/W
* TOOLTIPS_GetDispInfoA/W sends TTN_GETDISPINFO(=TTN_NEEDTEXT) notification to
tool's notify window, which is
Hello.
I've sent a patch that changes X11DRV_GetSystemPaletteEntries behavior and a
test something like a week ago. I guess they fell into that so called not
obviously correct category (or maybe not correct at all one). I'll appreciate
any comments or suggestions on possible improvements.
60 matches
Mail list logo
