Reece Dunn a écrit :
1/ the games themselves tend to work very well (and have done for a
long while now thanks to the great work CodeWeavers did in getting
DirectDraw and Direct3D working);
While you are at in, you can also thanks people that worked in this area
in their spare time.
A+
2010/1/6 Christian Costa titan.co...@wanadoo.fr:
Reece Dunn a écrit :
1/ the games themselves tend to work very well (and have done for a
long while now thanks to the great work CodeWeavers did in getting
DirectDraw and Direct3D working);
While you are at in, you can also thanks people
Reece Dunn a écrit :
2010/1/6 Christian Costa titan.co...@wanadoo.fr:
Reece Dunn a écrit :
1/ the games themselves tend to work very well (and have done for a
long while now thanks to the great work CodeWeavers did in getting
DirectDraw and Direct3D working);
While you are at
whoops, sending to list as well!
-- Forwarded message --
From: David Gerard dger...@gmail.com
Date: 2010/1/6
Subject: Re: The (Casual) Game Support Report in Wine (Jan 2009)
To: Reece Dunn mscl...@googlemail.com
2010/1/5 Reece Dunn mscl...@googlemail.com:
2/ the major
2010/1/6 David Gerard dger...@gmail.com:
whoops, sending to list as well!
2010/1/5 Reece Dunn mscl...@googlemail.com:
2/ the major issues appear to be in the application launchers used
by different game providers (most of which are in the current wine
implementation of the IE browser
Hi,
With Dan reporting on the success of Visual C++ 2005, I thought I
would post my findings of various casual (and other) games.
In general, my observations are that:
1/ the games themselves tend to work very well (and have done for a
long while now thanks to the great work CodeWeavers did
Hi,
Perhaps support for more VGA features can increase compatibility of DOS
software on 32-bit hardware. 64-bit users won't be able to run most dos
programs as there is no vm86 support when using a 64-bit kernel. In the end we
need x86 emulation..
Roderick
Hey, that CGA video support patch
Perhaps support for more VGA features can increase compatibility of DOS
software on 32-bit hardware. 64-bit users won't be able to run most dos
programs as there is no vm86 support when using a 64-bit kernel. In the
end we need x86 emulation..
Dosemu (not dosbox) works nice here on my 64 bit
On Sun, 2008-10-19 at 20:56 -0700, Dan Kegel wrote:
Hey, that CGA video support patch today from Peter Dons Tychsen,
http://winehq.org/pipermail/wine-patches/2008-October/063417.html
reminded me there's an old downloadable DOS game my wife likes
to dig out every now and then. I tried it today
Am Montag, den 20.10.2008, 12:36 +0200 schrieb Stefan Dösinger:
Dosemu (not dosbox) works nice here on my 64 bit linux distro. How are they
doing that? Afaics dosemu uses vm86 instead of a full-blown CPU emulation.
Dosemu has a hybrid approach. On x86, vm86 is used. On systems lacking
vm86 (that
Peter Dons Tychsen schrieb:
[...]
I would love to see support for games like paratrooper and police
quest.
don't they work in DOS-Box?
bye Jochen
Jochen wrote:
I would love to see support for games like paratrooper and
police quest.
don't they work in DOS-Box?
We would like to get to the point where users
don't have to wonder which tool to use to run .exe's with.
i.e. it would be nice if we could just map .exe's to
Wine in the desktop.
On Monday 20 October 2008 02:14:41 pm Jochen Theodorou wrote:
don't they work in DOS-Box?
I know Daggerfall doesn't work all that great in DOSBox (it's a heavy effort
in tweaking to get the videos to play at the right speed, and that usually
causes the game to play like crap, and
Don't forget the .com files those wonderful real-mode 64K wonders...
I noticed that the distros do not map .com files to wine.
They probably should.
/p
On Mon, 2008-10-20 at 16:18 -0700, Dan Kegel wrote:
Jochen wrote:
I would love to see support for games like paratrooper and
police
Hey, that CGA video support patch today from Peter Dons Tychsen,
http://winehq.org/pipermail/wine-patches/2008-October/063417.html
reminded me there's an old downloadable DOS game my wife likes
to dig out every now and then. I tried it today and discovered
that what's stopping it is support for a
From what I can see, the culprit would be this :
trace:opengl:X11DRV_SwapBuffers (0x403d55e0)
trace:opengl:wglMakeCurrent ((nil),(nil))
X Error of failed request: GLXBadDrawable
As the glXSwapBuffers call may return before the buffer swap is actually
done in hardware, it may happen that the
Lionel Ulmer wrote:
I did the +opengl trace, but it comes to about 16MB! Is there
something specific you are looking for that I could grep for?
As Mike said, Wine traces compress REALLY well with gzip or bzip2. After,
once it gets into a manageable state, you could either upload it somewhere
for
Sorry, meant to send this to the list first time around...
But I narrowed it down to 3 Wine calls in the
critical loop: SetEvent, WaitForSingleObject and ResetEvent.
I tried wrapping each of these functions with
__asm__(pushfl\n); at the start and __asm__(popfl\n); at
the end to preserve the
Thanks for the responses, and sorry for the late reply (real
life has been limiting my hacking time...)
glXMakeCurrent(default_display, None, NULL)
If you could do a non-wine test case for that and see if it's just a buggy
driver, that'd be good.
It turns out not to be as simple as that. I did a
1. MusicVR exits with this error:
Could you send me a +opengl trace of the problem ? Maybe the game is done
some strange things (like doing a SwapBuffer without a rendering context set
or stuff like that) which are OK on Windows and not on Linux.
I did the +opengl trace, but it comes to about
On Tue, 06 Apr 2004 09:29:05 +0100, James Perry wrote:
I did the +opengl trace, but it comes to about 16MB! Is there
something specific you are looking for that I could grep for?
bzip2 destroys Wine traces. 16mb is nothing compared to the multi-gig logs
we sometimes deal with around here ;)
On Tue, 06 Apr 2004 09:23:45 +0100, James Perry wrote:
It's difficult to trace properly as PECrypt has debugger
detection and behaves oddly if it detects breakpoints or
whatever. But I narrowed it down to 3 Wine calls in the
critical loop: SetEvent, WaitForSingleObject and ResetEvent.
I tried
On Tue, Apr 06, 2004 at 09:23:45AM +0100, James Perry wrote:
Thanks for the responses, and sorry for the late reply (real
life has been limiting my hacking time...)
glXMakeCurrent(default_display, None, NULL)
If you could do a non-wine test case for that and see if it's just a buggy
Mike Hearn wrote:
On Tue, 06 Apr 2004 09:29:05 +0100, James Perry wrote:
I did the +opengl trace, but it comes to about 16MB! Is there
something specific you are looking for that I could grep for?
bzip2 destroys Wine traces. 16mb is nothing compared to the multi-gig logs
we sometimes deal
I did the +opengl trace, but it comes to about 16MB! Is there
something specific you are looking for that I could grep for?
As Mike said, Wine traces compress REALLY well with gzip or bzip2. After,
once it gets into a manageable state, you could either upload it somewhere
for me to download it
btw, are there already any automated tools for parsing Wine logs?
There is the examine-relay perl script in the tools directory, but it's only for
relay traces.
Ivan.
Hi everyone,
I've been following Wine development for a while but
now I think it's time to contribute something. I don't
use Windows anymore (except for PowerPoint at work),
but I decided it would be good to be able to play some
games on Linux. So I grabbed Wine from CVS, compiled it
up and
1. MusicVR exits with this error:
X Error of failed request: GLXBadDrawable
Major opcode of failed request: 145 (GLX)
Minor opcode of failed request: 11 (X_GLXSwapBuffers)
Serial number of failed request: 10522
Current serial number in output stream: 10523
I traced it
28 matches
Mail list logo
