Text Only | Text with Attachments

QB64.org Forum

Active Forums => QB64 Discussion => Topic started by: TerryRitchie on September 07, 2018, 12:58:25 am

Title: Hardware vs Software Images
Post by: TerryRitchie on September 07, 2018, 12:58:25 am
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?
Title: Re: Hardware vs Software Images
Post by: TerryRitchie on September 07, 2018, 10:29:04 pm
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.
Title: Re: Hardware vs Software Images
Post by: Omerta7486 on September 10, 2018, 11:55:13 pm
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.
Title: Re: Hardware vs Software Images
Post by: TerryRitchie on September 11, 2018, 12:11:23 am
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. :)
Title: Re: Hardware vs Software Images
Post by: TerryRitchie on September 14, 2018, 02:19:22 pm
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.
Title: Re: Hardware vs Software Images
Post by: FellippeHeitor on September 14, 2018, 02:49:50 pm
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)
  9.  
  11. DIM SHARED rStep AS INTEGER, cStep AS INTEGER
  13. DIM SHARED xStep AS INTEGER, yStep AS INTEGER
  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.  
  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
  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
  46.  
  47. SUB showText
  48.     LOCATE r, c
  49.     PRINT m$;
  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
  61.  
  62. SUB showImage
  63.     _PUTIMAGE (x, y), circleImage&
  65.  

I used the technique a lot in my ever under-development Spaceship game (https://github.com/FellippeHeitor/Spaceship) too.
Title: Re: Hardware vs Software Images
Post by: Pete on September 14, 2018, 02:56:06 pm
What's the big deal? I always have a ball in SCREEN 0!

Pete :D
Title: Re: Hardware vs Software Images
Post by: FellippeHeitor on September 14, 2018, 04:23:43 pm
Title: Re: Hardware vs Software Images
Post by: Gets on September 14, 2018, 06:23:33 pm
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.
Title: Re: Hardware vs Software Images
Post by: TerryRitchie on September 14, 2018, 11:22:56 pm
Quote from: Gets on September 14, 2018, 06:23:33 pm
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.
Title: Re: Hardware vs Software Images
Post by: FellippeHeitor on September 14, 2018, 11:50:42 pm
You can always change _DISPLAYORDER.
Title: Re: Hardware vs Software Images
Post by: TerryRitchie on September 14, 2018, 11:59:17 pm
Quote from: FellippeHeitor on September 14, 2018, 11:50:42 pm
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.
Title: Re: Hardware vs Software Images
Post by: FellippeHeitor on September 15, 2018, 12:02:42 am
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
Title: Re: Hardware vs Software Images
Post by: Gets on September 15, 2018, 01:55:04 am
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.
Text Only | Text with Attachments