_DISPLAY: Would it be of any use to have parameters?

[CharlieJV]

Although I can't think of a glowing use case for this, it has been on my mind for the last couple of days.

Code: (Select All)

_DISPLAY start_x, start_y, width, height

Would that be a useful thing?

Just to quickly demonstrate with BAM:

• Run the program
  
• View the source code
  

[bplus]

Seems to me that would make _Display more a nuisance to use.

PLUS how would _AutoDisplay work?

[DSMan195276]

It could be interesting, but on the QB64 side it might be a bit hard to implement. You should be able to achieve the same thing by rendering to a separate image and using `_PutImage` before `_Display`, so I'm not sure it would actually save that much work.

[CharlieJV]

Although I can't think of a glowing use case for this, it has been on my mind for the last couple of days.

Code: (Select All)

_DISPLAY start_x, start_y, width, height

Would that be a useful thing?

Just to quickly demonstrate with BAM:

• Run the program
  
• View the source code
  

Oh,I forgot to mention: optional parameters.  When not specified, _display is for the whole guacamole.

[SMcNeill]

I'm with Matt on this.  I don't think this would be that useful in all honesty.  _PUTIMAGE would be much more practical to just put the image as you want to the display.

_DISPLAY 100, 100, 200, 200

Now with the above, are those absolute coordinates?  Or relative?  Does that showcase the display from (100,100)- (200,200) or does it showcase the display from (100,100)-(300,300)?

Does it *ONLY* show that portion of the screen, with the rest of the screen basically just blacked out?

Does it expand that portion of the screen so that it scales up to cover the whole display?  If it expands, does it keep aspect ratio?  stretch it?  skew it?  clip it?

If I put in the values backwards, can it display the image upside down?  Or mirrored?

_PUTIMAGE can easily be controlled to do any and all of these things, as well as blending and non-blending.

I just don't see what the use here would be.

[Gets]

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