Hi.
Stefan Dösinger wrote:
Am Samstag, 15. Dezember 2007 12:19:36 schrieb Alexander Dorofeyev:
This seems to be specific to front buffer. Maybe glFlush really should be called in BltOverride (or clearing subroutine) if the target is front buffer?
Yes, glFlush() has to be called when writing to the front buffer. SwapBuffers does an implicit flush, so for the back buffer you don't have to do anything, but the front buffer needs a glFlush(). It isn't there yet, so it should be added.
OK, I'll work on that. There seem to be more places with this issue, at least UnlockRect appears to need it, it helps problems in one ddraw game I tested (Red Alert 2). BTW, if no swapchain exists for a render target and iface == device->render_targets[0], it's a front buffer, right?
The fbo activation you moved is a different problem. It needs to be fixed as well, but it is not as easy as swapping the calls :-( . Essentially, ActivateContext has to be called before the fbo setup, due to multithreading concerns. On the other hand, some things ActivateContext does fail if an fbo is active, so fbos must be set before activatecontext. Essentially we'll have to move fbo setup into ActivateContext, but this has some implications on multiple render targets and depth stencil swapping which need more investigation. OpenGL driver limitations play a role here as well.
Just to be sure, by fbo activation you mean LoadLocation(..., SFLAG_INDRAWABLE, ...) or apply_fbo_state? I think I only moved the former relative to ActivateContext. At the moment I backtracked on that change anyway. Actually I guess I was wrong that LoadLocation before ActivateContext may be a problem, because in SFLAG_INDRAWABLE case LoadLocation seems to call either surface_blt_to_drawable or flush_to_framebuffer_drawpixels both of which do ActivateContext. GL calls are in other codepaths that won't be entered, unfortunately I didn't notice it previous time. At least that's so at the moment.