Projectiles cause 5fps frame drop each?
by BeyondtheTech · in iTorque 2D · 05/22/2009 (1:17 pm) · 8 replies
Using the shoots.cs and other pre-built scripts, I started writing a game where bullets would be flying all over the place and when I started out with 1 or 2 players and 1 or 2 bullets, the gameplay stayed at a satisfying 40+ frames per second. However, when I started to actually enjoy testing my game in a real-world scenario and started tapping/shooting like crazy, I noticed that the frame rate steadily dropped to as low as 1-5fps, even queuing up all the screen taps after I let go.
I'll admit that I didn't try the Behavior Shooter demo on my iPhone (had a hard enough time just trying to compile my game without all the extra steps), but how many sprites is too many for most when they start to see a significant impact on game performance?
My bullet objects are relatively small, and I was hoping to throw in some particle activity for smoke and fire, so I hope my efforts aren't going to be dashed too quickly. I understand that the iPhone has an obviously inferior processor to the Mac, but I noticed a lot of iPhone games out there that look so busy with so much going on screen at once.
A couple of things to note - I've never been able to compile with optimizations (I get some bad "EXC" error during the build. I turned off Use Network, and even tried disabling the memory manager in the header file.
Is it the scripts in my objects that are doing it? Am I going about something wrong when I'm sending it to the device?
I'll admit that I didn't try the Behavior Shooter demo on my iPhone (had a hard enough time just trying to compile my game without all the extra steps), but how many sprites is too many for most when they start to see a significant impact on game performance?
My bullet objects are relatively small, and I was hoping to throw in some particle activity for smoke and fire, so I hope my efforts aren't going to be dashed too quickly. I understand that the iPhone has an obviously inferior processor to the Mac, but I noticed a lot of iPhone games out there that look so busy with so much going on screen at once.
A couple of things to note - I've never been able to compile with optimizations (I get some bad "EXC" error during the build. I turned off Use Network, and even tried disabling the memory manager in the header file.
Is it the scripts in my objects that are doing it? Am I going about something wrong when I'm sending it to the device?
#2
Is there a way to maintain a smooth framerate, such as 24 or 30 minimum, such that my game won't look or play back like a badly warped record (wow, that's showing my age)?
05/22/2009 (2:49 pm)
That's fine, I wasn't expecting a hundred objects simultaneously, just about a dozen at most (two six-shooters). What I wanted to know is that since I'm still at the beginning of my development, I just wanted to get a feel for other developers who are in the process or completed their game to see how much they had to compromise, and what tweaks became the ultimate workarounds for a limited processor such as the one on the iPhone.Is there a way to maintain a smooth framerate, such as 24 or 30 minimum, such that my game won't look or play back like a badly warped record (wow, that's showing my age)?
#3
In regards to building to the phone, the problem is that your iTGB project for the mac and for the PC have different flags set, so when they compile your project to .dso files the iPhone version can't read them because the files were compiled with the mac version. The solution to this is to right click the target you want to use, get info, go down to the pre-processing area, and make sure that you have the same flags set for the targets in your regular xcode project and your xcode_iphone project (no more and no less).
These are the flags I am using right now:
__IPHONE__ TORQUE_PLAYER TORQUE_RELEASE TORQUE_DISABLE_MEMORY_MANAGER PUAP_SCRIPT_CHANGE PUAP_OPTIMIZE USE_COMPONENTS
Also note that unless you fixed it already there is a typo in the TORQUE_DISABLE_MEMORY_MANAGER, you need to add the 'R' on the end.
05/22/2009 (3:43 pm)
In regards to framerate, I am having a similar issue with the attack in my game. The framerate is generally fine, until I go to attack. In my game right now attacking is done by creating a collision box in front of the player just for a split second, I don't know if it is the creation process that does this but later tonight or tomorrow I hope to attempt to have it created in the scene at all times, and then simply set its position to where I need it when I attack, and then remove it when I stop attacking. Hopefully that will help, I will post back here with any results.In regards to building to the phone, the problem is that your iTGB project for the mac and for the PC have different flags set, so when they compile your project to .dso files the iPhone version can't read them because the files were compiled with the mac version. The solution to this is to right click the target you want to use, get info, go down to the pre-processing area, and make sure that you have the same flags set for the targets in your regular xcode project and your xcode_iphone project (no more and no less).
These are the flags I am using right now:
__IPHONE__ TORQUE_PLAYER TORQUE_RELEASE TORQUE_DISABLE_MEMORY_MANAGER PUAP_SCRIPT_CHANGE PUAP_OPTIMIZE USE_COMPONENTS
Also note that unless you fixed it already there is a typo in the TORQUE_DISABLE_MEMORY_MANAGER, you need to add the 'R' on the end.
#4
Creation of objects on iPhone tends to cause slowdown. The best solution is to pre-create the collision box as a seperate object and simply move it to the correct screen position as needed (move it to some neutral off screen position when it isn't).
You should find that your frame rate improves significantly as a result.
Edit: Raphael
Generally speaking a lot of the games made with iTGB at the moment tend to stick with the single screen approach at the moment. A lot of optimisation is needed to get performance up, such as batching all sprite draws into a single call and using a single large texture for all of the sprites in a batch.
Realistically speaking. The iphone can cope with 25 - 30 drawcalls before you start to see slide show style animations. iTGB can end up trying to do a heck of a lot more than that at present.
05/22/2009 (5:17 pm)
@ZeinadCreation of objects on iPhone tends to cause slowdown. The best solution is to pre-create the collision box as a seperate object and simply move it to the correct screen position as needed (move it to some neutral off screen position when it isn't).
You should find that your frame rate improves significantly as a result.
Edit: Raphael
Generally speaking a lot of the games made with iTGB at the moment tend to stick with the single screen approach at the moment. A lot of optimisation is needed to get performance up, such as batching all sprite draws into a single call and using a single large texture for all of the sprites in a batch.
Realistically speaking. The iphone can cope with 25 - 30 drawcalls before you start to see slide show style animations. iTGB can end up trying to do a heck of a lot more than that at present.
#5
1. Your using too much script. Scripting is REALLY slow compared to c++ on the iphone.
2. You have really poorly optimized art work.
From my experience #1 is the primary issue. I get really good 30-40fps in my game with all native c++ behaviors and game logic with 20-30 objects moving on the screen, and another 10-20 offscreenobjects periodically doing distance and line of site checks. I'm very happy with the speed of iTGB, but I'm doing all native code. With script iTGB really just doesn't perform very well.
05/23/2009 (5:25 pm)
The primary problem with iTGB is the speed of scripting. In native c++ code you can do some really amazing stuff with iTGB. From my experience if your having speed problems with iTGB it's either:1. Your using too much script. Scripting is REALLY slow compared to c++ on the iphone.
2. You have really poorly optimized art work.
From my experience #1 is the primary issue. I get really good 30-40fps in my game with all native c++ behaviors and game logic with 20-30 objects moving on the screen, and another 10-20 offscreenobjects periodically doing distance and line of site checks. I'm very happy with the speed of iTGB, but I'm doing all native code. With script iTGB really just doesn't perform very well.
#6
It's funny how I cringed at the idea of trying to learn Objective-C and found myself using iTGB, only to find out I should be using C++, something equally oblivious to me. ;)
05/23/2009 (5:39 pm)
You can probably guess what my next question would be... How hard is it to translate TorqueScript into native C++ code, and how involved would that be?It's funny how I cringed at the idea of trying to learn Objective-C and found myself using iTGB, only to find out I should be using C++, something equally oblivious to me. ;)
#7
The other option is to do games that are not framerate sensitive. Puzzle games and other strategy games you could quite easily write in script code. Your just not going to be able to write games that require 20+ frames a second AND consistent framerates.
05/24/2009 (6:48 am)
If you've never done any C/C++ it can be a pretty difficult transition. C/C++ are are a lot more difficult than scripting, java and other languages that handle memory management and prevent memory overwrites and other types of issues. So it's not really a very good option for non-programmers. If your going to stick with script you've got to really understand the limitations of it and design your game and logic around minimizing the amount of periodic script calls. The other option is to do games that are not framerate sensitive. Puzzle games and other strategy games you could quite easily write in script code. Your just not going to be able to write games that require 20+ frames a second AND consistent framerates.
Torque Owner Peter Dwyer
You will need to put a cap on the number of projectiles each player can have active at any one time. Depending on what else you plan to have flying around the screen. This cap may end up as low as one or two!
You need to scale your project for the platform it's running on. Sometimes that means NOT making bullet hell on a phone!