<br>
<div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div style="font-family: 'DejaVu Sans'; font-size: 9pt; font-weight: 400; font-style: normal;">
<div class="im">> I don't want any code outside the tile engine to access pixel<br>
> data in any way other than through the iterators: we are not going to<br>
> expose tiles to filters and make filters responsible for cobbling together<br>
> tiles.<br></div>
+1000 :) </div></blockquote><div><br>I won't! promise! =)<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div style="font-family: 'DejaVu Sans'; font-size: 9pt; font-weight: 400; font-style: normal;">
and using iterators increase maintanbility. And anyway, I would doubt iterators add much overhead, at least, callgrind usually blame tiles retrieval, so I agree that strategy that limit tiles retrieval should be investigated instead.<br>
</div></blockquote><div><br>Iterators are not <span>panacea</span>. And if we have code-duplication with iterators or not it won't increase any maintainability.<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div style="font-family: 'DejaVu Sans'; font-size: 9pt; font-weight: 400; font-style: normal;">
<p style="margin: 0px; text-indent: 0px;"><br></p>That said it might be worth to delegate some operations to the data manager (bitBlit or copy for instance), if it means they can be more efficient, since we would be calling them more, but that shoould be exceptional and only if it gives a speed boost.<br clear="all">
</div></blockquote></div><br>At the moment we already have some (at least with my engine):<br>1) clear(rect, color) - fills the @rect with @color. If the rect is big enough filling is done in a cheap way - tiles are shared.<br>
2) copy-constructor - duplicates a dataManager in a shared (deferred) way. It means that no actual copying is done synchronously. So you can use this to optimize code.<br><br><br><br><br>-- <br>Dmitry Kazakov<br>