2010/1/6 David Gerard :
> whoops, sending to list as well!
>
> 2010/1/5 Reece Dunn :
>
>> 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 ActiveX control);
>
> Curious ques
whoops, sending to list as well!
-- Forwarded message --
From: David Gerard
Date: 2010/1/6
Subject: Re: The (Casual) Game Support Report in Wine (Jan 2009)
To: Reece Dunn
2010/1/5 Reece Dunn :
> 2/ the major issues appear to be in the application launchers used
&
Reece Dunn a écrit :
2010/1/6 Christian Costa :
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 thank
2010/1/6 Christian Costa :
> 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
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+
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 in
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
> >> "
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 vice-versa..)
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
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
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 to
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 (tha
> 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 bi
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
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 driver
On Wed, Apr 07, 2004 at 10:09:30AM +0100, James Perry wrote:
> OK, thanks for the suggestions. It's online now at
>
> http://www.epcc.ed.ac.uk/~jamesp/gltrace.txt.bz2
>From what I can see, the culprit would be this :
trace:opengl:X11DRV_SwapBuffers (0x403d55e0)
trace:opengl:wglMakeCurrent ((nil)
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
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
> 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.
> 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
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 sometime
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 bu
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 t
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 ;)
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 16MB
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:
>
> 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 tra
On Mon, 29 Mar 2004 11:37:46 +0100, James Perry wrote:
> I traced it to the line:
>
> glXMakeCurrent(default_display, None, NULL)
>
> in dlls/opengl32/wgl.c. My OpenGL (nVidia) doesn't
> seem to like the drawable being set to None, although
> according to the GLX docs, this should be OK. Simply
>
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 tested
30 matches
Mail list logo