object:applyForce() issue in iOS simulator

Solar2D iOS
#1

Hi,

I use _object:applyForce() _to move my sprite and it works very well in Corona Simulator, however when I build the game for iOS and run it in iOS simulator - I see that _object:applyForce() _kind of ~10 times weaker than in Corona Simulator, means my sprite is moving super slow, but other objects on the scene moving as fast at they move in Corona Simulator (they use transition.to though, so not driven by Physics). I also noticed when I fire a bullet (isBullet = true) it very often does not detect a collision with other object and skip it, fly through it… Again the issue is only in iOS Simulator and with Physics interactions after export (iOS 12.1 and latest Corona build). In Corona Simulator - everything works as expected.

#2

The iOS simulator is very slow, I wouldn’t recommend it for testing physics-based games - you’re just not going to get anywhere near the same FPS as you do in the Corona Simulator or a real device. If the same happens on a real device then that would be something to look into further.

#3

In cases like this, always, always, always provide some code that demonstrates your issue.

It could be that this is some well known issue, or it could be a simple case of a typo or some overlooked issue. For instance, with your bullets, are your other objects or the bullet itself thick enough so that it can’t pass through the objects between frames? If your objects/bullet are only a few pixels wide, then this is bound to happen. As for your applyForce(), how do you actually do it? Seeing the code would remove the guesswork and save time.

#4

thanks everyone, the problem was only specific to native iOS Simulator, when I deployed to the device - all good. I was confused that in native iOS Simulator only physics driven objects were very slow, but objects driven by transition.to was working fine. Anyway I am aware how terribly slow native iOS simulator for games, hopefully Apple will fix it with the upcoming OpenGL depreciation and as a result rebuilded iOS Simulator to support Metal.

#5

Transitions use very little math.  Physics uses a lot, so if you don’t have a lot of ‘equivalent’ CPU power you’re going to suffer.

#6

OpenGL ES was already depreciated with iOS 12, but games that use it will still continue to run, for now.

#7

The iOS simulator is very slow, I wouldn’t recommend it for testing physics-based games - you’re just not going to get anywhere near the same FPS as you do in the Corona Simulator or a real device. If the same happens on a real device then that would be something to look into further.

#8

In cases like this, always, always, always provide some code that demonstrates your issue.

It could be that this is some well known issue, or it could be a simple case of a typo or some overlooked issue. For instance, with your bullets, are your other objects or the bullet itself thick enough so that it can’t pass through the objects between frames? If your objects/bullet are only a few pixels wide, then this is bound to happen. As for your applyForce(), how do you actually do it? Seeing the code would remove the guesswork and save time.

#9

thanks everyone, the problem was only specific to native iOS Simulator, when I deployed to the device - all good. I was confused that in native iOS Simulator only physics driven objects were very slow, but objects driven by transition.to was working fine. Anyway I am aware how terribly slow native iOS simulator for games, hopefully Apple will fix it with the upcoming OpenGL depreciation and as a result rebuilded iOS Simulator to support Metal.

#10

Transitions use very little math.  Physics uses a lot, so if you don’t have a lot of ‘equivalent’ CPU power you’re going to suffer.

#11

OpenGL ES was already depreciated with iOS 12, but games that use it will still continue to run, for now.