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.