Hm. About code separation.

[Boudewijn Rempt]

On Tuesday 27 July 2004 21:14, Boudewijn Rempt wrote:
>
> However, I think that that's wrong, and I'll try to untangle the situation
> tonight. The tile manager should store bytes and know nothing, absolutely
> nothing, about the nature of the bytes stored, except for the number of
> bytes that makes up a pixel. So no dependencies on anything from
> core/color_strategy.
>

To expand on this, I think we should work towards the following model:

A paint device, that is, a 2 dimensional raster of data can be visualized as 
follows:

+----------------------------------------+
|  +--------------+ +------------------+ |
|  | data manager | | data interpreter | |
|  +--------------+ +------------------+ |
+----------------------------------------+

I.e, a box that contains a box with data, and a toolkit that can interpret
the data. It is not desirable that the data knows about the toolkit: it's
the paint device to know which way the data should be interpreted.

And then I come back to Casper's point: it's okay for the data interpreter,
that is, the colour strategy, to receive a pointer to a memory location that
is the beginning of a contiguous chunk of memory that is interpretable by the
data interpreter (even though _I_'d prefer to pass it a vector, I feel that
direct memory messing should have gone with the Flintstones).

It's not okay for the data manager to be dependent on the API of the data 
interpreter.
-- 
Boudewijn Rempt | http://www.valdyas.org/fading/index.cgi