I'm working on fixing the menus in carmageddon and I have a question.
I have set the DirectDrawRenderer to opengl and it all crashes (where it works under gdi, just displays incorrectly).
Now I traced the problem down to: dlls/wined3d/surface.c d3dfmt_convert_surface
The loop at: http://source.winehq.org/git/wine.git/?a=blob;f=dlls/wined3d/surface.c;h=1f4...
loops over the surface height and width, the only problem is that the surface height appears to be scaled up to the next power of 2.
As carmageddon runs in 320x200 the loop tries to iterate over 320x256 and subsequently crashes with a page fault in winedbg.
Is there anyway to get the original window's dimensions and perhaps feed that to the function & hence loop, instead? Or should I just accept that carmageddon will forever be restricted to the gdi renderer? :P
Now I traced the problem down to: dlls/wined3d/surface.c d3dfmt_convert_surface
loops over the surface height and width, the only problem is that the surface height appears to be scaled up to the next power of 2.
As carmageddon runs in 320x200 the loop tries to iterate over 320x256 and subsequently crashes with a page fault in winedbg.
Sounds like that the surface conversion code still makes some assumptions about the allocated memory size and the surface size. Wine used to allocate the full power of 2 size, but I removed that and allocate only the real surface size because there are some applications which expected a specific pitch for the surface. The power of 2 size usage vs real size was pretty inconsistent, I guess there is another inconsistency.
Should I go ahead and remove the same from dlls/wined3d/surface.c and submit a patch, or have you beaten me to it? =D
On 3/25/07, Stefan Dösinger stefandoesinger@gmx.at wrote:
Sounds like that the surface conversion code still makes some assumptions about the allocated memory size and the surface size. Wine used to allocate the full power of 2 size, but I removed that and allocate only the real surface size because there are some applications which expected a specific pitch for the surface. The power of 2 size usage vs real size was pretty inconsistent, I guess there is another inconsistency.
Am Samstag 24 März 2007 22:42 schrieb Nathan Williams:
Should I go ahead and remove the same from dlls/wined3d/surface.c and submit a patch, or have you beaten me to it? =D
On 3/25/07, Stefan Dösinger stefandoesinger@gmx.at wrote:
Sounds like that the surface conversion code still makes some assumptions about the allocated memory size and the surface size. Wine used to allocate the full power of 2 size, but I removed that and allocate only the real surface size because there are some applications which expected a specific pitch for the surface. The power of 2 size usage vs real size was pretty inconsistent, I guess there is another inconsistency.
Is the crashing call done from flush_to_framebuffer_* or LoadTexture?
It crashes at: dlls/wined3d/surface.c d3dfmt_convert_surface: 1593 *dest++ = table[color][0];
http://source.winehq.org/git/wine.git/?a=blob;f=dlls/wined3d/surface.c;hb=HE...
If I hack that loop to be the right height, it works without complaint.
The original setting of the height to be a power of 2 is: http://source.winehq.org/git/wine.git/?a=blob;f=dlls/wined3d/surface.c;hb=HE...
On 3/25/07, Stefan Dösinger stefandoesinger@gmx.at wrote:
Is the crashing call done from flush_to_framebuffer_* or LoadTexture?
Am Samstag 24 März 2007 23:59 schrieb Nathan Williams:
It crashes at: dlls/wined3d/surface.c d3dfmt_convert_surface: 1593 *dest++ = table[color][0];
Yes, but from where is this called? d3dfmt_convert_surface: gets a height parameter, and this parameter is incorrect.
-
Nathan Williams -
Stefan Dösinger