Re: Game engines and wine
Am 14.02.2010 um 05:26 schrieb Dan Kegel: The two main commercial ones with freely downloadable SDKs that I know about are Unity3D ( http://appdb.winehq.org/objectManager.php?sClass=versioniId=19268 ) and Unreal ( Unreal's UDK requires .net 3.5, so it can't be installed at the moment ). There are two issues here: One is supporting the products of the game engine, and supporting the game builder itself. It's like supporting apps compiled by visual studio 2008 versus supporting Visual Studio 2008 itself. I don't know about Unity3D, but Unreal 3 is basically working, although it is slow(in dx9, not dx10). Luckily we don't need .NET to run the games :-/ That said, supporting the build tools themselves might be useful for Wine development purposes. When I worked on the DirectX SDK samples I sometimes recompiled some samples to test a few things.
Wine HQ Down?
Greetings: Cannot connect to www.winehq.org this morning. Scheduled downtime or did the site drop again? James McKenzie
Re: Game engines and wine
On Sun, Feb 14, 2010 at 2:39 AM, Stefan Dösinger stefandoesin...@gmx.at wrote: There are two issues here: One is supporting the products of the game engine, and supporting the game builder itself. It's like supporting apps compiled by visual studio 2008 versus supporting Visual Studio 2008 itself. Exactly. I don't know about Unity3D, but Unreal 3 is basically working, although it is slow(in dx9, not dx10). Luckily we don't need .NET to run the games :-/ :-) That said, supporting the build tools themselves might be useful for Wine development purposes. When I worked on the DirectX SDK samples I sometimes recompiled some samples to test a few things. Yeah, having the build tools running on Wine is a very nice to have, not a must. It's a developer convenience thing, both for us and for the game developers. The less they have to switch between two operating systems to get their work done, the more time they'll spend developing, testing, and believing in Wine. - Dan
Re: oldconfig.c: produce DEVICEMAP//SERIALCOMM entries
Detlef Riekenberg wrote: On Fr, 2010-02-12 at 13:00 +0100, Alexandre Julliard wrote: A C Hurst a.hu...@sheffield.ac.uk writes: Fixes bug 11811 [http://bugs.winehq.org/show_bug.cgi?id=11811] and its duplicates. This patch sent some time back (over a year) was ignored/lost in noise. Could someone review please? this belongs in mountmgr, and should be based on the actual devices as reported by HAL. - HAL is deprecated / in maintenance mode http://www.freedesktop.org/wiki/Software/hal - DeviceKit is a set of projects to replace HAL http://www.freedesktop.org/wiki/Software/DeviceKit The daemon is libudev and the userspace tools where renamed to udisks: http://lists.freedesktop.org/archives/devkit-devel/2009-December/000567.html The question now lies in if the Mac porting projects will get libudev to build and be functional on MacOSX 10.4+. libhal was not, and probably never will be because of the architecture. Today, the updates for Ubuntu 10.04 replaced devicekit-disks-doc with udisks-doc. - HAL Migration path: http://wiki.ubuntu.com/Halsectomy http://wiki.debian.org/HALRemoval Great. Time to do some reading James McKenzie
Re: Intercepting GDI calls
Charles Davis wrote: Jui-Hao Chiang wrote: Hi, all: I am currently starting a project which tries to run a window application on one (source) machine, and display on another (destination) machine. Of course, the VNC or X11 forwarding technique can achieve the same goal, but I am trying to reduce the bandwidth by not transferring the video frame buffer but transfer the GDI function calls instead. Uhhh... That's kinda how X11 works. I mean, sending drawing and windowing calls as opposed to transferring the entire FB. What do you hope to accomplish with this? Given what I just told you, why won't X11 suffice? X11 on a Mac is cumbersome. X11 on Windows is a real pain (I know I work with it on a daily basis) and is downright butt ugly. Opening a new window in Wine or Windows is more desirable. Maybe this can be expanded to support Aqua/Cocoa on MacOSX. I'll agree that this is duplication of the existing X11 code, but the effect is more pleasant to the eye and leads to less user confusion, not to speak of a less expensive solution (I have yet to find a 'free' X11 client that is worth anything on Windows.) One final comment: X11 is the defacto windowing system for Linux/Unix, but let's not forget that the target audience may be any desktop system, Linux/UNIX, MacOSX, Free/OpenBSD, Solaris, and Windows. Thus the built solution should support all of these as close to the Native interface as possible. James McKenzie
Re: Intercepting GDI calls
On 12 February 2010 06:11, Jui-Hao Chiang windtracek...@gmail.com wrote: I am currently starting a project which tries to run a window application on one (source) machine, and display on another (destination) machine. Of course, the VNC or X11 forwarding technique can achieve the same goal, but I am trying to reduce the bandwidth by not transferring the video frame buffer but transfer the GDI function calls instead. The way I can see is try to intercept all the calls inside gdi32.dll, and forward the calls and parameters to remote machine by using some RPC library, and then replay the GDI calls on the destination machine. Sounds like you're actually trying to reproduce Citrix or Tarantella. (Which do rather better than X11 in many ways.) Not that I have useful advice on doing so ... - d.
Re: Intercepting GDI calls
On Sun, Feb 14, 2010 at 6:31 PM, David Gerard dger...@gmail.com wrote: On 12 February 2010 06:11, Jui-Hao Chiang windtracek...@gmail.com wrote: I am currently starting a project which tries to run a window application on one (source) machine, and display on another (destination) machine. Of course, the VNC or X11 forwarding technique can achieve the same goal, but I am trying to reduce the bandwidth by not transferring the video frame buffer but transfer the GDI function calls instead. The way I can see is try to intercept all the calls inside gdi32.dll, and forward the calls and parameters to remote machine by using some RPC library, and then replay the GDI calls on the destination machine. Sounds like you're actually trying to reproduce Citrix or Tarantella. (Which do rather better than X11 in many ways.) Not that I have useful advice on doing so ... In the Wine design this would be very, very inefficient. The main issue is that we lack a DIB engine and due to that we forward those calls to X11 and then read the result back. In case of plain remote rendering this would be very inefficient. In case of Wine you might want something like a local framebuffer which you somehow sync with a remote one... First experiment with NX though but it might suffer from these performance issues. Roderick
Re: recent winmm/midimap tests
Saulius Krasuckas schrieb: Hi folks is it only me getting short midi-like sounds during non-interactive run of Winetest, or is this known new bug already? S. AFAIK its by design of the new tests, its seems we cant get around it. -- Best Regards, André Hentschel
Wine without X? Failing in dlls/winex11.drv
Trying to build Wine on a new tester which initially had too few packages installed I ran into the following. In file included from bitblt.c:33: x11drv.h:30:22: error: X11/Xlib.h: No such file or directory x11drv.h:31:27: error: X11/Xresource.h: No such file or directory x11drv.h:32:23: error: X11/Xutil.h: No such file or directory x11drv.h:33:23: error: X11/Xatom.h: No such file or directory x11drv.h:44:21: error: X11/Xmd.h: No such file or directory x11drv.h:45:24: error: X11/Xproto.h: No such file or directory Indeed include/config.h has HAVE_X11_XLIB_H undefined since, well, all these headers indeed are missing. On the other hand, configure did not halt. In fact, configure did not even warn about this situation unlike it does in other cases. How to fix this? Should dlls/winex11.drv just not be built in such a case? Should configure error out? (We do have --without-x, too, though.) Anything else? Currently we do pass configure and then run into a compile failure later on. Gerald
Re: Wine without X? Failing in dlls/winex11.drv
Gerald Pfeifer ger...@pfeifer.com writes: How to fix this? Should dlls/winex11.drv just not be built in such a case? Should configure error out? (We do have --without-x, too, though.) Anything else? Currently we do pass configure and then run into a compile failure later on. It's definitely supposed to fail in configure. That's handled by the standard autoconf built-in check for X. Please try to figure out why it doesn't catch that case. -- Alexandre Julliard julli...@winehq.org
Re: Wine without X? Failing in dlls/winex11.drv
Gerald Pfeifer wrote: Trying to build Wine on a new tester which initially had too few packages installed I ran into the following. Gerald: Please take time to read through the remainder of the posts here, even though you've been here for a while. It is NOT possible to build Wine without some sort of X on the build computer right now. It would be great if --without-x did work throughly. Are you willing to fix this? James McKenzie
Current status of XI2 mouse stuff now that Lucid Lynx includes XI2?
I recall that Paul Hampson did a first cut at using XI2, linked to from the bottom of http://wiki.winehq.org/DInput, and http://wiki.winehq.org/Bug6971 says the new XInput2 X11 extension (which is part of XOrg 7.5) provides relative mouse motion events. Once this extension is more common, we will be able to fix Wine properly. Well, here it is, and XI2 is said to be included in Ubuntu Lucid Lynx Alpha 2; so it's about to get a lot more common. Has anybody tried it out lately? What's Paul's status? Incidentally, I just noticed a page about how somebody made the transition to XI2 on another project, see http://www.clearchain.com/blog/posts/xinput-1-xinput-2-conversion-guide - Dan
Re: Current status of XI2 mouse stuff now that Lucid Lynx includes XI2?
On 15 February 2010 11:13, Dan Kegel d...@kegel.com wrote: I recall that Paul Hampson did a first cut at using XI2, linked to from the bottom of http://wiki.winehq.org/DInput, and http://wiki.winehq.org/Bug6971 says the new XInput2 X11 extension (which is part of XOrg 7.5) provides relative mouse motion events. Once this extension is more common, we will be able to fix Wine properly. Well, here it is, and XI2 is said to be included in Ubuntu Lucid Lynx Alpha 2; so it's about to get a lot more common. For us non-Ubuntu users, what xorg stable version has XI2? Has anybody tried it out lately? What's Paul's status? Incidentally, I just noticed a page about how somebody made the transition to XI2 on another project, see http://www.clearchain.com/blog/posts/xinput-1-xinput-2-conversion-guide - Dan
Re: Current status of XI2 mouse stuff now that Lucid Lynx includes XI2?
On Sun, Feb 14, 2010 at 4:46 PM, Ben Klein shackl...@gmail.com wrote: On 15 February 2010 11:13, Dan Kegel d...@kegel.com wrote: I recall that Paul Hampson did a first cut at using XI2, linked to from the bottom of http://wiki.winehq.org/DInput, and http://wiki.winehq.org/Bug6971 says the new XInput2 X11 extension (which is part of XOrg 7.5) provides relative mouse motion events. Once this extension is more common, we will be able to fix Wine properly. Well, here it is, and XI2 is said to be included in Ubuntu Lucid Lynx Alpha 2; so it's about to get a lot more common. For us non-Ubuntu users, what xorg stable version has XI2? http://www.x.org/wiki/Releases/7.5 - Dan
