Codesnippets > 2D-snippets

2D drawdisc() drawcircle()

<< < (2/6) > >>

sf-in-sf:
I find the alpha plotting too slow. To go fast, we would need to be more direct and use a pointer to the drawing surface memory location. Then the symetry trick would make sense, I think.
I don't know how to do it in practice. In GLb are we allowed to go down to such a low level C procedure? Would android -in java- accept it?

fuzzy70:
SETPIXEL is the problem with regards to being the major speed killer.

I have been looking at your code & thinking of ways of how to speed it up, not got down to writing code as of yet but trying out things in my head. Symmetry would speed things up but with various degrees of increase, for example the increase would be at it's maximum effect if the whole object fitted on the screen whereas the minimum increase would be something like only a quarter of the circle being visible (defeats the point of symmetry if none of it gets seen or plotted).

As it stands with your code you check at the start of the function what is visible & only plot what's going to be visible on screen. To me that would have to be modified or removed for it to work with symmetry, or possibly kept & the symmetry points checked at runtime to see if they are visible. The problem with the latter approach is that the extra checks (4 checks for 4 point symmetry & 8 checks for 8 point) will eat into the gains of symmetry thanks to the extra code, by how much I do not know until I test it for real but I think it will still be faster than non-symmetric circles.

Sorting out the plotting speed might possibly be solved by either using MEM2SPRITE or openGL. The 1st I have used numerous times before & while the MEM2SPRITE command does have an overhead I have not come across a time yet where it has been slower than plotting pixels using SETPIXEL. Check my post http://www.glbasic.com/forum/index.php?topic=8670.0 with a simple test I done with drawing a mandelbrot with colour cycling. My 1st version of that used SETPIXEL & seriously struggled to hit 5FPS I think it was, may have been slightly faster or slower I can't remember but was nowhere near as fast as the MEM2SPRITE  version.

I can't really help on the openGL side of things or if you would gain any kind of speed increase but only mentioned it in case someone reading this with knowledge of using it can confirm or deny if it would benefit it's use.

Hopefully in the next couple of days I will be able to play around with a MEM2SPRITE version, a symmetry version & probably a combo of both to see if/how much a speed increase can be made.

Lee

bigsofty:

--- Quote from: sf-in-sf on 2013-Mar-25 ---In GLb are we allowed to go down to such a low level C procedure? Would android -in java- accept it?

--- End quote ---

Yes, GLBasic uses C, even on Android. Just remember to stick within the constraints of GLES 1.1 API when the target is a mobile platform.

Brick Redux:

--- Quote from: fuzzy70 on 2013-Mar-25 ---SETPIXEL is the problem with regards to being the major speed killer.
--- End quote ---

Drawline seemed to speed things up(instead of Setpixel) when I was using MEM2SPRITE for image editing. Even when plotting a single point. The only other solution on offer seemed to be Inline code that turns off Setpixels Safe mode.  Playbasic for example has a fast fill command that uses this. (But its limited in its use.)

sf-in-sf:

--- Code: (glbasic) ---// We need something like
POKE 53280, 0
im_loc% = VARPTR(my_foot_image_73052)
// same with VARSEG
POKE im_loc, 0xB787
--- End code ---

Hi guys!
As the bear says, "sorry for the long paws!"... :D...  Eventually I'm back after a test of MEM2SPRITE. Good news: yes it speeds things up. I get a constant 2.2 fps at 1.1 GHz or so, and a 800x600 window -no double glazing, sorry.
But the constant fps is not normal, regardless whether a huge circle/ellipse or a tiny dot has been printed. It means that the plotting job to the array[] is very fast (only tested with no alpha, oh lazy me), but the rest is slow. Can DRAWSPRITE be so slow? Mmmh... I don't think so but need to check. If not, MEM2SPRITE would be the slow element (?...).
//*******
Anyway, I'd like to find a fast way to do it, for an app. Please can anyone help us? How can I find (in inline C) the pointer to the back buffer, so that I can plot directly into it instead of {into the array[], then MEM2SPRITE, then DRAWSPRITE, then SHOWSCREEN}?
If this question was tricky or cheeky, here is another option: 1) with CREATESCREEN I create a sprite to the right size. 2) Again, what is the pointer to that sprite? Pleeeeeeease!...
And thanks in advance.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version