Game behaves differently between 32bit and 64bit systems

[LeNitrous]

The subject is the question itself.
Game behaves differently between 32 bit and 64 bit systems. Here's a comparison screenshot


One of my libraries that handles timing is HUMP's timer library. The game runs slow on 64 bit and the timer doesn't seem to work but runs fine in 32 bit.
I tried using both 32bit and 64bit LOVE on 64bit Windows 10 which has the same effect.

[ivan]

I can't debug all of the code, but at first glance I see that "dt" is not used properly in this case:

Code: Select all

function ent:update(dt)
	self.y = self.y + (self.multiplier/2)*2.5
	if (self.y >= 768+64) then
		ents.remove( self.id )
	end
end

should look something like:

Code: Select all

function ent:update(dt)
  self.y = self.y + self.velocity*dt

The same approach must be used for all moving objects as well as visual effects and animations.
OR instead of dealing with velocities, you can use something like tweener which works based on "time elapsed".
Remember that "dt" varies between systems.

[LeNitrous]

I can't debug all of the code, but at first glance I see that "dt" is not used properly in this case:

Code: Select all

function ent:update(dt)
	self.y = self.y + (self.multiplier/2)*2.5
	if (self.y >= 768+64) then
		ents.remove( self.id )
	end
end

should look something like:

Code: Select all

function ent:update(dt)
  self.y = self.y + self.velocity*dt

The same approach must be used for all moving objects as well as visual effects and animations.
OR instead of dealing with velocities, you can use something like tweener which works based on "time elapsed".
Remember that "dt" varies between systems.

While it did help optimize my code. The issue between the system architecture is still present. Thanks a lot though.

[ivan]

LeNitrous, you have to make sure "dt" is used correctly if you expect the same behavior across different machines.
Start with something simple like:

Code: Select all

local elapsed = 0
function love.update(dt)
  elapsed = elapsed + dt -- track elapsed time
end

function love.draw()
  love.graphics.origin()
  love.graphics.rotate(elapsed/math.pi) -- 180 degrees per second
  love.graphics.rectangle('fill', 0, 0, 100, 10) -- draw a rotated rectangle
end

This should give you an example of how to produce consistent rotation based on the value of "dt".

Another approach is to use a "fixed" time step but that's a little harder to understand and implement.

Also, note that "optimization" means something different in programming terminology and has nothing to do with your question.

[LeNitrous]

I think we got a bit off topic there. While dt has something to do with game updates, The problem lies somewhere else.
in game.lua:

Code: Select all

function game:enter()
	TEsound.play("assets/sounds/stream.mp3", "bgm")
	ents.Create( "player", bounds.x2/2, bounds.y2 )
end

I disabled the entities from spawning except the player.
From what I noticed is that the game updates slower than normal in game but runs fine in menu and results screen. Also...

Code: Select all

stage_1 = Timer.every(0.05, function() ents.Create( "object", math.random(bounds.x1+16,bounds.x2-16), -100 ) end)

HUMP's Timer library doesn't seem to function as it should.

Note: Here's an update

[pgimeno]

I don't see the problem. Here's a screenshot from my 32 bit Linux:



As a side note, you seem to have a bug handling resolutions that are not 16:9.

[LeNitrous]

I don't see the problem. Here's a screenshot from my 32 bit Linux:



As a side note, you seem to have a bug handling resolutions that are not 16:9.

32 bit systems don't have any issues whatsoever.
I have both 32 bit and 64 bit Windows 10 PCs. Also, I haven't updated it yet to fully support other resolutions. It only supports 16:9 and 4:3 from the latest update.
1366x768, 1360x768, 1024x768 are currently supported

[pgimeno]

32 bit systems don't have any issues whatsoever.

Ok. Can you explain what the problem is in a 64 bit machine then? I don't see a problem with the screenshot you've posted, except the density is a bit different. The density looked right in my 32 bit machine.

Also, I haven't updated it yet to fully support other resolutions. It only supports 16:9 and 4:3 from the latest update.
1366x768, 1360x768, 1024x768 are currently supported

My resolution is 1280x1024. That's 5:4.

[LeNitrous]

32 bit systems don't have any issues whatsoever.

Ok. Can you explain what the problem is in a 64 bit machine then? I don't see a problem with the screenshot you've posted, except the density is a bit different. The density looked right in my 32 bit machine.

Also, I haven't updated it yet to fully support other resolutions. It only supports 16:9 and 4:3 from the latest update.
1366x768, 1360x768, 1024x768 are currently supported

My resolution is 1280x1024. That's 5:4.

In General, Object spawning (the falling objects) has a delay which is handled by HUMP's Timer library.

Code: Select all

Timer.every(0.05, function() ents.Create( "object", math.random(bounds.x1+16,bounds.x2-16), -100 ) end)

32 bit Systems handles the delay correctly while 64 bit Systems completely ignore the delay.

[pgimeno]

32 bit Systems handles the delay correctly while 64 bit Systems completely ignore the delay.

I see a very similar density in my 32 bit screenshot and in your 64-bit screenshot, so I still don't see the problem.

What are the FPS of the 32-bit and the 64-bit machine? I'm currently using 60. Switching to 75 I don't see much of a change, though, but the pieces fall a bit faster, causing the impression of a reduced density.