Efficient rasterization on the Oric

The Oric video chip is not an easy beast to master, so any trick or method that allows to achieve nice visual results is welcome. Don't hesitate to comment (nicely) other people tricks and pictures :)
User avatar
Dbug
Site Admin
Posts: 4040
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Efficient rasterization on the Oric

Post by 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 :)
User avatar
HigashiJun
Flying Officer
Posts: 195
Joined: Tue Dec 10, 2019 9:29 am
Location: Tokyo (Japan)

Re: Efficient rasterization on the Oric

Post by HigashiJun »

Thanks for this interesting article !

:D
HigashiJun
User avatar
ibisum
Wing Commander
Posts: 1526
Joined: Fri Apr 03, 2009 8:56 am
Location: Vienna, Austria
Contact:

Re: Efficient rasterization on the Oric

Post by 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?
User avatar
Dbug
Site Admin
Posts: 4040
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Re: Efficient rasterization on the Oric

Post by Dbug »

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 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.
User avatar
ibisum
Wing Commander
Posts: 1526
Joined: Fri Apr 03, 2009 8:56 am
Location: Vienna, Austria
Contact:

Re: Efficient rasterization on the Oric

Post by 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.
User avatar
Dbug
Site Admin
Posts: 4040
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Re: Efficient rasterization on the Oric

Post by 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.
Post Reply