Re: [AD] Bug with transparent ellipses

[Jon Rafkind <workmin@xxxxxxxxxx>]

Elias Pschernig wrote:
> On Sun, 2006-09-03 at 18:41 -0400, Jon Rafkind wrote:
>   
>> That works, but needs to be done for the 15/16/24/32 blenders as well. I
>> started to do it but quickly realized there are a bunch of macros to
>> take care of. I think 8 bit needs this too.
>>
>> #define MAKE_DTS_BLENDER()     color_map
>> #define MAKE_PS_BLENDER()      color_map
>> #define MAKE_DLS_BLENDER(a)    (color_map->data[(a) & 0xFF])
>>
>> And of course the macro you fixed MAKE_PP_BLENDER. At this point would
>> it just be easier to set a default color_map/blender? I realize this is
>> a fundamental change but I dont see what harm could come from it.
>>
>>     
>
> Yeah, ideally, would assert against all cases where color_map or
> _blender_func_* are accessed. 
>
> I also can see no harm of setting defaults, but I think, as we already
> have 100ds of asserts, for similar things, it would be more consistent
> to also add asserts here. For 4.3, I strongly would prefer defaults
> though.. as I said, I consider the 4.2 way here very bad design.
>
> Also, modifying a few #defines like above is probably less likely to
> break something so short before the release than providing default
> blenders - but it might actually be the other way around.
>
>   
Ok, but with your patch doesnt it automatically use al_assert whereas
al_assert is only turned on when DEBUGMODE is enabled?

#ifdef DEBUGMODE
   #define ASSERT(condition)     { if (!(condition)) al_assert(__FILE__,
__LINE__); }
   #define TRACE                 al_trace
#else
   #define ASSERT(condition)
   #define TRACE                 1 ? (void) 0 : al_trace
#endif

so the code would somehow have to use ASSERT(color_map), right?