Text Only | Text with Attachments

QB64.org Forum

Active Forums => QB64 Discussion => Topic started by: TerryRitchie on September 27, 2018, 12:41:33 pm

Title: Hardware vs Software Screens
Post by: TerryRitchie on September 27, 2018, 12:41:33 pm
The subject is a bit misleading, but here is my situation.

I'm currently working on adding layers to the sprite library. Think of each layer as a separate screen where sprites and other objects designated as belonging to a layer do their thing only on that layer. Sprites on layer 3 for instance can't interact (collide) with sprites on layer 4. Other layers could be used for scrolling backgrounds to create parallax scenery, etc..

Each layer consists of a software and hardware image. The software image is used for software based sprite images, drawing commands (CIRCLE, LINE, etc..), background images, and any other software based images. The hardware layer is used just before a display update by copying the software image to a hardware image (33) and then displaying that layer on the screen. Since hardware sprite images don't actually "attach" themselves to a software based image when using _PUTIMAGE they are not drawn until all software layers have been drawn, converted to hardware, and then displayed.

My question is: is there any real benefit to converting the layers to hardware before displaying?

I'm beginning to wonder if there is even a need for any sprite to be software based at all.

In my loop where software and hardware sprites are drawn before updating the screen, do I need to identify and draw software sprites first, then identify hardware sprites and draw them after the layer's have been merged, or will _DISPLAYORDER _SOFTWARE _HARDWARE take care of this for me?

I don't know why I am having difficulty wrapping my head around this, but something just doesn't seem right with the way QB64 handles software and hardware images and the way they interact, or is that just stinkin' thinkin' on my part?
Title: Re: Hardware vs Software Screens
Post by: FellippeHeitor on September 27, 2018, 01:21:03 pm
Quote
My question is: is there any real benefit to converting the layers to hardware before displaying?

Speed.

Quote
I'm beginning to wonder if there is even a need for any sprite to be software based at all.

Everything will be faster if you convert everything to hardware before displaying.

Quote
In my loop where software and hardware sprites are drawn before updating the screen, do I need to identify and draw software sprites first, then identify hardware sprites and draw them after the layer's have been merged, or will _DISPLAYORDER _SOFTWARE _HARDWARE take care of this for me?

Everything software will go to the software layer and everything hardware to the hardware layer. Then they'll be shown according to your instruction with _DISPLAYORDER.
Title: Re: Hardware vs Software Screens
Post by: TerryRitchie on September 27, 2018, 01:25:04 pm
Here is the routine that currently handles updating the layers before displaying to screen.

- Update software sprites by having them drawn to their respective layer
- Make the destination the display screen
- Create a temporary image to merge all the layers onto (merge)
- Cycle through the layer in reverse order (larger numbered layers sit lower in the field)
- Merge the layers onto the temporary image
- Create a hardware image of the merged layers (hardware)
- Place the hardware image on the destination display screen
- Remove the temporary software and hardware images
- Update hardware sprites by having them drawn to the destination display screen
- Display the final results (_DISPLAY)

Any thoughts?

Code: QB64: [Select]
  1. '    ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
  2. SUB SL_DISPLAY () '                                                                                                                                                                          SL_DISPLAY
  3.     'ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
  4.  
  5.     ' declare global variables
  6.  
  7.     SHARED SL_layer() AS SL_LAYERS '    master layer array
  8.     SHARED SL_global AS SL_GLOBAL '     common globals array
  9.  
  10.     ' declare local variables
  11.  
  12.     DIM layer AS INTEGER '              layer counter
  13.     DIM odest AS INTEGER '              original destination
  14.     DIM merge AS LONG '                 software image to merge all layers onto
  15.     DIM hardware AS LONG '              hardware image of merged layers to place on working screen
  16.  
  17.     SL_update_auto_sprites -1 '                                                          (SL_SOFTWARE)  update all software automatic sprites
  18.     odest = _DEST '                                                                                     save original destination
  19.     _DEST SL_layer(0).image '                                                                           working screen is destination
  20.     merge = _NEWIMAGE(SL_global.swidth, SL_global.sheight, 32) '                                        create screen to merge layers
  21.     layer = UBOUND(SL_layer) '                                                                          reset layer counter
  22.  
  23.     DO '                                                                                                cycle through layers backwards (high to low)
  24.         IF SL_layer(layer).visible THEN '                                                               is this layer visible?
  25.             _PUTIMAGE , SL_layer(layer).image, merge '                                                  merge this layer
  26.         END IF
  27.         layer = layer - 1 '                                                                             decrement layer counter
  28.     LOOP UNTIL layer = 0 '                                                                              leave when all layers merged
  29.  
  30.     hardware = _COPYIMAGE(merge, 33) '                                                                  create hardware image of merged layers
  31.     _PUTIMAGE , hardware '                                                                              place hardware image on working screen
  32.     _FREEIMAGE merge '                                                                                  merged software image no longer needed
  33.     _FREEIMAGE hardware '                                                                               merged hardware image no longer needed
  34.     SL_update_auto_sprites 0 '                                                           (SL_HARDWARE)  update all hardware automatic sprites
  35.     _DEST odest '                                                                                       restore original destination
  36.     _DISPLAY '                                                                                          update display screen with changes
  37.  
  39.  
Title: Re: Hardware vs Software Screens
Post by: TerryRitchie on September 27, 2018, 01:27:18 pm
Thanks Fellippe. So I do want to maintain hardware for speed as I will notice a difference.

In that case I'm going to remove the need for software sprites all together. Software images will only be used for updating the layers themselves.
Title: Re: Hardware vs Software Screens
Post by: FellippeHeitor on September 27, 2018, 01:29:46 pm
Makes sense.
Title: Re: Hardware vs Software Screens
Post by: TerryRitchie on September 27, 2018, 01:41:43 pm
To this end I will incorporate "objects" into the library. An object will be a software image (sprite, background image, etc..) used to draw onto a layer. Objects will have the ability to be retrieved from a sprite sheet (think textures and sprite images to build maps), or be loaded directly from a file (such as a background image). An object's location and characteristics will be maintained so sprites can interact with them (a maze built from objects for instance).

Thanks Steve for the suggestion of turning this into a game creation tool. I haven't had this much fun since my last visit to the dentist. LOL JK  Seriously though, I love the challenge this is providing.

Oh boy, back to the code for another major change. :)
Text Only | Text with Attachments