ITGB 1.1 Feedback Thread
by Michael Perry · in iTorque 2D · 12/19/2008 (3:24 pm) · 82 replies
iTGB v1.1 Feedback Thread
Purpose:The purpose of this thread is to gather feedback focused completely on the release of iTGB 1.1. We are open to whatever you can provide, but ask that we focus on this particular version.
Areas of Interest:
- Crashes
- Bugs
- Favorite Features
- #1 Feature Improvement
- #1 New Feature Request
Documentation:
Please use the Official Documentation Feedback Thread to post any feedback.
*** Thread will be unlocked later today ***
About the author
Programmer.
#62
Anyone know if there is a way to programmatically capture screenshots? I'd like to pre-generate 10-20 animated frames of particle animations programmatically and then combine them later. Right now I used Mac's GRAB application which works but it's very difficult to capture fluid sequences of particle animations.
01/08/2009 (8:44 am)
Looks like the setUsesPhysics fixed my problem. This is very odd because I've never used that call and it was working a couple days ago. Oh well everything seems to be working now. I just spent a few hours getting rid of my particle animations and switching to static animations to improve the frame rate. It's running much better now and working well.Anyone know if there is a way to programmatically capture screenshots? I'd like to pre-generate 10-20 animated frames of particle animations programmatically and then combine them later. Right now I used Mac's GRAB application which works but it's very difficult to capture fluid sequences of particle animations.
#63
01/08/2009 (8:54 am)
I've never really tried it, but there is a doScreenShot() function in the common directory. you can try to loop and see if that's working. Please let me know if it does cause it sounds like a good idea to have animation instead of particles. I used to be an fx animator so I prefer houdini or Maya for that kind of stuff :)
#64
If there is a good application you could recommend for pixel art I'd be interested in hearing it. Assuming it's not expensive.
01/08/2009 (9:26 am)
If I self rated myself I'd be a 5/100 on artwork and 90/100 on programming. So everything for a game is easy for me except the artwork. It's really held me back in the past from doing my own indie titles.If there is a good application you could recommend for pixel art I'd be interested in hearing it. Assuming it's not expensive.
#65
For particles, houdini probably the best program out there and the indie version is quite cheap. However, the learning curve in houdini is the worse I've even seen so I don't think it'l be a good fit. I actually enjoy doing particles in TGB. it's very simple and does the job for most of my ingame needs. I hope your idea of rendering out TGB particles works. I'm gonna start using it too if it does.
01/08/2009 (1:56 pm)
I am not familiar with any good program that can help with pixel art.For particles, houdini probably the best program out there and the indie version is quite cheap. However, the learning curve in houdini is the worse I've even seen so I don't think it'l be a good fit. I actually enjoy doing particles in TGB. it's very simple and does the job for most of my ingame needs. I hope your idea of rendering out TGB particles works. I'm gonna start using it too if it does.
#66
01/08/2009 (4:31 pm)
I hear Pixen for Mac is pretty good. Free.
#67
I get like 4000+ errors compiling it. The errors are related to not being about to OpenAL/al.h but I see it added
to the project etc.
I've added a new component and would like to incorporate it into TGB and TGBGame so I can test it out.
01/08/2009 (8:49 pm)
Has anyone gotten the Mac xcode project to compile for the Torque Game Builder or TGBGame targets?I get like 4000+ errors compiling it. The errors are related to not being about to OpenAL/al.h but I see it added
to the project etc.
I've added a new component and would like to incorporate it into TGB and TGBGame so I can test it out.
#68
see my posting and the posting above mine on dec 23th
01/08/2009 (8:56 pm)
Yes, no problem actually after you have fixed the broken links.see my posting and the posting above mine on dec 23th
#69
01/09/2009 (8:57 am)
Thanks that worked after I figured out all the links. Also xcode wasted a bunch of my time because it took me forever to figure out that it kept treating my new directory link as a resource instead of a file. I had to create the files and cut and past the code and store the actual code in the project directory.
#70
MoveTowards (reused from behavior shooter)
TakeDamageAdvanced (rewrote because the behaviorshooter one wasn't suitable for my needs)
DealDamageAdvanced (rewrote because the behaviorshooter one wasn't suitable for my needs)
TargetSelector (loops through a SimSet of global potential targets and shoots at the closest one in range based upon distance, really cool how safeDelete automatically removes it from this global set for me wasn't completely expecting that).
My Performance test scenario was about 10-15 objects with 10 shooters shooting every second with a projectile animation and explosion on hit animation. This gave the system about 10-25 objects to move, track and check collisions etc.
With pure script behaviors I was getting around 1-3 frames per second though it varied somewhat. After rewriting these main behaviors as components I'm getting 22-30 frames per second with 12 shooters and 20 objects.
This scenario has proven to me the value of replacing most script behaviors with components.
Based on this I'd recommend anyone having poor performance to rewrite their script behaviors as components and you'll likely get close to getting the framerate you need.
It was a little slow going at first but the Examples from the behavior component shooter really helped for a lot of things. I had to go to code to figure out a few things but it was well worth it. With native component behaviors the performance of iTGB is REALLY good on the iphone for the limited hardware that it's using.
I still have a few places to improve performance for hotspots, because my DealsDamage behavior still has some script left in it that can be removed. But I'm very happy with the way it performs now with native components.
01/09/2009 (10:52 pm)
I Just finished converting the 4 most important game scripts (of my game so far) behaviors into native components. I moved the following behaviors into components:MoveTowards (reused from behavior shooter)
TakeDamageAdvanced (rewrote because the behaviorshooter one wasn't suitable for my needs)
DealDamageAdvanced (rewrote because the behaviorshooter one wasn't suitable for my needs)
TargetSelector (loops through a SimSet of global potential targets and shoots at the closest one in range based upon distance, really cool how safeDelete automatically removes it from this global set for me wasn't completely expecting that).
My Performance test scenario was about 10-15 objects with 10 shooters shooting every second with a projectile animation and explosion on hit animation. This gave the system about 10-25 objects to move, track and check collisions etc.
With pure script behaviors I was getting around 1-3 frames per second though it varied somewhat. After rewriting these main behaviors as components I'm getting 22-30 frames per second with 12 shooters and 20 objects.
This scenario has proven to me the value of replacing most script behaviors with components.
Based on this I'd recommend anyone having poor performance to rewrite their script behaviors as components and you'll likely get close to getting the framerate you need.
It was a little slow going at first but the Examples from the behavior component shooter really helped for a lot of things. I had to go to code to figure out a few things but it was well worth it. With native component behaviors the performance of iTGB is REALLY good on the iphone for the limited hardware that it's using.
I still have a few places to improve performance for hotspots, because my DealsDamage behavior still has some script left in it that can be removed. But I'm very happy with the way it performs now with native components.
#71
Use components for physics, heavy math and logic, and convert larger script blocks to components after you "finalize" them.
If you find yourself building list of items and looping through them in your scripts, doing lots of calculations, you might want to put that into a component.
If you're just setting some variables, doing basic math and the like, scripts are fine
Like BehaviorShooter, get it to work with scripts first, do all your testing, get in the features/functionality you want, then convert them to components for speed.
With PUAP_SCRIPT_CHANGE defined in your build, this is less necessary, obviously components still have benefits(straight C/C++ will always be faster), but scripts are a lot faster than without it defined.
01/10/2009 (12:05 am)
For best results, use scripts for prototyping, quick debugging, and callbacks. Use components for physics, heavy math and logic, and convert larger script blocks to components after you "finalize" them.
If you find yourself building list of items and looping through them in your scripts, doing lots of calculations, you might want to put that into a component.
If you're just setting some variables, doing basic math and the like, scripts are fine
Like BehaviorShooter, get it to work with scripts first, do all your testing, get in the features/functionality you want, then convert them to components for speed.
With PUAP_SCRIPT_CHANGE defined in your build, this is less necessary, obviously components still have benefits(straight C/C++ will always be faster), but scripts are a lot faster than without it defined.
#72
BTW your exactly right. What I'm doing is writing the behavior first in script and getting it right (maybe 2-3) and then rewriting it in native if it's called a lot.
It's REALLY nice to be able to prototype in script and then convert to native code for speed.
01/10/2009 (12:32 am)
I am using the default build project file that comes with iTGB 1.1 . Apparently it doesn't have that setting or some others I've heard about in the forums. Until we have documentation on what flags to set I'm just using the default build settings, whatever that is configured for. I'll try setting that flag and see what happens.BTW your exactly right. What I'm doing is writing the behavior first in script and getting it right (maybe 2-3) and then rewriting it in native if it's called a lot.
It's REALLY nice to be able to prototype in script and then convert to native code for speed.
#73
BTW I got the screenshot capture for converting point animations into bitmap animations it works great for small to medium size animations. The only negative is I haven't figured out how to capture with transparency. I have to manually erase the background for each frame in photoshop etc. If I could capture with transparency then I'd be golden. Point animations look a lot better than the graphic animations, but still better than i could do by hand.
01/10/2009 (6:52 am)
Eyal, BTW I got the screenshot capture for converting point animations into bitmap animations it works great for small to medium size animations. The only negative is I haven't figured out how to capture with transparency. I have to manually erase the background for each frame in photoshop etc. If I could capture with transparency then I'd be golden. Point animations look a lot better than the graphic animations, but still better than i could do by hand.
#74
I'm impressed with your components performance increase. I was trying to avoid getting into the C++ code since I am able to complete my games using only the kickass torqueScript. but I guess for the iPhone I'm gonna have to work a bit harder :)
01/10/2009 (9:01 am)
Bret, That's really cool you got it to work. I guess you can choose different bg color based on the color of your particles for a better matte (green,blue,red screen) this could work better than black bg since a lot of times in particles the edges are darker (smoke,explosions) and could be cliped in the matte process.especially if you want semi-transparent particles. you would just make green your alpha channel. I'm impressed with your components performance increase. I was trying to avoid getting into the C++ code since I am able to complete my games using only the kickass torqueScript. but I guess for the iPhone I'm gonna have to work a bit harder :)
#75
01/10/2009 (10:52 am)
So how are you guys seeing the FPS on the phone? When I turn the debug banner on in TGB and then run the app on the phone, the debug banner is offset, huge, and I cannot read anything on it.
#76
you can not use the debug banner on the iphone, its screen is at least 200% too small for it ;)
01/10/2009 (11:04 am)
Check out the shooter example game and its related gui handling part. That way you can have the FPS and time per frame data shown at the top, same as with the shooter component project.you can not use the debug banner on the iphone, its screen is at least 200% too small for it ;)
#77
01/10/2009 (3:49 pm)
Just start your app in the iphone instruments using the opengl ES profile. It'll give you FPS within xcode.
#78
02/09/2009 (6:58 am)
edit: I found the problem with the OSX build, just needed to create the symlinks..would be nice if this issue was listed somewhere in the official documentation ;)
#79
Here's the debugger console output:
05/05/2009 (6:23 pm)
I hope someone can shed some light on an issue I am having when I tried to rebuild the iTGB engine via xCode. I performed the missing OpenAL files fix as mentioned on an earlier post to get rid of the error messages. It finished building without errors but when I ran it, I get an error: "Torque Game Builder Debug has exited with status 5" Here's the debugger console output:
dyld: Library not loaded: @executable_path/../Frameworks/Ogg.framework/Versions/A/Ogg Referenced from: /Users/btan/Working/iTGB_1_1/tgb/Torque Game Builder Debug.app/Contents/MacOS/Torque Game Builder Debug Reason: image not found The Debugger has exited due to signal 5 (SIGTRAP).The Debugger has exited due to signal 5 (SIGTRAP).
#80
Remove the incorrect files and link them up properly from the command line to fix linking. Use tar to make a backup of your frameworks for later :)
Quick example:
05/05/2009 (7:41 pm)
That would be because of missing symlinks inside the Xiph.org frameworks (Ogg Vorbis/Theora). The links have turned into files because of version control's inability to store them (or the platform differences between all OSes used in development of Torque?). The actual contents are the word "link" and a path to the correct file/directory, so you could find all the files you need to replace with a recursive grep.Remove the incorrect files and link them up properly from the command line to fix linking. Use tar to make a backup of your frameworks for later :)
Quick example:
cd iTGB_1_1/engine/lib/xiph/macosx/Ogg.framework rm Ogg ln -s Versions/A/Ogg Ogg...and so on for any other link files.
Conor O'Kane
cokane.com
oniPhoneTouchDown definitely isn't working - which means no multi-touch events are possible.