Hardware vs Software Screens

[TerryRitchie]

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?

[FellippeHeitor]

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

Speed.

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.

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.

[TerryRitchie]

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.  
38. END SUB
39.  

[TerryRitchie]

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.

[FellippeHeitor]

Makes sense.

[TerryRitchie]

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. :)