[5/5] WineD3D: Implement buffer subrange mapping with GL_APPLE_flush_buffer_range

Stefan Dösinger stefan at codeweavers.com
Wed Dec 16 05:20:18 CST 2009


Am 16.12.2009 um 11:33 schrieb Henri Verbeet:

> 2009/12/15 Stefan Dösinger <stefan at codeweavers.com>:
>> @@ -85,6 +85,21 @@ static void buffer_create_buffer_object(struct wined3d_buffer *This)
> ...
>> +            This->maps = HeapAlloc(GetProcessHeap(), 0, sizeof(*This->maps));
> 
> This is the wrong place for that. Either do it in buffer_init(), or in
> buffer_Map(). Keeping track of maps should also be in a separate
> patch, and you should integrate "lock_count".
No, I think its the right place because tracking the maps only makes sense with a VBO, and if we have a dynamic VBO we have to keep track of the maps(even with ARB). So I think its just right to allocate and free this together with the VBO.

>> +    /* TODO: GL_ARB_map_buffer_range */
>> +    return gl_info->supported[APPLE_FLUSH_BUFFER_RANGE];
> As a general rule, I think it makes sense to add support for ARB
> extensions (when available) before vendor specific extensions.
Well, I still don't have a working Linux install on any of my machines that can run Left 4 Dead at decent speed(the only game I know that really profits from the dynamic buffers), and OSX doesn't support the ARB extension

So this comes from a personal computer setup issue. Doesn't make the APPLE extension code any different though.




More information about the wine-devel mailing list