Am 02.11.2015 um 11:48 schrieb Henri Verbeet <hverbeet(a)gmail.com>: I think I'll hold off on this until the regression from 1ca9dfc8ee25f4ae188fdacd4d3d56046cef8003 is resolved, but you can probably split the logging changes into their own patch. Fair enough.
+ char name[32]; + sprintf(name, "Color attachment %u", i); + context_dump_fbo_attachment(gl_info, target, GL_COLOR_ATTACHMENT0 + i, name); sprintf() is one of those things that's usually best avoided. In this case the string is mostly redundant as well, since you have the attachment enum.
I prefer "GL_COLOR_ATTACHMENT0" over "0x8CE0", but I guess wine_dbg_sprintf would also do the job without requring my own sprintf.
+ entry = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, + FIELD_OFFSET(struct fbo_entry, key.objects[object_count])); + entry->d3d_render_targets = HeapAlloc(GetProcessHeap(), 0, + gl_info->limits.buffers * sizeof(*entry->d3d_render_targets)); + context_create_fbo_key(&entry->key, render_targets, depth_stencil, color_location, ds_location, + gl_info->limits.buffers); + memcpy(entry->d3d_render_targets, render_targets, sizeof(*entry->d3d_render_targets) * gl_info->limits.buffers); + entry->d3d_depth_stencil = depth_stencil; Why HEAP_ZERO_MEMORY? Do we no longer initialize all fields? I don't trust the padding of the structure array after the 4 byte DWORD on 64 bit architectures.