Supreme Commander Up and running!
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
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
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.
-- Markus
On 20/03/07, Markus <kde(a)3danim.de> 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.
On Tue, 2007-03-20 at 23:44 +0100, H. Verbeet wrote:
On 20/03/07, Markus <kde(a)3danim.de> 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
On 21/03/07, Stephan Rose <kermos(a)somrek.net> 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.
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.
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
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?
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
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. -- Best regards Wojciech Arabczyk :: http://www.arabek.net :: jid:arab(a)chrome.pl
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.
-- Markus
Am Mittwoch 21 März 2007 14:31 schrieb H. Verbeet:
On 21/03/07, Mirek <thunder.m(a)czela.net> 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.
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?
-- Markus
On 22/03/07, Markus <kde(a)3danim.de> 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.
On Thursday 22 March 2007 18:16, you wrote:
On 22/03/07, Markus <kde(a)3danim.de> 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. -- Markus
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)
On 22/03/07, Stefan Dösinger <stefandoesinger(a)gmx.at> 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.
Am Donnerstag 22 März 2007 23:59 schrieb H. Verbeet:
On 22/03/07, Stefan Dösinger <stefandoesinger(a)gmx.at> 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
participants (7)
-
Felix Nawothnig -
H. Verbeet -
Markus -
Mirek -
Stefan Dösinger -
Stephan Rose -
Wojciech 'arab' Arabczyk