Re: Direct3D, the kernel and ReactOS
On Wed, Mar 29, 2006 at 11:12:06PM +0200, Stefan Dösinger wrote: My long term suggestion is to move the Direct3D-OpenGL translation code from WineD3D to gdi and a win32k sys, and write ddraw.dll, d3d8.dll and d3d9.dll to use that interface. The user mode dlls can be shared with Reactos, and from a technical point of view, even Microsoft's DirectX dlls can be used on Wine(including the hardware emulation layer). first of all excuse my ignorance of the d3d interface and so on - but this sounds to me like wine should not deal with the userland dlls at all then? once all the hardware is handled in the kernel parts what is the gain in having our own implementations? installing dx with the games should be sufficient then? on the other hand, if the interface of the kernel parts is hardly documented why not stick with the current implementation that does a good job with what it does and implement/stub the kernel things once an app crashes? -- cu pgpC83ERNLezC.pgp Description: PGP signature
Re: advpack: Forward ExecuteCabA to its unicode counterpart
James Hawkins wrote:
@@ -86,6 +87,43 @@ HRESULT WINAPI DoInfInstall(const SETUPC
/***
* ExecuteCabA(ADVPACK.@)
+ *
+ * See ExecuteCabW.
+ */
+HRESULT WINAPI ExecuteCabA(HWND hwnd, CABINFOA* pCab, LPVOID pReserved)
+{
+UNICODE_STRING cab, inf, section;
+CABINFOW cabinfo;
+HRESULT hr;
+
+TRACE((%p, %p, %p)\n, hwnd, pCab, pReserved);
+
+if (!pCab)
+return E_INVALIDARG;
+
+RtlCreateUnicodeStringFromAsciiz(cab, pCab-pszCab);
pCab-pszCab can be NULL, right? I don't think
RtlCreateUnicodeStringFromAsciiz handles that case in the way you expect.
--
Rob Shearman
Re: Direct3D, the kernel and ReactOS
On Thursday 30 March 2006 06:51, Christoph Frick wrote: On Wed, Mar 29, 2006 at 11:12:06PM +0200, Stefan Dösinger wrote: My long term suggestion is to move the Direct3D-OpenGL translation code from WineD3D to gdi and a win32k sys, and write ddraw.dll, d3d8.dll and d3d9.dll to use that interface. The user mode dlls can be shared with Reactos, and from a technical point of view, even Microsoft's DirectX dlls can be used on Wine(including the hardware emulation layer). first of all excuse my ignorance of the d3d interface and so on - but this sounds to me like wine should not deal with the userland dlls at all then? once all the hardware is handled in the kernel parts what is the gain in having our own implementations? installing dx with the games should be sufficient then? Technically sufficient, maybe, but it might be actually illegal to install Direct X on anything non-windows. Of course the blame is shifted to the user, but if one thinks about corporate wine deployments, they wouldn't want to do illegal things. They might as well deploy pirated Windows, you know. And mind you, Direct X is not for games only. I bet there are non-gaming 3D applications that use it. CAD systems come to mind. I think that for example Solid Edge uses Direct X (no, didn't try to get it running under wine yet). Cheers, Kuba
Re: OT: General behaviour of the community (from 'Why winetools is utterly useless, once and for all')
On 3/29/06, Chris Morgan [EMAIL PROTECTED] wrote: How do you propose we prevent people from emailing people that post towine-devel?How do we choose who gets to email people directly andwho doesn't?How do we filter the contents of their email?Segin doesn't speak for the entire community and he isn't a lead on the project.If that were the case this would be a more seriousmatter.If people quit because of him then what are we to do?Giventhe lack of relationship between wine and Segin they might as wellhave quit wine development because of some Nigerian money transfer email or other spam.My point is that the solution isn't trying to enforce censorship whereyou simply cannot and where it doesn't impact the community.As longas he doesn't abuse his list membership we have no reason to become involved in this issue.You won't find me supporting any kind ofrestrictions on what he says or which mailing lists he can belong toat this point in time.ChrisOk, but here is a point for you to chew on. Say that I go on a business trip for my company, and that while on this trip, I meet with some clients, and we go out for a business dinner. A few days later, while still out of town, I run into those clients again, and we all decide to go to a billiard. While at said billiard we all start drinking. No problems there. But if I continue drinking, eventually I am going to get drunk, and need assistance getting back to my hotel room. Mind you I am on a business trip and with some clients, but I am not at a business meeting. Even though I am (at the time) not representing the company, it still looks bad for them that an employee would do that in front of the client. The same principle applies here. It looks bad on the wine project as a whole that someone who participates in the devel list would email someone (even off list) and say the things that were said. Ordinarily I am against censorship myself, but I do believe in moderation, and I believe that people should be held accountable for their actions even if they are speaking only for themself, if it makes other people or things look bad. To answer your question, there isnt really a way, and I wasnt trying to say that we should prevent him from emailing others directly, or filtering his emails, I was saying that a lot of the things he does for the project should be restricted. AFAICT he has some high level permissions on bugzilla, and the appdb. Maybe those could (should?) be suspended temporarily, I dunno, I will leave it up to the big wigs here to decide if he should be punished in any way, and if so, what that punishment should be. As I said though, it is his opinion, and he is entitled to that opinion (at least in the US), but I think he should have kept it to himself, or at least not used such strong wording like ing dumb***
Re: Direct3D, the kernel and ReactOS
On Thu, Mar 30, 2006 at 08:29:03AM -0500, Kuba Ober wrote: Technically sufficient, maybe, but it might be actually illegal to install Direct X on anything non-windows. Might be or is? Or will be like dcom? At least with dcom ms made the point clear. they just dont provide it beside the os. but i can not remember a single game in my collection, that does came with the dx-package needed to run it (i hardly remember anything that came with dcom98.exe). so does anybody knows the actual license or is there anything known what ms has in mind in the near future? I bet there are non-gaming 3D applications that use it. CAD systems come to mind. I think that for example Solid Edge uses Direct X (no, didn't try to get it running under wine yet). yeah i am sure there are lots of non-game applications that utilize directx - dsound for sound apps, d3d for cad, office, 3d, ... and so on. all in all i know close to nothing what goes on the various dlls - but from a point of view like this it seems to be a lot of work to redo the work of others if there is no real need for it, like e.g. accessing hardware or operating system stuff. license issues aside i would only a consider a massive performance gain something that is worth it (and there still remains the question, why is that original dll so much slower with the underlying framework then). and of course its a lot easier to implement something that is *cough* well documented than something that is totally unknown to mankind. -- cu pgpbZAgPXBLOh.pgp Description: PGP signature
Re: [Bug 1181] Keyboard translation broken: uses raw keycodes
On Thu, 30 Mar 2006, Wine Bugs wrote: http://bugs.winehq.org/show_bug.cgi?id=1181 --- Additional Comments From [EMAIL PROTECTED] 2006-30-03 10:26 --- Peter, I'm not sure if you ever did subscribe to wine-devel, but you did mention that wine could possibly reuse parts of your keysym implementation. Could you email the list (even if you dont scubscribe) and let them know about this bug, and see if anyone is willing to take a look at it. Just make sure you let them know you aren't subscribed, if you aren't, and to CC you on replies. Hi, now you know about this bug. As the comment says, it might be possible to reuse some parts from the rdesktop implementation. I'm not saying that it will be easy, though. To be honest, I think bug 4923, and many others, are more important. Instead of fixing Wine, it might be possible to enhance Xvnc so that it can emulate a physical Xserver with a certain physical keyboard. Regards, -- Peter Åstrand ThinLinc Chief Developer Cendio http://www.cendio.se Teknikringen 3 583 30 LinköpingPhone: +46-13-21 46 00
Need Help for IniFileMapping
Hi all. I need your Help to see, how IniFileMapping works on different NT-Versions. An updated kernel32_crosstest.exe, that prints a lot of informations and a detailed description is here: http://bugs.winehq.org/show_bug.cgi?id=4096 Thanks for your Help (IniFile is the redirection from *.ini - Files to the Registry, by GetPrivateProfileString() and Friends.) -- By By ... ... Detlef
Re: [RESEND][x11drv] cleanup: Move x11drv escape codes to one common header file.
Tomas Carnecky [EMAIL PROTECTED] writes: This patch doesn't change any logic or C sourcecode, it only moves the X11DRV escape code definition to one common header file. Currently the definitions are spread over several C source files, and even there the definitions differ from file to file. I don't see anything wrong with this patch unless you *want* to have it difficult to maintain the code. Actually, that's more or less what we want. That sort of inter-dll dependencies should be strongly discouraged, and we don't want to add more of it than strictly necessary; as far as possible we also don't want dlls to depend on private headers, so copying a few things across is the preferred approach. If it becomes a problem it means something is wrong with our implementation. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Direct3D, the kernel and ReactOS
Sounds like a good project to hack on occasionally while putting the majority of effort into improving the current implementation. In other words, some effort is warranted because of the benefits of sharing code, however, wine can always transition to the new layout after it has a complete and (mostly) correct DirectX implementation. There's no reason the GDI and win32k.sys couldn't be going into the wine tree at the same time as improvements to the current system. --tim
Re: [WIDL] Implement support for unique strings
Eric Kohl wrote: case PASS_OUT: +if (in_attr has_size pointer_type == RPC_FC_UP phase == PHASE_FREE) +break; if (!out_attr) continue; break; I don't think this is correct. Firstly, it should continue, not break. Secondly, I think it only doesn't need to free the string if it has a size. I'm pretty sure it shouldn't depend on being a unique string. -- Rob Shearman
Re: Improper message recursion revealed by recent desktop window changes
On Friday 31 March 2006 02:41, Alexandre Julliard wrote: I committed a few fixes that should help, please give it a try. The problem is fixed (so the app now works) although I am still getting the pack_message FIXMEs - it is possible though that this is a different problem that was masked by the earlier one. I will investigate further. -- Troy Rollo - [EMAIL PROTECTED]
Re: Why winetools is utterly useless, once and for all.
On Mon, 2006-03-27 at 21:32 -0500, Segin wrote: There is one reason, inarguable (if you reply to this you have a IQ of 0) as to why WineTools is useless: Most of the WineTools 'magic' is in it's ~/.wine/config file, which Wine no longer uses/acknoleges, thefore, WineTools is utterly useless and has no point in existing AT ALL, PERIOD. Thought it might be interesting to refer back to the email that kicked all of this off and try to look at it in detail. There is one reason, inarguable Anything is arguable, if one has arguments that can be backed up with evidence. (if you reply to this you have a IQ of 0) Everyone has an IQ of more than 0. If they didn't, it is unlikely they would be able to read and so would not be in a position to respond. I also believe that anyone who reads this list has demonstrated a remarkable degree of intelligence in trying to move as far away from Windows as possible. The inference of this statement seems to be 'I am right because I am. I deny you the right to disagree - if you do I have already marked you out as an imbecile and you are not worthy of any consideration' - sounds rather fascist to me. as to why WineTools is useless. I have used Winetools when necessary, when there was no other easily available option. IE is required for me to use online banking. I have complained to my bank, and asked them to support FireFox and they have declined. Winetools helped me achieve what I needed. For my specific needs, winetools was useful. Most of the WineTools 'magic' Implication by use of quotation marks - winetools claims to be magic. It does not, as far as I know. is in it's ~/.wine/config file, which Wine no longer uses/acknoleges, Ignoring the poor spelling and concentrating on the details, I have used versions of winetools that supported the config file, and more recently, versions that support the newer registry configuration. Given my understanding of current wine configuration I think the statement may be misleading. If I am wrong, I am happy to be corrected, preferably in a private email. WineTools is utterly useless and has no point in existing AT ALL, PERIOD. I have already described at least one reason for it to exist. Shouting isn't necessary, but if it makes segin feel better, that's entirely up to him. The point of this email is not to argue as to whether winetools is good for Wine or not - I can see both sides of the argument. Neither do I believe that any form of banning is necessary. I'm opposed to censorship generally, and given that no individual attack was made such sanctions could be counterproductive, given that segin has offered to submit code to wine in the future. All I can suggest is that when individuals have an opinion they believe strongly in, perhaps it might be a good idea to read though any open message they send before hitting 'Send' to see if it is readable and stands up to rational criticism. I have the greatest of respect for the entire wine community (no exceptions) and know that with rational debate and argument wine will be a huge (maybe the biggest) factor in ending the Windows monopoly.
Re: COMCTL32: Add comctl32 to the list of always builtin dlls.
Vitaly Lipatov wrote: I do not agree with this patch. There is broken code in WINE's comctl32 realization (in treeview/listview code) and we need overrides builtin dll by native for get differences... Sure. You can still do that using WINEDLLOVERRIDES=comctl32=n, so it doesn't impede testing. Mike
advpack: The Plan
Hey, As you've probably noticed, I've been working on implementing advpack for a couple months now; a lot of progress has been made, and I'm glad to say that the end is in sight. The rest of this email details the game plan for finishing advpack. advpack has five main install functions: DoInfInstall, ExecuteCab, LaunchINFSection, LaunchINFSectionEx, and RunSetupCommand. They all basically do the same thing with minor differences in functionality. ExecuteCab extracts the files to install from a cab archive, LaunchINFSectionEx provides backup and rollback capability, and RunSetupCommand can also launch executables. When installing an INF section, advpack calls setupapi to install the base INF commands, such as CopyFiles and AddReg. After this, advpack parses the Advanced INF for advanced commands that are only installable when using advpack. These commands include: Values: RequiredEngine - Use either setupapi or setupx, we will ignore it. CustomDestination - assigns ldids to extra directories. SmartReboot - same reboot options as LaunchINFSection. Cleanup - deletes the INF when the install/uninstall is finished if this is 1. CheckAdminRights - check if the user is admin if this is 1. Actions: RegisterOCXs UnregisterOCXs BeginPrompt EndPrompt RunPreSetupCommands RunPostSetupCommands DelDirs PerUserInstall Backup/Rollback: ComponentName ComponentVersion BackupReg PreRollBack BackupPath Internally, there will be three main install functions: install_init, which will open the INF, make sure it's legit, and other initializations, spapi_install, which will call setupapi to install the base INF commands, and adv_install, which will parse the install section and run the provided commands. Each advanced command will be implemented by a function of similar name, e.g., RegisterOCXs would be implemented by the function register_ocxs, etc. All the command functions will be in a hash map, the key being the command name, the value being a pointer to the function that implements the command. adv_install will use setupapi to parse the entries of the install section, calling the function returned by a query to the hash map. According to INF Web [1], some commands are run before others, so there will probably be three or four maps, the functions in the maps grouped according to the order in which the commands should be run. For example, RunPreSetupCommands is to be executed after the BeginPrompt command, so begin_prompt would be in the phase 1 map, and run_pre_setup_commands would be in the phase 2 map. We would call the parser like so: run_adv_commands(InstallSection, phase1_map); run_adv_commands(InstallSection, phase2_map); run_adv_commands(InstallSection, phase3_map); If a command in the install section is not in the map, we just ignore it. This is The Plan so far, so if anyone has any ideas or suggestions, I'd love to hear from you. Thanks, James Hawkins [1] http://www.winpack.org/petr/INF_web/
Re: advpack: The Plan
On Thu, 2006-03-30 at 23:12 -0600, James Hawkins wrote: there will probably be three or four maps, the functions in the maps grouped according to the order in which the commands should be run. Or maybe simpler, instead of storing just the function pointer as the value for the map, store a structure that has 2 fields: -- priority -- function So than you just call things as: for (i=0; i MAX_PRIO; i++) run_adv_commands(InstallSection, i, phase_map); And ignore entries with incorrect priorities. -- Dimi Paun [EMAIL PROTECTED] Lattica, Inc.
Photoshop plugins in Gimp on Linux using Wine!
I've been hearing rumblings about people using Wine to run windows photoshop plugins on Linux Gimp, but hadn't seen anything concrete. Well, here it is: http://www.gimp.org/~tml/gimp/win32/pspi.html Have a look. Congratulations, Wine! - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv
new to wine, Guild Wars don't display correctly
Hi everyone, Sorry in advance not to know where to post, but I'm new to wine. I would play guild wars and unfortunately, as you guess, it doesn't work. First of all, I'm under debian stable and i'm using the debian package wine_0.9.10~winehq1-2_i386.deb. My kernel is 2.6.8 and my graphic card is an ati radeon 9000pro (I know ...ouch...) So i first try with the dri driver and , although my 3D was ok(openGL1.2 it seems), it was too slow to be playable and my mouse didn't appear. So i use now the official ati last driver(openGL 1.3 it seems). Now, most of the images doesn't appear. If you know guild wars, in the login screen, i have only rocks, the background image behind rocks and the "window" for login in front of rocks don't appear. I can send you the lasts many "fixmes" that appears but for some seconds, i have approximatively 1Mo file. However, i have no "err". The lasts line are : fixme:d3d:IWineD3DDeviceImpl_SetRenderState (0x4d290020)-(190,15) not handled yet fixme:d3d:IWineD3DDeviceImpl_SetRenderState (0x4d290020)-(191,15) not handled yet fixme:d3d:IWineD3DDeviceImpl_SetRenderState (0x4d290020)-(192,15) not handled yet fixme:d3d:IWineD3DDeviceImpl_SetRenderState (0x4d290020)-(193,-1) not handled yet fixme:d3d:IWineD3DDeviceImpl_SetRenderState (0x4d290020)-(194,0) not handled yet fixme:d3d:IWineD3DDeviceImpl_SetRenderState (0x4d290020)-(198,0) not handled yet fixme:d3d:IWineD3DDeviceImpl_SetRenderState (0x4d290020)-(199,0) not handled yet fixme:d3d:IWineD3DDeviceImpl_SetRenderState (0x4d290020)-(200,0) not handled yet fixme:d3d:IWineD3DDeviceImpl_SetRenderState (0x4d290020)-(201,0) not handled yet fixme:d3d:IWineD3DDeviceImpl_SetRenderState (0x4d290020)-(202,0) not handled yet fixme:d3d:IWineD3DDeviceImpl_SetRenderState (0x4d290020)-(203,0) not handled yet fixme:d3d:IWineD3DDeviceImpl_SetRenderState (0x4d290020)-(204,0) not handled yet fixme:d3d:IWineD3DDeviceImpl_SetRenderState (0x4d290020)-(205,0) not handled yet fixme:d3d:IWineD3DDeviceImpl_SetRenderState (0x4d290020)-(206,0) not handled yet fixme:d3d:IWineD3DDeviceImpl_SetRenderState (0x4d290020)-(207,2) not handled yet fixme:d3d:IWineD3DDeviceImpl_SetRenderState (0x4d290020)-(208,1) not handled yet fixme:d3d:IWineD3DDeviceImpl_SetRenderState (0x4d290020)-(209,1) not handled yet fixme:d3d:IWineD3DDeviceImpl_SetRenderState (0x4d290020)-(162,-1) not handled yet fixme:d3d:IWineD3DDeviceImpl_SetRenderState (0x4d290020)-(163,0) not handled yet fixme:d3d:IWineD3DDeviceImpl_SetRenderState (0x4d290020)-(164,1065353216) not handled yet fixme:d3d:IWineD3DDeviceImpl_SetRenderState (0x4d290020)-(165,1) not handled yet fixme:d3d:IWineD3DDeviceImpl_SetRenderState (0x4d290020)-(172,3) not handled yet fixme:d3d:IWineD3DDeviceImpl_SetRenderState (0x4d290020)-(173,1) not handled yet fixme:d3d:IWineD3DDeviceImpl_SetRenderState (0x4d290020)-(178,1065353216) not handled yet fixme:d3d:IWineD3DDeviceImpl_SetRenderState (0x4d290020)-(179,1065353216) not handled yet fixme:d3d:IWineD3DDeviceImpl_SetRenderState (0x4d290020)-(180,0) not handled yet fixme:d3d:IWineD3DDeviceImpl_SetRenderState (0x4d290020)-(181,0) not handled yet fixme:d3d:IWineD3DDeviceImpl_SetRenderState (0x4d290020)-(182,1065353216) not handled yet fixme:d3d:IWineD3DDeviceImpl_SetRenderState (0x4d290020)-(183,0) not handled yet fixme:d3d:IWineD3DDeviceImpl_SetRenderState (0x4d290020)-(184,0) not handled yet fixme:d3d:IWineD3DDeviceImpl_SetRenderState 500 from glStencilOp(...) @ device.c / 3809 fixme:d3d:IWineD3DDeviceImpl_SetRenderState 500 from glStencilOp(...) @ device.c / 3809 fixme:d3d:IWineD3DDeviceImpl_SetRenderState 500 from glStencilOp(...) @ device.c / 3809 There are also in the upper-middle of the log file many : fixme:d3d:IWineD3DDeviceImpl_EvictManagedResources (0x4d290020) : stub Hope this can help a bit My command line to launch the games is : wine "E:/toph/games/GUILD WARS/Gw.exe" 2gw.wine I use win98 version per default because sometimes with win2k i have some ntdll errors when connecting to internet(areanet). I don't use anything else. I try display by hardware or emulation, with simple or double buffer, in a window or in directly, with pixel shader or not, but nothing works. Per default, my screen is 1024*768*24bits Note that tuxracer (or ppracer) works so i don't think it comes from the driver, but i can make mistakes... Instead of changing my graphic card for an nvidia one, is there a solution to play guild wars ? I know cvscedega but i want to use wine (because it's fully free). I'm not a developer but i want to contribute to the project as i can. And trying to found accurately problems, i think, is the little thing i can do for wine project. Thanks in advance for your help :-) BONNEL Christophe
Re: new to wine, Guild Wars don't display correctly
Am Freitag, 31. März 2006 09:12 schrieb BONNEL Christophe: Hi everyone, Sorry in advance not to know where to post, but I'm new to wine. It would be better to post requests like this to [EMAIL PROTECTED] First of all, I'm under debian stable and i'm using the debian package wine_0.9.10~winehq1-2_i386.deb. My kernel is 2.6.8 and my graphic card is an ati radeon 9000pro (I know ...ouch...) The fglrx driver you mentioned doesn't work any more on those cards. PPracer has problems too: Start the Doing course. Head to the yellow arrows on the left. They will disapper when you come really close. So i first try with the dri driver and , although my 3D was ok(openGL1.2 it seems), it was too slow to be playable and my mouse didn't appear. So it basically worked with the open source driver? So i use now the official ati last driver(openGL 1.3 it seems). Now, most of the images doesn't appear. If you know guild wars, in the login screen, i have only rocks, the background image behind rocks and the window for login in front of rocks don't appear. You hit the bug ati introduced with 8.19.10. I think it's related to opengl display lists, and I've reported it to ati months ago. Didn't get a reply so far I can send you the lasts many fixmes that appears but for some seconds, i have approximatively 1Mo file. However, i have no err. The lasts line are : fixme:d3d:IWineD3DDeviceImpl_SetRenderState (0x4d290020)-(190,15) not handled yet fixme:d3d:IWineD3DDeviceImpl_SetRenderState (0x4d290020)-(191,15) not handled yet fixme:d3d:IWineD3DDeviceImpl_SetRenderState (0x4d290020)-(192,15) not handled yet fixme:d3d:IWineD3DDeviceImpl_SetRenderState (0x4d290020)-(193,-1) not handled yet fixme:d3d:IWineD3DDeviceImpl_SetRenderState (0x4d290020)-(194,0) not handled yet fixme:d3d:IWineD3DDeviceImpl_SetRenderState (0x4d290020)-(198,0) not handled yet fixme:d3d:IWineD3DDeviceImpl_SetRenderState (0x4d290020)-(199,0) not handled yet fixme:d3d:IWineD3DDeviceImpl_SetRenderState (0x4d290020)-(200,0) not handled yet fixme:d3d:IWineD3DDeviceImpl_SetRenderState (0x4d290020)-(201,0) not handled yet fixme:d3d:IWineD3DDeviceImpl_SetRenderState (0x4d290020)-(202,0) not handled yet fixme:d3d:IWineD3DDeviceImpl_SetRenderState (0x4d290020)-(203,0) not handled yet fixme:d3d:IWineD3DDeviceImpl_SetRenderState (0x4d290020)-(204,0) not handled yet fixme:d3d:IWineD3DDeviceImpl_SetRenderState (0x4d290020)-(205,0) not handled yet fixme:d3d:IWineD3DDeviceImpl_SetRenderState (0x4d290020)-(206,0) not handled yet fixme:d3d:IWineD3DDeviceImpl_SetRenderState (0x4d290020)-(207,2) not handled yet fixme:d3d:IWineD3DDeviceImpl_SetRenderState (0x4d290020)-(208,1) not handled yet fixme:d3d:IWineD3DDeviceImpl_SetRenderState (0x4d290020)-(209,1) not handled yet fixme:d3d:IWineD3DDeviceImpl_SetRenderState (0x4d290020)-(162,-1) not handled yet fixme:d3d:IWineD3DDeviceImpl_SetRenderState (0x4d290020)-(163,0) not handled yet fixme:d3d:IWineD3DDeviceImpl_SetRenderState (0x4d290020)-(164,1065353216) not handled yet fixme:d3d:IWineD3DDeviceImpl_SetRenderState (0x4d290020)-(165,1) not handled yet fixme:d3d:IWineD3DDeviceImpl_SetRenderState (0x4d290020)-(172,3) not handled yet fixme:d3d:IWineD3DDeviceImpl_SetRenderState (0x4d290020)-(173,1) not handled yet fixme:d3d:IWineD3DDeviceImpl_SetRenderState (0x4d290020)-(178,1065353216) not handled yet fixme:d3d:IWineD3DDeviceImpl_SetRenderState (0x4d290020)-(179,1065353216) not handled yet fixme:d3d:IWineD3DDeviceImpl_SetRenderState (0x4d290020)-(180,0) not handled yet fixme:d3d:IWineD3DDeviceImpl_SetRenderState (0x4d290020)-(181,0) not handled yet fixme:d3d:IWineD3DDeviceImpl_SetRenderState (0x4d290020)-(182,1065353216) not handled yet fixme:d3d:IWineD3DDeviceImpl_SetRenderState (0x4d290020)-(183,0) not handled yet fixme:d3d:IWineD3DDeviceImpl_SetRenderState (0x4d290020)-(184,0) not handled yet fixme:d3d:IWineD3DDeviceImpl_SetRenderState 500 from glStencilOp(...) @ device.c / 3809 fixme:d3d:IWineD3DDeviceImpl_SetRenderState 500 from glStencilOp(...) @ device.c / 3809 fixme:d3d:IWineD3DDeviceImpl_SetRenderState 500 from glStencilOp(...) @ device.c / 3809 These are harmless, they are fixmes from the direct3d initialization. Some render states aren't supported by wines d3d implementation, but when wined3d initializes, it sets them to the default value, which causes such messages. The last three fixmes are fixed in the current cvs version, and they are harmless too. There are also in the upper-middle of the log file many : fixme:d3d:IWineD3DDeviceImpl_EvictManagedResources (0x4d290020) : stub EvictManagedTextures is a windows-related video memory management thing, and it won't have much impact too. If it has, then it will only show slightly reduced performance for a few secounds after loading. It should remove the managed textures from the video card, to make the memory free for new textures. Hope this can help a bit My command line to launch
Re: new to wine, Guild Wars don't display correctly
On 31/03/06, Stefan Dösinger [EMAIL PROTECTED] wrote: fixme:d3d:IWineD3DDeviceImpl_SetRenderState 500 from glStencilOp(...) @ device.c / 3809 fixme:d3d:IWineD3DDeviceImpl_SetRenderState 500 from glStencilOp(...) @ device.c / 3809 fixme:d3d:IWineD3DDeviceImpl_SetRenderState 500 from glStencilOp(...) @ device.c / 3809 These are harmless, they are fixmes from the direct3d initialization. Some render states aren't supported by wines d3d implementation, but when wined3d initializes, it sets them to the default value, which causes such messages. The last three fixmes are fixed in the current cvs version, and they are harmless too. Unfortunately, no, that's not fixed yet. I suspect the problem is the three glGetIntegerv call slightly above that call, since they use constants only defined in OpenGL 2.0.
