Post by: bplus on November 14, 2019, 12:20:38 am
Code: QB64: [Select]
Attached is demo code for these:
[ This attachment cannot be displayed inline in 'Print Page' view ]
[ This attachment cannot be displayed inline in 'Print Page' view ]
Post by: Petr on November 14, 2019, 11:10:27 am
Post by: bplus on November 14, 2019, 11:43:04 am
Nice work, BPlus. Next method is with virtual screens and transparency + _PUTIMAGE.
Thanks Petr, looks like you want to go beyond bricks ;)
Post by: Petr on November 14, 2019, 11:45:37 am
Post by: SierraKen on November 14, 2019, 11:46:39 am
Post by: SierraKen on November 14, 2019, 11:51:24 am
Post by: bplus on November 14, 2019, 11:59:15 am
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
Post by: Petr on November 14, 2019, 12:00:50 pm
Post by: SierraKen on November 14, 2019, 01:23:08 pm
Post by: SMcNeill on November 14, 2019, 04:58:54 pm
_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. ;)
Post by: bplus on November 14, 2019, 05:07:01 pm
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]
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.
Post by: Petr on November 15, 2019, 09:39:52 am
Post by: SMcNeill on November 15, 2019, 10:46:16 am
Code: QB64: [Select]
- _DEST destHandle&
- _SOURCE imageHandle&
- _FREEIMAGE im1 'free the two temp images
- _FREEIMAGE im2 'free the two temp images
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. ;)
Post by: bplus on November 15, 2019, 11:28:08 am
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.
Post by: Petr on November 15, 2019, 11:29:16 am
Post by: SMcNeill on November 15, 2019, 11:46:02 am
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.
Honestly, I don’t either. The question about paint fills by Tempodi (and worked on by Petr), was the first time I’ve worked with SCREEN 12 in YEARS. Occasionally I’ll do stuff in 256 color mode, but anything less than that is just a PITA and a waste of time, IMHO...
I just thought it’d be nice to highlight an error-checking method for your code, in case anyone really wanted to use it in lower color modes, but it’s not something I’d actually plug into my own programs usually. For personal use, I tend to prefer speed over error-checking, with the assumption that if I do have problems with something, I can always debug it and add that extra functionality/protection later. ;)
Post by: bplus on November 15, 2019, 12:10:48 pm
eg the very idea of painting with images!
So I am not ever going to be snubbing code just because it's in an outdated screen mode.
Post by: TempodiBasic on November 16, 2019, 10:12:47 am
People please tell me, better a neutral color or a copy of the area of image to be overwritten if you work in 32bit mode?
Cool paintImage!
Post by: bplus on November 16, 2019, 11:01:08 am
Ah-a here is the idea that Steve uses to build Paint Tiling QB45 emulator for SCREEN 12!
People please tell me, better a neutral color or a copy of the area of image to be overwritten if you work in 32bit mode?
Cool paintImage!
Hi TempodiBasic,
When using this SUB in 32 bit color mode:
Code: QB64: [Select]
The only color to watch out for is _RGB(119, 24, 49), because to find the places to PAINT the image, the area at x, y is PAINTed first with that color to the Border~& color that should enclose x, y unless you want to paint to edges and have all other areas enclosed with Border~& color.
Post by: Petr on November 19, 2019, 01:47:10 pm
Code: QB64: [Select]
- 'function return unused color number, v.1
- _DEST img
- _DEST 0
- FreeColor = GETFREECOLOR~&(im32)
- SCREEN im32
- 'LINE (0, 0)-(500, 500), FreeColor, B 'uncomment both rows, paint color, which in original is not used and program correctly test himself as bad.
- 'PAINT (10, 10), FreeColor, FreeColor
- 'program correct functionality automatic test
- H$ = "Program OK"
- _MEMFREE n
- PRINT H$
- GETFREECOLOR~& = -1 'without definitions FreeColor in my loop and none free color it return -1~& (4294967295)
- CASE 1
- FRC = FRC + 1
- GETFREECOLOR = FRC
- CASE 4
- test = 2
- NEXT ic
- _MEMFREE m
- ERASE C32
- NEXT r
- NEXT b
- NEXT g
- NEXT a
Post by: bplus on November 19, 2019, 03:10:35 pm
I noticed you are testing for Alpha but neither POINT nor PAINT work with Alphas. As I mentioned previously, I was disappointed that even &H color constant values would not be recognized by POINT or PAINT even with full aplha 255 or FF. It sure would be nice if an invisible border color could be used to contain PAINTS so lines aren't left with paintImage.
Maybe you _MEMory guys can write _ALPHAPOINT and _ALPHAPAINT subroutines?
Here is another test with Brick Image:
Code: QB64: [Select]
Post by: Petr on November 19, 2019, 04:42:25 pm
Therefore, as you have noticed, my program for finding unused colors starts from alpha 255. :) OR use _DONTBLEND in program :)
What you want, PAINT with alpha, is practically a problem. Alpha shows the RGB color intensity depending on the background used. Therefore, you would have to write a complex algorithm that would not work on the principle of a uniform color boundary of the place where you do new color. I've tried to write something like my own PAINT in the past, but it's more complicated than I thought. (I stopped having fun with it, so this is uncomplete somewhere on my harddrive).
Principle of function, as I imagined it: Read the color number X, Y at the place where you want to color. Then from this point go to all sides (something as your maze search algorithm) and look for the positions of the points that have a different color than the color of the place you want to color. After you get the whole circuit completely, you paint it and color it. That's how PAINT works right now, just looking for a specific color. I suppose ALPHA would not mind such a function. The only thing she cares about is a different (any) color point than the default color (color in place where is coloring applyed. before color apply). How confirm, that circuit is complete? Hmm.... good ask :)
Post by: TempodiBasic on November 21, 2019, 06:12:16 pm
about this
Quote
I noticed you are testing for Alpha but neither POINT nor PAINT work with Alphas. As I mentioned previously, I was disappointed that even &H color constant values would not be recognized by POINT or PAINT even with full aplha 255 or FF.I can disagree because it seems that POINT works
Code: QB64: [Select]
- SLEEP 1
About why PAINT doesn't recognize BorderColor% because in Wiki BorderColor% can be also a Long32 and not only an integer
http://qb64.org/wiki/PAINT (http://qb64.org/wiki/PAINT)
moreover there is something broken in the PAINT command implementation for its alternating working well/bad
see here
Code: QB64: [Select]
but POINT seems to work in these examples.
Post by: TempodiBasic on November 21, 2019, 06:24:39 pm
Quote
Principle of function, as I imagined it: Read the color number X, Y at the place where you want to color. Then from this point go to all sides (something as your maze search algorithm) and look for the positions of the points that have a different color than the color of the place you want to color. After you get the whole circuit completely, you paint it and color it. That's how PAINT works right now, just looking for a specific color. I suppose ALPHA would not mind such a function. The only thing she cares about is a different (any) color point than the default color (color in place where is coloring applyed. before color apply). How confirm, that circuit is complete? Hmm.... good ask :)
what do you think of these different implementation of FloodFill ?
https://en.wikipedia.org/wiki/Flood_fill (https://en.wikipedia.org/wiki/Flood_fill)
I think that the 8 way direction implementation is far away from PAINT command, and you?
Post by: bplus on November 21, 2019, 07:12:17 pm
Here is my screen shot for code you say works:
BTW I understand why alpha should not work, it's not same color when overlaying other colors.
Post by: bplus on November 21, 2019, 09:28:33 pm
Code: QB64: [Select]
- 'CONST r1 = &HFFBB0000, r2 = &HFF00BB00 'OK paint works right with line box
- 'CONST r1 = _RGB32(200, 0, 0), r2 = _RGB32(0, 128, 0) ' <<<<<<< screws up doesn't even draw box!!!
- ' ok normal paint working
- ' and alpha paint NOT working
- 'r1 = _RGBA32(200, 0, 0, 200)
- 'r2 = _RGBA32(0, 128, 0, 200)
- SLEEP 1
Post by: bplus on November 22, 2019, 10:11:35 am
Code: QB64: [Select]
- 'CLS '<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< OHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH AHA!
- ' with CLS get match right off the bat! Remove comment ' and no testing needed.
- ' OK so POINT can read and match Alpha
- red2 = &H80FF0000
- a = a + 1
- COLOR &HFFFFFFFF
- PRINT "press any to awaken next... "
- PRINT "A match or Alpha ran all the way to 255, Test done."
OK so now I have to retest PAINT... with this fine POINT understood.
Post by: bplus on November 22, 2019, 10:35:39 am
Code: QB64: [Select]
- 'CONST r1 = &HFFBB0000, r2 = &HFF00BB00 'OK paint works right with line box
- 'CONST r1 = _RGB32(200, 0, 0), r2 = _RGB32(0, 128, 0) ' <<<<<<< screws up doesn't even draw box!!!
- ' ok normal paint working
- ' and alpha paint NOT working
- 'CLS '<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< might work now, nope!
- _DONTBLEND '<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< OK now???? YES but _DONTBLEND ruins transparency to make border lines invisible.
- SLEEP 1
Ha! I reread Petr's post and have retested pretty much what he had already said, sorry Petr some of us are slow readers (me).
I too tried my own PAINT algorithm a recursive one and crashed until limited checking to only one or two directions. So why not do one direction at a time, nope, tried and doesn't work either. I too am wondering how Pathfinding (and Fire and Minesweeper) worked so well because same deal, basically.
There must be a way, QB64 can do anything any other program can do, though might be slower....
Post by: bplus on November 22, 2019, 11:07:05 am
Hi Bplus
about thisI can disagree because it seems that POINT worksCode: QB64: [Select]
About why PAINT doesn't recognize BorderColor% because in Wiki BorderColor% can be also a Long32 and not only an integer
http://qb64.org/wiki/PAINT (http://qb64.org/wiki/PAINT)
moreover there is something broken in the PAINT command implementation for its alternating working well/bad
see hereCode: QB64: [Select]
but POINT seems to work in these examples.
OK TempdiBasic, POINT does work, thanks!
And it looks to me like where PAINT does work, your Border Color is full Alpha 255 and where it doesn't work your Border Color is not full Alpha.
Post by: SMcNeill on November 22, 2019, 02:55:27 pm
Code: QB64: [Select]
As you can tell, this doesn't fully fill our area for us, in all cases, but it does fill a large portion for us. At this point, all we should really need to do is run the routine recursively again around the end points of the square we've created. I was going to finish sorting it out, but my wife ended up in the hospital again with her asthma acting up terribly. I don't know how much free time I'll have until she gets home again, so I might not be able to follow-up and finish the concept for quite some time if nobody else is interested in doing it...
The advantage to running the routine in this manner is that it fills huge chunks of our screen at a time in boxes, without running recursively on each point. The number of recursive calls is going to be phenomenally smaller than what we'd have if we checked each point individually, and probably wouldn't run out of memory or stack space on us.
I won't promise that it'll work, but I think the concept is sound. ;)
Post by: Petr on November 22, 2019, 03:53:45 pm
I'd love to look at your concept, but it won't be right away. I have a visit that I have to give attention. So maybe in two days there will be time. May it all go well with your wife and she will soon be home. P.
Post by: TempodiBasic on November 22, 2019, 06:51:57 pm
Quote
And it looks to me like where PAINT does work, your Border Color is full Alpha 255 and where it doesn't work your Border Color is not full Alpha
yes this code confirm the theory of 255 alpha goodness!
Code: QB64: [Select]
Post by: TempodiBasic on November 22, 2019, 07:07:47 pm
about the idea to use _DONTBLEND
here is a workaround that must be coded in a function that stores and then draws back the frame of the area to be painted.
Code: QB64: [Select]
- 'CONST r1 = &HFFBB0000, r2 = &HFF00BB00 'OK paint works right with line box
- 'CONST r1 = _RGB32(200, 0, 0), r2 = _RGB32(0, 128, 0) ' <<<<<<< screws up doesn't even draw box!!!
- ' ok normal paint working
- ' and alpha paint NOT working
- 'CLS '<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< might work now, nope!
- CLS , back
- _DONTBLEND '<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< OK now???? YES but _DONTBLEND ruins transparency to make border lines invisible.
- SLEEP 1
- _BLEND ' reactivate alpha
Post by: SMcNeill on November 22, 2019, 07:13:50 pm
Code: QB64: [Select]
- fill 200, 200, &HFFFF0000, 0
- pass = 1
- Array(x, y) = pass
- finished = -1
- pass = pass + 1
This may not be so impossible to make use of, once it's optimized for _MEM. As it is now, it's good for a one time "change it and save it" type routine, but I definitely wouldn't rely on it for anything performance heavy.
Post by: TempodiBasic on November 22, 2019, 07:18:23 pm
Good Luck with illness of your wife!
I wish you'll come back at home together soon safe and healthy !
PS I find your idea genial and I think that we must adapt it for any kind of shape!
Post by: bplus on November 22, 2019, 08:18:21 pm
Non-Recursive PaintFill. At this point, it's slower than heck, but it works!Code: QB64: [Select]
This may not be so impossible to make use of, once it's optimized for _MEM. As it is now, it's good for a one time "change it and save it" type routine, but I definitely wouldn't rely on it for anything performance heavy.
And guess what guys, POINT fails us, try Steve's code with a transparent color for border color.
I just came up with similar non recursive and it fails because POINT fails. I tried border colors with _RGBA32 and with &H and even used the POINT color at the border of a box to be filled, they all fail to stop the fill.
Post by: bplus on November 22, 2019, 08:34:21 pm
Code: QB64: [Select]
- 'try each one of these, solids work transparents don't!
- 'ptGreen = _RGBA32(0, 128, 0, 5) 'transparent
- 'ptGreen = &HFF008000 'solid
- 'ptGreen = &HF0008000 'transparent
- 'ptGreen = POINT(510, 510) '<<<<<<<<try with or without comment
- sfill 515, 515, &HFFFF0000, ptGreen
- 'FOR i = 100 TO 100.75 STEP .25
- 'NEXT
- sfill 100, 100, &HFFFF0000, &HFFFFFFFF
- PRINT "done"
- DIM pass, finished
- pass = 1
- Array(x, y) = pass
- finished = -1
- pass = pass + 1
PS This was same test code I was using with my non recursive Fill but mine was leaking through diagonal neighbors so CIRCLE had to be triple walled or it leaked whereas B option in LINE worked without renenforced walls.
Post by: bplus on November 22, 2019, 08:43:32 pm
So our attempts at using an alternate routine for PAINT fill are futile until we get POINT figured out.
Post by: SMcNeill on November 22, 2019, 08:50:35 pm
PSET (x,y), _RGBA32(255,255,255,128)
Now, PSET that over a white background, a red background, and a black background. Is the color on your screen going to still be _RGBA32(255,255,255,128), or is it going to be a blended version of that color? Bright white (barely toned down), Pink, and then dull white/gray are going to be your screen colors. Using that value as a paint border isn’t going to work as that color doesn’t actually exist on your screen.
One important thing will *always* keep it from existing: the visible display doesn’t allow any alpha less than 255. At least, it hasn’t in any of my past testing.
Post by: bplus on November 22, 2019, 08:59:20 pm
Point isn’t failing; your bordercolor fails.
PSET (x,y), _RGBA32(255,255,255,128)
Now, PSET that over a white background, a red background, and a black background. Is the color on your screen going to still be _RGBA32(255,255,255,128), or is it going to be a blended version of that color? Bright white (barely toned down), Pink, and then dull white/gray are going to be your screen colors. Using that value as a paint border isn’t going to work as that color doesn’t actually exist on your screen.
One important thing will *always* keep it from existing: the visible display doesn’t allow any alpha less than 255. At least, it hasn’t in any of my past testing.
Then why are we making something to replace PAINT? I thought it was so we could use transparent border colors.
I was trying to be careful that the border was always over black.
Post by: SMcNeill on November 22, 2019, 09:04:44 pm
Then why are we making something to replace PAINT? I thought it was so we could use transparent border colors.
I was trying to be careful that the border was always over black.
I thought it was so could paint an image/texture over something, which is an ability PAINT doesn’t offer. (Or was just looking for a speedier alternative?)
Post by: bplus on November 22, 2019, 09:14:26 pm
What do you think? possible?
Post by: bplus on November 22, 2019, 09:38:31 pm
Code: QB64: [Select]
One of those dah... eureka moments. Spray paint a brickwall pattern:
Post by: TempodiBasic on November 24, 2019, 10:36:27 am
Go behind the limit of BorderColor% !
Yes put away the border and paint in the limit of the area!
[ This attachment cannot be displayed inline in 'Print Page' view ]
But what do you think about POINT? what is the point of POINT with alpha channell?
Do POINT read and bring back the fusion of more colors in the same pixel in alphachannel?
It is possible an empowered function _POINT that can distinguish between colors merged into the pixel? (I think no but I'm not expert and I have a poor knowledge of graphic hardware).
Thanks to read
Post by: bplus on November 24, 2019, 11:49:01 am
I am totally confused by POINT, it reports numbers correctly but according to Steve:
Quote
One important thing will *always* keep it from existing: the visible display doesn’t allow any alpha less than 255. At least, it hasn’t in any of my past testing.
It seems true in my test of using an Alpha (less than 255) for a border control both with PAINT and with fill routines.
So strange, it reports the right number but won't work in display???
Remember I tested it earlier in this thread when you complained about my comment about using POINT and detecting Alpha and the test said it could read alpha (over black) the same if over black, and you did have to CLS first for black background.
I don't know, another Life Mystery!
Post by: Petr on November 24, 2019, 12:26:37 pm
Post by: Petr on November 25, 2019, 10:23:56 am
Code: QB64: [Select]
- Fill 400, 200, &H4AEEC2F7
- Fill 400, 300, &HFFFFFF00
- Fill 1, 1, &HFFFFFFFF
- Fill 200, 440, &HE0FFFFFF
- Fill 400, 500, &HDF00FF00
- TYPE border
- 'z bodu plneni jede vpravo a udela caru od bodu plneni k okraji. Tyto body zapise do pole.
- 'from fill points X, Y go to right and draw line. This points are writed to array B.
- px = x: py = y
- B(i).X = px
- B(i).Y = py
- i = i + 1
- px = px + 1
- ' od x do prava
- '-----------------------------------------------------------------------------------------
- 'from fill points X, Y go to left, points are writed to array B, draw line.
- px = x: py = y
- B(i).X = px
- B(i).Y = py
- i = i + 1
- px = px - 1
- i = 0
- 'od X do leva
- 'Start in: REDIM (C).... from all points in array B fill to bottom. Write this points to array C.
- 'vyplni vechny body od predchozi linie plneni smerem dolu.
- Fx = B(i).X
- Fy = B(i).Y
- C(j).X = Fx
- C(j).Y = Fy
- Fy = Fy + 1
- j = j + 1
- i = i + 1
- NEXT p
- 'vyplni predchozi linie plneni smerem nahoru
- 'from all points in array B fill to ceiling. Write this points to array C.
- i = 0
- Fx = B(i).X
- Fy = B(i).Y - 1
- C(j).X = Fx
- C(j).Y = Fy
- Fy = Fy - 1
- j = j + 1
- i = i + 1
- NEXT p
- 'nize: z bodu v poli C jet vlevo a vpravo, nahoru a dolu.
- 'do this 4x:
- 'look if neigthbour point is BCK. Starting points are contained in Array C. Look to left, right, up and down. If this color is BCK, fill it until
- 'is color other than BCK. Write this points to array B. After then is S selected and loop go again. After then write values from array B to array C
- 'and search again. Total search: 4x.
- i = 0
- Fx = C(p).X
- Fy = C(p).Y
- Fx = Fx + Sx
- Fy = Fy + sy
- B(i).X = Fx
- B(i).Y = Fy
- i = i + 1
- NEXT s
- NEXT p
- C(L).X = B(L).X
- C(L).Y = B(L).Y
- NEXT search
- ERASE C
- ERASE B
Post by: bplus on November 25, 2019, 10:52:17 am
Looks like it just does the color it lands on at x, y, also looks pretty fast compared to my effort:
https://www.qb64.org/forum/index.php?topic=1914.msg111421#msg111421
Did you compare times with Steve's Magic filler?
Post by: Petr on November 25, 2019, 11:41:55 am
Code: QB64: [Select]
- PRINT "How to fill the black area in a circle now, without damaging the square? - others color borders"
- PRINT "Press key..."
- Fill 400, 530, &HADFFFFFF
- TYPE border
- 'z bodu plneni jede vpravo a udela caru od bodu plneni k okraji. Tyto body zapise do pole.
- 'from fill points X, Y go to right and draw line. This points are writed to array B.
- px = x: py = y
- B(i).X = px
- B(i).Y = py
- i = i + 1
- px = px + 1
- ' od x do prava
- '-----------------------------------------------------------------------------------------
- 'from fill points X, Y go to left, points are writed to array B, draw line.
- px = x: py = y
- B(i).X = px
- B(i).Y = py
- i = i + 1
- px = px - 1
- i = 0
- 'od X do leva
- 'Start in: REDIM (C).... from all points in array B fill to bottom. Write this points to array C.
- 'vyplni vechny body od predchozi linie plneni smerem dolu.
- Fx = B(i).X
- Fy = B(i).Y
- C(j).X = Fx
- C(j).Y = Fy
- Fy = Fy + 1
- j = j + 1
- i = i + 1
- NEXT p
- 'vyplni predchozi linie plneni smerem nahoru
- 'from all points in array B fill to ceiling. Write this points to array C.
- i = 0
- Fx = B(i).X
- Fy = B(i).Y - 1
- C(j).X = Fx
- C(j).Y = Fy
- Fy = Fy - 1
- j = j + 1
- i = i + 1
- NEXT p
- 'nize: z bodu v poli C jet vlevo a vpravo, nahoru a dolu.
- 'do this 4x:
- 'look if neigthbour point is BCK. Starting points are contained in Array C. Look to left, right, up and down. If this color is BCK, fill it until
- 'is color other than BCK. Write this points to array B. After then is S selected and loop go again. After then write values from array B to array C
- 'and search again. Total search: 4x.
- i = 0
- Fx = C(p).X
- Fy = C(p).Y
- Fx = Fx + Sx
- Fy = Fy + sy
- B(i).X = Fx
- B(i).Y = Fy
- i = i + 1
- NEXT s
- NEXT p
- C(L).X = B(L).X
- C(L).Y = B(L).Y
- NEXT search
- ERASE C
- ERASE B
I didn't compare speed with Steve. There's no point in proving I'm better :) (THIS IS JOKE!)
Frankly, I will use this function to draw an image, and then I will put the finished image on the screen in a program. Using color filling while running a program is nonsense. This is an unnecessary load on the processor. I will not solve the speed, I will solve the fill - so as in the QB4.5. I do not share claim, that working with a program below 256 colors is a waste of time. Not for me.
Post by: TempodiBasic on November 25, 2019, 01:29:57 pm
Quote
Just a note. Each _NEWIMAGE screen has a RGBA32 background 0,0,0,0, this changes to 0,0,0,255 when CLS is used.i'll go on and I try this study of POINT in SCREEN 32bit
Code: QB64: [Select]
with this results
[ This attachment cannot be displayed inline in 'Print Page' view ]
but tiese results show that in screen 32bit the color are merged to that are yet on the screen so as Petr suggests before original black background is RGBA 0 0 0 0 while after CLS it becomes 0 0 0 255 getting a different value with POINT!
Good this!
[ This attachment cannot be displayed inline in 'Print Page' view ]
and this one !
[ This attachment cannot be displayed inline in 'Print Page' view ]
Post by: SMcNeill on November 25, 2019, 02:26:36 pm
Post by: TempodiBasic on November 25, 2019, 04:52:50 pm
Thanks for tip so we can force to use black RGBA 0,0,0,0
result after CLS,0 is the same as in original screen 32bit
[ This attachment cannot be displayed inline in 'Print Page' view ]