Efficient rasterization on the Oric

[Dbug]

While working on the Flood Fill code, I realized I never really explained in one single place how to draw things efficiently on the machine, so hopefully this article should help you.

https://osdk.org/index.php?page=articles&ref=ART19

Feel free to ask question or comment

[HigashiJun]

Thanks for this interesting article !

[ibisum]

This was really interesting and definitely educational... left me wanting more, perhaps how you'd handle optimising a blitter function that copies blocks quickly in HIRES mode, including attribute-handling and so on .. maybe you'd consider that for your next article?

[Dbug]

This was really interesting and definitely educational... left me wanting more, perhaps how you'd handle optimising a blitter function that copies blocks quickly in HIRES mode, including attribute-handling and so on .. maybe you'd consider that for your next article?

I guess that would have to have some limits, like only be able to move at the byte level, not actual pixel level, else handling attributes would not work.

I've been thinking adding to the OSDK a generic "memcopy with stride" function, which basically could do something like that (apart from the attribute handling), basically could be used to copy rectangular areas from screen to screen, or buffer to screen, or even graphics stored linearly to the screen as proper rectangular shapes.

I'm not quite sure how attributes could be handled though, other than being copied with the rest like normal bytes, because you don't really know what appears on the right of where you copy things.

Another things to consider is how to handle overlaps, and if masking should be involved.

[ibisum]

I guess that would have to have some limits, like only be able to move at the byte level, not actual pixel level, else handling attributes would not work.

Yes, this would still be quite useful in the same context as this tutorial - optimising a function for OSDK C.

I'm not quite sure how attributes could be handled though, other than being copied with the rest like normal bytes, because you don't really know what appears on the right of where you copy things.

Would it not be worth it to have an 'attribute mixup' path, post-blit (or during) that applies different semantics to the operation - i.e. _NOFIX - don't bother with attributes, _PAD_RIGHT - scan to the right to 'fix' the attribute overload, _BLACK - set attributes to 0, etc.

[Dbug]

Need to think about how to do that, because that would have serious performance implication, from being able to just do an bunch of lda/sta to something that actually have to load the source data to check if the value is less than 64 and then somewhat store it until we reach the end... or start by scanning right to left and stop at the first attribute found (if any), and then only do the lda/sta fast copy.

If we had a 65C02, we could have used BIT $nnnn,x to check for attributes, since the V flag will matches the bit 6, so BIT + BVC/BVS could be used, but on the NMOS 6502 this addressing mode is not available.

The problem with ultra-generic/flexible code, is that it ends up being uselessly slow.