Re: patch for unprovided glXGetProcAddressARB function in Solaris OpenGL
(See attached file: patch_sun_opengl) Well, which Wine release did you use for your patch ??!!? In current CVS Wine, we have the following code : p_glXGetProcAddressARB = wine_dlsym(opengl_handle, glXGetProcAddressARB, NULL, 0); (...) local_func = p_glXGetProcAddressARB(lpszProc); So basically, the glXGetProcAddressARB function is loaded at run-time and then your patch is useless. Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: Int21 fixes - Update
0x4a : This is not valid C. RESET_CFLAG cannot happen before variable declarations. Move RESET_CFLAG to start of subfunction. Well, this is not valid C, but is perfectly valid C99. And as most of the people now are using GCC 3.X to develop Wine, these kind of stuff happen a lot more often (ie a lot of 'breakage' of compiles happens on people still using older GCC releases). Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: When will Wine integrate an x86 CPU emulator?
Not only it would be extremely complex but I am not even sure it would be more efficient. Well, one case where the performance gain may be significant is gaming. Basically, if you run your GL library emulated, you will use the GLX network protocol to communicate with the X server to a pretty heavy performance penalty compared to any direct rendering architecture (especially for texture uploads and such). Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: When will Wine integrate an x86 CPU emulator?
Anyhow, I realize that the Wine-devel list isn't the most hospitable place for these sorts of ideas. That's why I set up http://darwine.sf.net. Well, I looked at the site and did not see much there... Is there any design diocuments / roadmaps on how you plan to go forward that we could read so as to know how you plan to actually tackle the issues raised by all the people here ? Ie something that would tell : - how you plan to go forward (complete Wine fork rewriting big chunks of the code or 'parameter translation' layer with Wine code mostly untouched) - how some specific issues would be handled (exceptions, '...' functions, ...) For the moment, the only thing I see is making Winelib working on OS/X (which is a nice thing but has not much to do with running Win32/X86 applications on OS/X). Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: interesting stuff I have been finding out about DirectX
The core DX dlls (like ddraw.dll, dsound.dll, dinput.dll and others) dont seem to make kernel-mode or driver/hardware calls directly. Most of it appears to be done via other places (such as winmm.dll, some special thunks in gdl32.dll and others) Well, if you look at TransGaming DDraw code in Wine, you will see that they mimic the way DirectX is doing this (ie by somehow using an Escape in the GDI which returns a structure filled with function pointers and private datas). Now this is a debate we had in the current WineHQ D3D development team : should we base our DirectX implementation on how Windows does the separation between the DLL and the drivers or just implement the DLL and do our own driver interface. After some debate, we choose the second one : - to not be tied down to some MS APIs at both sides (ie at DLL entry points and at DLL exit points). - DLL entry points are 1) documented pretty well in MSDN and 2) easily testable by doing some simple Win32 programs. Compared to the MSDN, the DDK I read was a lot more difficult to read (and I have no idea if it's even 'legal' to implement something using the DDK without MS' aproval as it's not really a published API). - finally, as the ultimate goal of Wine is to reimplement Wine and as no applications should use these low-level calls directly, the current solution used in Wine works fine :-) Anyway, if people from ReactOS want to use our DirectX calls with Windows drivers, the way we choose is not the way to go... Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: When will Wine integrate an x86 CPU emulator?
The most interesting activity on Wine with x86 emulation is QEMU. If that had existed last year then there wouldn't have been a Darwine. QEMU now has a mailing list: http://mail.gnu.org/archive/html/qemu-devel/ What is 'fun' is that QEMU resulted from a discussion I had with its author about how to best run Wine on a non-X86 system and the resulting conclusion we reached (after some time late in the night :-) ) : the easiest and most robust way to do that was to emulate at the syscall level. Note also this post (http://mail.gnu.org/archive/html/qemu-devel/2003-08/msg00058.html) where Fabrice agrees with my post about Wine on OS/X :-) Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: When will Wine integrate an x86 CPU emulator?
I don't think this would be as hard as it sounds, if the .spec files could
be used to describe all of the parameters and calls to the API functions.
Well, the big problem is that .spec files are so 'passé' now :-)
Correct me if I'm wrong, but I think that most new APIs are now exported
through COM objects and not 'standard' APIs (I could do a check on the
current Wine DLLs, but well, a lot of stuff is using COM nowadays).
So you would need to have a way to describe all COM inputs / outputs. Then
there is the matter also that Wine uses the COM objects internaly exactly
like the program does.. So you cannot say 'hey, let's put converting
functions in this COM vtable' as this will break when called from X86 code.
Finally, you will have the problems of 'non-trivial' argument passing (ie
data which are not described by C structures). For that, you will have to
rewrite the C code parsing this for each call (and thus have a
emulator-specific path). This is the case for bitmaps, a lot of DirectX
stuff, ... It's exactly the same issue for '...' functions.
And you will have to rewrite most of Wine's OpenGL code too :-)
So, yes, it's doable. Now is it pratical to do so and acceptable to rid a
lot of Wine code with if (emulated) { } else { } ?
Lionel
--
Lionel Ulmer - http://www.bbrox.org/
Re: GTA3 crash :( -- RedHat 9
However, try commenting out the line in directx.c : object-visInfo = glXChooseVisual(object-display, DefaultScreen(object-display), dblBuf); Basically, for this to work reliably, you have three choices : - do a full rewrite of the Wine windowing code to be able to somehow 'recreate' on the fly an X Window with new parameters (in this case, a better visual). This would help me also in the OpenGL code :-) - create yourself (by adding some hacks in X11DRV) a new window with this visual - do as I did for the DesktopDoubleBuffered option, but more generic (by adding stencil support to the already existing double buffering option). Then people could add in their DLL overrides 'GTA.EXE = windows are double buffered and stencilled'. Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: GTA3 crash :( -- RedHat 9
On Thu, Aug 14, 2003 at 10:02:55PM +0100, Jason Edmeades wrote: This seems to work ok on some (my!) drivers, but I know others have had problem with it. Well, your driver must either 1) be less picky on visual consistency or 2) have a stencil associated to the default double-buffered visual... Yep - I take it that its not possible to replace the visual of an existing window? I knowledge of X programming is very low, and I dont understand how visuals and contexts all fit together. Not that I know of... And the only rule, from what I know, is that the visual you create your GLX context with must be compatible with the one your window was created with. So if you create a window with a stencil and then use a stencil-less visual, it will work. The reverse won't work though as it's not compatible. I've also started looking at some render to texture support Raphael added, and that uses PBuffers which seem to also magic contexts out of thin air. I have no idea how things are supposed to fit together, but I'll get there. Well, the other way would be to do all rendering to PBuffers and copy this to the main window on each Flip... But this would slow us down even if the drivers optimises PBuffer = frame buffer blits (especially if the driver supports 'page flipping' or I do not remember how NVIDIA tells their optimisations for full-screen glXSwapBuffers). But well, that would be the easiest solution :-) I dont like adding configuration options for things which should be transparent to the user. I'll have to look into this again in the future, but in the meantime I might put code to catch the X exception and cope with it. Well, yeah, at least handle the X error gracefully. Or this is where you could put something like 'Add the following lines to your config file and re-run Wine'. And as you can get easily the application name here, you can pretty easily generate a nice pre-formatted config entry. Of course it's hacky ... but it beats rewriting / massaging Wine's core windowing code (hullo Alexandre :-) ) into accepting OpenGL quirks. Incidentally, one thing that annoys me is full screen. Does the d3d 7 code (or opengl code) do resolution switching, and do you have a pointer to how it occurs. At the moment 'fullscreen' is an undecorated window on the desktop, keeping the desktop window at the resolution it is already at. Well, I never use games full-screen so I never actually did some code for this :-) I know that : 1) there is no full-screen option in OpenGL as games use standard Win32 code to go into full-screen. 2) DDraw's full-screen code relies on ChageDesktopSettings or something like that to switch resolution. Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: [X11DRV] Re-add support for the 'UseXShm' config key.
Do you actually need it? Otherwise I think we might as well remove it completely, clearly nobody depends on it since it has been broken for a long time. Well, sometimes, in some rare debugging cases, it's useful to have it, yeah. Basically, I was hunting down a GFX corruption bug and was wondering if it was due to the fact that the XShm code path is 'asynchronous' and that we sent two updates in a row while the first one was not yet finished processing on the X server side... And in doing this, I found out that the 'disable XShm' option did not work anymore and I sent this patch. Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: Strange code in misc/registry.c
It's clearly a bug, since the code asks for trouble by requesting to read more data than it actually should. In that case the code has to do: new_key_name = malloc(strlen(key_name)+dkh-keynamelen+1); strcpy(new_key_name, key_name); Well, these two lines are EXACTLY what the strndup code does :-) Lionel -- Lionel Ulmer - http://www.bbrox.org/
Strange code in misc/registry.c
Hi all, Having lately some strange crashes when I start Wine with any --debugmsg command, I started to look at where the problem occured. From my investigations, it came in the file misc/registry.c while loading 'system.1st' (yeah, I know, I should run in a no-Windows install, but well, my Wine installation is 6 years old and still working, so I won't change now :-) ). Anyway, the faulty function is '_strdupnA'. I added some traces and I have this : 0009:trace:reg:_strdupnA System\CurrentControlSet\Control\MediaProperties\PrivateProperties\Joystick (0x3c003f40) 79 0009:trace:reg:_strdupnA 0x3c003f90 This means that the string given as a parameter has the pointer '0x3c003f40', the length parameter is '79' and it returns '0x3c003f90'. It crashes later on at : 0009:trace:reg:_strdupnA System\CurrentControlSet\Control\MediaProperties\PrivateProperties\Joystick\OEM (0x3c003f90) 114 0009:trace:reg:_strdupnA 0x3c003418 So we give the '0x3c003f90' pointer (which is of length 79 as seen in the previous debug output) but (if you look at the code), will read 114 bytes from it (as the function uses 'memcpy' and not 'strncpy'). The attached patch fixes all crashes on my box, but well, as I am not very familiar with this code, sent it to wine-devel and not wine-patches for review by Registry gurus :-) Lionel -- Lionel Ulmer - http://www.bbrox.org/ ? misc/registry_hack.c Index: misc/registry.c === RCS file: /home/wine/wine/misc/registry.c,v retrieving revision 1.127 diff -u -r1.127 registry.c --- misc/registry.c 24 Jun 2003 02:32:01 - 1.127 +++ misc/registry.c 2 Aug 2003 19:59:44 - @@ -99,7 +99,7 @@ if (!str) return NULL; ret = _xmalloc( len + 1 ); -memcpy( ret, str, len ); +strncpy( ret, str, len ); ret[len] = 0x00; return ret; }
Re: Strange code in misc/registry.c
I'm not a Registry guru by all means :-), but IMO the real bugs are at lines 701: new_key_name = _strdupnA(key_name,strlen(key_name)+dkh-keynamelen+1); and 1011: new_key_name = _strdupnA(key_name,strlen(key_name)+nk-name_len+1); Not really as the code does this : /* create new subkey name */ new_key_name = _strdupnA(key_name,strlen(key_name)+dkh-keynamelen+1); if (strcmp(new_key_name,) != 0) strcat(new_key_name,\\); strncat(new_key_name,dkh-name,dkh-keynamelen); So basically it does 'duplicate my string but add XXX bytes to it as I want to strcat to it a new string of len XXX'. Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: ddraw patch
Some comments :
+ case D3DRENDERSTATE_LINEPATTERN: {
+ D3DLINEPATTERN pattern;
+ #ifdef WORDS_BIGENDIAN
+ pattern.wRepeatFactor = *((WORD*)pattern + 2);
+ pattern.wLinePattern = *((WORD*)pattern);
+ #else
+ pattern.wRepeatFactor = *((WORD*)pattern);
+ pattern.wLinePattern = *((WORD*)pattern + 2);
+ #endif
Why not someting 'simple' as pattern = *((D3DLINEPATTERN *) dwRenderState); ?
Your code is not working anyway because (AFAICS) you never actually store
something in 'pattern'.
+ if(pattern.wRepeatFactor) {
+ glEnable(GL_LINE_STIPPLE);
+ FIXME(implement wRepeatFactor parameter for glLineStipple\n);
+ glLineStipple(1, pattern.wLinePattern);
+ } else {
+ glDisable(GL_LINE_STIPPLE);
+ }
+ break;
+ }
+
Well, as long as you are here, I would rather do something like that :
if(pattern.wRepeatFactor 256) {
FIXME(not supported in OpenGL - clamping to 256);
}
glLineStipple(pattern.wRepeatFactor, pattern.wLinePattern);
Because, from what I can see in the man page, the first parameter of the
LineStipple call is exactly equivalent to 'pattern.wRepeatFactor'.
By the way, which game uses this rendering state ?
@@ -921,16 +940,16 @@
case CONVERT_PALETTED: {
IDirectDrawPaletteImpl* pal = current_surface-palette;
BYTE table[256][4];
- int i;
- int x, y;
+ unsigned int x, y;
BYTE *src = (BYTE *) (((BYTE *) src_d-lpSurface) + (bpp * rect-left) +
(src_d-u1.lPitch * rect-top)), *dst;
-
+
if (pal == NULL) {
/* Upload a black texture. The real one will be uploaded on palette
change */
WARN(Palettized texture Loading with a NULL palette !\n);
memset(table, 0, 256 * 4);
} else {
/* Get the surface's palette */
+ unsigned int i;
for (i = 0; i 256; i++) {
table[i][0] = pal-palents[i].peRed;
table[i][1] = pal-palents[i].peGreen;
And what are the reasons for all these changes ? I do not see why it's
better to have the loop variables signed instead of unsigned (except if you
have a compiler warning about signed / unsigned comparison).
Lionel
--
Lionel Ulmer - http://www.bbrox.org/
Re: [dx69+70] FPS + SetTransform transformation
On Wed, Jul 16, 2003 at 07:58:51PM -0700, Steven Edwards wrote: Note: I had a concern about calling gettimeofday, but I saw it was already used in dlls\ntdll\time.c and I think I have done the right includes. If you can avoid gettimeofday please try to. I have a patch to add gettimeofday to wine_port in the ReactOS tree but the dlls really should avoid calling *nix only functions if you can. Not that it really matters as most of WINEs directX stuff wont work on ReactOS for years++ anyway. In the D3D1-7 FPS code (which is under #ifdef / #endif for the moment), I used QueryPerformanceCounter as a real Windows program would do :-) I will switch to the new FPS channel too, it's a nice idea. Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: Good News : WineMine Works on Mac OS X :)
Better, why not help make Linux as nice as MacOS, then you wouldn't need to go to all this hassle in the first place. In that case, why not just install Windows, it would prevent us all the hassle to develop Wine :-) Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: [URLMON] Implement URLDownloadToFileA/W
Changelog: Mike McCormack [EMAIL PROTECTED] Lionel Ulmer [EMAIL PROTECTED] - implement URLDownloadToFileA/W Just to add that, for once, this patch is LGPL'ed as it's 'based' (let's rather say 'stealed' :-) ) on some of Mike's code. Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: wine/dlls/opengl32 wgl.c
On Sat, Jul 12, 2003 at 12:59:49AM -0300, Marcelo Duarte wrote: Modified files: dlls/opengl32 : wgl.c Well, I only modified one file in the dlls/opengl32 directory make[2]: Entering directory `/home/mduarte/wine/dlls/d3d8' And all your warnings are in the d3d8 directory. So are you REALLY sure that it's my patch that caused these warnings to appear ??!?? Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: still many warnings from Mesa
It seems recent patches by Raphaël have fixed all these apart from mere four: Errrm, I did the changes, not Raphaël :-) directx.c:779: warning: implicit declaration of function `glXGetProcAddressARB' wgl.c:325: warning: implicit declaration of function `glXGetProcAddressARB' wgl.c:325: warning: comparison between pointer and integer wgl.c:334: warning: assignment makes pointer from integer without a cast Well, for these, we need to define 'GLX_GLXEXT_PROTOTYPES' to have the prototype defined... After, I have no idea if this could break things up in case of 'bad' GL headers installed (ie do we prefer 10 people complaining of Wine not compiling or 1 with warnings ?). But at least these warnings are 'less critical' than the GL ones (where some functions had float / double parameters = the generated code was useless). Here, the generated code with or without warnings should be the same :-) Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: still many warnings from Mesa
I think using a function pointer should be better. Hmmm, let me hack this up for OpenGL (wgl.c)... We will see what it gives :-) Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: GDI renderer
I would like to know the actual status of it, and how to configure wine to use it in place of the X11 drv? Out of curiosity, why would you use this SDL driver instead of the X11 driver ? Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: [X11DRV] Fix crash on bad fonts...
Why not print a user message here that such and such font might be broken? Because I prefer having Wine working without any user intervention than having to hold hands to people not understanding why they should remove this font (and not knowing how to find it or how to delete it). Feel free though to add the message and do the support on #WineHQ later on (not that we see you much there lately :-) ). Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: still many warnings from Mesa
Could someone please have a look at addressing these? Well, I think the only way to safely remove these are by using --disable-opengl. Ie I will detect that one has 'ABI-compliant' GL headers (ie that it defines the glXGetProcAddressARB / multi-texture prototypes) and disable OpenGL build if not. I know it's a Linux only ABI but well, people on other platforms can fix the issue if they need it to be fixed :-) Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: still many warnings from Mesa
Nah. It works perfectly, without a single warning, once #define GL_GLEXT_PROTOTYPES is added, but Raphaël didn't want that due to problems with broken nVIDEA drivers or somthing like that. (...) This is not a Linux versus FreeBSD issue. Well, the Linux ABI tells this : 4.4. glx.h must include the prototype of the glXGetProcAddressARB extension described above. 4.5. All OpenGL 1.2 and ARB_multitexture, GLU 1.3, and GLX 1.3 entry points and enumerants must be present in the corresponding header files gl.h, glu.h, and glx.h, even if only OpenGL 1.1 is implemented at runtime by the associated runtime libraries. So if your system was compliant, you should have all the glMulti* prototypes defined in your gl.h file and glXGetProcAddressARB too So you should not have any warning. Nothing is mentionned in the ABI about any need for 'GL_GLEXT_PROTOTYPES' protection of these calls, so well, I still think that it's somehow a problem in your headers :-) Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: still many warnings from Mesa
There is no such thing that is widely known as the Linux ABI _and_ that mandates things like this. Do you refer to http://oss.sgi.com/projects/ogl-sample/ABI/ ? Yes. If we're nitpicking, this has nothing to do with an ABI, but with an API. Well, the documentation is called an ABI so I take their naming conventions even if in the case of header file definitions I agree with you. If we are not nitpicking, this problem still exists with Mesa-5.0.1, so it would be nice to address it (as Raphaël once suggested). Well, feel free to do so, this is a can of worm that I do not particularly like to open (and it works for me (tm)). But I will post a mail on the Mesa-devel mailing list about the glXGetProcAddressARB issue, we will see what I get for an answer :-) Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: still many warnings from Mesa
So i prefer to do fixes to not have more any problems with not corrects headers than waiting for corrects one (or if you prefer you can put correct headers on wine source tree). Well, you are free to fix those warnings if you wish (I won't do it as it works perfectly well on my system so I cannot test with what I consider broken headers). If you do so, change also the 'make_opengl' Perl script as I would prefer not to always come behind people comitting direct fixes to the auto-generated files as soon as I want to update the files. Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: [OPENGL] Compilation fixes on some b0rken headers
On Fri, Jun 20, 2003 at 05:22:22AM +0200, Sylvain Petreolle wrote: A 50k patch ?? Well, and so ? If I sent it as a compressed file, the 'all patches need to be readable junkies' will complain. And well, it's plain text, so even people with dial-up will download it pretty fast thanks to line compression :-) Lionel PS: '50 lines quoted for one line reply ?' (and using the dreaded Outlook quoting convention) -- Lionel Ulmer - http://www.bbrox.org/
Re: [OPENGL] Compilation fixes on some b0rken headers
I couldnt even test the benefits of your patch (using Xfree86+Mesa headers here, no complain from the compiler) Yeah I know, on my box there is no complaints either... But well, to be on the safe side, I remove all 'typedefs' from the auto-generated files to be sure to never have this issue again ;-) Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: Wintab dll: Status report.
Sometimes a badly configured tablet can generate X errors on the XOpenDevice method. Fixed by ensuring tablet driver was functional. I don't know if the errors need to be caught, or not, but I think they were causing crashes. This is probably related to synchonous/asynchonous X modes. In case you want to catch this, there is a mechanism in place in Wine to handle X calls which can lead, in 'normal usage' to X11 error being sent. Look at, for example, the DGA2 initialization. Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: [D3D] Xvidmode and surface locking
Ok, I recently started using System Shock 2 fullscreen with xvidmode enabled in my wine config, and here's something strange. When xvidmode is enabled, and I'm in a game and press esc to go to the menu, then esc again to return to the game, or load another save or go through a bulkhead/elevator and cause it to load another level, when it returns to the game the 3D area is completely black, though the HUD/inventory and brackets around items all shows up. Well, seeing this description, I could say only one thing : DRIVER PROBLEM :-) You description seems to imply that the glReadPixels call returns a completely black frame buffer (whereas the drawing seems to work well as shown when you remove the surface locking stuf). To be 100 % sure, you could enable the debug code in the Lock / Unlock case to have nice screenshots (if they are all black, that would show that :-) ). Maybe it could be fixed by my attempts to use the texture engine instead of glReadPixels (to be submitted only after profiling)... Did you try changing the resolution manually using Ctrl +/- ? Does it work like that ? As for System Shock 2, I have the full game, so no need to show me the demo. Lionel PS: do not count on me to debug this, I hate XVidMode :-) -- Lionel Ulmer - http://www.bbrox.org/
Re: GL under the render window
I'm writing a 3d modelling/animation package and although I'm not writing a native port for linux I test the software with Wine for compatibility. I've recently wrote the OpenGL initialization code and noticed that when primitives are drawn, their actually drawn undernieth the rendering window. How do you get the DC that you use to draw your GL stuff on ? As far as I know, you have the same issue the NWN Model Viewers / Editors have (search on wine-devel on a thread on this issue where I explain exactly where the problem comes for). It's not fixed as of yet although a patch fixing this has been sent recently (I still need to look at it though :-/ ). Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: Sound3D problems
There were come great changes in dsound lately (especially in buffers i think). Is this the source of problems? Or is it lack of CriticalSection stuff (I don't really understand them, so I didn't bother with them when I was writing it)? Well, in my DSound3D test case (the demo for ArxFatalis), I get a crash due to DSound3DListener COM vtable being overwritten (and thus a nice crash when the application calls one of the functions). From the data that replaces the pointer, it looks like it's been 'mixed' over (as the data looks like a sound buffer). I did not manage really to track it down yet (was never able to break Wine to add the watchpoint at the right address) but either we have a buffer size issue (and thus memory overrun) or a threading issue (for exmple a buffer getting Released while it get mixed and the buffer address is then reallocated to another object ... and when the mixing function continues on the now-freed buffer = crash). Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: couple of questions about pthreads (scheduler/pthread.c) in wine
My questions are: 1) Why Winelib uses it's own implementation of pthreads (at least it looks like this is intention)? Because Wine uses his own threading model to emulate the one used in real Windows. This means that pthread needs to be 'ported' to this model for it to integrate well with Wine. 2) Is it possible to force linker to use symbols from libpthread.so instead of symbols from ntdll.dll.so? (I don't know how to tell linker to use symbol, e.g. pthread_cond_wait, from specified library, i.e. /lib/libpthread.so.0). Well, maybe you can, but we do not guarantee at all that the result will even work. If you use Winelib to port an application and never intend to use any native Windows DLL, it could, but that is currently not supported by Wine (ie have Wine use pthread for its threading). Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: DEVENUM.DLL Implementation
How do you get the game to run, then? I have a game (Rubik's playground) that won't start because the start movie can't load. Well, the only game that I personnally test which requires Quartz (SystemShock2) simply does not play the movies if there is an error... So basically, it works per default. Otherwise, there is the '--dll quartz,devenum=n' solution :-) Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: DEVENUM.DLL Implementation
It's probably best to ask Alexandre about this, but it either slipped through the cracks (and I didn't want to submit it again until I was completely happy with it) or it was due to depending on other unimplemented behaviour (IFilterMapper interface). Yeah, let's wait for him to come back from vacations :-) I was just surprised the other day when I looked at the devenum DLL directory and found it empty and somehow remembered someone sending a huge patch to fill it in. It should work alright if you can get the patch to apply properly, but IIRC a few changes conflict with it. If you want, I wrote a Python script that transforms most of the 'old-style' COM definitions to 'new-style' COM macro usage. I could give it to you (I do not remember if your patch defined a lot of COM objects or not). As for the future, work on Quartz shouldn't be too hard to do. A minimal working system would be a File Source 'codec', video and audio renderers and the graph builder, along with my device enumerator implementation. Well, if you want to start work on Quartz, feel free to do it, you would be our saviour (to all the gamerz out there who cannot have intro / cutscene movies due to the missing Quartz stuff in Wine). We were planning to start on it this summer, but well, as we have still a lot of work on D3D(7/8/9) and DInput, it was not really our highest priority. Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: DEVENUM.DLL Implementation
This should be an almost complete implementation of DEVENUM.DLL What is not complete yet, is one function that uses IFilterMapper2 (not implemented yet in quartz.dll) to generate some dynamic information about the waveIn, waveOut and midi devices available. Also, it seems to fail when using built-in oleaut32, but not when using native devenum and not when using native oleaut32. I am hoping the reason for this should become fixed/clearer after implementing quartz.dll (and no, I am not volunteering!). Alexandre, Robert, Do you have any idea why this patch was never comitted to Wine ? Maybe this will prevent me to do 'quartz,devenum=n' and only 'quartz=n' to get movies in some applications :-) Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: [DINPUT] Some more dinput stuff
As your patch is a little malformed and conflicts with mine (a big one) i send my patch merged with yours, can you look if all is correct. Why did you not send a patch against a tree patched with Christian's ? And moreover, it seems you have another patch lying around (the one adding the IDirectInputDevice2A interface to the QueryInterface call). The problem is not the Changelog one, it's just that it's now really hard to do any code review with these kinds of stuff as change are accumulating :-/ Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: [DShow] A bunch of stubs...
I've been thinking (waits for the applause to die down). DirectShow is similar in style and architecture to GStreamer right? They both use graphs of connected elements. Would it be possible to use GStreamer to implement Quartz? /me applauds.. Tom, add Mike as the new Quartz maintainer :-) Actually, we may use this solution, but I really never looked at it to see if it's doable. It could be, but on the other hand, one could say 'Win32 GUI is similar in style to GTK+, you have buttons and sliders and widgets, so let's use GTK+ to do Win32 GUI elements' :-) Moreover, when you see this : trace:quartz:Graphbuilder_RenderFile(0x403c3680/0x403c3680)-(Lr:\\sshock2\\cutscenes\\cs1.avi (0x40682a80), (null) ((nil))): stub !!! trace:quartz:Graphbuilder_FindFilterByName (0x403c3680/0x403c3680)-(LLG Video Renderer (0x4068294c), 0x4068262c): stub !!! You see that the application expects to have their own renderer to be used... So it complicates a bit all the stuff if GStreamer chooses one for us which is not the one the application expects. Finally, the hard part is not (I think) how to implement it, but how DShow works (there are hundreds of COM interfaces / objects and most is constructed 'automagically' by 'Graphbuilder_RenderFile'). Once we have the logic in place to build this graph the same way Windows applcations expects us to build it, then we will have done most of the work I think and the rest is only code stealing :-) Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: Getting game X to work under wine
Just a quick question. Lets suppose theres a game that currently does not work under wine, and I wanted to correct the problem. But, given the recent flurry of commits, should I try to fix it by myself? Or is it better to wait a little more for the code to stabilize? Well, if you feel confortable diving into the DDraw / D3D / D3D8 code, feel free to try to fix it yourself. Note however that : 1) most games do not work due to issues completely unrelated to DirectX 2) if you plan to do some 'big' development, contact me (on D3D7) or Raphaël / Jason on D3D8 to be sure to not step on anyone's toes. Finally, if you wait for the code to stabilize, you may wait for a long time ;-) Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: SMP Problems?
err:dsound:DSOUND_MixOne underrun on sound buffer 0x40437f48 err:ntdll:RtlpWaitForCriticalSection section 0x77e340 ? wait timed out, retrying (60 sec) tid=0009 err:ntdll:RtlpWaitForCriticalSection section 0x77e340 ? wait timed out, retrying (60 sec) tid=000c Wine exited with a successful status Well, if you do not fear huge traces and if the problem occurs too with +relay, do a +relay trace and see who created this '0x77e340' critical section. Is it a Wine-internal critical section or one from the game ? Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: ddraw bug
Any one have on of the games I mentioned??? (these games aren't particlerly common) Well, seeing where you crash and the +ddraw trace just before, it's a pretty common set of consecutive DDraw calls common to many games. Did you try more games or only these two ? I did not change the confige or anything from the prev installtion, but this is what I do every cvs update usualy without clean and configure but this time I had to becouse of some d3d compile problems... Well, considering that neither me nor Raphael has never seen this issue, I think that you will have to debug it yourself... Or try to find a demo version of these games showing the issue for us to be able to debug it :-) If you want to debug it yourself, break on 'HAL_DirectDraw_Construct', see that 'This-local.lpGbl' is correctly initialized and then put a watchpoint on the lpGbl variable to see when it goes back to being NULL. Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: ddraw bug
well, for what i know of that code 'dd_gbl' should never be null. If it's NULL you may have a huge integrity problem in ddraw ;( Have anyone the same behavior ? I never saw this. But well, a '+ddraw' trace could only help us debug the issue (because just a GDB backtrace is usually not enough to understand when and where the problem occured). So could you (nor Raphaël :-) ) send to the list if not too big or to me in private a +ddraw log up to the point where the game crashes. Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: Main_DirectDraw_WaitForVerticalBlank
Anyone is planing to fix Main_DirectDraw_WaitForVerticalBlank soon? Well, the day Wine has direct hardware access we may define it. Otherwise, with the state of the current low level drivers (ie we go through X11), this is completely useless. When I try to start Diablo I demo, it's one of the two ddraw fixme I get... (the other one is Main_DirectDraw_SetCooperativeLevel) I don't know if the implementation of that will fix the game, since it seem to work, but the screen stay black... I really doubt that this is the reason for the black screen. Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: GL Header question
well, better ;) my goal is to detect and active all capabilities on runtime and never bother again about declared/defined caps from gl headers (gl,glext,glx). For this we need an header where all defines and functions pointers are declared (as seen in d3dcore_gl.h) As said in another mail, I agree for glext.h but not for GL.h. Or if we go that way, why not ship a 'valid' set of gl.h / glext.h / glxext.h that are known to work instead of redoing all the constants ? For example, we know that Raphael has a configuration where his tree builds... Well, let him ship his .hs in Wine :-) Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: GL Header question
their machines compared to the people running it. My only comment is whether d3dcore_gl.h is the right place for it, as putting it in something like \include\wine\winegl.h would mean the definitions can be reused by ddraw, and the opengl dlls in the same way. Wine's OpenGL DLL does not need any #defines. We actually do not do any (for now that is) GL call that is not done by the Windows application itself. So all the enums are compiled in the Windows code, not in Wine. Of course, the day we will support WGL pbuffers using GLX PBuffers, we may have the same kind of issues, but never as bad as for D3D. Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: GL Header question
Curiously, why glext and not gl? I'd be more for shipping all 3 if required or merging them all into one wine header. Could we not just be causing ourselves the same problem further down the line otherwise? It's just because we never had any problems until now with the standard GL headers... I.e. before we started playing with extensions in D3D / D3D8, we never had any build problems (basically, we detected GL as not supported in configure if the gl.h was too old / bad). So it was just to limit the number of code we add to Wine and the possible error that will happen to create hundreds of #defines / prototypes. Perhaps they are copyright nvidia? :-) AFAICR, NVIDIA only ships gl.h and glx.h files. You need to get glext.h and glxext.h yourself. And these we can generate ourselves from the GL extension registry :-) Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: Fixme:s in simcity 4 native install (DDRAW.dll.DdEntry, commctrl:InitCommo)
err:module:import_dll No implementation for DDRAW.dll.DdEntry18 imported from C:\windows\system\d3d8.dll, setting to 0xdeadbeef This means that your Wine install does not have D3D8 built (probably because you do not have the OpenGL headers installed on your box if you built yourself or that you missed the OpenGL dependency when installing a package). And 'native' D3D8 is certainly not supported by Wine. Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: Re: Submits galore
PS: As jason have some compilation problems too as it use a specific gl.h with a generic glext.h, i'm thinking about not using anymore the gl/glext headers definitions (i'm too bored to fixes each mismatch headers declaration) Well, I would say that we use the standard gl.h file (otherwise it's too messy) but completely remove the dependency on glext.h. I plan to change all _EXT and _ARB stuff in the D3D7 code by _WINE #defines (defined from the GL extension specs) and to never use at all the function pointer typedef and use my own. Basically, my baseline would be GL 1.2 and all the rest would be redefined. Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: Re: Re: Submits galore
well, the problem is that gl.h defines ugly things too. as i have reports from users using mesa headers 3.4 (openGL 1.2 only declared but ugly pre 1.3 support) while using Mesa5.0 (very easy to do: install a XFree4.0 and after install only mesa5) Well, I would only use 1.2 defines from the GL headers. All the rest would be prefixed or suffixed by _WINE so no risk of conflicts. So even if the headers are ugly, I do not see how it could break things. i think you'll have many breakage :) Well, if I do the following, I wonder how I could have breakages :-) : #define GL_COMBINE_RGB_WINE0x8571 I.e. I do not plan to use ANY pre-defined values from the header but to define them all myself. So tell me where I could have breakage ? As you want, But for me, I think building with GL1.4 (last ans most complete) headers and detecting/activing caps on runtime it's a more proper solution (no more #ifdef/#define in code, only in d3dcore_gl.h definitions). I cannot see how you can do this without shipping all the GL / GLX 1.4 headers with Wine itself. If you plan to redefine stuff, this is exactly what I planned to do and you told that it would introduce breakage :-) Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: GL Header question
Right, but what about winelib applications who want to use some Windows specific OpenGL extensions (fore exemple render_to_texture) ? Well, for the moment this is not supported... And anyway, these would depend on a 'wglext.h' or 'wgl.h' (no idea how it's done in Windows) which we would create from scrach anyway as it's not present in the Linux system headers. Well, i have thought to begin implement it ;) Feel free to do it :-) Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: Success Story with Tomb Raider 3
On Thu, Jun 05, 2003 at 08:14:09PM +0200, Sylvain Petreolle wrote: Thanks to the D3D/ddraw workers, the last storm of patches makes Tomb Raider 3 able to start. Well, TR3 Demo works since AGES on my box :-) You must set ZBuffer to on to get all graphics, and we run into gray levels at the moment. Great Work guys. Can you send me screenshots of the 'gray levels' ? Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: Re: Re: Re: Submits galore
original way to solve the problem, but as openGL1.2 is really a few things you can redefine all openGL. (and i think it will be better readable and workable than mixing GL_*_WINE and GL_*) Well, we are already mixing GL_*_ARB, GL_*_EXT, GL_*_NV, ... Why not replace all these extensions (which may or may not be defined in the header files) by our own 'extension superset', called GL_*_WINE ? And if you do that (no more official gl.h include) you shouldn't have anymore problem that you have used some GL_* only defined in you official gl.h but not openGL1.2 compliant Well, the problem with the approach you are using now in D3D8 is that you are using the same name than the official one... And this could easily lead to 'name clashes' with #define or typedef renaming. So either we do everything ourselves or we go my way, but I do not think your way is fixing all problems :-) Yes, you are right, but i prefer code readable :) What is non-readable in what I propose ? You find _WINE so ugly ? You prefer _ARB or _EXT ? so do it, i'll reuse it for d3d8 :) but do it for official OpenGL1.2 defines too (as i have commented before) Well, I already use 79 API calls in D3D7. And I did not count how many of the GL enums, but surely more. I think it would really be a pain to re-do all this ourselves. So if we go the 'let's have our own extension files', at least take header files from an 'external vendor' (for example Mesa) and massage our code for it to work on these headers. At least if we have breakage, it will always be internal and never due to external dependencies. Or we could auto-generate these headers :-) well, i don't want to use the user installed gl.h (it can introduce breakage with beautifuls old specific headers), and i don't want to have all opengl headers into wine tree (wine don't need to install it adn we don't need all defines). Can you tell me any breakage introduced by old gl.h ? If you tell me 'They define extensions too !!!', this is not problem for my way as all extensions would be redefined with the _WINE suffix :-) Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: Major FUD (was Re: Add root drive mapping to default config file)
Now, if someone would like to offer a *technically competent* argument as to why mapping a drive letter to / is bad, I'd love to hear it. Basically, adding '/' as a drive is to help people which are not able to properly configure / install Wine (and who do not understand the 'Drive' error message). So it will mask other bugs like games checking that their data file are on a CD-Rom and failing because the data is accessed via the '/' overide and not the CD-Rom path. So I mostly object for aesthetically reasons (ie as we emulate Windows, be as kludgy as Windows : use drive letters :-) ). For a Winelib application, I would agree with Dimi though. And finally, as for Wine hurting your FS, there is the famous '!$!$!$!$.cfr' bug when running Eplorer with Wine. I have no idea if it could also break something in your Linux FS though :-) Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: Major FUD (was Re: Add root drive mapping to default config file)B
This seems like a different issue. In fact, this will be solved if we also had a proper definition for the CDROM, wouldn't it? Of course. But if the user had a correct Wine configuration, he would not have had the problem that made Mike add '/' as a drive path... And all this discussion would not have been started at all :-) Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: Major FUD (was Re: Add root drive mapping to default config file)
I see mapping a drive to `/' as `proper' configuration. (i.e. If Wine is meant to integrate apps to the Unix environment, it shold be able to see the full Unix environment.) Ah, there is where my opinion diverges the most from most of the people here (and why I advocate a lot for the Desktop option). I do *NOT* want to have my Windows and my Linux stuff to mix together. So I always use Dekstop mode and I have clearly delimited Windows drives for Wine. Lionel (who wonders if he's the only one in this case :-) ) -- Lionel Ulmer - http://www.bbrox.org/
Re: [D3D] Some execute buffers rewrites + misc fixes
This seems like the Copy/Paste syndrom [:-)] Anyway, I fixed it in one of my pending patch. Yes! From a ZBuffer surface to another... Don't remember the game though... (because it crashed in another part of wine) Wow... This is nice :-) When doing the standard blit, the app set the DDBLT struct pointer to NULL so without the check this simply crashes when accessing the depthfill member of the structure. Yeah, it's in my plans to have the ZBuffer a bit better handled to not crash when applications do strange things with it... Proper Lock / Blt support will never be fast on any GL implementation I know though :-/ Yes this can be done as well. [:-)] Fixed it in one of my patches too. Because the world transformation introduced the W coordinate which cannot be passed to drawing functions. But well, this coordinate should be always be 1 after the world transformation so we can ommit it. Well, you can pass the W coordinates using the 1/W trick, no ? If you use the XYZRHW format and give it X, Y, Z, 1/W after your computation it should work, no ? Slow but working from what I can see... Oh! Well I forgot this hack... [;-)] I think to support this using GL, we should use the feedback buffer. Will surely be slow, but well, better than to write our own lighting :-) Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: Add root drive mapping to default config file
On Tue, Jun 03, 2003 at 10:29:52AM +0100, Mike Hearn wrote: Oooh, here's an idea - how about if when you ran wine from an area of disk that wouldn't normally be mapped, it creates a temporary ghost mapping that doesn't appear in the config file but only for itself and child processes? It takes precedance... Well, what about grafting brains on Wine users instead ? But well, I would prefer to change the error message to be even more verbose... What about putting a nice URL in it pointing to a page where they could read all about drive configuration in Wine ? Because mapping '/' by default is plain ugly in my opinion... It's like shipping some server application with a default blank password :-) Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: Add root drive mapping to default config file
That would work too. But it's just a general pain in the ass even when you know exactly what is going on anyway, it's not like Wine is already too convenient to use or anything. No, but if they users get this error, it means that they did not configure Wine properly... So that we are only hiding the problem anyway. What makes you sure that they will have set a fake C drive properly or created the sub-directories and all that stuff ? Can't agree, I'm not seeing the security problem here. Me neither. Just stupid default values :-) Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: Fix for ddraw: CreateSurface
On Thu, May 29, 2003 at 12:12:26AM +0200, Sylvain Petreolle wrote: Since some surface types are unhandled for now, OffScreenPlain is assumed. Unused members of the DDSURFACEDESC2 structure are set to zero, so the bitperpixel is zero. DDRAW_width_bpp_to_pitch is called with bpp 0 and apps are stopping on assert(bpp != 0); /* keeps happening... */ At least WinDVD starts with this patch, will it be accepted until we implement other surface types ? Well, I think it would be better to check for the OVERLAY flag and return 'NOT SUPPORTED' in this case. Could you try this and tell us if it works too ? Lionel PS: can't really send a patch as I am a bit far from my box :-) -- Lionel Ulmer - http://www.bbrox.org/
Re: Implements languagegroups functions
Again, I'm not a C expert but I think it's invalid strict C to declare variables half way through a block, they all have to be at the top of the function together. It's valid C99 though... And as GCC 3.2.x is a C99 compiler, one will see more and more such code being submitted as patches (I did it also once by mistake when I was developping on my laptop which has more recent tools than my main development machine). I wonder if it's possible to force GCC 3.2 to act as a C97 compiler.. It could be used in Wine's configure script to prevent breakage on us poor GCC 2.95.X compilers :-) Wine doesn't like C++ style comments (//) because some C compilers don't accept them, I think you have to use /* */ I think // is valid C99 too. Lionel -- Lionel Ulmer - http://www.bbrox.org/
[Fwd] [announce] QEMU x86 emulator version 0.1
Hi all, People wanting to experiment running Wine and X86 programs on PPC could try to test this. Be warned that it's not very polished on PPC yet. This implements what was discussed here (being that to run Wine/X86 on PPC it's better to run all user space emulated). Lionel PS for mailing list moderators : Fabrice bcc'ed the wine mailing list Saturday but as the mail did not appear today, I am forwarding it, so you may reject his original mail if he still is in the moderator queue. - Forwarded message from Fabrice Bellard [EMAIL PROTECTED] - Date: Sun, 23 Mar 2003 21:46:47 +0100 From: Fabrice Bellard [EMAIL PROTECTED] Subject: [announce] QEMU x86 emulator version 0.1 To: undisclosed-recipients: ; Hi, The first release of the QEMU x86 emulator is available at http://bellard.org/qemu/. QEMU achieves a fast user space Linux x86 emulation on x86 and PowerPC Linux hosts by using dynamic translation. Its main goal is to be able to run the Wine project on non-x86 architectures. Fabrice. - End forwarded message - -- Lionel Ulmer - http://www.bbrox.org/
Re: installing ie55
you mean if i can read around the browser holy war that some idiot started up there? is there anyone who admins that who could delete the irrelevant garbage from there? Oh well, it's been ages since I advocate to remove ALL possibilities of forums / comments from the App Database but nobody listens :-) Lionel -- Lionel Ulmer - http://www.bbrox.org/
'make depend' b0rken on fresh check-out
Hi all, It seems that 'make depend' is broken on a fresh CVS check-out on a clean tree. This is because 'makedep' is linked against 'libs/port' which is NOT built yet (kinda ironic to have dependencies problem building our dependency tool :-) ). Configure finished. Do 'make depend make' to compile Wine. cd ./tools make basename tools/makedep make[1]: Entering directory /usr/local/src/Wine/CVS/wine_work/tools' gcc -c -I. -I. -I../include -I../include -g -O2 -Wall -mpreferred-stack-boundary=2 -gstabs+ -DLEX_OUTPUT_ROOT=\lex.yy\ -DINCLUDEDIR=\/usr/local/src/Wine/Build_02/include/wine\ -DBINDIR=\/usr/local/src/Wine/Build_02/bin\ -D_REENTRANT -o makedep.o makedep.c gcc -g -O2 -Wall -mpreferred-stack-boundary=2 -gstabs+ -o makedep makedep.o -L../libs/port -lwine_port /usr/local/bin/ld: cannot find -lwine_port collect2: ld returned 1 exit status make[1]: *** [makedep] Error 1 make[1]: Leaving directory /usr/local/src/Wine/CVS/wine_work/tools' make: *** [tools/makedep] Error 2 Doing first 'make' in the 'libs/port' directory fixed the issue. Lionel PS: any news about the Wine conference :-) ? -- Lionel Ulmer - http://www.bbrox.org/
Re: DPRINTF-TRACE dlls/ddraw/dsurface/main.c
This is why I said these needs manual review, so we can eliminate
this type of tests. But personally I would have liked it a lot more
if you could code these like so:
if (TRACE_ON(ddraw)) {
- DPRINTF( Real caps are : ); DDRAW_dump_DDSCAPS2(our_caps);
DPRINTF(\n);
+ TRACE( Real caps are : %s\n, debugddscaps2(our_caps));
Of course, I would like it better too if all the 'caps' functions could
return an actual string and if we just could auto-magically do a
'TRACE(.. %s ..);'.
At the time I started adding all these dump functions to DDraw, I was aware
of no good way to do that (ie with thread-safe string buffers guaranteed of
sufficient size to use to print my caps in).
If now something like that is present in the debug tools, I would be more
than happy to change all that (when I find time as I'm pretty short of it
lately). Of course, if this is already documented how to do it, tell me to
RTFM :-)
Lionel
--
Lionel Ulmer - http://www.bbrox.org/
Re: DPRINTF-TRACE dlls/ddraw/dsurface/main.c
Just to nitpick, in most of your patches, you have this :
if (TRACE_ON(ddraw)) {
- DPRINTF( Real caps are : ); DDRAW_dump_DDSCAPS2(our_caps);
DPRINTF(\n);
+ TRACE( Real caps are : ); DDRAW_dump_DDSCAPS2(our_caps); TRACE(\n);
}
As we use 'TRACE' now and not 'DPRINTF', the 'TRACE_ON' constructs could be
removed.
But well, one could say that it optimizes stuff to not do the test thrice :-)
Lionel
--
Lionel Ulmer - http://www.bbrox.org/
Re: d3d to support renderstate DDRENDERSTATE_ANTIALIAS
There are two ways to do this: 1. using glHint like I did 2. using glEnable What is preferable? From the Red Book, you also need to enable 'GL_X_SMOOTH' to have aliasing work. As I am a newbie to D3D is there something else to be done to make this really work? Well, from what I understand from D3D and GL this is wrong. This code should rather be in the DrawPrimitive call when the 'D3DRENDERSTATE_EDGEANTIALIAS' flag is set to TRUE (and only for lines). The 'D3DRENDERSTATE_ANTIALIAS' flag is used to enable full-scene anti-aliasing (something that is NOT controlled by OpenGL function call at all). The only thing that GL provides is this, but it has a caveat as seen in the man page for glEnable : GL_POLYGON_SMOOTHIf enabled, draw polygons with proper filtering. Otherwise, draw aliased polygons. For correct anti-aliased polygons, an alpha buffer is needed and the polygons must be sorted front to back. So if we use it, we need to have an Alpha buffer, set ourselves the blend factors and ask the application to send the primitives sorted (see Red Book for a discussion on that). If you want to really enable anti-aliasing, you can (on NVIDIA drivers) by setting an environment variable (__GL_FSAA_MODE). I have no idea if any GL extension is planned to control anti-aliasing from GL itself, this could be asked to people participating in the GL ARB meetings (like Brian Paul or people like him). So I don't think this patch should be applied as is... Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: [OGL] Some updates...
Unfortanately this doesnt fix the SimCity4 issues. Screen still black (the 3D) Although the error messages are gone : ) Well, you could raise a Bugzilla bug report and attach an +opengl trace (to be able to see what strange stuff it is doing to our GL code :-) ). Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: Problem with recent builds under RH8.0
As I said, my GL headers come from the CVS pull from the DRI, not from any pre-packaged headers. Well, I think the problem comes from one of your OpenGL headers... Can you do a 'grep GL_VERSION_1_3' in your GL headers (mostly GL.h I think). From what I suspect, you will get something like this : #define GL_VERSION_1_31 The problem is that your OpenGL library is NOT implementing GL 1.3 (as shown in your glxinfo output). This means that you have a mismatch between your system headers and your library. This could be considered as a bug to report to the DRI people (if they really provide a gl.h which defines GL_VERSION_1_3, they should also provide a library with all OpenGL 1.3 entry points). We *could* fix this in Wine by adding yet another configure check (or going the full 'GetProcAddress' way which would be needed if we wanted a nice OpenGL packaged Wine) but well, sometimes enough is enough and stuff should be fixed outside of Wine and respecting the rules instead of adding yet another work-around. Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: Problem with recent builds under RH8.0
I've seen the same here on my Red Hat 8.0 box. A workaround is to disable opengl by passing --without-opengl to configure. Could you give us exactly what your set-up is ? Ie what packages provides 'glext.h' on your system. You could also send me your glext.h file for me to look at :-) Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: IDA regression again :-)
does the first patch help ? Yeah, it works better now (I finally managed to get it to work before that : I just had to click a long time for the console to register my clicks :-) ). And 'Backspace' and 'Return' seems to be still broken :-) Anyway, where can one find docs on how the console works (MSDN, ...) to be able to help out debug 'simple' stuff ? as a dirty work around, apply the second patch, and define WC_USER (to 1) in your env when you want USER backend (instead of CURSES) Did not test it as IDA now works 'almost' fine with patch 1. Thanks, Lionel (still IDAing Tribes :-/ ) -- Lionel Ulmer - http://www.bbrox.org/
IDA regression again :-)
Hi all, Seems that with latest CVS, the ncurses driver 'added' a lot of regressions to IDA... The biggest gripe is that the mouse support is VERY flaky (I can click some times but once it stops working, it seems that I cannot do anymore with it). As I do not know exactly how to select stuff in the GUI using only the keyboard (which seems flaky too as the Backspace and Delete key seem not really to work), I am a bit stuck. How could one help debug this relatively crucial application to help in some D3D / OpenGL investigations ? Lionel PS: we REALLY should be able to use the old slow as hell graphical driver as a fallback -- Lionel Ulmer - http://www.bbrox.org/
Re: Compile Error in d3d8
On Wed, Feb 05, 2003 at 11:44:22PM +0100, Uwe Bonnes wrote: Hallo, since about last week, wine compilation stops in d3d8: device.o: In function `DrawPrimitiveI': /home/bon/tmp/wine/compile/wine/dlls/d3d8/device.c:535: undefined reference to `glMultiTexCoord3f' /home/bon/tmp/wine/compile/wine/dlls/d3d8/device.c:516: undefined reference to `glMultiTexCoord2f' /home/bon/tmp/wine/compile/wine/dlls/d3d8/device.c:416: undefined reference to `glMultiTexCoord3f' I did a make distclean and the problem persists. I think the problem is that Raphael / Jason used 'glMultiTexCoord3f' (which is OpenGL 1.2.1) rather than 'glMultiTexCoord3fARB' which is what the OpenGL Linux ABI requires (as they require support for ARB_multitexture which has the ARB versions of the calls). Could you try to replace them by ARB calls and tell us if it works better ? Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: WineConf 2003
By the way, it looks like that page has some typos. The German page looks more correct, and is still mostly English (go figure): http://www.linuxtag.org/2003/de/conferences/cfp.html Well, wherever the summit is hold, I will try to be there this time ... if we start to agree on a date soon (otherwise I may have to skip again due to vacations or other stuff :-) ). Germany, UK, all fine for me :-) Lionel (who toyed with the idea to try to organize a D3D summit will all developpers as we are 3 French and one Brit :-) ). -- Lionel Ulmer - http://www.bbrox.org/
Re: Opengl Glide
Out of curiosity : are you the guy who submitted the Tribes 1 bug on WineHQ about input and stuff ? If not, could you raise a bug (or two, one for input the other for OpenGL) so that we could go back and forth on these issues more easily than by mail on the devel list ? * As soon as any key is pressed, wine quits = Fix with native dinput.dll version dx4-dx6 For this I would need a --debugmsg +dinput,+seh trace of the problem. THe debugger won't work due to the 'LL hooks' problem, but let's hope that it will be enough. * Opengl isn't detected and impossible to choose = Currently no fix, although it works to use glidewrappers. Don't know what Tribes uses to detect opengl. For this, a +relay,+opengl,+x11drv log would be needed. My other question is this, if i want to use glide (got a voodoo3) how do i enable and use this in wine? Do i do a ./configure --enable-glide or --with-glide ? And so on.. If should be used automagically and not need any configure stuff. Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: Opengl Glide
Guilty as charged, been working on this thing for quite some time now. Well, can't find your bug report again... The latest open on Wine + Tribes is not from you. just send me the www link and i will upload the logs. If you can't find the bug anymore, raise two new ones (we will close the old ones when we find them :-) ). Or rather use this one for the dinput problem : http://bugs.winehq.com/show_bug.cgi?id=1234 If you can do for me the trace I asked at the end I would be happy :-) Any idea, why Tribes don't detect opengl? i'm not familiar with any other game that does this. Although i know that Tribes didn't support Opengl nativly but it added it with a patch later on. Well, for this, create a new bug and attach the +opengl,+relay,+x11drv log I requested. Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: [DINPUT] Fix some stupid game :-)
On Sun, Feb 02, 2003 at 02:39:07PM +0100, Andreas Mohr wrote: Cool, this should fix a lot of games, hopefully. And maybe also Unreal Tournament (NOT 2003!), where I've been searching like frantic for that mouse acquire issue some time ago... Well, the other fix would be to do an implicit Acquire at device creation (as it's done for the keyboard). But if the 'clean' fix work, let's use this one up until the point in time where an uglier one is needed :-) Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: [DDRAW] Fix bug 1246
Changelog : Add support for 24 bpp to _Blt_ColorFill. Fix endianness issue in DIB_DirectDrawSurface_Blt. While I agree with the patch, the easiest way would still be to completely remove support for the evil 24 / 24 screen configuration everywhere in Wine and only support 24 / 32. For example, in GetSysMetrics we report bpp as 24 (even in 24 / 32 mode) whereas Windows would return 32 and that breaks some apps (do not remember which though). And as I do not know of any modern graphic card supporting this (maybe Matrox because I did not test it), it should not hurt anyone. The other way would be : if ANYONE here uses (or can use) his card in 24 / 24 mode, please contact me so that I can do experiments on your X display to detect 24 / 24 from 24 / 32 :-) Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: Run from the build tree possible?
is it possible somehow to run Wine from the build tree? I mean without 'make install'? It's too lengthy to install after every one line change during printf-debugging... Huh ? Doing 'make install' from the DLL directory where you did the change is too slow ? Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: Games Swat 3d
Presumably, added to the list of programs that work ;) Well, as the funds / time of the D3D developpers is limited, we do not have all the existing D3D game ever done :-) This is where open source should work (ie a lot of applications testers / bug reporters) but for the moment, we do not have that many testers. Swat3d is a great game, and one that I happen to own. Haven't tried it in wine for a while, maybe I'll give it a try after work today. This is better :-) If it works, send me screenshots / ddraw log so that I can update the page when I find some time. Lionel (back from vacations still in one piece :-) ) -- Lionel Ulmer - http://www.bbrox.org/
Re: A strange problem with xmpeg
On Wed, Jan 22, 2003 at 09:10:19PM -0500, Waldeck Schutzer wrote: I have more data on item (2). I traced back the problem to be in Main_DirectDraw_CreateSurface. The application (or even wine itself) had requested a surface with flags DDSCAPS_VIDEOMEMORY and DDSCAPS_OVERLAY set. These are apparently not supported and, instead of failing, that function assumes the creation of an offscreen surface instead. However, it seems the other parameters (including surface BPP) were not adequately set, which causes wine to crash later on in DDRAW_width_bpp_to_pitch. Well, no need to debug further, OVERLAY are not supported anymore in Wine right now. Re-adding support this is on my TODO list but I am now doing Direct3D work and do no want to 'spread too thin' on multiple things so it may be a while (if ever) before it's re-added. I guess that a patch would be to return an error at surface creation when OVERLAY are requested. Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: Help wanted: Implementing Wine dlls that need access to X11 commands.
I tried to make sense of this issue by referring to direct draw and open gl dlls, but just got more confused. Do NOT look at DirectDraw or OpenGL for references as how it is done... The current stuff there are mostly hacks to get the DLL separation to work (ie for DDraw, it should go through a proper HAL and for OpenGL, it's not documented how Windows did it, so we did our own hacks). Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: The version info patches + d3d question
the problem is they dont run even with the patches because they cant get version info from d3dim.dll and probably other d3d dlls. since wine doesnt have these dlls how can wine give these programs the needed info or is it planned to split ddraw in a ddraw and a d3d component? actually, we are speaking about d3d architecture, but it will be possible to implement d3dim.dll (minors d3d calls) into near future using the new codebase. And d3d component (for version 3..7) is contained into ddraw.dll I don't even know WHAT d3dim.dll is :-) What does it contain for API ? I know about D3DRM.DLL (that won't be supported) for the 'retained mode' API but I thought that all 'immediate mode' API was in ddraw.dll and not in a separate library. Why not first test with an empty DLL with just the version ressources in it and see if it's enough ? Lionel -- Lionel Ulmer - http://www.bbrox.org/
[D3D status] Page update...
Hi all, I updated the D3D status page (http://www.bbrox.org/d3d_status.html) with some new screenshots and some new demos. Nothing revolutionnary though :-) Thanks to Christian for the 3D Mark 2000 paragraph. Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: Problem in dlls/ddraw/dsufrace/main.c
trace:ddraw:Main_DirectDrawSurface_GetAttachedSurface (0x402a9418)-Looking for caps: 4,0,1,1 output: 0x741ed0 Caps are : DDSCAPS_BACKBUFFER trace:ddraw:Main_DirectDrawSurface_GetAttachedSurface Surface: (0x402a9b38) caps: 1000601c,0,0,0 Surface caps are : DDSCAPS_BACKBUFFER DDSCAPS_COMPLEX DDSCAPS_FLIP DDSCAPS_3DDEVICE DDSCAPS_VIDEOMEMORY DDSCAPS_LOCALVIDMEM trace:ddraw:Main_DirectDrawSurface_GetAttachedSurface Returning surface 0x402a9b38 with description : - DDSD_CAPS : DDSCAPS_BACKBUFFER DDSCAPS_COMPLEX DDSCAPS_FLIP DDSCAPS_3DDEVICE DDSCAPS_VIDEOMEMORY DDSCAPS_LOCALVIDMEM - DDSD_HEIGHT : 480 - DDSD_WIDTH : 640 - DDSD_PITCH : 1280 - DDSD_LPSURFACE : 0x424b - DDSD_PIXELFORMAT : ( DDPF_RGB , RGB bits: 16, R f800 G 07e0 B 001f) Well, you completely lost me here... Could you restate your problem from the beginning ? Because well, in your trace, I see that you actually FOUND a valid attached surface. So the 'if (found == NULL)' test will be FALSE and thus whether this code is in or not would not change anything at all. So I doubt that removing this piece of code would change anything in the application's behaviour. The only thing I could see would be that you were running with a quite old CVS version and when you ugraded you got one fix I did on the GetAttachedSurface code to handle some problem we had with useless caps in the DDSCAPS structure being tested whereas they should not have been. Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: Problem in dlls/ddraw/dsufrace/main.c
found=NULL;
for (surf = This-attached; surf != NULL; surf = surf-next_attached){
... // surf is not modified into that
if (...) found=surf;
}
if (found == NULL) {
TRACE(Did not find any valid surface\n);
return DDERR_NOTFOUND;
}
Well, we loop on 'surf' (which will be NULL at the end of the loop) and test
'found' (that won't be NULL if a matching surface was found). So no, I do
not see any problem here.
Lionel
--
Lionel Ulmer - http://www.bbrox.org/
Re: Problem in dlls/ddraw/dsufrace/main.c
On Tue, Jan 07, 2003 at 10:11:02PM +0100, Sylvain Petreolle wrote: OK. So in the case found=surf=NULL and we disable the test that exits with an error, should the part of the function after the test fail or not ? Well, according to what the MSDN tells us, if no surface is found or if more than one surface matching the requirements are found, the function should return DDERR_NOTFOUND. So I do not really understand what you mean. If you suspect this error to be the cause of the game not to work, you should rather look if it's normal or not to not find the requested attached surface. Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: [d3d7/patch #1] firstimpl for (Get|Set)ClipPlane for d3d7
case D3DRENDERSTATE_CLIPPING:/* 136 */
- /* Nothing to do here... Even if what we receive is already clipped by
the application,
-we cannot tell OpenGL to not re-clip it. */
+ case D3DRENDERSTATE_CLIPPLANEENABLE: /*152*/
+ {
+ GLint i;
+ DWORD mask, runner;
+
+ if (dwRenderStateType==D3DRENDERSTATE_CLIPPING) {
+ mask =
((dwRenderState)?(This-parent.state_block.render_state[D3DRENDERSTATE_CLIPPLANEENABLE-1]):(0x));
+ } else {
+ mask = dwRenderState;
+ }
+ for (i = 0, runner = 1; This-parent.max_clipping_planes; i++,
runner = (runner1)) {
You forgot the 'i ' before the 'This-parent.max_clipping_planes'.
+ if (mask runner) {
+ glEnable(GL_CLIP_PLANE0 + i);
+ } else {
+ glDisable(GL_CLIP_PLANE0 + i);
+ }
+ }
+ }
break;
(...)
-HRESULT WINAPI
-Main_IDirect3DDeviceImpl_7_GetClipPlane(LPDIRECT3DDEVICE7 iface,
-DWORD dwIndex,
-D3DVALUE* pPlaneEquation)
+HRESULT WINAPI
+Main_IDirect3DDeviceImpl_7_GetClipPlane(LPDIRECT3DDEVICE7 iface, DWORD Index,
D3DVALUE* pPlaneEquation)
And here, you renamed the dwIndex (the official MSDN sanctionned variable
name) to Index :-)
(...)
HRESULT WINAPI
-Main_IDirect3DDeviceImpl_7_SetClipPlane(LPDIRECT3DDEVICE7 iface,
-DWORD dwIndex,
-D3DVALUE* pPlaneEquation);
-
Usually, we keep the Main declaration even if we never use it and replace it
with a GL one. This is always to help an hypothetical new driver.
(...)
+HRESULT WINAPI
+GL_IDirect3DDeviceImpl_7_SetClipPlane(LPDIRECT3DDEVICE7 iface, DWORD Index, CONST
D3DVALUE* pPlaneEquation)
Same comment for Index here too.
Otherwise, looks good :-)
Lionel
--
Lionel Ulmer - http://www.bbrox.org/
Some ddraw / GDI palette problem
Hi all, In 'old' D3D games, a lot of textures are created paletted... And each of these texture has its own DDraw palette object. And thus each has some GDI memory allocated. This means that after some time, we run out of GDI Heap space due to all these palettes created there : trace:ddraw:Main_DirectDraw_CreatePalette (0x4038ff48)-(0044,0x406b1340,0x406b1978,(nil)) trace:palette:CreatePalette entries=256 err:local:LOCAL_GetBlock not enough space in GDI heap 01b7 for 1052 bytes Now that problem is fixed in one game (it was due to some bad reference counting is some D3D code fixed in patch 79), but if ever it happens in yet another game, is it possible to increase this space ? Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: [D3D 78] Small patch to get Tomb Raider 3 to work
On Sat, Jan 04, 2003 at 07:28:26PM +0100, Sylvain Petreolle wrote: Do you know if tomb raider needs absolutely OpenGL to work ? Mine fails because NVidia driver makes bad access to the memory :/ No idea if Tomb Raider 3 still has a software rasterizer or not. I will try on my box at home when I come back and will tell you if it works here with my NVIDIA drivers :-) Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: Mac OS X/Darwin port of Wine
This issue comes up a few times a year (isn't it in a FAQ somewhere?) Anyway, take a look at these threads: Yeah, this is one of the most persistant 'Wine dream' around :-) I had once a long discussion with a fellow hacker on this subject (going into the likes of using Valgrind's virtualization engine to output non-X86 code to do dynamic translation and so on). We agreed that before starting with Wine, one could start with running, for example, Linux/x86 binaries on Linux/PPC. That would already validate the fact that you can draw the line at one point and from there run such an heterogenous environment. It's a very nice subject... A pitty it has such a low importance (seeing how X86 dominates the desktop market). Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: MAX_LIGHTS redefinition
On Thu, Jan 02, 2003 at 10:35:55PM -0800, Francois Gouget wrote: MAX_LIGHTS is defined in two places: * mesa.c #define MAX_LIGHTS 8 * d3d_private.h #define MAX_LIGHTS 16 So this patch removes the definition from mesa.c. Hopefully this is ok. This is fixed in one of the 10 or so pending D3D patches. At least, in my working tree I do not have the problem anymore :-) Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: Debugger / wineconsole problem
do you mean switching window or desktop ? In my case, windows (using Metacity on a standard Gnome install of Mandrake8). And no entering / exiting or mouse action can bring the input back. there are a few know bugs in scroll implementation, but that shouldn't screw up the scrollbar. could you be more precise on the issues here Well, simply that when I click on the scrollbar, nothing moves (ie I cannot scroll at all). The corruption happens sometimes when I do a 'disas' for example and that the console is scrolled on its own due to the new text being displayed and that only ojne line is continuously repeated. Will take screenshots when the problem occurs again. -- Lionel Ulmer - http://www.bbrox.org/
Re: [D3D 67] Fix small compilation bug
This patch fix a compilation bug that was around for 10 patches or so. Hmmm, seems that gcc 3.2 that is in Mandrake is in C99 mode by default... Sorry for all the GCC 2.X users out there :-) Lionel -- Lionel Ulmer - http://www.bbrox.org/
Debugger / wineconsole problem
Hi all, I have a little annoying problem with the wineconsole / winedbg : as soon as I switch to another window and come back to the debugger, I loose keyboard input. Mouse input still works fine. I have also often graphical glitches (ie I have only garbage when scrolling due to a newline being displayed). The scollbar seems also to be non-functionnal. Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: d3d three more renderstates for n2002
with one of the last patches from the cvs the game Nascar 2002 now recognizes
the d3d rasterizer in the config tool. The patch below adds three more
handlers for the D3DRENDERSTATE. As d3d seems to me pretty undocumented i can
only try to find things out using goolgle and see the example code there - a
link to doku would be really appreciated.
For the documentation, do a Google search on the .CHM files from the various
DirectX SDKs (as the relevant documentations are not to be found anymore on
MSDN's site, only DX8 / 9 is still there).
I have them all but think it's not very legal to redistribute them. I could
though give you the file names so you can Google them :-)
Only the D3DRENDERSTATE_CLIPPING stuff seems pretty obvious. I dont have a
clue what the EXTEND stuff does and can also only guess what the EDGEANTIALIAS
does. I also was not able to test it in the game - the d3d stuff seem to lack
a lot of functions this game relies on - i will try to add further functions
step by step.
Well, I really wonder what 'the lot of functions' are that is lacking... Do
you have a tree with all the patches recently sent applied to or a plain CVS
tree ? From my experience, the only stuff missing is the
SetTextureStageState stuff. I doubt that other 'important' features are
still missing.
The d3d7 code looks pretty bound to mesa - i dont use mesa, so i can not say
if this works or not with mesa - only with the opengl provided by nvidia and
what the manpages say.
Well, the Mesa name in the Wine source tree is historic (at the time these
files were created, the only OpenGL code for Linux was Mesa and it was using
the OSMesa extension to run). And as it's a pain to rename files in CVS, it
was never done.
The day we will move the files around to a d3dgl.dll library to ease
packaging, the files will be renamed.
+ case D3DRENDERSTATE_CLIPPING:
+ /* enables/disables clipping; get the maximal amount of
+* possible clippling planes in this opengl implementation and
+* enable/disable em all */
+ {
+ GLint i, maxclipplanes;
+ glGetIntegerv(GL_MAX_CLIP_PLANES,maxclipplanes);
+ for (i=0; imaxclipplanes; i++) {
+ if (dwRenderState) {
+ glEnable(GL_CLIP_PLANE0+i);
+ } else {
+ glDisable(GL_CLIP_PLANE0+i);
+ }
+ }
+ }
+ break;
Well, did you add also the code creating these clipping planes ? Otherwise,
it's not such a good idea to enable them :-)
I will have to reboot in Windows (or pester Endy to give me his CHM file
viewer :-) ) to tell exactly what that should do and how these clipping
planes are created.
+
+ case D3DRENDERSTATE_EXTENTS:
+ /* boolean
+* dont have a clue what this does */
+ FIXME(What is D3DRENDERSTATE_EXTENTS supposed to do?\n);
+ break;
Why not keep the standard 'not supported' instead of adding a case ?
+
+ case D3DRENDERSTATE_EDGEANTIALIAS:
+ /* in opengl the antialiasing of points, lines and polygons can
+* be set separate - assuming this only actives it for polygons */
+ if (dwRenderState) {
+ glEnable(GL_POLYGON_SMOOTH);
+ } else {
+ glDisable(GL_POLYGON_SMOOTH);
+ }
+ break;
+
This looks fine... Except that I have no real idea after reading the OpenGL
man page exactly what GL_POLYGON_SMOOTH does :-)
And I think you could enable it for lines too (but well, I do not know any
game using lines though).
Anyway, welcome on board :-)
Lionel
PS: I updated the d3d_status.html page.
--
Lionel Ulmer - http://www.bbrox.org/
Re: D3D status - bis
I took that as a hint http://www.telusplanet.net/public/lambregt/wine/d3d_status.html g Thanks. Uploaded this new version with some additions... Lionel -- Lionel Ulmer - http://www.bbrox.org/
D3D status - bis
Hi all, I created a small web page with the list of the demos / games I am using to test Direct3D and their various status. If anyone of you has a demo that is almost running (ie it starts in D3D mode and does not crash to reason not linked to D3D) and you want me to look at it, send me a private mail and we will see what I can do (once I come home to my ADSL line :-) ). I would also be glad of people testing the same demos than me with other OpenGL libraries to see if they have the same texturing problem that I have. The status page is here : http://www.bbrox.org/d3d_status.html Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: D3D status - bis
If any of these are downloadable a url link would be appreciated. I downloaded all of them from GamesDomain.com (it has a nice alphabetical list of all demos so it should not be that hard for anyone to get them :-) ). Note that I am on an 33.6 paid by the minute link here, so if anyone wants to 're-work' my page to add a lot of links, he is free to do so, I certainly can't. Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: D3D status - bis
very Good idea, but it will be better if we can separate D3D[1-7] to D3D[8-9] demos as the two development in wine ;) Well, as I only work (for now) on D3D[1-7] and this page is more done for me to know where I stand on all the games, I did not want to add too much stuff (ie as long as I do not work on D3D8, I won't add any of these games on this list). Otherwise, it's a bigger project (like some sort of 'developper only' application database). Lionel -- Lionel Ulmer - http://www.bbrox.org/
Some D3D status updates...
Hi all, As it was one of my objectives when Christian's work prodded me into restarting working on D3D, I am happy to show here the first screen shot of SystemShock2 working (alas texture-less) with Wine : http://www.bbrox.org/system_shock2.png Merry Christmas to everybody :-) Lionel (with one week and a half of almost full-time hack vacation left :-) ) -- Lionel Ulmer - http://www.bbrox.org/
