01-03-2024, 06:16 PM
I think it's less about the specific parameters and more about what we're capable of if we try to have more control over the Display system
As a quick example, we can use PUTIMAGE to easily manipulate images, but we also have a set of basic commands we can use to create our own image manipulation system. Sometimes, it's better. Like using MEM to paste a solid background image. We lose access to a lot of those features with HARDWARE images, but you can still recreate some: create a palette map graphic and then use it for your own HARDWARE PSET, LINE, FILL_CIRCLE functions, etc. Not as good as readymade functions with free 32-bit color support, but it's something.
But when it comes to DISPLAY, there isn't much room to take control yourself. AUTODISPLAY runs at a fixed 30fps, apparently. DISPLAY does a full screen comparison before deciding to update or not, I think. So while PUTIMAGE is a good way to work with just a portion of the screen, it's not really the same as DISPLAY just checking the portion of the screen you want updated. Similarly, you might want to only clear a portion of the screen, but CLS does the whole thing. You can use MEMFILL as _Byte to target a portion, but since everything besides _Byte is comparatively slow, it's limited and you lose options for color.
Maybe there are ways to get more control over how updating the display is handled, but when you don't know what those are, imaginary parameters are the simplest example you can make of what they could be.
My use case was a program where the _SOFTWARE page regularly only took up 1/3 of the screen, so I was wondering if I could improve performance by just working with that portion
As a quick example, we can use PUTIMAGE to easily manipulate images, but we also have a set of basic commands we can use to create our own image manipulation system. Sometimes, it's better. Like using MEM to paste a solid background image. We lose access to a lot of those features with HARDWARE images, but you can still recreate some: create a palette map graphic and then use it for your own HARDWARE PSET, LINE, FILL_CIRCLE functions, etc. Not as good as readymade functions with free 32-bit color support, but it's something.
But when it comes to DISPLAY, there isn't much room to take control yourself. AUTODISPLAY runs at a fixed 30fps, apparently. DISPLAY does a full screen comparison before deciding to update or not, I think. So while PUTIMAGE is a good way to work with just a portion of the screen, it's not really the same as DISPLAY just checking the portion of the screen you want updated. Similarly, you might want to only clear a portion of the screen, but CLS does the whole thing. You can use MEMFILL as _Byte to target a portion, but since everything besides _Byte is comparatively slow, it's limited and you lose options for color.
Maybe there are ways to get more control over how updating the display is handled, but when you don't know what those are, imaginary parameters are the simplest example you can make of what they could be.
My use case was a program where the _SOFTWARE page regularly only took up 1/3 of the screen, so I was wondering if I could improve performance by just working with that portion