Paint Image

[bplus]

Turned out pretty easy!

Code: QB64: [Select]

1. SUB paintImage (x, y, Border~&, destHandle&, imageHandle&)
2.     _DEST destHandle&
3.     PAINT (x, y), _RGB32(119, 24, 49), Border~&
4.     FOR y = 0 TO _HEIGHT(destHandle&)
5.         FOR x = 0 TO _WIDTH(destHandle&)
6.             _SOURCE destHandle&
7.             IF POINT(x, y) = _RGB32(119, 24, 49) THEN
8.                 _SOURCE imageHandle&
9.                 PSET (x, y), POINT(x MOD _WIDTH(imageHandle&), y MOD _HEIGHT(imageHandle&))
10.             END IF
11.         NEXT
12.     NEXT
13. END SUB
14.  

Attached is demo code for these:
 

 

[Petr]

Nice work, BPlus. Next method is with virtual screens and transparency + _PUTIMAGE.

[bplus]

Nice work, BPlus. Next method is with virtual screens and transparency + _PUTIMAGE.

Thanks Petr, looks like you want to go beyond bricks ;)

[Petr]

I am pleased, that you know, where I use it :)

[SierraKen]

Incredible graphics, but I have no idea how you did that. LOL

[SierraKen]

I just tried it and got an Invalid Handle on Line 79. But you got some awesome code there. Reminds me of how I used POINT to make text larger. I wonder if it's because I put all the files in their own directory?

[bplus]

I just tried it and got an Invalid Handle on Line 79. But you got some awesome code there. Reminds me of how I used POINT to make text larger. I wonder if it's because I put all the files in their own directory?

Sounds like the image file didn't load which most likely cause is that under the Run menu of IDE > there is no bullet next to "Output EXE to Source Folder" so when you compiled the program the exe went to QB64 folder instead of the download folder with the image files.

And yes I did use that trick for blowing up text for the "B+" graphic part. ;) I have made a sub of that so I can print sized text anywhere, probably should have used it :D

[Petr]

Oh, deleted, my faul.

[SierraKen]

Yep bplus, that was the problem lol. Man that's amazing stuff, good job!

[SMcNeill]

A few points here (as I happily steal and repurpose this code for my own demo)...

_RGB32(119, 24, 49) —>  Just make these _RGB commands (no 32), and you can use this in other screen modes (like SCREEN 12 or 256-color mode).  Only thing to watch for is if the fill color is used elsewhere in the program.  In 32-bit mode, that _RGB color isn’t very likely to be used previously (a simple generation of a random color, and a check to make certain it’s not in use could eliminate all “paint bleeds”), but as we reduce our color palette smaller, it’s more likely to fill wrong areas...

I haven’t looked at Petr’s fill routine yet, but it might work better in lower colors modes, without the worry of bad fills.  I’ll need to check it out later.  ;)

Point 2: Get _DEST and _SOURCE at the start of the sub, and then restore them at exit time, if you want the routine to be more portable.  ;)

[bplus]

A few points here (as I happily steal and repurpose this code for my own demo)...

_RGB32(119, 24, 49) —>  Just make these _RGB commands (no 32), and you can use this in other screen modes (like SCREEN 12 or 256-color mode).  Only thing to watch for is if the fill color is used elsewhere in the program.  In 32-bit mode, that _RGB color isn’t very likely to be used previously (a simple generation of a random color, and a check to make certain it’s not in use could eliminate all “paint bleeds”), but as we reduce our color palette smaller, it’s more likely to fill wrong areas...

I haven’t looked at Petr’s fill routine yet, but it might work better in lower colors modes, without the worry of bad fills.  I’ll need to check it out later.  ;)

Point 2: Get _DEST and _SOURCE at the start of the sub, and then restore them at exit time, if you want the routine to be more portable.  ;)

Thanks Steve, I was just going to post your improvement:

Code: QB64: [Select]

1. SUB paintImage (x, y, Border~&, destHandle&, imageHandle&)
2.     d = _DEST: s = _SOURCE
3.     _DEST destHandle&
4.     PAINT (x, y), _RGB(119, 24, 49), Border~&
5.     FOR y = 0 TO _HEIGHT(destHandle&)
6.         FOR x = 0 TO _WIDTH(destHandle&)
7.             _SOURCE destHandle&
8.             IF POINT(x, y) = _RGB(119, 24, 49) THEN
9.                 _SOURCE imageHandle&
10.                 PSET (x, y), POINT(x MOD _WIDTH(imageHandle&), y MOD _HEIGHT(imageHandle&))
11.             END IF
12.         NEXT
13.     NEXT
14.     _DEST d: _SOURCE s
15. END SUB
16.  

I caught the saving and restoring _SOURCE and _DEST but missed the _RGB switch, dropping 32.

Update: Just checked Steve's improvements with the demo test code and ran fine, so that makes this version the best so far.

[Petr]

And from that, what you write, BPlus and Steve, it shows an option for MEM and a feature that quickly finds an unused combination of RGB colors to prevent malfunction :-)

[SMcNeill]

Here's a version of your paint image routine which I think would probably be "image bleed" proof:

Code: QB64: [Select]

1. SUB paintImage (x, y, Border~&, destHandle&, imageHandle&)
2.     DIM d AS INTEGER, s AS INTEGER
3.     DIM w AS INTEGER, h AS INTEGER
4.     DIM c1 AS _UNSIGNED LONG, c2 AS _UNSIGNED LONG
5.     DIM p1 AS _UNSIGNED LONG, p2 AS _UNSIGNED LONG
6.     DIM im1 AS INTEGER, im2 AS INTEGER
7.     d = _DEST: s = _SOURCE
8.     w = _WIDTH(destHandle&): h = _HEIGHT(destHandle&)
9.     c1 = _RGB(119, 24, 49): c2 = _RGB(124, 49, 119)
10.     im1 = _COPYIMAGE(destHandle&): im2 = _COPYIMAGE(destHandle&)
11.  
12.     _DEST im1: PAINT (x, y), c1, Border~& 'paint one background one color
13.     _DEST im2: PAINT (x, y), c2, Border~& 'paint a second background a different color
14.     _DEST destHandle&
15.     w = _WIDTH(imageHandle&): h = _HEIGHT(imageHandle&)
16.     FOR y = 0 TO _HEIGHT(destHandle&)
17.         FOR x = 0 TO _WIDTH(destHandle&)
18.             _SOURCE im1: p1 = POINT(x, y) 'check for proper color on one background
19.             _SOURCE im2: p2 = POINT(x, y) 'check for proper color on second background
20.             IF p1 = c1 AND p2 = c2 THEN 'if both our backgrounds match the expected colors then
21.                 _SOURCE imageHandle&
22.                 PSET (x, y), POINT(x MOD w, y MOD h) 'paint the destination with our image
23.             END IF
24.         NEXT
25.     NEXT
26.     _DEST d: _SOURCE s
27.     _FREEIMAGE im1 'free the two temp images
28.     _FREEIMAGE im2 'free the two temp images
29. END SUB

Instead of painting the background of our original destination _RGB(119, 24, 29), we instead make a copy of the background and paint that copy.  Then, for error checking, we take a second copy of the original background, and paint it a second color...

Only in areas where those two changes overlap, do we actually paint our image onto the original background.

The end result works so that if our whole screen was _RGB(119, 24, 29) to begin with, we'd still only paint in the desired area, and not paint our pattern across the whole screen.  It's going to be a lot slower than what you had originally (we're copying and freeing images, painting three times in total, and getting point values from multiple screens for comparisons), but it's going to be more reliable if we're working on screens with a reduced color palette (like the SCREEN 12 which I was using for paint fill elsewhere).

It's a tradeoff of speed for safety, and I wouldn't want to use this version as a fill routine inside a game loop (I imagine your FPS would drop considerably), but it'd work nice as a simple routine to plug in and use to fill an area once, so you can use it for something else in your code elsewhere.  ;)

[bplus]

Hi Steve,

Frankly my dear, I don't give a damn about SCREEN 12 mode. ;-))

Why in the wide world would you willingly and wistfully waste wonderful color options in graphics 32 for 16 colors? 0 alpha!?!? And further, be restricted in screen size to one.

If an image happens to "bleed" in a point or two, that actually might create a really cool effect, but a the sub does need a proper warning not to use the one off color allot or change the PAINT color to different if need to use _RGB(119, 24, 49)

BTW I was disappointed to learn that POINT does not recognize &H color constants, I had to switch code to _RGB32 colors in my testing of the SUB. To me, that is a bigger problem with this sub for 32 bit graphics users.

[Petr]

Thank you Steve. I started writing a function that returns the number of the first unused color in the image (or -1 if there is no free color). This resulted in my question on flashing colors in text mode. If I have a function that returns a free color number, I will ensure correct operation for both the BPlus and my image fill methods, that also use PAINT; So both methods require using an free (in image unused) color.