ddraw: Allow creating back buffer for pre-DirectX 7 interfaces.
thunderbird2k at gmail.com
Wed Jul 21 01:20:12 CDT 2010
2010/7/20 Roderick Colenbrander <thunderbird2k at gmail.com>:
> 2010/7/20 Oldřich Jedlička <oldium.pro at seznam.cz>:
>> Hi Stefan,
>> On Tuesday 20 July 2010 00:01:13 Stefan Dösinger wrote:
>>> Am 19.07.2010 um 21:24 schrieb Oldřich Jedlička:
>>> > Hi Stefan,
>>> > On Monday 19 July 2010 20:56:35 Stefan Dösinger wrote:
>>> >> Allowing the creation of the surface is most likely not enough, the
>>> >> backbuffer has to be useable after it has been created. Specifically,
>>> >> when the app attaches the backbuffer to the frontbuffer(assuming this
>>> >> works, needs a test) wined3d has to be made aware of the change -
>>> >> there's a SetFrontBackBuffers method in the wined3d device to
>>> >> reconfigure the primary swapchain.
>>> > There is at least one game verified to work with CreateSurface method
>>> > that allows creation of back buffers - Bulanci (Combat Pillows, bug
>>> > #9008). But I have to admit that I don't know the internals of WineD3D,
>>> > nor DirectX.
>>> You probably get away with not dealing with AddAttachedSurface by luck.
>>> With the GDI 2D renderer ddraw passes the attached backbuffer explicitly
>>> to wined3d. With the GL renderer you may not be so lucky because it may
>>> render to an offscreen texture instead of the backbuffer.
>> I've analysed the usage by the game and read something about
>> MSDN says that AddAttachedSurface might work, but should not be used on the
>> flipping chain (i.e. to attach back buffers to front buffers). Thus I think there
>> is no change necessary at the moment.
> Sounds like a test is needed there since MSDN is not the most reliable
> source of information. I found a comment on MSDN which says
> AddAttachedSurface can work on a swapchain but it is an unsupported
>> I've downloaded the "bulanci" game (Combat Pillows) and analysed how it is
>> used. The created BACKBUFFER is always Blt'ed onto the FRONTBUFFER (see
>> attachment), there is no call to AddAttachedSurface. I don't know if there is
>> any additional action (=coding) needed.
>> @all: Can anybody please have look at the attached log snippet if there is
>> something wrong? It looks to me that everything works. I've used wine with
>> original patch removing the backbuffer check.
> If it is really true that AddAttachedSurface won't work then a patch
> like this might be fine (wait for Stefan's confirmation though). I
> wonder can you perform any 3D rendering to this type of extra
> backbuffer (it would need FBOs then) or is it just a 'helper' buffer?
> Might require testing too...
Just something else I thought about before going to bed, the game only
requests that the surface is a 'back buffer'. CreateNewSurface in
DirectDraw sets video memory related flags. It might be useful to add
some tests what type of memory, Windows selects for a standalone
backbuffer. Who knows it might select system memory.
More information about the wine-devel