Hardware vs Software Images

[TerryRitchie]

It's been a Loooong time since I have played around with hardware image capability in QB64, and even then it was in the experimental stage.

Just so I have this straight, once I have committed an image as hardware (mode 33) I can do nothing with that image except for displaying it (_PUTIMAGE, _MAPTRIANGLE), or copying it (_COPYIMAGE).

Even trying to set a hardware image as a source, to say read a POINT() from it will not work, correct?

If I need to make a change to a hardware image, I'll need to have a software image copy of it, make the changes on the software image, then once again convert the image to hardware with _COPYIMAGE to another handle. Is that correct?

[TerryRitchie]

So I take it no one is using hardware images. :)

I've confirmed through playing around that hardware images are in fact just for viewing.

[Omerta7486]

I think you may[/i] be able to _putimage from one hardware image to another. Don't quote me on that! Lol. But, no. You can't use any pixel level functions, or any chromatic or graphical functions.

[TerryRitchie]

You are correct. I've tested most of the scenarios out and it would seem the limit is what you state. Thanks for the feedback. :)

[TerryRitchie]

Another cool thing about hardware images ... they do not interact at all with software images.

Move a hardware image around on a software screen and the software screen is unaffected. No need to CLS  or restore the background at every iteration.

However, because of this behavior it was necessary for me to implement software and hardware sprites into my updated sprite library. Which is cool, because a programmer using the library can now tell the sprite which type it is and change that behavior at any time.

[FellippeHeitor]

Hardware images are so cool that you can even place them on SCREEN 0:

Code: QB64: [Select]

1. 'SCREEN 0 is 640x400 pixels
2. DIM SHARED circleImage&
3. temp& = _NEWIMAGE(50, 50, 32)
4. _DEST temp&
5. CIRCLE (25, 25), 20
6. PAINT (25, 25), _RGB32(255, 0, 0), _RGB32(255, 255, 255)
7. circleImage& = _COPYIMAGE(temp&, 33)
8. _FREEIMAGE temp&
9.  
10. DIM SHARED r AS INTEGER, c AS INTEGER
11. DIM SHARED rStep AS INTEGER, cStep AS INTEGER
12. DIM SHARED x AS INTEGER, y AS INTEGER
13. DIM SHARED xStep AS INTEGER, yStep AS INTEGER
14. DIM SHARED m$
15.  
16. r = 1: rStep = 1
17. c = 1: cStep = 1
18. x = 320: xStep = 5
19. y = 200: yStep = 5
20. m$ = "This is SCREEN 0!"
21. COLOR 15, 1
22.  
23. DO
24.     CLS
25.     IF TIMER - lastTextMovement > .2 THEN
26.         lastTextMovement = TIMER
27.         moveText
28.     END IF
29.     showText
30.  
31.     moveImage
32.     showImage
33.     _DISPLAY
34.     _LIMIT 30
35. LOOP
36.  
37. SUB moveText
38.     c = c + cStep
39.     IF c + LEN(m$) > 80 THEN c = c - 1: cStep = cStep * -1: COLOR INT(RND * 14) + 1
40.     IF c < 1 THEN c = c + 1: cStep = cStep * -1: COLOR INT(RND * 14) + 1
41.  
42.     r = r + rStep
43.     IF r > 25 THEN r = r - 2: rStep = rStep * -1: COLOR , INT(RND * 7) + 1
44.     IF r < 1 THEN r = r + 2: rStep = rStep * -1: COLOR , INT(RND * 7) + 1
45. END SUB
46.  
47. SUB showText
48.     LOCATE r, c
49.     PRINT m$;
50. END SUB
51.  
52. SUB moveImage
53.     x = x + xStep
54.     IF x + _WIDTH(circleImage&) > 640 THEN x = x - 1: xStep = xStep * -1
55.     IF x < 1 THEN x = x + 1: xStep = xStep * -1
56.  
57.     y = y + yStep
58.     IF y + _HEIGHT(circleImage&) > 400 THEN y = y - 1: yStep = yStep * -1
59.     IF y < 1 THEN y = y + 1: yStep = yStep * -1
60. END SUB
61.  
62. SUB showImage
63.     _PUTIMAGE (x, y), circleImage&
64. END SUB
65.  

I used the technique a lot in my ever under-development Spaceship game too.

[Pete]

What's the big deal? I always have a ball in SCREEN 0!

Pete :D

[FellippeHeitor]

[Gets]

I use hardware images, but like you pointed out, you mainly trade an increase in speed for a uniform drop in functionality. You also have to separate software and hardware graphic routines since they're displayed completely separately and there are some compatibility issues with hardware images that require running everything in software mode for some people. Can't just draw a few lines on top of a sprites, I have to store line data with the sprite, load it when rendering the sprite, and then draw them right before the screen is displayed. I'm assuming the issues are related to the old version of OpenGL QB64 uses, but I don't know how to detect the problem ahead of time or recreate it.

[TerryRitchie]

Can't just draw a few lines on top of a sprites, I have to store line data with the sprite, load it when rendering the sprite, and then draw them right before the screen is displayed. I'm assuming the issues are related to the old version of OpenGL QB64 uses, but I don't know how to detect the problem ahead of time or recreate it.

I'm not quite following what you mean here. Could you please elaborate more on this? I have not run into any issues yet because I'm still in the beginning stages of the library. Any heads up on issues I may encounter I am very interested in. Thanks :)

Edit: after reading a few times I think I see what you mean. Drawing a LINE(), or anything software related, will be drawn under the hardware image. Yes, I see that as a potential issue to overcome.

Hmmm... I suppose a second software screen would need to be maintained in the background that contains only those graphics you wish to overlay onto a hardware sprite. The portion of the screen where the sprite resides would need to be lifted and laid over top of the software sprite, then converted to a hardware sprite using mode 33. Yikes, I'll need to look into this.

[FellippeHeitor]

You can always change _DISPLAYORDER.

[TerryRitchie]

You can always change _DISPLAYORDER.

Will that work?

_DISPLAYORDER _HARDWARE, _SOFTWARE

The screen will always be software. If I need to refresh an entire background, any hardware images drawn will be completely covered by the software screen's background. Maybe?

Ok, I'll need to play around with this. Thanks for the idea Fellippe.

[FellippeHeitor]

Unless you CLS with a transparent color, then it's a transparent software screen with hardware images beneath.

Code: QB64: [Select]

1. CLS , _RGBA32(0, 0, 0, 0)
2. 'or
3. CLS , _RGB32(0, 0) 'valid for the latest dev build
4. 'or
5. CLS , 0

[Gets]

The main issues were related to the fact that hardware images won't work at all for some people though(don't know how common these issues are), and the solution was to manually keep all hardware and software graphic work separate,mimicking what _Displayorder would normally do. That way everything would function the same even if you couldn't use hardware images.

 Right now my programs are set up so that I only need to change one variable to  switch between a hardware and software version. When I first discovered it was an issue at all, it was with a program that was already completed and depended on _Displayorder to keep the graphics separated for me, so going back through the program and separating everything manually was a hassle.