Supreme Commander Up and running!

[Stephan Rose]

I've got SC up and running, had to apply that font patch (that moving
into the source anytime soon btw? It does work nicely).

So looking at my debug output at stuff that's got errors or fixme's, I
came across this little line:

fixme:file:ReplaceFileW

Figure, that'd be as good as a start as any as something for me to
implement. Easy to test too....just before I dive into it, anyone
potentially already working on it (or is there a good way to check)?

Figured I'd ask first before 2 people work on the same thing.

Stephan

[Felix Nawothnig]

Stephan Rose wrote:
> Figure, that'd be as good as a start as any as something for me to
> implement. Easy to test too....just before I dive into it, anyone
> potentially already working on it (or is there a good way to check)?
>
> Figured I'd ask first before 2 people work on the same thing.

Someone sent a patch to implement that function one or two weeks ago. 
Didn't get commited though.

Felix

[Stefan Dösinger]

Am Dienstag 20 März 2007 20:34 schrieb Stephan Rose:
> I've got SC up and running, had to apply that font patch (that moving
> into the source anytime soon btw? It does work nicely).

Which font patch?

Does the game actually run? How is it from the d3d point of view?

[Markus]

On Tuesday 20 March 2007 21:00, Stefan Dösinger wrote:
> Which font patch?

http://bugs.winehq.org/show_bug.cgi?id=7507
> Does the game actually run? How is it from the d3d point of view?

Yes, but it is only somewhat playable from a graphics point of view if you 
turn off GLSL. Otherwise all buildings and items will be invisible.

[H. Verbeet]

On 20/03/07, Markus  wrote:
> On Tuesday 20 March 2007 21:00, Stefan Dösinger wrote:
> > Which font patch?
>
> http://bugs.winehq.org/show_bug.cgi?id=7507
> > Does the game actually run? How is it from the d3d point of view?
>
> Yes, but it is only somewhat playable from a graphics point of view if you
> turn off GLSL. Otherwise all buildings and items will be invisible.

It would be useful if someone would look into that.

[Stephan Rose]

On Tue, 2007-03-20 at 23:44 +0100, H. Verbeet wrote:
> On 20/03/07, Markus  wrote:
> > On Tuesday 20 March 2007 21:00, Stefan Dösinger wrote:
> > > Which font patch?
> >
> > http://bugs.winehq.org/show_bug.cgi?id=7507
> > > Does the game actually run? How is it from the d3d point of view?
> >
> > Yes, but it is only somewhat playable from a graphics point of view if you
> > turn off GLSL. Otherwise all buildings and items will be invisible.
>
> It would be useful if someone would look into that.

I'll look around a bit and see if I can come up with anything.

I'll hold off on the "ReplaceFileW" thing for the time being to see if
that other patch gets committed.

I also saw that this is missing:

err:d3d9:IDirect3DDevice9Impl_StretchRect Texture filters not supported
yet

So if nobody is doing anything there I might look into that.

Btw, I also noticed that it seems to use a few DLLs we don't appear to
have. Namely:

d3dx9_31.dll
faultrep.dll
winsta.dll
x3daudio1_1.dll

I am guessing that missing audio-dll is largely why I am not seeing any
sound in SC?

An implementation for that d3dx9_31.dll is also something I might be
interested in looking into.

Stephan

[H. Verbeet]

On 21/03/07, Stephan Rose  wrote:
> err:d3d9:IDirect3DDevice9Impl_StretchRect Texture filters not supported
> yet
>
> So if nobody is doing anything there I might look into that.

I've got a mostly working patch for implementing StretchRect using the
EXT_framebuffer_blit extension. That can handle filtering as well, if
we would actually pass the filter through.

[Stefan Dösinger]

Am Dienstag 20 März 2007 21:54 schrieb Markus:
> On Tuesday 20 March 2007 21:00, Stefan Dösinger wrote:
> > Which font patch?
>
> http://bugs.winehq.org/show_bug.cgi?id=7507
> > Does the game actually run? How is it from the d3d point of view?
>
> Yes, but it is only somewhat playable from a graphics point of view if you
> turn off GLSL. Otherwise all buildings and items will be invisible.

Sounds to me like it starts using Shader Model 2.0 and above when glsl is 
enabled and thus hit some bugs in wined3d or the driver.

[Stephan Rose]

On Wed, 2007-03-21 at 00:11 +0100, Stefan Dösinger wrote:
> Am Dienstag 20 März 2007 21:54 schrieb Markus:
> > On Tuesday 20 March 2007 21:00, Stefan Dösinger wrote:
> > > Which font patch?
> >
> > http://bugs.winehq.org/show_bug.cgi?id=7507
> > > Does the game actually run? How is it from the d3d point of view?
> >
> > Yes, but it is only somewhat playable from a graphics point of view if you
> > turn off GLSL. Otherwise all buildings and items will be invisible.
>
> Sounds to me like it starts using Shader Model 2.0 and above when glsl is 
> enabled and thus hit some bugs in wined3d or the driver.

According to the system requirements the highest it uses is 2.0.

I am also wondering if some of the other bugs, such as geometry being in
the wrong place may be resulting from the d3dx9_31.dll not being our
own. Maybe seeing some interoperability issues there between the native
version of that and our own version of the remaining d3d dlls?

Stephan

[Stefan Dösinger]

> > > > Which font patch?
> > >
> > > http://bugs.winehq.org/show_bug.cgi?id=7507

Oh, not d3d related.
> According to the system requirements the highest it uses is 2.0.
>
> I am also wondering if some of the other bugs, such as geometry being in
> the wrong place may be resulting from the d3dx9_31.dll not being our
> own. Maybe seeing some interoperability issues there between the native
> version of that and our own version of the remaining d3d dlls?

No, this is not the case. d3dx9_31 is supposed to work with wine and works 
nice so far.

Can you attach a screenshot showing the rendering issues and / or open a bug 
for them?

[Mirek]

Stefan Dösinger napsal(a):
> > > > > Which font patch?
> > > >
> > > > http://bugs.winehq.org/show_bug.cgi?id=7507
>
> Oh, not d3d related.
> > According to the system requirements the highest it uses is 2.0.
> >
> > I am also wondering if some of the other bugs, such as geometry being in
> > the wrong place may be resulting from the d3dx9_31.dll not being our
> > own. Maybe seeing some interoperability issues there between the native
> > version of that and our own version of the remaining d3d dlls?
>
> No, this is not the case. d3dx9_31 is supposed to work with wine and works 
> nice so far.
>
> Can you attach a screenshot showing the rendering issues and / or open a bug 
> for them?

Hi, here is screenshot: 
http://headline.czela.net/Mirek/wine/Supreme%20Commander/ with GLSL and 
this is part of messages when playing demo game:

fixme:d3d_draw:drawStridedInstanced >>>>>>>>>>>>>>>>> 0x502 from 
glDrawElements @ drawprim.c / 991
fixme:d3d_draw:drawStridedInstanced Unsupported WINED3DDECLTYPE_FLOAT16_4
fixme:d3d_draw:drawStridedInstanced >>>>>>>>>>>>>>>>> 0x502 from 
glDrawElements @ drawprim.c / 991
fixme:d3d_draw:drawStridedInstanced Unsupported WINED3DDECLTYPE_FLOAT16_4
fixme:d3d_draw:drawStridedInstanced >>>>>>>>>>>>>>>>> 0x502 from 
glDrawElements @ drawprim.c / 991
fixme:d3d_draw:drawStridedInstanced Unsupported WINED3DDECLTYPE_FLOAT16_4
fixme:d3d_draw:drawStridedInstanced >>>>>>>>>>>>>>>>> 0x502 from 
glDrawElements @ drawprim.c / 991
fixme:d3d_draw:drawStridedInstanced Unsupported WINED3DDECLTYPE_FLOAT16_4
fixme:d3d_draw:drawStridedInstanced >>>>>>>>>>>>>>>>> 0x502 from 
glDrawElements @ drawprim.c / 991
fixme:d3d_draw:drawStridedInstanced Unsupported WINED3DDECLTYPE_FLOAT16_4
fixme:d3d_draw:drawStridedInstanced >>>>>>>>>>>>>>>>> 0x502 from 
glDrawElements @ drawprim.c / 991
fixme:d3d_draw:drawStridedInstanced Unsupported WINED3DDECLTYPE_FLOAT16_4
fixme:d3d_draw:drawStridedInstanced >>>>>>>>>>>>>>>>> 0x502 from 
glDrawElements @ drawprim.c / 991
fixme:d3d_draw:drawStridedInstanced Unsupported WINED3DDECLTYPE_FLOAT16_4
fixme:d3d_draw:drawStridedInstanced >>>>>>>>>>>>>>>>> 0x502 from 
glDrawElements @ drawprim.c / 991
fixme:d3d_draw:drawStridedInstanced Unsupported WINED3DDECLTYPE_FLOAT16_4
fixme:d3d_draw:drawStridedInstanced >>>>>>>>>>>>>>>>> 0x502 from 
glDrawElements @ drawprim.c / 991
fixme:d3d_draw:drawStridedInstanced Unsupported WINED3DDECLTYPE_FLOAT16_4
fixme:d3d_draw:drawStridedInstanced >>>>>>>>>>>>>>>>> 0x502 from 
glDrawElements @ drawprim.c / 991
fixme:d3d_draw:drawStridedInstanced Unsupported WINED3DDECLTYPE_FLOAT16_4
fixme:d3d_draw:drawStridedInstanced >>>>>>>>>>>>>>>>> 0x502 from 
glDrawElements @ drawprim.c / 991
fixme:d3d_draw:drawStridedInstanced Unsupported WINED3DDECLTYPE_FLOAT16_4
fixme:d3d_draw:drawStridedInstanced >>>>>>>>>>>>>>>>> 0x502 from 
glDrawElements @ drawprim.c / 991
fixme:d3d_draw:drawStridedInstanced Unsupported WINED3DDECLTYPE_FLOAT16_4
fixme:d3d_draw:drawStridedInstanced >>>>>>>>>>>>>>>>> 0x502 from 
glDrawElements @ drawprim.c / 991
fixme:d3d_draw:drawStridedInstanced Unsupported WINED3DDECLTYPE_FLOAT16_4
fixme:d3d_draw:drawStridedInstanced >>>>>>>>>>>>>>>>> 0x502 from 
glDrawElements @ drawprim.c / 991
fixme:d3d_draw:drawStridedInstanced Unsupported WINED3DDECLTYPE_FLOAT16_4
fixme:d3d_draw:drawStridedInstanced >>>>>>>>>>>>>>>>> 0x502 from 
glDrawElements @ drawprim.c / 991
fixme:d3d_draw:drawStridedInstanced Unsupported WINED3DDECLTYPE_FLOAT16_4
fixme:d3d_draw:drawStridedInstanced >>>>>>>>>>>>>>>>> 0x502 from 
glDrawElements @ drawprim.c / 991
fixme:d3d_draw:drawStridedInstanced Unsupported WINED3DDECLTYPE_FLOAT16_4
fixme:d3d_draw:drawStridedInstanced >>>>>>>>>>>>>>>>> 0x502 from 
glDrawElements @ drawprim.c / 991
fixme:d3d_draw:drawStridedInstanced Unsupported WINED3DDECLTYPE_FLOAT16_4
fixme:d3d_draw:drawStridedInstanced >>>>>>>>>>>>>>>>> 0x502 from 
glDrawElements @ drawprim.c / 991
fixme:d3d_draw:drawStridedInstanced Unsupported WINED3DDECLTYPE_FLOAT16_4
fixme:d3d_draw:drawStridedInstanced >>>>>>>>>>>>>>>>> 0x502 from 
glDrawElements @ drawprim.c / 991
fixme:d3d_draw:drawStridedInstanced Unsupported WINED3DDECLTYPE_FLOAT16_4
fixme:d3d_draw:drawStridedInstanced >>>>>>>>>>>>>>>>> 0x502 from 
glDrawElements @ drawprim.c / 991
fixme:d3d_draw:drawStridedInstanced Unsupported WINED3DDECLTYPE_FLOAT16_4
fixme:d3d_draw:drawStridedInstanced >>>>>>>>>>>>>>>>> 0x502 from 
glDrawElements @ drawprim.c / 991
fixme:d3d_draw:drawStridedInstanced Unsupported WINED3DDECLTYPE_FLOAT16_4
fixme:d3d_draw:drawStridedInstanced Unsupported WINED3DDECLTYPE_FLOAT16_4
fixme:d3d_draw:drawStridedInstanced Unsupported WINED3DDECLTYPE_FLOAT16_4
fixme:d3d_draw:drawStridedInstanced Unsupported WINED3DDECLTYPE_FLOAT16_4
fixme:d3d_draw:drawStridedInstanced Unsupported WINED3DDECLTYPE_FLOAT16_4
fixme:d3d_draw:drawStridedInstanced Unsupported WINED3DDECLTYPE_FLOAT16_4
fixme:d3d_draw:drawStridedInstanced Unsupported WINED3DDECLTYPE_FLOAT16_4
fixme:d3d_draw:drawStridedInstanced Unsupported WINED3DDECLTYPE_FLOAT16_4
fixme:d3d_draw:drawStridedInstanced Unsupported WINED3DDECLTYPE_FLOAT16_4
fixme:d3d_draw:drawStridedInstanced Unsupported WINED3DDECLTYPE_FLOAT16_4
fixme:d3d_draw:drawStridedInstanced Unsupported WINED3DDECLTYPE_FLOAT16_4
fixme:d3d_draw:drawStridedInstanced Unsupported WINED3DDECLTYPE_FLOAT16_4
fixme:d3d_draw:drawStridedInstanced Unsupported WINED3DDECLTYPE_FLOAT16_4
fixme:d3d_draw:drawStridedInstanced Unsupported WINED3DDECLTYPE_FLOAT16_4
fixme:d3d_draw:drawStridedInstanced Unsupported WINED3DDECLTYPE_FLOAT16_4
fixme:d3d_draw:drawStridedInstanced Unsupported WINED3DDECLTYPE_FLOAT16_4
fixme:d3d_draw:drawStridedInstanced Unsupported WINED3DDECLTYPE_FLOAT16_4
fixme:d3d_draw:drawStridedInstanced Unsupported WINED3DDECLTYPE_FLOAT16_4
fixme:d3d_draw:drawStridedInstanced Unsupported WINED3DDECLTYPE_FLOAT16_4
err:d3d9:IDirect3DDevice9Impl_StretchRect Texture filters not supported yet

Mirek

[Wojciech 'arab' Arabczyk]

Hello
> http://headline.czela.net/Mirek/wine/Supreme%20Commander/ with GLSL and
> this is part of messages when playing demo game:
>
> fixme:d3d_draw:drawStridedInstanced >>>>>>>>>>>>>>>>> 0x502 from
> glDrawElements @ drawprim.c / 991
> fixme:d3d_draw:drawStridedInstanced Unsupported WINED3DDECLTYPE_FLOAT16_4
> fixme:d3d_draw:drawStridedInstanced >>>>>>>>>>>>>>>>> 0x502 from
> glDrawElements @ drawprim.c / 991

I've encountered this when running some windows demoscene prod, with GLSL 
FBO's enabled. Try switching to pbuffer as it helped here.

[Markus]

On Wednesday 21 March 2007 13:26, Wojciech 'arab' Arabczyk wrote:
> > http://headline.czela.net/Mirek/wine/Supreme%20Commander/ with GLSL and
> > this is part of messages when playing demo game:
> >
> > fixme:d3d_draw:drawStridedInstanced >>>>>>>>>>>>>>>>> 0x502 from
> > glDrawElements @ drawprim.c / 991
> > fixme:d3d_draw:drawStridedInstanced Unsupported WINED3DDECLTYPE_FLOAT16_4
> > fixme:d3d_draw:drawStridedInstanced >>>>>>>>>>>>>>>>> 0x502 from
> > glDrawElements @ drawprim.c / 991
>
> I've encountered this when running some windows demoscene prod, with GLSL
> FBO's enabled. Try switching to pbuffer as it helped here.

Setting either pbuffer, fbo or no OffscreenRenderingMode key at all did not 
have any effect.

[H. Verbeet]

On 21/03/07, Mirek  wrote:
> fixme:d3d_draw:drawStridedInstanced Unsupported WINED3DDECLTYPE_FLOAT16_4

That'll do it. Looks like it's not so much the GLSL implementation as
the different caps we return when GLSL is used.

[Stefan Dösinger]

Am Mittwoch 21 März 2007 14:31 schrieb H. Verbeet:
> On 21/03/07, Mirek  wrote:
> > fixme:d3d_draw:drawStridedInstanced Unsupported WINED3DDECLTYPE_FLOAT16_4
>
> That'll do it. Looks like it's not so much the GLSL implementation as
> the different caps we return when GLSL is used.

Ah yes, Instancing makes sense for a real time strategy game.

[Markus]

On Wednesday 21 March 2007 16:08, Stefan Dösinger wrote:
> Am Mittwoch 21 März 2007 14:31 schrieb H. Verbeet:
> > That'll do it. Looks like it's not so much the GLSL implementation as
> > the different caps we return when GLSL is used.
>
> Ah yes, Instancing makes sense for a real time strategy game.

Any chance instancing will be implemented any time soon?

[H. Verbeet]

On 22/03/07, Markus  wrote:
> On Wednesday 21 March 2007 16:08, Stefan Dösinger wrote:
> > Am Mittwoch 21 März 2007 14:31 schrieb H. Verbeet:
> > > That'll do it. Looks like it's not so much the GLSL implementation as
> > > the different caps we return when GLSL is used.
> >
> > Ah yes, Instancing makes sense for a real time strategy game.
>
> Any chance instancing will be implemented any time soon?

We've got instancing support, although there may be bugs. That
particular datatype isn't supported though. I'm not sure how hard it
would be to implement this, and if perhaps there are any extensions we
could use.

[Markus]

On Thursday 22 March 2007 18:16, you wrote:
> On 22/03/07, Markus  wrote:
> > Any chance instancing will be implemented any time soon?
>
> We've got instancing support, although there may be bugs. That
> particular datatype isn't supported though. I'm not sure how hard it
> would be to implement this, and if perhaps there are any extensions we
> could use.

I've done some searching on the net for an instancing extension and two seem 
to exist:
An older NVidia specific extension "NVX_instanced_arrays"
http://http.download.nvidia.com/developer/presentations/2006/gdc/2006-GDC_Op...

and a newer "ext_draw_instanced" which seems to be more "official". I've 
however read several times that it apparently only works on 8800 series cards 
or newer.
http://developer.download.nvidia.com/opengl/specs/GL_EXT_draw_instanced.txt

Possibly nothing new to you folks but maybe it saves some time on research.

[Stefan Dösinger]

> I've done some searching on the net for an instancing extension and two
> seem to exist:

Right now we handle instancing with some kind of software emulation. Roughtly 
it works like this:

/* Non-instanced attribs are set as stream sources in opengl */
for(i = 0; i < num_instances; i++) {
    for(j = 0; i < instanced_attribs) {
        glVertexAttribfv(&instanced_attrib[j])
    }
    glDrawElements(vertices per instance to draw);
}

The problem that occurs here is that some vertex attribute type can't be set 
in the glVertexAttribfv calling loop. Most likely because I didn't figure out 
which gl call takes the precise argument. Should be easy to figure out.

The way we handle instancing is not instancing on the hardware side, but we 
don't have to apply all states again per instance. glDrawElements is cheaper 
than D3DDevice::DrawPrimitive, its d3d counterpart.

With ext_draw_instanced we can do d3d-style hardware instancing, but this 
extension is only supported on gf8800 cards(or used to be, at least)

[H. Verbeet]

On 22/03/07, Stefan Dösinger  wrote:
> The problem that occurs here is that some vertex attribute type can't be set
> in the glVertexAttribfv calling loop. Most likely because I didn't figure out
> which gl call takes the precise argument. Should be easy to figure out.

NV_half_float looks useful.

[Stefan Dösinger]

Am Donnerstag 22 März 2007 23:59 schrieb H. Verbeet:
> On 22/03/07, Stefan Dösinger  wrote:
> > The problem that occurs here is that some vertex attribute type can't be
> > set in the glVertexAttribfv calling loop. Most likely because I didn't
> > figure out which gl call takes the precise argument. Should be easy to
> > figure out.
>
> NV_half_float looks useful.

By the way, I think this is also wrong in the attribute table for loading the 
streams