Loading screens...

[Chief]

By the way, i managed to find out what gave the "attempt to call a number value" error when a body/shape made in the coroutine collided with one made outside. It was the self.shape:setData() function. If i remove it from the shape the error doesn't pop up, if i add it it comes back.

Any ideas on how i would fix this, because i kinda need to have data set to the shapes...

With the difference that love.thread already exists.

Is there maybe a hidden doc. for it? Would like to look into it

[vrld]

It is difficult to help you with your code without actually having a look at your code.

[Luiji]

Where's the documentation for love.thread?

[bartbes]

I was talking about Nevon's comment, there is no audio fix yet, love.thread has been written. It is not, however, in 0.6.2.

[Jasoco]

Stupid audio bug. Hope you squash that sucker soon.

Also, why do we need loading screens? I haven't had any loading time on any Löve project I've worked on to even justify needing a load screen. The only time I did see a load screen was in that super-cool file downloading project that would show a "downloading" progress bar while it downloaded a file. Super cool. That one worked in a way where it would call the love.graphics.present() function inside the loop that handled downloading. So every frame it would download a little, then update the screen to draw the progress.

[nevon]

Also, why do we need loading screens? I haven't had any loading time on any Löve project I've worked on to even justify needing a load screen. The only time I did see a load screen was in that super-cool file downloading project that would show a "downloading" progress bar while it downloaded a file. Super cool. That one worked in a way where it would call the love.graphics.present() function inside the loop that handled downloading. So every frame it would download a little, then update the screen to draw the progress.

It's nice for when you're doing downloads or huge resource loading while playing music or animations.

[Luiji]

Well the love.graphics.present() idea is ingenious!

[Jasoco]

Well the love.graphics.present() idea is ingenious!

Well, it's how the love.run() function works. If you write your own love.run() (Which I do) you will see that you have complete control over everything including graphics.clear, graphics.present, timer.step, what gets passed as the dt variable... (timer.getDelta()) Complete control. By calling drawing and present and other important functions during a long loop you can take away the inconvenient pause you sometimes get when it gets stuck in a loop for a while.

Say for instance you do a:

Code: Select all

variable = {}
for x=0,10000 do
  varable[x] = {}
  for y=0,10000 do
    variable[x][y] = stuff
  end 
end

It will take a long time. (Like if you create a huge map. Though really, you never really need that big of a map for most purposes.) But hypothetically you could call all that stuff inside and make it less horrible. Though in my experience it slows down the process a bit. Play around.

[Jasoco]

Here's an example I was playing with:
REMOVED: SEE BELOW
The first step is to clear the screen. Enter the loop.

Now the problem is if you call the stuff every single frame it will slow the process down SIGNIFICANTLY. I ran a test without this stuff of making an array of that size in my above post and my computer froze for minutes. So what you do is only call the updates every few loops. In my case, I did it every 10 loops. It ends up going faster than if I did it every loop.

Problem is for some reason, it still acts like it's frozen. In that I get the spinny cursor. And I can't quit the program. But it updates fine. I assume it has something to do with events not being captured. Weird thing is I placed the Event handling stuff into this new loop and it made it so if I press X on the window, it just stops the loop and continues. Instead of actually quitting the program. I will need to do further research.

Edit:
REMOVED: KEEP SCROLLING
If I place this at the end of the last loop, it will make the app responsive. But you won't be able to quit it until it finishes. (And thus enters the normal game loop.)

[Jasoco]

This is my finished prototype example:

Code: Select all

  local titi = love.timer.getTime()
  love.graphics.clear()
  local maxLoop = 100000
  local tmp = {}
  local tmp2 = 0
  local progStep = 100
  for x=0,maxLoop do
    tmp[x] = math.random(1,1000)

    if tmp2 >= progStep then tmp2 = 0 end
    if tmp2 == 0 then
      dt = love.timer.getDelta()
      love.timer.step()
      love.graphics.setColor(100,100,100)
      love.graphics.rectangle("fill", 100, 100, maxLoop/200, 30)
      love.graphics.setColor(255,255,255)
      love.graphics.rectangle("fill", 100, 100, x/200, 30)
      love.graphics.setColor(0,0,0)
      love.graphics.print(x.." of "..maxLoop, 106, 122)
      love.timer.sleep(1)
      love.graphics.present()
    end
    tmp2 = tmp2 + 1

    if love.event then
      for e,a,b,c in love.event.poll() do
        love.handlers[e](a,b,c)
        print(e, a, b, c)
      end
    end
  end
  print(love.timer.getTime() - titi)

This example draws a progress bar on screen.

Set progStep to how often you want it to update. If you set it low it takes longer. The higher you set it, the faster it goes. So set it to a fair number. I could set it to 1000 and it'll go faster than 100 which goes faster than 10 which is about a fraction of doing it every frame. For example:
10000 = 4.5 seconds
1000 = 4.6 seconds
100 = 7 seconds
10 = 37 seconds
1 = Forever.. literally

So you notice that around 1000 it levels out. YMMV though. The higher the number though, the longer between updates. 1000 looks good to the eye. 10000 looks less good and both are about the same time so I go with 1000.

I don't know the math to have it actually set to a certain width, so right now it's just maxLoop/200. Little help maybe?