Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

In this Discussion

Tagged

Draw algrithms not always refreshed
  • TapsiTapsi
    Posts: 8

    Quite simple, I update code in the draw function and some draw functions will not be called. Solution is to close the app ( also from task managerm) and restarting it, then the draw code will be drawn correctly.

    Device : iPad1 Os: iOS 5

  • SimeonSimeon
    Posts: 3,732

    Is it mainly ellipse() calls? I've started to see this happening too.

    I notice that if I draw a rect() before the ellipse, then it shows up. Seems to be some sort of state bug and I'm looking into it.

  • TapsiTapsi
    Posts: 8

    Yep.

    After I outsourced some calculations into an outside function and called this in the draw function itself, all goes fine and faster. I can post my code later, if it helps to reproduce the problem.

    EDIT:: Btw, hope you're not angry if I'm post always some hints and ideas :P Ahm, I would advise to add a thrid predefined function into the MAIN script. This should be update( int delay ) and should be called before the draw function is called. This would be more compatible with an entity system, that normaly contains update and draw logic. ( as an idea ^^ )

  • SimeonSimeon
    Posts: 3,732

    Wouldn't it be update(float delta)?

    This is possible, but would't it essentially be the same as doing the following?

    --
    function draw()
        update(DeltaTime)
        -- Drawing here
    end
    
  • TapsiTapsi
    Posts: 8

    Yeah this what I do atm.
    I saw, if you paste the content of the update function directly into the draw function, the draw speed will be low and some times buggy. If I outsource my logic, then all runs fast and fine. But I can't understand why this runs so much slower ( if the update content is in the draw function )....
    The code will be compiled to lua bytecode at start, or not? If the draw function will be interpreted at every step, then I could understand why it is slower with update content in it.
    But this should be added to your future tutorials. That the users should the above way of insert an update function :)

    But maybe I'm the only one with that problem xD

  • SimeonSimeon
    Posts: 3,732

    That is very odd. Do you have an example that runs slower when the the update code is inlined into the draw function? It would be interesting to have a look at. Also is this iPad 1 or 2?

  • TapsiTapsi
    Posts: 8

    I updated my example, but I try to reproduce it tomorrow and will share the source here. I have an iPad 1. :)

  • I've been seeing this problem a lot lately. I have a "Waterfall" class that fills the screen with images that are 720 pixels wide and 1 pixel high. I started using the images as a replacement for a similar method that used ellipses. The draw performance with ellipses was poor but with images I can update the screen much faster. The program draws a line of data at the top of the screen and then moves it down one pixel when the next draw occurs. Old data is always moved down and new data is always inserted at the top of the screen (water-falling). I do a pre-fill at the beginning of the code to completely fill the screen with data at start-up.

    What I've been seeing quite often is that nothing will draw when the program loop starts. I can close the folder and then open another folder and execute that program. Drawing will then commence. At this point I can close the other folder and return to my waterfall program and it will draw. I never need to change any code. I'm changing some sort of internal state when I shift to another program I think. This issue may have already been addressed (thought I read about it somewhere else here...).

    Ahhhhh....I see it will be corrected in 1.2.7 :)

  • I'm keeping rect(0,0,10,10) at the start of my draw loop until 1.2.8 :)

  • SimeonSimeon
    Posts: 3,732

    I suspect if it's a state error then rect(0,0,0,0) will probably work too (and not draw on the screen).

  • Thanks for the workaround gentlemen.