[d3d9] Check for null image in D3D9DeviceEx::FlushImage()

[gofman]

Fixes a crash in Tales from the Borderlands (330830) during E1 Chapter4 which is an old regression (worked in Proton 5.13-6).

Reproduction:

1. Launch game to create prefix
2. Drop contents of attached save file zip (10 files) into compatdata/330830/pfx/drive_c/users/steamuser/Documents/Telltale Games/Tales from the Borderlands
3. Relaunch the game.
4. Once on the main menu, select "Play" and then press "A" to "Continue Episode 1".
5. Once Rhys wakes from from the floor, make your way to the caravan door (using the left joystick).
6. Select the caravan door to exit.
7. Make your way up the hill towards the group.

save.zip

The game is crashing in D3D9DeviceEx::FlushImage trying to access null image from pResource->GetImage(). D3D9CommonTexture::D3D9CommonTexture doesn't create image for all types of textures. However, the same D3D9CommonTexture::D3D9CommonTexture marks the image for upload with SetAllNeedUpload(), that's how it gets to FlushImage through UploadManagedTextures. There are other places when the image can be marked for upload without checking if it has an image but the game hits this one. Of course there are different ways to fix it, e. g., do a more thorough check in UploadManagedTexture[s], but it seems to me it is easier and more robust to check the pointer in FlushImages rather than hunt all its possible usages.

[gofman]

As an additional info, the texture in question has D3DPOOL_SCRATCH pool. I briefly tested on Windows (AMD) that setting such a texture doesn't result in a error on Draw(), draw actually happens and sampled colour is 0. The same happens with dxvk.

Not related here, but for D3DPOOL_SYSTEMMEM there is the difference: Windows fails the Draw() and doesn't draw anything. There is a caveat though (as it happens with errors from Draw()): calling exactly the same Draw() second time in a row doesn't fail and yields zero sampled colour (same way as with _SCRATCH at once). dxvk with D3DPOOL_SYSTEMMEM behaves the same as with D3DPOOL_SCRATCH.

UPDATE: both these tests result in a crash in Draw() with dxvk without the patch from here of course.