iTorque 2d 1.5.1 Release??

#161 I have preview 1.5.1 woking on my Mac but I'm not sure how to copy a project from 1.5 over to 1.5.1 - I've tried copying all the files in the "projectiles" folder from 1.5 to 1.5.1 that I added and then I manually applied any changes to scripts I made in 1.5 to the existing scripts in 1.5.1. I then deleted any dso files that would have been from 1.5.

When I start up iTorque Game Builder.app it starts fine but no graphics/images for the level are displayed although the objects exist in the Projects Object Tree and I can select them in the Object Tree and edit them. When I open the Datablocks editor the datablocks are in the right hand column (Level_1 Datablocks) but the Managed Datablocks list is totally empty. When I use the "Play Game" button the game starts and plays fine. When I exit out of the TGBDebug the Game Builder does not have any graphics/images displayed (just like when it started - no changes). Weird.

I know I messed up - but what?

Thanks!

#162 just logged into my account, the new version is not there.

How do I get access?

#163 @George
It's not a separate product listing, it's in the iTorque 1.5 downloads. Go to your iT2D 1.5 download, don't forget to check the EULA box, and you'll see the preview download along with the others.

#164 @Troy, and all wanting to migrate from 1.5 to 1.5.1

In order to fix the RootViewController issue, a new Xcode project had to be set up. This means that just copying over your project is going to cause problems and what not.

The best way to migrate is to make a NEW project with 1.5.1, and then migrate your scripts and code over to that project.

#165 @michael: xcodes4 works - thank you; but I found that there is problem to setup Portrait for iPhone, can you check it?

#166 The input doesn't work for me in Windows with 1.5.1.
The cursor simply doesn't appear over the main screen.
I am moving a projevt from iTorque 1.5.
I think I had this problem once.
Ant suggestions ?

#167 I found it:
hideCursor() in line 36 of levelManagement.cs.
This prevents events in Windows.
Is still there, I remenber that I corrected this in the first implementation. And It's still there.

#168 This seems to me analysis error:
$pref::iOS::DeviceType == 1
$pref::iOS::RetinaEnabled == 1

The two variables seems to determine just one thing: device type.
The point is the decision when a device is different.
In the context of iT2D they are different when they have different resolutions and/or different computing power.
For me the solution is to create an unique identifier for every iOS device that works with iT2D.
0-iphone3gs, 1-iphone4, 2-iphone4s, ... .
If you create incomplete identifiers , you will make the same analysis errors again.

#169 Another thing that is completely wrong for me is have levels constructed for different devices in the same project files.
This makes easier to create a level for an artist , but make more difficult to create different behaviors in different devices for a programmer.
I have this problem now. I found that simsets for iPad and iPhone are in the engine code.This seems to me a very bad idea, because the best way is construct different levels specialized for the device.
The paths of resources for construction must be completely different.
This leads to a mass confusion in the code.

#170 It's bad practice to look for specific devices. You look for capabilities, like the OpenGL ES version available, screen density etc. This is in Apple's own recommendations too :)

#171 Ronny, the entity "device" will easily appear in analysis.
You can define this entity with it's attributes and it's relationships (in an ER approach, we can use OO, but the result is the same).
If we have a lot of important variations (CPU/GPU/RAM) in the same iOS device , like 4 or 5 iPhone 3GS with several differences , ok. Since storage size(8, 16 or 32 GB) is not important, for a conventional game, why not classify by the device model , since it's essentially the same?
If the platform was Android, of course, the device capabilities must constitute attributes that must be checked . In OpenGL , there are interfaces to return the device capabilities and extensions.
You must map the extensions using function pointers and register this capabilities, in the device entity ( or class in the project)
BUT, this will constitute again, attributes for the entity device.
The point is, you always have an entity "device". The interface is simple or complex , that's why you see several different classes with the same name in different frameworks. They will implement the complexity that is needed to solve the problem.
But nothing can change the fact that "a device has capabilities".
This is pure analysis.I think what Apple recommended is: we can change the hardware without notice, guys, even in the same model.
But I don't think that a consumer device can loose CPU Power or GPU power, because this can make users very upset.
OpenGL 3.0 is backward compatible with OpenGL 2.0, bute OpenGL 4.0 is not backward compatible with OpenGL 2.0. What means that a game could not work in future platforms even if it discovers capabilities.
Mobile GPUs are using OpenGL ES 2.0 , what is pretty like OpenGL 2.0.
But, this is an engine problem, since the engine creates a layer that prevent us to use OpenGL directly.
The problem that talked about, is the fact that an interface to the engine layer must have a device resolution that must be effective. You cannot create a layer that prevent or make difficult to create different paths in your game, since things can or must work different in different iOS devices. Things like CPU/GPU power and resolution are critical. This doesn't matters if your game don't push the platform to Its limits or your game work with the same interface in all iOS devices.
It seems that iT2D was optimized for this kind of production. This is just a design decision, but the right way to do this is creating a device that could be manipulated by the programer. What your program do to instantiate this object correctly, is a very different problem.

#172 When is Preview 2 coming out?

#173 This is post is a part of what was originally posted by Eric here and here.

Quote:We are crunching on 3 Step Studio and that milestone ends in late September, which is why many of our resources are consumed. The work they are doing will benefit our 2D engine(s). So, even though we are weeks away from that release, perhaps I can give you a few nuggets now (some you do know I'm sure).

1) iTorque/Torque 2D have merged into one product.
2) We've integrated Box2D.
3) We've built and underlying modular component-like system so that it's easier to maintain and extend functionality.
4) In adding Box2D, we broke several sections of the editor so we will need to fix them before we can provide an update.

As it stands, this is completely accurate as far as resource allocation is concerned. I have no bandwidth to work on a second preview for iT2D 1.5.1. Any time I could scrounge up would be spent outside of work, which increases the risk of more problems. Even that preview has a high risk of bugs not being fixed or more being introduced.

The current plan is that a 1.5.1 preview 2 will not happen, unless I am taken off my current project. The likelihood of that is basically zero, since I am a critical resource for the other project. I will be posting a reply in Conor's Blog, but that will be the only status update I can provide without misleading anyone.

I deeply apologize to everyone. It is embarrassing and painful that I cannot deliver on what I was expected to. What could be addressed, will be in the next official update, but that timeline extends beyond September.

#174 Thanks, Michael. That's exactly what I needed to hear. Good luck!

#175 Lengthier post on Conor's blog

#176 Thanks Mich - I understand your hands are tied on this issue. Hopefully the new version will create a fresh start and can be maintained more easily.

#177 Hi everyone it has been a VERY long time since I was here however I have followed this particular thread. Since iTorque2d is becoming part of Torque2d and the software is being rebuilt from the ground up I do have a question. Will I be able to port over my existing projects? One project in particular will have around 60 levels when finished (60 scene files)
so I dont fancy going back through and rebuilding 60 scenes with various mechanics etc.
Will there be cross compatibility or am I looking at a rebuild?
Thanks in advance.

#178 @Jack-S- Backwards compatibility will be completely non-existent. Your levels will have to be converted, as well as some other files. Someone is likely to create a level converter to handle the following:

1. Rename all t2dStaticSprite and t2dAnimationSprite objects to sprite
2. Convert behavior field to collections
3. Convert datablock fields to prefabs
4. Convert linkpoint field to joint collections
5. Rename all t2d objects by removing the "t2d" prefix
6. Convert old tile layer objects to the new version
7. Convert file format from .cs to .scene.taml

#179 @Michael - You know, the conversion process of a simple project would be a great topic for a 2D Day blog.