Page 1 of 2
Game behaves differently between 32bit and 64bit systems
Posted: Sat Jul 09, 2016 2:24 pm
by 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.
Re: Game behaves differently between 32bit and 64bit systems
Posted: Sat Jul 09, 2016 3:24 pm
by 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.
Re: Game behaves differently between 32bit and 64bit systems
Posted: Sun Jul 10, 2016 9:21 am
by LeNitrous
ivan wrote: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.
Re: Game behaves differently between 32bit and 64bit systems
Posted: Sun Jul 10, 2016 10:18 am
by 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.
Re: Game behaves differently between 32bit and 64bit systems
Posted: Sun Jul 10, 2016 11:08 am
by 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
Re: Game behaves differently between 32bit and 64bit systems
Posted: Sun Jul 10, 2016 11:17 am
by 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.
Re: Game behaves differently between 32bit and 64bit systems
Posted: Sun Jul 10, 2016 11:24 am
by LeNitrous
pgimeno wrote: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
Re: Game behaves differently between 32bit and 64bit systems
Posted: Sun Jul 10, 2016 11:32 am
by pgimeno
LeNitrous wrote: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.
LeNitrous wrote: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.
Re: Game behaves differently between 32bit and 64bit systems
Posted: Sun Jul 10, 2016 11:48 am
by LeNitrous
pgimeno wrote:LeNitrous wrote: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.
LeNitrous wrote: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.
Re: Game behaves differently between 32bit and 64bit systems
Posted: Sun Jul 10, 2016 12:27 pm
by pgimeno
LeNitrous wrote: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.