Roderick Colenbrander gmx.net> writes:
>
> > > Second the required 3d functionality is VERY limited. Basicly the
> only
> > > thing the videocard needs support is texturing which all cards do.
> >
> > But that's obviously wrong - the video *driver* also needs to support
> it.
> > And the
> > Second the required 3d functionality is VERY limited. Basicly the
only
> > thing the videocard needs support is texturing which all cards do.
>
> But that's obviously wrong - the video *driver* also needs to support
it.
> And the current 3D video driver situation in Linux is horrible.
>
> --- Ursprüngliche Nachricht ---
> Von: Molle Bestefich <[EMAIL PROTECTED]>
> An: Jesse Allen <[EMAIL PROTECTED]>
> Kopie: Roderick Colenbrander <[EMAIL PROTECTED]>,
> wine-devel@winehq.org
> Betreff: Re: DirectDraw over Direct3D
> Datum: Thu, 15 Dec 200
Molle Bestefich schrieb:
> The patch is fine and all, but if I'm right and there's a lot of
people using OS drivers that doesn't support the features needed (thus
making performance worse), this patch should be optional and not
replace the current working stuff..
as far as I understood it this p
On 12/15/05, Molle Bestefich <[EMAIL PROTECTED]> wrote:
> Jesse Allen wrote:
> > > The current state of open source video drivers for Linux is as far as
> > > I know that they only do basic 2D. For 3D you have to use
> > > closed-source drivers, which is simply not an option for a lot of
> > > peo
Jesse Allen wrote:
> > The current state of open source video drivers for Linux is as far as
> > I know that they only do basic 2D. For 3D you have to use
> > closed-source drivers, which is simply not an option for a lot of
> > people, be that because of stability, compatability or other issues.
On 12/15/05, Molle Bestefich <[EMAIL PROTECTED]> wrote:
> Roderick Colenbrander wrote:
> > For old videocards the GL renderer won't work and the
>
> The current state of open source video drivers for Linux is as far as
> I know that they only do basic 2D. For 3D you have to use
> closed-source dri
Roderick Colenbrander wrote:
> For old videocards the GL renderer won't work and the
The current state of open source video drivers for Linux is as far as
I know that they only do basic 2D. For 3D you have to use
closed-source drivers, which is simply not an option for a lot of
people, be that be
--- Aric Cyr <[EMAIL PROTECTED]> wrote:
> Raphael club-internet.fr> writes:
>
> >
> > On Tuesday 13 December 2005 09:28, Stefan Dösinger wrote:
> > > Am Dienstag, 13. Dezember 2005 04:25 schrieb Aric Cyr:
> > > > What is slow with ATI cards? It seems that you should only need basic
> > > > 3
Raphael club-internet.fr> writes:
>
> On Tuesday 13 December 2005 09:28, Stefan Dösinger wrote:
> > Am Dienstag, 13. Dezember 2005 04:25 schrieb Aric Cyr:
> > > What is slow with ATI cards? It seems that you should only need basic 3D
> > > acceleration to do what you propose. Is fglrx missing
On Tuesday 13 December 2005 21:43, Mike Hearn wrote:
> On Mon, 12 Dec 2005 21:11:44 +0100, Stefan Dösinger wrote:
> > In Wine, there are 2 ways: The first is to use X calls, which is safe,
> > but slow.
>
> What makes you think that? X drawing primitives as well as XRender should
> be hardware acc
On Mon, 12 Dec 2005 21:11:44 +0100, Stefan Dösinger wrote:
> In Wine, there are 2 ways: The first is to use X calls, which is safe, but
> slow.
What makes you think that? X drawing primitives as well as XRender should
be hardware accelerated even though they aren't OpenGL.
On Tuesday 13 December 2005 09:28, Stefan Dösinger wrote:
> Am Dienstag, 13. Dezember 2005 04:25 schrieb Aric Cyr:
> > What is slow with ATI cards? It seems that you should only need basic 3D
> > acceleration to do what you propose. Is fglrx missing something that
> > would be required for 2D ren
> > What is slow with ATI cards? Â It seems that you should only need basic
> 3D
> > acceleration to do what you propose. Â Is fglrx missing something that
> would
> > be required for 2D rendering?
> Texture upload is very slow. glReadPixels, glWritePixels and friends take
> ages. That means tha
Am Dienstag, 13. Dezember 2005 04:25 schrieb Aric Cyr:
> What is slow with ATI cards? It seems that you should only need basic 3D
> acceleration to do what you propose. Is fglrx missing something that would
> be required for 2D rendering?
Texture upload is very slow. glReadPixels, glWritePixels a
Stefan Dösinger gmx.at> writes:
> least write access to /dev/mem, which is a HORRIBLE security risk. That's
> were OpenGL comes into play: It is hardware accellerated, and doesn't
> require /dev/mem access. But the drawback is, that it needs a 3D
> accellerator, and a decent driver. It works f
Hello,
> Following your mail on wine-devel about DDRAW, I now understand better
> what's going on behind the scenes. Below is the result of an experiment I
> did at the beginning of this month. Reading your message, I wanted to share
> it with you.
First, thanks for your comments, and one suggestio
TA 1.0 (fresh off the CD) also wouldn't start for me, however, after
installing the v3.1c patch (the last one ever released) it started up
just fine.
--tim
On 12/6/05, James Liggett <[EMAIL PROTECTED]> wrote:
> I fired up Total Annihilation just yesterday with Wine 0.9.2 and it
> > was very slow.
On 12/5/05, Roderick Colenbrander <[EMAIL PROTECTED]> wrote:
>
> Atleast on my system StarCraft was really unplayable while the game is
> supposed to run on a 20x slower system (pentium90). Perhaps the problem is
> video driver related as I think the issues are less severe for Ati users.
> (thought
Lionel Ulmer schrieb:
> On Mon, Dec 05, 2005 at 10:22:23PM +0100, Peter Beutner wrote:
>
>>Isn't indirect rendering always unaccelerated, i.e. done in software?
>
>
> Nope. Indirect means only that all your OpenGL commands are encapsuled into
> GLX commands and then serialized over the X network
> Well, we can first stabilize D3D7 => WineD3D (which will already be quite a
> lot of work to first do and then polish) and then see if we move the 2D
> part too.
Moving both 2D and D3D7 at the same time would make the handling of D3D7
surfaces easier. At the moment, I have overrides for
IDirect
On Mon, Dec 05, 2005 at 10:22:23PM +0100, Peter Beutner wrote:
> Isn't indirect rendering always unaccelerated, i.e. done in software?
Nope. Indirect means only that all your OpenGL commands are encapsuled into
GLX commands and then serialized over the X network link (which could be a
local Unix s
> How about moving the current 2D code to WineD3D, and making DDraw running
> over
> WineD3D in any case. Then WineD3D could decide wether to use plain X11, DGA
> or OpenGL for 2D rendering. :)
That basically bows down to have WineD3D completely replace the 'HAL'
architecture which was introduc
Lionel Ulmer schrieb:
> On Sun, Dec 04, 2005 at 07:27:29PM -0700, Jesse Allen wrote:
>>This patch seems similar to glSDL where it wraps SDL's 2d API to
>>OpenGL. The good thing about this it can provide acceleration and not
>>require root like DGA. The bad thing with this idea is that it can't
>>b
Am Montag, 5. Dezember 2005 21:10 schrieb Lionel Ulmer:
> On Mon, Dec 05, 2005 at 08:17:38AM +0100, Stefan Dösinger wrote:
> > I hope I can come up with a patch for testing this week, then we can have
> > a look ;)
>
> I think that to merge Roderick's and your patch, the best would be to
> directly
On Sun, Dec 04, 2005 at 07:27:29PM -0700, Jesse Allen wrote:
> Is Starcraft really that slow? How does this compare with using DGA?
Nothing can beat DGA (actually DGA2 as you would need depth change to go to
8 bit colours to run StarCraft) in raw speed as it is the method which does
copy the les
On Mon, Dec 05, 2005 at 08:17:38AM +0100, Stefan Dösinger wrote:
> I hope I can come up with a patch for testing this week, then we can have a
> look ;)
I think that to merge Roderick's and your patch, the best would be to
directly hook WineD3D even at the 2D level and not have DDraw hook DDraw's
> This patch seems similar to glSDL where it wraps SDL's 2d API to
> OpenGL. The good thing about this it can provide acceleration and not
> require root like DGA. The bad thing with this idea is that it can't
> be used on older video cards or even some newer ones that lack proper
> direct render
Am Montag, 5. Dezember 2005 07:48 schrieb Roderick Colenbrander:
> The patch can make TA a lot faster the problem is that the game crashes
> because it becomes multithreaded. Command&Conquer (which crashes when you
> move the mouse) felt a lot faster, further StarCraft is a lot faster too.
> When t
Hi,
> Is Starcraft really that slow? How does this compare with using DGA?
> I'm not too sure because its speed vaires. I've been testing
> Starcraft this weekend and it has been plenty speedy. But I do
> remember when trying to play it multiplayer a few months ago and was
> burned when it r
The patch can make TA a lot faster the problem is that the game crashes
because it becomes multithreaded. Command&Conquer (which crashes when you
move the mouse) felt a lot faster, further StarCraft is a lot faster too.
When the multithreading issue is over TA will most likely be playable on
your s
> Is Starcraft really that slow? How does this compare with using DGA?
> I'm not too sure because its speed vaires. I've been testing
> Starcraft this weekend and it has been plenty speedy. But I do
> remember when trying to play it multiplayer a few months ago and was
> burned when it ran sl
On 12/4/05, Roderick Colenbrander <[EMAIL PROTECTED]> wrote:
> Hi,
>
> As you all might know 2d games tend to be slow on Wine. For a lot of games the
> main bottleneck is depth conversion which happens in cases when the depth
> requested by the game and the X desktop color are not the same.
>
> As
Hi,
As you all might know 2d games tend to be slow on Wine. For a lot of games the
main bottleneck is depth conversion which happens in cases when the depth
requested by the game and the X desktop color are not the same.
As a way to speedup 2d Lionel assisted me with hacking wine's ddraw to let
34 matches
Mail list logo
