problem running an exe of my game on win7 64bit

[felix24]

Hey guys,

recently I made an exe of the game I'm working on at the moment, following the steps described in the wiki. It works fine on my pc, my laptop and my Dad's pc, all of which are running 32 bit windows vista. However when I brought it to my freind's place so he could try it out for me (on his 64 bit win7 pc), the game wouldn't start most of the time, and when it did it was very laggy and glitchy. It mainly seemed like the physics was glitching. Bodies were just randomly flying around the place for no reason.
I was wondering if there are any known issues with Love and 64 bit windows? I'm not using frame buffers which, as I've read in other posts, can cause problems on some pcs.

Thanks in advance for any replies

[Taehl]

There are no issues with Win7 x64 (I, myself, use it). Could you describe your friend's hardware, please? Physics woes like that could be due to a big difference in framerate (possibly caused by a better/worse processors and/or graphics cards) coupled with uncareful coding techniques.

[thelinx]

Tell him to update his graphics drivers.

Also, to minimize the physics spazzing out issue, add this in the top of your love.update:

Code: Select all

  dt = math.min(dt, 0.1)

[Rad3k]

Also, to minimize the physics spazzing out issue, add this in the top of your love.update:

Code: Select all

  dt = math.min(dt, 0.1)

Or even better, use this function as love.run:

Code: Select all

function love.run ()
   -- these don't change, so we can make them local for faster access
   local audio, graphics = love.audio, love.graphics
   local event, timer = love.event, love.timer

   -- Prepare stuff
   if love.load then love.load(arg) end

   local timestep = 1/240
   local accumulator = 0
   -- Set a reasonable FPS limit
   local min_frame_time = 1/60

   -- Main loop
   while true do
      -- Update the timer
      if timer then
         timer.step()
         accumulator = accumulator + timer.getDelta()
      end

      -- Process events
      if event then
         for e, a, b, c in event.poll() do
            if e == "q" then
               if not love.quit or not love.quit() then
                  if audio then audio.stop() end
               end
               return
            end
            love.handlers[e](a, b, c)
         end
      end
      
      -- Do the game mechanic
      if love.update then
         if timer then
            while accumulator >= timestep do
               love.update(timestep)
               accumulator = accumulator - timestep
            end
         else
            love.update(0)
         end
      end

      -- Draw the graphics
      if graphics then
         graphics.clear()
         if love.draw then love.draw() end
      end

      -- Wait for the end of this frame
      if timer then
         timer.step()
         local work_time = timer.getDelta()
         if work_time < min_frame_time then
            timer.sleep((min_frame_time - work_time) * 1000)
         end
         accumulator = accumulator + work_time
      end

      -- Show the frame
      if graphics then
         graphics.present()
      end
   end
end

If you didn't supply your own love.run, just add this code to your main.lua and it should work with no problems. Basically it makes your game logic (such as physics) framerate-independent, and also caps the framerate to 60 FPS (you can change it easily, just modify the value of 'min_frame_time' at the beginning of the function, or set to 0 to disable).

[felix24]

thanks for all the responses guys.

Rad3k: I added the code you mentioned and will get him to try it again. thanks for that

let you guys know how it goes.

[slime]

Or even better, use this function as love.run:

Code: Select all

...

love.timer.sleep isn't very accurate on some computers.

[benloran]

love.timer.sleep isn't very accurate on some computers.

I've run into this problem, too. Do you know of a workaround (other than to just not use it)?

[Rad3k]

Or even better, use this function as love.run:

love.timer.sleep isn't very accurate on some computers.

Sleep accuracy can depend on many factors, like system load, process priority and so on. Fortunately, in my code, the only thing that's affected by sleep's accuracy is pushing frames to display (flipping buffers). This means that some frames may arrive a little sooner, and some a little later than expected. If you're worried about it, increasing target FPS to double of your display framerate may help reduce the effects. Or you can disable FPS limit completely.

[felix24]

ok, so he tried it out again. and it works fine except it takes about 10 seconds or so to start up. just displays a white screen for those seconds.

some hardware specs of his pc:
processor: i7 2600K, quad core, 3.4 gigs
motherboard: P8P67 Deluxe Motherboard
RAM: 8 gigs DDR3
Graphics Card: Nvidia GTX 580

thanks for all the help so far.