On Sun, Oct 30, 2005 at 02:15:56PM +0100, Stefan Dösinger wrote:
> However, I'd
> suggest a software implementation for DX7 as a fallback for cards which don't
> have shaders and cards which don't have the necessary extensions.
Well, if you go this way, that means writing an almost complete (exce
An update to the drawStridedSlow thing: With my a little bit less senseless
ProcessVertices implementation, the framerate increased from 1.5 fps to 4.5
fps([EMAIL PROTECTED] Mhz) and from 2 fps to 6 fps ([EMAIL PROTECTED] mhz). So
I guess it's
the garbage I am sending to drawPrimitives that mak
Hello,
> It may be possible to use the feedback buffer and get OpenGL to do all the
> work
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/opengl/glf
>unc02_3m42.asp.
>
> The majority of the math is fairly simple matrix transforms, OpenGL
> extensions usually have all the math r
--- Stefan Dösinger <[EMAIL PROTECTED]> wrote:
> Hello,
> I think I got the DrawIndexedPrimitiveVB going now(my tracing suggests this),
> and now I've hit ProcessVertices(). As someone mentioned allready, this is a
> complex call, and it isn't implemented in DX7, DX8 or WineD3D.
>
> This call
--- "H. Verbeet" <[EMAIL PROTECTED]> wrote:
> > One other Question: How slow is DrawStridedSlow? WineD3D uses it because of
> > the diffuse ans specular colors. Currently I get only one useable vertex
> > into
> > DrawIndexedPrimitiveVB from ProcessVertices, the other 5 to draw have their
> > va
On Saturday 29 October 2005 13:17, H. Verbeet wrote:
> On the subject of drawStridedSlow / color fixups, something I was
> wondering about is how feasible it would be to use vertex shaders to
> fix the colors. I guess it would require reimplementing pretty much
> the entire fixed function pipeline
Hi,
On Friday 28 October 2005 23:34, Stefan Dösinger wrote:
> Hello,
> I think I got the DrawIndexedPrimitiveVB going now(my tracing suggests
> this), and now I've hit ProcessVertices(). As someone mentioned allready,
> this is a complex call, and it isn't implemented in DX7, DX8 or WineD3D.
The
> One other Question: How slow is DrawStridedSlow? WineD3D uses it because of
> the diffuse ans specular colors. Currently I get only one useable vertex into
> DrawIndexedPrimitiveVB from ProcessVertices, the other 5 to draw have their
> values zeroed. Without drawing anything I get 70 fps(screen r
Hello,
I think I got the DrawIndexedPrimitiveVB going now(my tracing suggests this),
and now I've hit ProcessVertices(). As someone mentioned allready, this is a
complex call, and it isn't implemented in DX7, DX8 or WineD3D.
This call does some Vertex Transformation, and depending on the App's
Hello,
I have read a little bit more into the concept of vertex buffering, and I
wanted to make sure that I've understood everything correctly and ask some
WineD3D questions.
According to some documents I've found on the internet and the description in
the DX7 SDK, the the application uses Vert
--- Stefan Dösinger <[EMAIL PROTECTED]> wrote:
> > Vertex buffers hold arrays of vertex (and possibly other) data, the stride
> > is the size of the vertex + data stucture in bytes.
> Thanks for the explanation :)
>
> Do you know any useable API documentation for Direct3D7? I can't find
> anyt
> Vertex buffers hold arrays of vertex (and possibly other) data, the stride
> is the size of the vertex + data stucture in bytes.
Thanks for the explanation :)
Do you know any useable API documentation for Direct3D7? I can't find anything
on msdn, only some fragments.
--- Stefan Dösinger <[EMAIL PROTECTED]> wrote:
> Hello,
> > I think the best thing to do is to create another function in
> > wined3d/device.c DrawIndexedPrimitiveVB that is based on
> > DrawIndexedPrimitiveUP but either takes a IWineD3DVertexBuffer or has the
> > caller use SetVertexBuffer and t
Hello,
> I think the best thing to do is to create another function in
> wined3d/device.c DrawIndexedPrimitiveVB that is based on
> DrawIndexedPrimitiveUP but either takes a IWineD3DVertexBuffer or has the
> caller use SetVertexBuffer and then call DrawIndexedPrimitiveVB .
>
> e.g.
> IWineD3DDevic
> Applications that are really doing multithreaded 3D rendering are quite
> rare (and the only case I know is just starting with one thread and then
> moving to another while not using the previous one again).
Empire Earth does, contrary to the first impression, more than that. It
switches the th
On Sat, Oct 15, 2005 at 08:44:05PM +0100, Oliver Stieber wrote:
> It may be easier to do in DirectX 7 because of the
> way it manages states.
Well, I wanted first to handle 'special cases' like applications using the
second thread just to do lock / unlock on the buffer or loading textures
(which i
> How about creating a new thread to to all rendering, and make the calls call
> this thread and block until the function's finished? Is this possible?
Yeah, this was another option we discussed (the 'marshalling' option as we
called it :-) ). Was deemed too slow as it would reduce performance of
--- Lionel Ulmer <[EMAIL PROTECTED]> wrote:
> On Sat, Oct 15, 2005 at 08:13:24PM +0100, Oliver Stieber wrote:
> > We could do that, or we could signal the other thread an tell it to release
> > the context which
> > should cut down on the context switching, I'm not sure how easy that would
> >
Am Samstag, 15. Oktober 2005 21:13 schrieb Oliver Stieber:
> --- Lionel Ulmer <[EMAIL PROTECTED]> wrote:
> > On Sat, Oct 15, 2005 at 07:30:34PM +0100, Oliver Stieber wrote:
> > > Add the OpenGL context to the device structure.
> > > Make a per-device critical section.
> > > Whenever a call is made
On Sat, Oct 15, 2005 at 08:59:55PM +0200, Stefan Dösinger wrote:
> Another update before sending: I've used my glXMakeCurrent hack with old
> ddraw, and guess what: Empire Earth brings the main menu up successfully[1].
> It's slow as hell(yes, 2D DIB with those horrible ATI drivers), and it has
On Sat, Oct 15, 2005 at 08:13:24PM +0100, Oliver Stieber wrote:
> We could do that, or we could signal the other thread an tell it to release
> the context which
> should cut down on the context switching, I'm not sure how easy that would be
> to setup (it doesn't
> seem possible using even objec
--- Stefan Dösinger <[EMAIL PROTECTED]> wrote:
> > To have this method work properly, one would have to somehow make
> > 'glXMakeCurrent(NULL)' run in the context of thread A before doing what you
> > did.
>
> [1] Screen shots are allways cool - www.doesi.gmxhome.de/ee-shot.png
You should be a
--- Lionel Ulmer <[EMAIL PROTECTED]> wrote:
> On Sat, Oct 15, 2005 at 07:30:34PM +0100, Oliver Stieber wrote:
> > Add the OpenGL context to the device structure.
> > Make a per-device critical section.
> > Whenever a call is made enter the critical section
> > Then check that the current active c
> To have this method work properly, one would have to somehow make
> 'glXMakeCurrent(NULL)' run in the context of thread A before doing what you
> did.
Threading fun Will be a long study of man pages and windows threading
things I guess.
A wild guess: Remove the context after every function
--- Stefan Dösinger <[EMAIL PROTECTED]> wrote:
> > Wined3d isn't thread safe yet. Threading will cause lots of problems
> > because when you call MakeActive with the OpenGL context it only makes the
> > context active on the current thread so when you switch threads you may be
> > using a differe
On Sat, Oct 15, 2005 at 07:30:34PM +0100, Oliver Stieber wrote:
> Add the OpenGL context to the device structure.
> Make a per-device critical section.
> Whenever a call is made enter the critical section
> Then check that the current active context is the same as the context on the
> device.
> If
On Sat, Oct 15, 2005 at 08:25:18PM +0200, Stefan Dösinger wrote:
> I'll try my wined3d glXMakeCurrent hack on old ddraw, just out of curiosity.
I checked your code you sent in the other part of the thread and it seems
strange... According to the man page:
BadAccess is generated if ctx
--- Lionel Ulmer <[EMAIL PROTECTED]> wrote:
> On Sat, Oct 15, 2005 at 04:58:00PM +0200, Stefan Dösinger wrote:
> > Hello,
> > Just one question about thread safety: The openGL crash I am struggling
> > with
> > seems related to threading:
>
> A, you fell again in the (in)famous multi-threa
Am Samstag, 15. Oktober 2005 20:11 schrieben Sie:
> On Sat, Oct 15, 2005 at 04:58:00PM +0200, Stefan Dösinger wrote:
> > Hello,
> > Just one question about thread safety: The openGL crash I am struggling
> > with seems related to threading:
>
> A, you fell again in the (in)famous multi-threaded
> Wined3d isn't thread safe yet. Threading will cause lots of problems
> because when you call MakeActive with the OpenGL context it only makes the
> context active on the current thread so when you switch threads you may be
> using a different OpenGL context. This also means that wined3d cannot
>
On Sat, Oct 15, 2005 at 04:58:00PM +0200, Stefan Dösinger wrote:
> Hello,
> Just one question about thread safety: The openGL crash I am struggling with
> seems related to threading:
A, you fell again in the (in)famous multi-threaded D3D applications :-)
Alas, for now, this is an unsolved is
--- Stefan Dösinger <[EMAIL PROTECTED]> wrote:
> Hello,
> Just one question about thread safety: The openGL crash I am struggling with
> seems related to threading:
> ---Crash in fglrx---
>
> The nvidia OpenGL implementation crashes in IWineD3DDeviceImpl_Clear, the
> fglrx implementation on th
Hello,
Just one question about thread safety: The openGL crash I am struggling with
seems related to threading:
<~3 lines of debug output from thread 0xb >
000b:trace:ddraw:Main_DirectDrawSurface_Unlock (0x7c8a3910)->Unlock((nil))
000b:trace:d3d_surface:IWineD3DSurfaceImpl_UnlockRect (0x7c8a3
Lionel Ulmer wrote:
On Fri, Oct 14, 2005 at 04:52:37PM +0100, Christian Costa wrote:
Since vertex buffer support is a hack, I think you can use standard
wined3d drawing primitives for the moment.
Well, vertex buffer support is only a hack in the case of 'pre-transformed'
buffers (i.e
--- Stefan Dösinger <[EMAIL PROTECTED]> wrote:
> Hello,
> I have come across a D3D7 call where I need some help with:
> IDirect3DDevice::DrawIndexedPrimitiveVB. The prototype is
> DrawIndexedPrimitiveVB(LPDIRECT3DDEVICE7 iface,
>D3DPRIMITIVETYP
On Fri, Oct 14, 2005 at 04:52:37PM +0100, Christian Costa wrote:
> Since vertex buffer support is a hack, I think you can use standard
> wined3d drawing primitives for the moment.
Well, vertex buffer support is only a hack in the case of 'pre-transformed'
buffers (i.e. if the application transfo
Hi Stefan,
Stefan Dösinger wrote:
Hello,
I have come across a D3D7 call where I need some help with:
IDirect3DDevice::DrawIndexedPrimitiveVB. The prototype is
DrawIndexedPrimitiveVB(LPDIRECT3DDEVICE7 iface,
D3DPRIMITIVETYPE
d3dptPrimitiveT
Hello,
I have come across a D3D7 call where I need some help with:
IDirect3DDevice::DrawIndexedPrimitiveVB. The prototype is
DrawIndexedPrimitiveVB(LPDIRECT3DDEVICE7 iface,
D3DPRIMITIVETYPE
d3dptPrimitiveType,
Hello,
> No idea if any application would actually be really accelerated though.
Well, it didn't help Empire Earth, it broke the intro video(black screen, not
faster), but it showed me a bug in my code.
Stefan
On Thu, Oct 13, 2005 at 07:31:09PM +0200, Stefan Dösinger wrote:
> I always thought this patch was commited to CVS. Must have been mistaken.
Well, will see if doing a patch like that could help in the DirectX code
waiting for merging the DDraw and WineD3D code.
No idea if any application would ac
Hello,
>I've got a hack that should make those kind of blits faster.
>http://www.winehq.org/pipermail/wine-patches/2005-September/020829.html
I always thought this patch was commited to CVS. Must have been mistaken.
Stefan
--- Stefan Dösinger <[EMAIL PROTECTED]> wrote:
> Hello,
> I've got some real rending working with d3d7 and wined3d: The Empire Earth
> intro movie is playing. Well, it's only a 2D bitblt thing, but anyway.
>
Great, keep up the good work..
> It's terribly slow on my ATI radeon M9, some GL call
Hello,
I've got some real rending working with d3d7 and wined3d: The Empire Earth
intro movie is playing. Well, it's only a 2D bitblt thing, but anyway.
It's terribly slow on my ATI radeon M9, some GL calls take a lot of time, but
it looks correct. A screenshot can be found at
ftp://doesi.gmxho
On Wed, Oct 12, 2005 at 02:23:09PM +0100, Oliver Stieber wrote:
> Some of the code currently falls back to the desktop windows, and it looks
> like the X root windows
> is the desktop window when wine isn't running in desktop mode.
> We should only be using the desktop window if that's what Window
--- Stefan Dösinger <[EMAIL PROTECTED]> wrote:
> Hello,
> > This should be managed by reference counting wherever possible, if ddraw
> > holds a reference to the surface then it won't be released when the device
> > is released.
> I tried to do this, but I ran into problems:
> I have a DirectDraw
Hello,
> This should be managed by reference counting wherever possible, if ddraw
> holds a reference to the surface then it won't be released when the device
> is released.
I tried to do this, but I ran into problems:
I have a DirectDrawSurface, a Direct3D7Device, WineD3DDevice and a
WineD3DSurfa
--- Lionel Ulmer <[EMAIL PROTECTED]> wrote:
> On Tue, Oct 11, 2005 at 10:24:58PM +0200, Stefan Dösinger wrote:
> > WineD3D can't create a device without a Window. For DirectDraw and D3D7
> > running without a Window is valid, at least to a certain extent. The D3D
> > light test does so, and som
--- Stefan Dösinger <[EMAIL PROTECTED]> wrote:
> Hello,
> I am trying again to Implement Direct3D 7 using WineD3D, and I've made some
> progress. The D3D7 Device implementation seems to initialize correctly, with
> the correct surfaces.
> My solution looks like this:
>
> * DirectDraw is u
> > WineD3D can't create a device without a Window. For DirectDraw and D3D7
> > running without a Window is valid, at least to a certain extent. The D3D
> > light test does so, and some games use this for some purposes. So I need
> > to do something for the case HWND == 0 or the d3d surface is not
On Tue, Oct 11, 2005 at 10:24:58PM +0200, Stefan Dösinger wrote:
> WineD3D can't create a device without a Window. For DirectDraw and D3D7
> running without a Window is valid, at least to a certain extent. The D3D
> light test does so, and some games use this for some purposes. So I need to
> do
Hello,
I've got the light test running successfully, but I have a problem and need
your advice:
WineD3D can't create a device without a Window. For DirectDraw and D3D7
running without a Window is valid, at least to a certain extent. The D3D
light test does so, and some games use this for some p
Hello,
> How do you handle the 'special' case Blits (between surface and texture,
> between surfaces, ...) ?
Well, I must admit that I don't have an totally detailed plan, but the DDraw
surface and the WineD3D surface share the same memory area. So those Blits
will be handled by the original Dire
On Mon, Oct 10, 2005 at 12:17:47AM +0200, Stefan Dösinger wrote:
> * WineD3D Surfaces can be attached to DDraw Surfaces, and they receive the
> properties of their parents, including the memory reserved for the surface
How do you handle the 'special' case Blits (between surface and texture,
betwe
Hello,
I am trying again to Implement Direct3D 7 using WineD3D, and I've made some
progress. The D3D7 Device implementation seems to initialize correctly, with
the correct surfaces.
My solution looks like this:
* DirectDraw is unmodified, and it remains in ddraw.dll.
* Direct3D7 uses generally
54 matches
Mail list logo
