Mentionable 1.5 Improvements
by Michael Perry · in iTorque 2D · 07/28/2011 (9:26 pm) · 67 replies
Greetings all. As another dev day winds down, I look back at the code that was written. So far, people seem pretty happy with the improved input system, which is really encouraging. Each release brings a big feature or change, but sometimes it's the little things that make people cheer. What you will not see is a big blog focused around the following list of subtle improvements. I thought you might want to see these to bide some time between now and the next release. Existing users will probably understand this a little better, which is why I made a forum post instead of a blog.
1.5 final will ship without this problem. iT2D project files will now be .it2dproj (little i before everything, right Apple?). While I'm at it, I will be changing the name of certain executables, templates, registry entries and plist files to make sure this is a much smoother installation on both Windows and OS X.
1. Mass selection removal (already in the second preview). You can multi-select entries on both sides to add or remove datablocks.
2. Organization. I'm still dabbling here, but I hear everyone loud and clear. The dialog is just fine for something like RainyDay, which only has three or four datablocks. However, the presentation does not scale well with dozens and dozens. There is no real ordering of the datablocks or clear separation. I have a couple of ideas I'm kicking around, such as a "Sort by" option and explicit separators (of some kind) between types.
2. Semi-auto management. I do not want to go overboard here, but I do think there is some room for helping users out with adding level datablocks. My initial approach will be to automatically add image and animation datablocks for anything in the level when the play button is pressed.
These changes have made developing iTorque 2D a lot easier for me, so there is some merit in revealing them ahead of time. This is the kind of stuff that doesn't get the marketing treatment for an engine release, but I love it. If I think of any other subtle improvements, I will list them in this thread. I'd really like your feedback, so don't hesitate.
File Association Changes
Most long term iTorque 2D users know a golden rule when installing a new version. Uninstall everything else first. This includes Torque 2D and previous versions of iTorque 2D. Why? Well, they all share the same executable names and project file extensions. If you double click a .t2dproj on Windows, there is a good chance you might launch the wrong editor. Imagine my development environment: one trunk and five branches of iTorque 2D, plus the Torque 2D repo trunk, plus installations of the final products. It's a real PITA, but you know that.1.5 final will ship without this problem. iT2D project files will now be .it2dproj (little i before everything, right Apple?). While I'm at it, I will be changing the name of certain executables, templates, registry entries and plist files to make sure this is a much smoother installation on both Windows and OS X.
More Editor Shortcuts
Simple, but a major time saver. I have removed the Visual Studio 2005 button from the Project tab. Two new buttons have replaced it. One will take you to the Xcode project for the OS X runtime, the other will open the new Visual Studio 2010 solution.Improved Level Datablocks Dialog
The introduction of level datablocks was smart. A great idea worth extending. The following three key improvements are on my radar for the 1.5 final. They are not solidified, but I have high hopes:1. Mass selection removal (already in the second preview). You can multi-select entries on both sides to add or remove datablocks.
2. Organization. I'm still dabbling here, but I hear everyone loud and clear. The dialog is just fine for something like RainyDay, which only has three or four datablocks. However, the presentation does not scale well with dozens and dozens. There is no real ordering of the datablocks or clear separation. I have a couple of ideas I'm kicking around, such as a "Sort by" option and explicit separators (of some kind) between types.
2. Semi-auto management. I do not want to go overboard here, but I do think there is some room for helping users out with adding level datablocks. My initial approach will be to automatically add image and animation datablocks for anything in the level when the play button is pressed.
Macro Reduction
Can anyone name all the macros that can be toggled for the various optimizations and feature add-ons for iTorque 2D? How about the list and the explanation? Yeah, not great. I already mentioned this in another thread, but I'm going to start eliminating certain flags and preprocessor definitions that are no longer useful. A prime example is Use Multi-touch. There was definitely a purpose to this flag previously, but this is actually a surefire blocker to using the improved input system. This is just one example. The list will grow as I continue evaluation.Source Code Stripping
There are quite a few source files that carried over as far back as the original Torque 2D days. Anyone use the turrets or foliage system in iTorque 2D? Didn't think so. I'm going to eliminate what I can, including the example components that no one seems to know exists. These will be taken out of the engine, but provided as downloads in tutorials that show C++ behaviorsThe Common Folder
I started my own personal project on the side. The first thing I did was gut the the game's common directory. From my IRC discussions with other users, I'm not the only one. It took very little time, increased load speed and is generally easier to parse. This is not an actual task or anything I planned for the 1.5 final, but this change could make a great Saturday morning improvement.These changes have made developing iTorque 2D a lot easier for me, so there is some merit in revealing them ahead of time. This is the kind of stuff that doesn't get the marketing treatment for an engine release, but I love it. If I think of any other subtle improvements, I will list them in this thread. I'd really like your feedback, so don't hesitate.
About the author
Programmer.
#22
08/25/2011 (5:24 pm)
The SVN system they currently use is very corporate-focused, from what I've read. It's not easy to share with different levels of users. There might also be trade secret reasons to not allow access ;)
#23
@All - I started a thread talking about the new 1.5 demos: Click here for awesome screenshots
08/26/2011 (12:18 pm)
@Pedro - Associates will be getting svn access again. So if you hold that title in the community, you can get access.@All - I started a thread talking about the new 1.5 demos: Click here for awesome screenshots
#24
Example behavior with binding:
Expanded field:
08/26/2011 (12:26 pm)
That reminds me! I have another mentionable 1.5 improvement. I created two new field types specific to iTorque 2D. If you have ever worked with the T2D behavior system, you can create fields for a new behavior that are tailored to input bindings. That is limited to keyboard, joystick and mouse. Well, I think behavior writers deserve easier access to the gyroscope and accelerometer:Example behavior with binding:
Expanded field:
%template.addBehaviorField(RollHorizontal, "Motion input for rolling the ball vertically", motion, "accelerometer accelx"); %template.addBehaviorField(RollVertical, "Motion input for rolling the ball vertically", motion, "accelerometer accely");
#25
08/26/2011 (2:17 pm)
Ooh, like.
#26
Well, until now. Straight from the SVN log:
- ADDED: Two new functions exist for t2dAnimatedSprite. They are getSpeedScale and setSpeedScale(float scale). You can use these to control the speed of the animation based on a float value.
You get things like this when you "eat your own dog food". An artist or designer needs something, so you way the risk/work vs reward. In this case, it was a very simple request to accommodate. Hopefully you all will be able to make use of this.
08/27/2011 (11:43 am)
For the deathball demo, the artist asked if I could speed up and slow down the rolling animation based on the velocity of the ball. My immediate response was "sure". However, I then realized that you cannot actually control the speed of the animation once it has been saved from the editor.Well, until now. Straight from the SVN log:
- ADDED: Two new functions exist for t2dAnimatedSprite. They are getSpeedScale and setSpeedScale(float scale). You can use these to control the speed of the animation based on a float value.
// Get the current speed, which is 1 by default %scale = %myAnimatedSprite.getSpeedScale(); // Double the animation speed %myAnimatedSprite.setSpeedScale(%scale*2);
You get things like this when you "eat your own dog food". An artist or designer needs something, so you way the risk/work vs reward. In this case, it was a very simple request to accommodate. Hopefully you all will be able to make use of this.
#27
I have a suggestion for the final release:
The XCode4 projects with the examples have 2 targets: device and simulator (sim). It seems that the "sim" target is not needed anymore, since the "device" target also has options for running in the simulator. Could you remove the "sim" target for the release?
Unrelated:
It seems that this is a XCode 4.1 for Lion feature, but the deployment for older iOS versions (3) is no longer shown. This is a needed feature to test in iOS 3x.
It seems that XCode for Snow Leopard had these options.
Considering at the moment going back to Snow Leopard:-)
09/04/2011 (10:34 am)
@MichaelI have a suggestion for the final release:
The XCode4 projects with the examples have 2 targets: device and simulator (sim). It seems that the "sim" target is not needed anymore, since the "device" target also has options for running in the simulator. Could you remove the "sim" target for the release?
Unrelated:
It seems that this is a XCode 4.1 for Lion feature, but the deployment for older iOS versions (3) is no longer shown. This is a needed feature to test in iOS 3x.
It seems that XCode for Snow Leopard had these options.
Considering at the moment going back to Snow Leopard:-)
#28
When I run any iTGB project I start getting a white screen.
This happens just after the initial "default" screen *and* before the OpenGL view is shown.
NOTE: it seems that this is not the same problem reported for older iTGB versions where a "white screen" also showed up but stayed.
www.garagegames.com/community/forums/viewthread/106853
In this case the screen just stays less than a second and then it disappears.
This started happening in my 1.4.1 version. So, I downloaded 1.5p2 but it *also* happens.
My system is OSX 10.7 (Lion) with XCode 4.1, but I have this for a while, and the problem only started now.
It seems that it is iTGB related, since it does not happen with other non-iTGB projects. It happens for both device and simulator.
It is very noticeable in the Aquarium demo.
Here's a SWF movie that shows the problem
Aquarium demo with blank screen
Note: for anyone interested in doing movie screenshots, I used
Jing
The trick to get this movie was to put a breakpoint in XCode in the part that the simulator is rotated to landscape, then open Jing, hover the mouse over the simulator to get the capture area, click, and start recording :-)
09/04/2011 (10:57 am)
This is a strange problem that started happening out of nowhere:When I run any iTGB project I start getting a white screen.
This happens just after the initial "default" screen *and* before the OpenGL view is shown.
NOTE: it seems that this is not the same problem reported for older iTGB versions where a "white screen" also showed up but stayed.
www.garagegames.com/community/forums/viewthread/106853
In this case the screen just stays less than a second and then it disappears.
This started happening in my 1.4.1 version. So, I downloaded 1.5p2 but it *also* happens.
My system is OSX 10.7 (Lion) with XCode 4.1, but I have this for a while, and the problem only started now.
It seems that it is iTGB related, since it does not happen with other non-iTGB projects. It happens for both device and simulator.
It is very noticeable in the Aquarium demo.
Here's a SWF movie that shows the problem
Aquarium demo with blank screen
Note: for anyone interested in doing movie screenshots, I used
Jing
The trick to get this movie was to put a breakpoint in XCode in the part that the simulator is rotated to landscape, then open Jing, hover the mouse over the simulator to get the capture area, click, and start recording :-)
#29
09/07/2011 (10:28 am)
Sorry for asking but what is the status of 1.5? are we still in beta form? I am starting a new project, and was considering using it. I will hold on for now. Cheers.
#30
09/07/2011 (10:32 am)
The engine is going into closed beta this week. Building a game on the previews or beta is never recommended. If you want to use 1.5, you will need to wait for the final release.
#31
(You WILL miss them when accounting for changes between versions!)
09/07/2011 (12:00 pm)
Building a game on 1.5 beta is *awesome* if you have no deadlines, though :)(You WILL miss them when accounting for changes between versions!)
#32
::))((
09/07/2011 (12:02 pm)
Why with no deadlines? and why is it awesome. I know I could just try it, but I dont have tiiimmmeee.::))((
#33
09/08/2011 (2:04 am)
@Mich: Closed Beta this week? 1.5Final or 1.5Preview3? When will you post on the blog?
#34
09/08/2011 (6:10 am)
@Andrea - This will be the first round of QA for the final. A blog will be coming out on Monday, since the Torque 3D blogs are posted on Fridays.
#35
09/08/2011 (11:27 am)
Updated the credits dialog in the editor to represent the iTorque 2D team. Also using a prettier image:
#36
09/08/2011 (11:59 am)
Michael, thank you so much for including me in the credits, I am really honored to be part of it. :-)
#37
09/08/2011 (9:45 pm)
I made the list! Still wondering how. Thanks :)
#38
MainWindow.xib - flash of white during app launch
It turns out that that white screen showing before the OpenGl view is because the MainWindow.xib of the iTorque project (that has a white screen) is loaded.
I confirmed this by changing the background color of the xib to red
Aquarium demo with red screen
09/10/2011 (11:41 am)
"google is your friend", so the issue reported above in #28 is identified here:MainWindow.xib - flash of white during app launch
It turns out that that white screen showing before the OpenGl view is because the MainWindow.xib of the iTorque project (that has a white screen) is loaded.
I confirmed this by changing the background color of the xib to red
Aquarium demo with red screen
#39
09/10/2011 (12:47 pm)
Normally you set the MainWindow.xib background to the splash, that way you don't get the flash of white when you go from MainWindow splash to Torque splash.
#40
My first try was to remove the MainWindow.xib file. Is that file really needed?
I did in the main function the following #if switch from the original
Then in the app delegate added this
that seems to be the standard way to initialize without the xib file, which it did (displaying the same red background for a while).
If I remove the red background call, the only change is that the background turns to black.
I then tried putting the "Default.png" as the xib background; that does the trick of avoiding the flick, but it has to be a better way to deal with this :-)
09/10/2011 (1:04 pm)
yes, so far that seems to be the only option.My first try was to remove the MainWindow.xib file. Is that file really needed?
I did in the main function the following #if switch from the original
// now, we run UIApplication which calls back and starts thread or timer
#if 1
platState.appReturn = UIApplicationMain(argc,argv,@"UIApplication",@"TGBAppDelegate");
#else
platState.appReturn = UIApplicationMain(argc, argv, nil, nil);
#endifThen in the app delegate added this
- (void)applicationDidFinishLaunching:(UIApplication *)application {
window = [[UIWindow alloc] initWithFrame:[[UIScreen mainScreen] bounds]];
window.backgroundColor = [UIColor redColor];
[window makeKeyAndVisible];that seems to be the standard way to initialize without the xib file, which it did (displaying the same red background for a while).
If I remove the red background call, the only change is that the background turns to black.
I then tried putting the "Default.png" as the xib background; that does the trick of avoiding the flick, but it has to be a better way to deal with this :-)
Torque 3D Owner Pedro Vicente
Space Research Software LLC
This may be a long shot, but is there any chance of licensees to have svn (read only :-) ) access? Or svn commit access for selected "contribute" branches ?
I notice that has been some bug fixing as lately, that way we would have all the latest on it without having to wait for the "previews". And the implementation would be the "official" instead of the "our own".