|
Post by n00b on Nov 19, 2020 9:11:36 GMT -6
I mentioned those functions because of how they work. The only exception to this is using CanvasClip. With CanvasClip you can set flag to 1 to avoid the slowdown. So try to replace WindowClip with CanvasClip if you are using it.
As for why WindowClip, FloodFill, and GetPixel are slow in RCBasic, it is because of how RCBasic works. RCBasic uses hardware accelerated rendering which means that Canvases, images, and fonts are textures in GPU memory. It makes drawing sprites really fast and doing raster effects on images and canvases really fast. But it also means that to access pixel data in the textures, the texture data has to be pulled from GPU memory into RAM. This process is slow.
WindowClip, FloodFill, and GetPixel all need to access pixel data in a texture in order to work. CanvasClip will also do this if flag is set to 0 but if you set flag to 1 in CanvasClip it will just copy that portion of texture to a new texture without accessing the pixels. The only downside to setting flag to 1 is that if you have opened up multiple windows with WindowOpen, the only window that will be able to access the image created with CanvasClip is the one that CanvasClip was used in. Most people only have one window open so this is recommended for anybody that needs to use CanvasClip.
WindowClip, FloodFill, and GetPixel should not be used in places where they are called repeatedly unless performance is not important for your program.
If you can explain what you are using GetPixel for, me or some of the other senior members here can help you code a better solution.
|
|
|
Post by rosy on Nov 20, 2020 7:30:09 GMT -6
For collision checking, of course. After all, if the image is on the screen, it is enough to read the data from the screen memory ...
|
|
|
Post by tbird on Nov 20, 2020 9:16:14 GMT -6
Your best bet is Box or circle collision, as n00b has already said GetPixel is a very slow routine to call. Do you require that level of accuracy?
|
|
|
Post by n00b on Nov 20, 2020 9:32:37 GMT -6
I actually used the Box method tbird is talking in all the games in the example folder. If you need more accuracy you can make your box a more complex polygon. It will still be several times faster than using GetPixel.
|
|
|
Post by rosy on Nov 20, 2020 14:07:41 GMT -6
But I guess I need to know the position of the object I'm checking but I don't know ...
In the next step I used CanvasClip instead of WindowClip and the picture can be seen (although instead of yellow it is blue), but for a change, collision detection on android does not work ...
|
|
|
Post by johnno56 on Nov 20, 2020 16:31:30 GMT -6
Hmm... Polygon collision... Never tried that one... Sounds like fun...
Rosy. You are correct. Other than using GetPixel(), you would need to know the co-ordinates of the 'other' object. Imagine you are using a 100x100 pixel square and want to use GetPixel() to check collision with another object. Technically, the computer would need to "keep track" of the 100 pixels on the "leading" side of the square and check to see if any of them are contacting the other object. A simple AABB (Axis Aligned Bounding Box) routine only needs to "keep track" of the corners of the objects being tested. In this example, both squares co-ordinates are "known", and only 8 co-ordinates need to be checked. (Colour is not an issue) As you can imagine, checking 8 co-ordinates as opposed to 100 co-ordinates, will be much faster. Circular collision only needs to know the center of each circle and the radius of each circle. Throw in a bit of Pythagoras, to test the distance between... Done. When running on a device that is, by comparison, slower than a PC, it would be wise to use a more efficient method of collision detection... In my opinion...
If you already know this, please do not interpret my suggestion, as condescending. As I do not know you personally, I have to proceed from the premise, that you may not know. No insult was intended.
J
|
|
|
Post by rosy on Nov 20, 2020 16:56:30 GMT -6
And who said that through GetPixel I can't check only the corners? I check 2 or 4 corners And for example, the road has the width of the screen, i.e. min. 2x640 points I would have to remember ...
There is probably a scaling problem in Android again. The canvas is scaled, and in GetPixel it probably works on physical coordinates.
The getpixel function to read data from the canvas would be handy. It would work without even updating the screen.
|
|
|
Post by johnno56 on Nov 20, 2020 20:14:20 GMT -6
No argument from me... GetPixel() is very capable...
I remember an old "lander" program I used only 2 points of reference. The extreme ends of the two landing struts. Unless both points were touching the landing pad, it registered as a crash. It was simple but got the job done...
|
|
|
Post by n00b on Nov 21, 2020 1:35:09 GMT -6
rosy - GetPixel is working on the scaled coordinates, not the physical ones. The canvas is scaled to fit the screen but it has the same size in memory you set it to. You can get the actual resolution of your screen with GetDesktopDisplayMode() and adjust the size of your window and canvases based on that if you don't want it to be scaled. And while GetPixel() may be a good solution on software rendering, it is extremely slow when using the GPU. To get the most performance out of your code you should consider rewriting your collision detection to remove constant calls to GetPixel(), especially if you are trying to port to Android or IOS. UPDATE: I think I found a bug in GetPixel on Android/IOS. I am looking into it now. It should be fixed with the next release.
|
|
|
Post by rosy on Nov 21, 2020 9:13:39 GMT -6
What is this bug and when will there be a new version?
If it works on canvas, why is it necessary to update first? Better to be able to check before update.
|
|
|
Post by n00b on Nov 21, 2020 19:07:14 GMT -6
The bug was in where is was reading the pixel color from on mobile. As for when the next release will be available, hopefully before the end of the year but I can't say for sure. I don't have a great record of pushing new releases in a timely manner.
|
|
|
Post by rosy on Nov 22, 2020 3:25:13 GMT -6
So GetPixel won't work now?
And CanvasClip could also run without the need for Update ...
|
|
|
Post by n00b on Nov 22, 2020 11:20:00 GMT -6
CanvasClip pulls from the canvas so Update is not needed. Update is needed for WindowClip because Update draws the canvases on the window. It also does a few other things like get keyboard and mouse events so it should be called atleast once in your main loop but often does not need to be called more than that.
|
|
|
Post by rosy on Nov 22, 2020 16:04:20 GMT -6
I update every 4 runs
|
|
|
Post by rosy on Nov 23, 2020 10:44:01 GMT -6
A tragedy with this Android. A lot of things work wrong. Problems with speed (GetPixel falling asleep does not change anything), garbage appears on the 2nd canvas despite cleaning, 3rd canvas is not visible at all, wrong colors, etc.
|
|