Re: Memory checking?
Giles == Giles Cameron [EMAIL PROTECTED] writes: Giles Ok. I am just entering the WINE development crowd, and have very Giles very little experiance with the Windows API (The first time I saw Giles it, I was terrifyed!) Anywho. It would appear that some programs Giles decide there isn't enough free memory available for their tasks Giles (EG, Train Simulator's CAB extaction process, I have yet to look Giles further into this to see if I even have the slightest clue what I Giles am talking about, however) so I was wondering if we could hack in Giles an option to allow the API to tell a little fib on the free Giles memory, since (From what I understand) Linux is so much better Giles with memory. This is an old issue. Some programs find _some_error and decide to report it as out-of-memory error. Mostly totally misleading... Look for the first error and cure it. -- Uwe Bonnes[EMAIL PROTECTED] Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
Re: DirectX 10 start as a SoC project?
Wasn't there mention of making a Windows XP version of wine's DirectX 10, so people can use XP for gaming instead of Vista? If so, it would be nice if your code compiles and works on Windows too. Yes, that is the idea :-) Just one note for clarity: I am a student, but I do not plan to work on D3D10 myself as a SoC project. I am rather suggesting it to other people interested :-) Oh, and just in case we run out of idea, there is still plenty work to do for DirectX. Other Ideas are dplay.dll, d3dxof.dll, dmusic.dll, d3dx9_xy.dll, dsound, ... pgp6VSu4SjWxt.pgp Description: PGP signature
Re: mapi32: Add DebugInfo to critical sections.
Jan == Jan Zerebecki [EMAIL PROTECTED] writes: Jan --- If this patch is rejected from inclusion, please tell me why, Jan as I would have to ask anyway. Nice disclaimer ;-) I wonder if it works? -- Uwe Bonnes[EMAIL PROTECTED] Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
Re: DirectX 10 start as a SoC project?
On 3/10/07, Stefan Dösinger [EMAIL PROTECTED] wrote: Hi, Thinking about SoC I though that starting a DirectX 10 implementation may be a good summer of code project. I do not mean implementing the full d3d10 lib, that would be way to much, more starting the infrastructure. Henri disagreed with the idea, so I thought I'll write a mail for public discussion :-) . Looking at the timeline for SoC I hope it isn't too late. My idea is to start a d3d10 implementation up to the following point: - Add a winver Windows Vista to make version checkers happy :-) - Create the d3d10 lib and start the .idl file for header generation - Write stubs for the functions to allow the app to create all the interfaces - Write test cases for reference counting. ddraw and d3d9 show that Microsoft does not stick to its own COM rules - Make methods that have already 1:1 equivalents in wined3d call wined3d. Add other methods as required to wined3d. - Implement them as far as you feel like :-) I think the good thing about this is that there are is not much knowledge about wined3d and d3d10 necessary at the start. The one who works on it can learn the d3d10 interface while writing the stubs and learn about wined3d when starting to call it. Opinions? Suggestions? Wasn't there mention of making a Windows XP version of wine's DirectX 10, so people can use XP for gaming instead of Vista? If so, it would be nice if your code compiles and works on Windows too. Cheers, Stefan Cheers Damjan
Re: wined3d: Allow SetCursorProperties on existing cursor
Am Sonntag 11 März 2007 03:08 schrieb Erich Hoover: I ran all of the d3d9 tests and did not get any errors with my patch applied. I did get an error when I ran your modified visual.c test, but I get the same errors with and without my patch. Yes; The existing d3d9 tests do not check what happens when the surface is actually modified, and they do not draw an actual cursor, because the device test just checks return values and not the actual drawing. But the test shows that the surface can be destroyed without modifying the cursor. I can try to extend the test cases for modifying the surface if you want to? pgp8kx8TXmMWN.pgp Description: PGP signature
Re: wined3d: Set wrapmode for cubemags to clamp regardeless of the sampler state
I adapted a Directx9 HLSL tutorial to display a black cubemap with one white line on one edge of one side and visually (by hand or better to say by eye) confirmed that the line is not mirrored on the opposite edge. I'd say the patch is fine. Anything else but clamp to edge does not make sense for cube maps anyway, considering how the location of the pixel is calculated[1]. The only way I can imagine that a texture coordinate gets 1.0 or -1.0 is due to filtering. So the patch has my blessing to go in, if any regressions occur then we can always add a test case. But I cannot think of any good way to test this, so I prefer to wait for an application to show up what can go wrong :-) [1]... http://oss.sgi.com/projects/ogl-sample/registry/ARB/texture_cube_map.txt pgpXK2LkwoMrp.pgp Description: PGP signature
RE: Tackling gdiplus?
Huw Davies [mailto:[EMAIL PROTECTED] wrote: It seems to me that gdiplus is a great project for an intern; it's scalable and not 'all or nothing' unlike the dib engine. In looking at the DIB engine I feel that one of the biggest obstacles to get it done is integrating it in a way that it can be partially integrated piece by piece without requiring a huge amount of patches that needs to be applied more or less in one go in order to still have it all work. On the other hand I think that is the only way to get it in at all unless Alexandre himself is going to do it and if you do it that way I would think it is not really an all or nothing thing. You can start with addition of infrastructure in the display driver interface without really changing anything in the actual handling. Once the necessary support to the display driver interface is done the DIB engine could be implemented and integrated piece by piece such as first Put/GetPixel operations and then lines, and so on. This means that the X server synchronization would have to remain in the X11 driver until every function is implemented but it could reduce the requirement to synchronize every time as DIB engine support for a new operation is added, although some operations won't have a lot of effect for most applications. I'm still convinced that the best aproach to integrate a DIB engine is inside GDI and not in the display driver. Not so much because it is easier (it seems not to be) but because it is cleaner and in the long run will benefit other possible display drivers too, without having to be concerned in such a driver about DIB operations if one doesn't really want to. I think likely candidates to have speed effects are Get/PutPixel, LineTo, and the various BitBlt operations, with the last ones probably being also the most complex ones. More esoteric operations such as Arcs will eventually have to be implemented too somehow but wouldn't be the most important ones to start with. Rolf Kalbermatter
Known desktop migration projects and their must have Windows apps
I'm putting a list together at http://wiki.winehq.org/DesktopMigrationProjects listing organizations who are migrating their users from Windows to Linux. I only list projects that have come out and said which Windows applications they really want to run on Linux. Since these migration projects, if they end up using Wine, will be very good publicity for the project, it might behoove us to look carefully at whether we can get the apps they need running. I know Banco do Brasil's folks are quite happy at the effort put into Lotus Notes 5.x recently, so it is possible for us to make a difference. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv
Re: winedbg: Support longer thread names
Erich Hoover a écrit : Real Name: Erich Hoover Description: The thread name length in winedbg is currently restricted to 9 characters, this is not nearly long enough for debugging threads in the Supreme Commander demo and results in character corruption on the terminal. Since this particular application names one of the threads with the map path (Map loader /maps/scmp_019/scmp_019.scmap), a significant increase in the number of characters is necessary. This patch ups the allowed thread name length to 100 characters and null-terminates the string in case an application exceeds that threshold value. Changelog: winedbg: Support longer thread names in that case, it would be better to dynamically allocate the string (and to create it by default at 5 bytes for the %04x value) furthermore, you need to change the comment in debugger.h in THREADNAME_INFO structure about the name's length, as it seems VC7 removed the restriction to 8 characters that existed in VC6 A+
Re: 0.9.32 hangs UltraVNC Viewer after a while
On 3/10/07, Dieter Rogiest [EMAIL PROTECTED] wrote: Mandriva Linux 2007.0 here. With wine 0.9.30 ultravnc_viewer.exe (remote access) works perfect. I installed wine 0.9.32 (wine-0.9.32-1.SoS.2007.0.i586.rpm). Using ultravnc_viewer.exe I saw immediately that the fullscreen title bar that should appear when you move your mouse to the top of the screen was now allways visible also in windowed mode. After a while (4 minutes) ultravnc_viewer stopped working, I could still see the remote desktop but my mouse clicks didn't happen. I went back to 0.9.30. Please run a regression test. Dieter Damjan
mswsock.dll, Soc legal questions
Hi, I'm pretty interested in implementing mswsock.dll as a SoC this summer : this dll seems to be used by many apps and it's, I think, the sort of job I can do. As I'm not a Wine dev, I was wondering about how should I work for implementing this lib : should I juste use the MSDN description of the functions and make some tests with some apps to validate the behavior ? Or can I take the original dll, execute some apps with it and try to see how the dll is interacting with other libs, what sort of network traffic is generated, etc ? Is this solution possible with the microsoft license ? Thanks, Ben
Re: wined3d: Allow SetCursorProperties on existing cursor
I ran all of the d3d9 tests and did not get any errors with my patch
applied. I did get an error when I ran your modified visual.c test, but I
get the same errors with and without my patch.
Test before patch:
fixme:d3d:IWineD3DDeviceImpl_GetAvailableTextureMem (0x167ec8) : stub,
simulating 64MB for now, returning 64MB left
visual.c:191: Test failed: IDirect3DDevice9_ColorFill failed with 88760096
visual.c:212: Test failed: IDirect3DDevice9_SetCursorProperties failed
with 8876086c
visual: 26 tests executed (0 marked as todo, 2 failures), 0 skipped.
Test after patch:
fixme:d3d:IWineD3DDeviceImpl_GetAvailableTextureMem (0x167ec8) : stub,
simulating 64MB for now, returning 64MB left
visual.c:191: Test failed: IDirect3DDevice9_ColorFill failed with 88760096
visual.c:212: Test failed: IDirect3DDevice9_SetCursorProperties failed
with 8876086c
visual: 26 tests executed (0 marked as todo, 2 failures), 0 skipped.
So, which change exactly are you concerned about? Changes are:
1) The removal of glDeleteTextures(1, This-cursorTexture); in device.c
This change should just keep SetCursorProperties from deleting the gl
texture. By removing this call an application can set the cursor to A,
change the cursor to B, then change the cursor back to A without having the
texture deleted.
2) The temporary allocation of This-glDescription.textureName in surface.c
This change should allow SetCursorProperties to retrieve cursor A the
second time in the A, B, A sequence. Without this change,
SetCursorProperties gets back a texture of 0 from the
IWineD3DSurface_PreLoad call. This allocation is temporary since
SetCursorProperties immediately resets that value:
This-cursorTexture = pSur-glDescription.textureName;
...
pSur-glDescription.textureName = 0; /* Prevent the texture from being
changed or deleted */
I don't think I'm missing anything here... However, the implementation of
item #2 could be changed around by using flags, as you discussed in a
previous email, and this would seem more consistent with the intent of
SFLAG_FORCELOAD (see the attached patch).
Erich Hoover
[EMAIL PROTECTED]
On 3/10/07, Stefan Dösinger [EMAIL PROTECTED] wrote:
The API documentation doesn't say anything about an application
releasing
the d3d surface,
There is a test for that somewhere in dlls/d3d9/tests/device.c (or some
other
test file in there).
but the documentation in the code seems to indicate that
the gl texture needs to remain when the surface is deleted - I did
nothing
to change this.
But IWineD3DSurfaceImpl_Release will destroy the gl texture of a surface
when
the surface is destroyed.
Also, if the gl surface still knows the texture, the following could cause
an
issue:
SetCursorProperties(cursorSurface, ...);
render some stuff
LockRect(cursorSurface, ...);
write some thing into the surface
UnlockRect(cursorSurface);
PreLoad(cursorSurface);
The PreLoad will then change the cursor without SetCursorProperties beeing
called. This should not happen. I tested that with some hacky test.
Unfortunately this cannot be automated in the visual tests because cursors
do
not show up in screenshots.
This is my hacky cursor test app:
http://stud4.tuwien.ac.at/~e0526822/visual.c
The successor of that file without the cursor tests is now in
dlls/d3d9/tests/visual.c. I think this visual.c version is not the version
I
used for checking later surface changes.
From b27ae021b3c52d6fc1bf918098219160dedefa5f Mon Sep 17 00:00:00 2001
From: Erich Hoover [EMAIL PROTECTED](none)
Date: Sat, 10 Mar 2007 19:02:16 -0700
Subject: wined3d: Allow SetCursorProperties on existing cursor
---
dlls/wined3d/device.c |8 +---
dlls/wined3d/texture.c | 23 ++-
2 files changed, 15 insertions(+), 16 deletions(-)
diff --git a/dlls/wined3d/device.c b/dlls/wined3d/device.c
index 0998eec..0339e8d 100644
--- a/dlls/wined3d/device.c
+++ b/dlls/wined3d/device.c
@@ -5207,13 +5207,6 @@ static HRESULT WINAPI IWineD3DDeviceIm
TRACE((%p) : Spot Pos(%u,%u)\n, This, XHotSpot, YHotSpot);
/* some basic validation checks */
-if(This-cursorTexture) {
-ENTER_GL();
-glDeleteTextures(1, This-cursorTexture);
-LEAVE_GL();
-This-cursorTexture = 0;
-}
-
if(pCursorBitmap) {
/* MSDN: Cursor must be A8R8G8B8 */
if (WINED3DFMT_A8R8G8B8 != pSur-resource.format) {
@@ -5243,6 +5236,7 @@ static HRESULT WINAPI IWineD3DDeviceIm
This-cursorWidth = pSur-currentDesc.Width;
This-cursorHeight = pSur-currentDesc.Height;
pSur-glDescription.textureName = 0; /* Prevent the texture from being
changed or deleted */
+/* NOTE: It is also important to keep the texture between
SetCursorProperties calls */
}
This-xHotSpot = XHotSpot;
diff --git a/dlls/wined3d/texture.c b/dlls/wined3d/texture.c
index e9a78cc..4c5cdd5 100644
--- a/dlls/wined3d/texture.c
+++ b/dlls/wined3d/texture.c
@@ -95,6 +95,7 @@ static void WINAPI IWineD3DTextureImpl_P
/*
Re: mswsock.dll, Soc legal questions
Benoit Pradelle a écrit : Hi, I'm pretty interested in implementing mswsock.dll as a SoC this summer : this dll seems to be used by many apps and it's, I think, the sort of job I can do. be aware that the easy parts have been started in last year SoC, but weren't applied to the git tree yet, and the other parts are pretty much hard to implement (will require wine server requests changes, and those elements won't be done until some other changes on asynchronous requests are done) As I'm not a Wine dev, I was wondering about how should I work for implementing this lib : should I juste use the MSDN description of the functions and make some tests with some apps to validate the behavior ? Or can I take the original dll, execute some apps with it and try to see how the dll is interacting with other libs, what sort of network traffic is generated, etc ? Is this solution possible with the microsoft license ? anything were you consider the DLL as a blackbox should be fine. you can start by MSDN (but MSDN doesn't always tell the truth, or ALL the truth), write your own test suites, or try some apps that require the DLL. Testing the calls to other DLLs wouldn't be needed either. Moreover, lots of call are likely done as IOCTL to ntdll, which an even greater project to implement (look for TDI) IMO, network analysis shouldn't be required as the API semantics are rather straightforward (there might be some issues about optimisation, but that's another story) And of course, start by looking at work from last year SoC. A+
Re: wined3d: Allow SetCursorProperties on existing cursor
On 11/03/07, Erich Hoover [EMAIL PROTECTED] wrote: So, which change exactly are you concerned about? Changes are: 1) The removal of glDeleteTextures(1, This-cursorTexture); in device.c This change should just keep SetCursorProperties from deleting the gl texture. By removing this call an application can set the cursor to A, change the cursor to B, then change the cursor back to A without having the texture deleted. 2) The temporary allocation of This-glDescription.textureName in surface.c This change should allow SetCursorProperties to retrieve cursor A the second time in the A, B, A sequence. Without this change, SetCursorProperties gets back a texture of 0 from the IWineD3DSurface_PreLoad call. This allocation is temporary since SetCursorProperties immediately resets that value: This-cursorTexture = pSur-glDescription.textureName; ... pSur-glDescription.textureName = 0; /* Prevent the texture from being changed or deleted */ I don't think I'm missing anything here... However, the implementation of item #2 could be changed around by using flags, as you discussed in a previous email, and this would seem more consistent with the intent of SFLAG_FORCELOAD (see the attached patch). Erich Hoover [EMAIL PROTECTED] You're trying to solve the wrong problem :-) The problem is that when we set the textureName to 0 we essentially kick the GL texture out of the surface which is then left in a somewhat inconsistent state. Calling SetCursorProperties again with the same surface will then fail because the surface no longer has a GL texture associated with it. The proper way to fix this is to make a copy of the GL texture rather than playing tricks with the surface loading code.
Re: DIB Engine GSoC
On 3/10/07, Brian Vincent [EMAIL PROTECTED] wrote: On 3/2/07, Steven Edwards [EMAIL PROTECTED] wrote: I don't really know anything about the DIB engine or the engineering problem in getting it accepted except that it is going to be a massive beast and almost impossible to implement in small changes. Yup, I'm dumb about it too. My $.02: with our fancy new git system, could we branch Wine and start developing a separate tree with a new DIB engine? Apply patches to both trees. There probably won't be too many merge conflicts because there's not a ton of work on GDI and x11drv these days. Or maybe we could release a Wine 1.0 and start a development branch with that as one of the goals. -Brian That is what I would have suggested doing if I applied for the DIB project this year. But with so much talk about it, I've shyed away from it. I wouldn't mind working on it with a team, and divide up the work though. Jesse
Re: DirectX 10 start as a SoC project?
On 3/10/07, Stefan Dösinger [EMAIL PROTECTED] wrote: Hi, Thinking about SoC I though that starting a DirectX 10 implementation may be a good summer of code project. I do not mean implementing the full d3d10 lib, that would be way to much, more starting the infrastructure. Henri disagreed with the idea, so I thought I'll write a mail for public discussion :-) . Looking at the timeline for SoC I hope it isn't too late. My idea is to start a d3d10 implementation up to the following point: - Add a winver Windows Vista to make version checkers happy :-) - Create the d3d10 lib and start the .idl file for header generation - Write stubs for the functions to allow the app to create all the interfaces - Write test cases for reference counting. ddraw and d3d9 show that Microsoft does not stick to its own COM rules - Make methods that have already 1:1 equivalents in wined3d call wined3d. Add other methods as required to wined3d. - Implement them as far as you feel like :-) I think the good thing about this is that there are is not much knowledge about wined3d and d3d10 necessary at the start. The one who works on it can learn the d3d10 interface while writing the stubs and learn about wined3d when starting to call it. Opinions? Suggestions? Cheers, Stefan The concept is nice, and I'd like to learn 3D graphic APIs better. But when I consider DX10, I don't have any DX10 apps, nor do I have Vista. I'd also be concerned if it is even properly documented if I were to start that way. So I'm not thinking I want to do DX10. However, this idea can be considered with any API that is currently not implemented. So I think I'll want to try this with a smaller more widely used API. Jesse
Re: DirectX 10 start as a SoC project?
Jesse Allen napsal(a): On 3/10/07, Stefan Dösinger [EMAIL PROTECTED] wrote: Hi, Thinking about SoC I though that starting a DirectX 10 implementation may be a good summer of code project. I do not mean implementing the full d3d10 lib, that would be way to much, more starting the infrastructure. Henri disagreed with the idea, so I thought I'll write a mail for public discussion :-) . Looking at the timeline for SoC I hope it isn't too late. My idea is to start a d3d10 implementation up to the following point: - Add a winver Windows Vista to make version checkers happy :-) - Create the d3d10 lib and start the .idl file for header generation - Write stubs for the functions to allow the app to create all the interfaces - Write test cases for reference counting. ddraw and d3d9 show that Microsoft does not stick to its own COM rules - Make methods that have already 1:1 equivalents in wined3d call wined3d. Add other methods as required to wined3d. - Implement them as far as you feel like :-) I think the good thing about this is that there are is not much knowledge about wined3d and d3d10 necessary at the start. The one who works on it can learn the d3d10 interface while writing the stubs and learn about wined3d when starting to call it. Opinions? Suggestions? Cheers, Stefan The concept is nice, and I'd like to learn 3D graphic APIs better. But when I consider DX10, I don't have any DX10 apps, nor do I have Vista. I'd also be concerned if it is even properly documented if I were to start that way. So I'm not thinking I want to do DX10. However, this idea can be considered with any API that is currently not implemented. So I think I'll want to try this with a smaller more widely used API. Jesse Nvidia introduced Nvidia SDK for DirectX 10 http://developer.nvidia.com/page/home.html direct link: http://developer.nvidia.com/object/sdk_home.html Mirek Slugen
Re: DirectX 10 start as a SoC project?
Am Sonntag 11 März 2007 19:40 schrieb Jesse Allen: On 3/10/07, Stefan Dösinger [EMAIL PROTECTED] wrote: Hi, Thinking about SoC I though that starting a DirectX 10 implementation may be a good summer of code project. I do not mean implementing the full d3d10 lib, that would be way to much, more starting the infrastructure. Henri disagreed with the idea, so I thought I'll write a mail for public discussion :-) . Looking at the timeline for SoC I hope it isn't too late. My idea is to start a d3d10 implementation up to the following point: - Add a winver Windows Vista to make version checkers happy :-) - Create the d3d10 lib and start the .idl file for header generation - Write stubs for the functions to allow the app to create all the interfaces - Write test cases for reference counting. ddraw and d3d9 show that Microsoft does not stick to its own COM rules - Make methods that have already 1:1 equivalents in wined3d call wined3d. Add other methods as required to wined3d. - Implement them as far as you feel like :-) I think the good thing about this is that there are is not much knowledge about wined3d and d3d10 necessary at the start. The one who works on it can learn the d3d10 interface while writing the stubs and learn about wined3d when starting to call it. Opinions? Suggestions? Cheers, Stefan The concept is nice, and I'd like to learn 3D graphic APIs better. But when I consider DX10, I don't have any DX10 apps, nor do I have Vista. I'd also be concerned if it is even properly documented if I were to start that way. So I'm not thinking I want to do DX10. However, this idea can be considered with any API that is currently not implemented. So I think I'll want to try this with a smaller more widely used API. Regarding applications, I have a few of them: /opt/windows/dxsdk/dx9/Samples/C++/Direct3D10 $ ls BasicHLSL10GPUSpectrogramPipesGS BinHDRFormats10 ShadowVolume10 CubeMapGS HLSLWithoutFX10 SimpleSample10 DisplacementMapping10 Instancing10 Skinning10 DrawPredicated MotionBlur10 SoftParticles EmptyProject10 MultiStreamRendering SparseMorphTargets FixedFuncEMU ParticlesGS Tutorials 21 applications, so it is a widely used API. Oh ooops, those are just the sdk demos. And only 19 of them, bin/ and EmptyProject10/ do not really count... Jokes aside, there aren't any dx10 apps yet, except some demo apps. The first one to be expected is Halo 2 on April 24th afaik. The only thing is that MS has created some hype around dx10 recently. It would give us some nice publicity if the Halo 2 box states Runs on Windows Vista and higher and winehq.org says Runs Halo 2 on Linux, MacOS, Windows XP and earlier I do not think d3d10 hardware is required yet, the reference rasterizer should work for the start. It is a long way to get any actual rendering going. Regaring Vista, the nice thing is that Students get Educational licenses cheap. But the license should be checked carefully. I for example may use it only for educational purposes. As I am working for CodeWeavers my hacking on wine isn't purely for educational purposes. No idea of SoC can be considered an educational thing. pgprP11LVHN53.pgp Description: PGP signature
Re: Alexandre Julliard : ntdll: Fixed a compiler warning for size_t/ unsigned int mismatch.
Francois Gouget [EMAIL PROTECTED] writes: Even so I think we can get a problem for the Win64 case: on Windows the size parameter will still be 32bits since it's an 'unsigned int'. So 64bit Windows applications will generate code that passes a 32bit size to _lfind(). But Wine's implementation will expect the size parameter to be 64bit since it's a size_t (which is 64bits in both Windows and Unix) and thus it will try to pop too much stuff off the stack. Parameters are always 64-bit on a 64-bit platform (and they are usually passed by registers anyway...) -- Alexandre Julliard [EMAIL PROTECTED]
Re: wined3d: Allow SetCursorProperties on existing cursor
Am Sonntag 11 März 2007 21:08 schrieb Erich Hoover: Yeah, that would make more sense wouldn't it :) Please see attached patch. If you do it that way, you can remove the PreLoad, LockRect the surface(with WINED3DLOCK_READONLY), use glTexImage2D to load This-cursorTexture and then Unlock the surface. This saves uploading - downloading - uploading. If you use that way, please remove SFLAG_FORCELOAD too. You should make sure that a correct gl texture unit is activated before loading This-cursorTexture with GL_EXTCALL(glActiveTextureARB(X)); Search through the code how that is done, you have to make sure that glActiveTextureARB is supported before using it. You don't have to enable GL_TEXTURE_2D to my knowledge to call glTexImage2D, but you have to restore the originally bound texture or dirtify the sampler you modify(IWineD3DDeviceImpl_MarkStateDirty(This, SAMPLER(X)); where X is the unit you selected before. (X = 0 is prefered). pgpySCtA8vWNO.pgp Description: PGP signature
Re: wined3d: Set wrapmode for cubemags to clamp regardeless of the sampler state
On 11/03/07, Stefan Dösinger [EMAIL PROTECTED] wrote: But I cannot think of any good way to test this, so I prefer to wait for an application to show up what can go wrong :-) I've written a test for this, I'll send it tomorrow together with some other patches.
Re: wined3d: Implented signed texture formats via NV_TEXTURE_SHADER
On Saturday 10 March 2007 23:20, Frank Richter wrote:
On 10.03.2007 15:02, Fabian Bieler wrote:
+static const PixelFormatDesc NV_texture_shader_formats[] = {
+{WINED3DFMT_V8U8,0x0,0x0,0x0,0x0
,2 ,FALSE ,GL_SIGNED_HILO8_NV ,GL_HILO_NV
,GL_BYTE},
Are you sure this is right? From the NV_texture_shader spec it looks to
me like HILO is for high-precision data, and that DSDT (described as
offset data) would be more appropriate for V8U8.
You're probably right about that. While I can't see a visual difference
between using HILO8 and DSDT in hl2 with dx81 (which uses V8U8), I'll resend
a modified patch.
Re: wined3d: Allow SetCursorProperties on existing cursor
On 11/03/07, Erich Hoover [EMAIL PROTECTED] wrote: Is the attached what you mean? Erich Hoover [EMAIL PROTECTED] +if (IWineD3DSurface_LockRect(pCursorBitmap, rect, NULL, WINED3DLOCK_READONLY) == WINED3D_OK) I know the current code doesn't do it everywhere either, but you should probably be using SUCCEEDED() there. +void *mem = rect.pBits; ... +glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA, width, height, 0, format, type, mem); That may work, but it's not guaranteed to, see http://msdn2.microsoft.com/en-us/library/bb206357.aspx
Re: DirectX 10 start as a SoC project?
On Sunday 11 March 2007 13:53, Stefan Dösinger wrote: Oh, and just in case we run out of idea, there is still plenty work to do for DirectX. Other Ideas are dplay.dll, d3dxof.dll, dmusic.dll, d3dx9_xy.dll, dsound, ... After Stefan mentioned this a couple of times, I'd like to restate that I'd stongly suggest anyone considering to tackle dplay or related things to shoot me an email first. I'm not planning to do this myself for this year, but I'm planning to participate in GSoC as a student, so I can't mentor anyone there. Of course if anyone is really good at that sort of work, I'll be happy to offer help on what I already have and all. I just think we still don't know enough about the dplay protocol to make a SoC project out of this. My EUR 0.02 Kai -- Kai Blin, kai Dot blin At gmail Dot com WorldForge developerhttp://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin/ -- Will code for cotton. pgpHZG2YJeAH0.pgp Description: PGP signature
Re: mapi32: Add DebugInfo to critical sections.
On Sun, Mar 11, 2007 at 12:27:54PM +0100, Uwe Bonnes wrote: Jan == Jan Zerebecki [EMAIL PROTECTED] writes: Jan --- If this patch is rejected from inclusion, please tell me why, Jan as I would have to ask anyway. Nice disclaimer ;-) I wonder if it works? No, I guess usually doesn't. Except for the few rejections where I get a direct reply from AJ, for all the rejections without a reply from anyone (which I guess are most of the rejections) I end up asking AJ on IRC. He then usually directly tells me why, possibly followed by more QA if I don't fully get how he wants something done or why that way. This way of doing also tends to produce things similar to: me: Did you take a look at this patch yet? AJ: not yet or please resend. It also seems asking AJ every now and then about a patch, makes him more likely to not miss that patch. Some few changes also need much pestering of AJ, persistence and a few tries each probably with contradicting and/or miscommunicated requirements. But that usualy results in a better solution. That said, AJ does a realy good job in reviewing patches Jan
Re: quartz: Check allocation failure and clearmemoryinDSound Renderer
Alexandre Julliard [EMAIL PROTECTED] wrote: The point is that (void*)0 isn't guaranteed to be represented by an all-zero bit pattern; but that's the case on any platform worth worrying about. If (void*)0 doesn't guarantee to actually set all bits to 0, then HEAP_ZERO_MEMORY doesn't guarantee it either. -- Dmitry.
Time for an advapi category in bugzilla?
I just filed a bug related to wine's advapi implementation ( http://bugs.winehq.org/show_bug.cgi?id=7690 ) and noticed there wasn't an advapi category in Bugzilla. Should there be? - Dan
