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
Efficient rasterization on the Oric
- HigashiJun
- Flying Officer
- Posts: 205
- Joined: Tue Dec 10, 2019 9:29 am
- Location: Tokyo (Japan)
- ibisum
- Wing Commander
- Posts: 1652
- Joined: Fri Apr 03, 2009 8:56 am
- Location: Vienna, Austria
- Contact:
Re: Efficient rasterization on the Oric
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?
Re: Efficient rasterization on the Oric
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.ibisum wrote: ↑Sun Feb 06, 2022 1:25 pm 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'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
- Wing Commander
- Posts: 1652
- Joined: Fri Apr 03, 2009 8:56 am
- Location: Vienna, Austria
- Contact:
Re: Efficient rasterization on the Oric
Yes, this would still be quite useful in the same context as this tutorial - optimising a function for OSDK C.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.
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.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.
Re: Efficient rasterization on the Oric
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.
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.