...

#1 Couldn't reproduce this, yet (Vista, ATI card). Looks like the clipmap refill gets screwed for some reason after the device reset.

#2 Couldn't repro on my nvidia based laptop with Vista either.. looking into it further and logging it.

#3 ...

#4 ...

#5 Hmm, have a vague hunch what that might be. On device reset, both the render target of the blender clipmap cache and the clipstack textures themselves are zombified first and then resurrected. However, for the clipmap fill to work, the render target of the blender cache has to be resurrected before the clipstack textures do. However, the texture manager guarantees no ordering here. Maybe that's the issue.

Joseph, could you test AtlasDemo and see whether you get the same effect? Unique terrain does not use a render target and thus should not have this issue if the above is true.

And BTW, is this happening under GL or DX or under both?

#6 Doh, crap, AtlasDemo is blended terrain... didn't think of that. Forget about AtlasDemo, Joseph. Could you give Barricade a try? (Is that included in the Beta... don't know actually; if not, you could pull it from the repo)

#7 ...

#8 ...

#9 Umpff... the Atlas module was deactivated before the GFX2 port and never got reactivated. And I didn't check but rather just assumed Barricade was working. I'm sorry, Joseph, for wasting your time.

I'm also pretty sure now that my above guess was wrong. Can't be that.

Will keep on looking into this.

BTW, Joseph, you can switch to GL by starting with "$pref::Video::displayDevice" set to "OpenGL" (at least, that's one way).

#10 ...

#11 Hmm, interesting finds. Especially the maximize/restore vs. resize thing.

The GL stuff sounds properly broken. Unfortunately have no means to test that on my equippment here thanks to Dell's cutting-edge driver support....

The "Invalid renderer name..." thing is a problem in the script files where the prefs get loaded *after* device inits. Fixed it for T3D in the repo but have yet to do it for the other example apps.

Thanks for putting so much time into this. Hope we'll get to the root of this.

PS: The cubemap thing is a GL restriction which doesn't apply with DX. Updated the sky cubemap in the repo. The error should be gone.

#12 ...

#13 Hmm, the rapid-sequence-of-resets-thing to me appeared to be very promising, but after enabling the show-contents-inside-window-when-drag-resizing thing in Windows, I've still got no luck reproducing this. Resizing is slow but never corrupted the texture.

Do you get this with sequences of window maximize and restore operations, too?

Another thought: is your version of the DX SDK up to date?

#14 Update: DX SDK is not to blame. bank helped verify this. All points to a genuine issue in the clipmap code.

#15 @Joseph
Ok, you were right on track. Seems like it won't happen without "show content inside window while resizing" being on. Could you give this a try on your system.

Thanks to bank for investigating into this.

#16 This definitely sounds like a job for the superhero Pix Man!.

#17 ...

#18 ...

#19 Update:

Seems to not happen on Vista systems but consistently on XP systems (regardless of vidcard manufacturer) with "show content inside windows while dragging" turned on. Maximizing/minimizing or toggling the editor cleans the clipmap up.

Seemed like the rapid succession of device resets may have caused the problem, but after discarding successive WM_SIZE events from the message queue, the problem still persists. Does not happen on 1.7.1. So, there most likely is a problem in either the clipmap code or GFX2.

I am almost 100% sure I have this issue showing up in another form, though. After saving the T3D mission under a different name and reloading from that file, the clipmap initially comes up as a complete mess. Maximizing/minimizing or toggling the editor clears the map. So I will fix that and then see whether the texture corruption goes away when resizing the window.

PS: Big thanks have to go out to bank who helped tremendously with testing.