Orthello 2D Framework - 100% FREE

When does the camera starts moving and what is controlling its movement? If you control this by code, you should be able to round the position, each time that it moves.

 

I'm using Orthello to develop for Android game. My game will jerky sometime and I couldn't know what is the problem. I found in some forum (I can't remember where), they did mentioned Orthello garbage collect is an issue. If this is the issue, how can I solve the problem? Or is there any way for me to figure out the issue? Thanks

 

Because lots of stuff can create jerky movement like :

- Garbage collection
( do not use List<> and create/delete elements a lot , use System.Array instead )
- vSync setting
( display quality VSync Count <- I don't sync )
- Instantiating objects
( use prefabricate to create objects on start and re-use them )

- and probably more ...

To determine what causes the jerky movement you will need to run the profiler that comes with Unity PRO,
this will usually give you an indication where to look.

Hope you can find your issue.

 

I have a small suggestion/request with regards to the 'movement target' of the View. I think this function would be even better if we could setup a rectangle around the target and have the View move only when the target is crossing the boundary of this rectangle. As it is now, it doesn't really fit a lot of games.

Of course, this is easy enough to do through code as well, using the OT.view.position, but could be one of those small things that make Orthello even more convenient to use.

 

I'm noticing that, for some reason, all my sprites are moving on the z-axis despite there not being any force applied there. Why is this?

 

Good suggestion ..
I will put it on my todo list...

if you already have the code at hand , please send it in ...

 

This is due to the painter algorithm that will add some decimals to the depth (zValue) x/y position related and orders the sprites that are at the same depth (layer) from left (back) to right (front) and top (back) to bottom (front)

in the upcoming 2.0 version there will be a bool OT.painterAlgorithm that can be set to false ( defaults to true ) to stop this behaviour.

 

This is my simple camera script, which is attached to the main camera and where 'playerMovement' is the name of the playerobjects script and playerPosition is the transform of the same object.

Code (csharp):

1. using UnityEngine;
2. using System.Collections;
3.  
4. public class CameraScript : MonoBehaviour {
5.    
6.     private float positionX;
7.     private float positionY;
8.    
9.     private float xOffset = 16f;
10.     private float yOffset = 16f;
11.    
12.     void Awake ()
13.     {
14.         positionX = OT.view.position.x;
15.         positionY = OT.view.position.y;
16.     }
17.    
18.     void Update ()
19.     {
20.         //check if the camera should move along the x-axis
21.         if (playerMovement.playerPosition.position.x > positionX + xOffset)
22.         {
23.             positionX = playerMovement.playerPosition.position.x - xOffset;
24.             OT.view.position = new Vector2(positionX,positionY);
25.         }
26.         else if (playerMovement.playerPosition.position.x < positionX - xOffset)
27.         {
28.             positionX = playerMovement.playerPosition.position.x + xOffset;
29.             OT.view.position = new Vector2(positionX,positionY);
30.         }
31.         //check if the camera should move along the y-axis
32.         if (playerMovement.playerPosition.position.y > positionY + yOffset)
33.         {
34.             positionY = playerMovement.playerPosition.position.y - yOffset;
35.             OT.view.position = new Vector2(positionX,positionY);
36.         }
37.         else if (playerMovement.playerPosition.position.y < positionY - yOffset)
38.         {
39.             positionY = playerMovement.playerPosition.position.y + yOffset;
40.             OT.view.position = new Vector2(positionX,positionY);
41.         }
42.     }
43. }

 

THANKS!!

I will integrate it into the upcoming 2.0 release.

 

Any 'happy' Orthello users that will be at the Unite 2012 in Amsterdam this year?

I will be there 3 days and would be delighted to have a chat about your experiences,ideas
and whishes about orthello.

Let me know (PM) if you are there so we can meet up.

 

Orthello 2.0 is here ..


| Download Orthello |

2.0
- READ UPDATE/UPGRADE INFO! in {project} / Orthello
- added : OTTextSprite, OT9ScaleSprite,
- added : Full mobile (multi finger) drag/drop support
- added : Side/TopDown (navmesh support) / 2.5D / 3D integration (OT3D)
- added : OTSound (easy sound support)
- Fixed multiple issues ( like : save state, parent/child control, material cache + mesh leaks , level persistance )
- EXAMPLES : check 0 - Simple Examples

 

Latest version has been put on Asset Store .. but due to some Asset Store error .. the package content won't change. I advise, for now, to download it using the link in my previous post, and not use the asset store.

 

Finding Orthello incredibly helpful so far! (Except that trying to google for help invariably leads to shakespear. Heh. )

First, what's the process for updating versions of Orthello? Do I simply need to re-import the package into the scene?

Secondly:

It seems the AnimatedSprite's DestroyOnFinish doesn't use Orthello's object pooling, which means my scene quickly acquires a lot of dead copies of whatever animated sprite I'm creating.

I changed the Stop() method in OTAnimatingSprite to use DestroyObject instead of Destroy, and it seemed to solve this. Is this just a leftover from pre 1.3, or is there some other reason to not use object pooling here?

 

Just importing the latest package into your project should do the trick.

IMPORTANT! Always backup your project before updating to be sure that you can roll back if something went wrong!

However ... If you moved the Standard Assets folder or other Orthello folders out of the default...

You should first move em back into their original position before importing, otherwise you will end up with a lot of 'missing scripts'
You could also import Orthello into a new project move/correct the folder structure and create a new import package for your project.

I think you have found a bug there....

AND FIXED IT!!
TX...

 

I notice I have some trouble instantiating prefabs using Orthello. Whenever I spawn them, they seem to appear at 0,0,0 every time rather than the position I try and spawn them at. Is this a bug or am I doing something wrong?

Code (csharp):

1. var debugSpawnEntity : GameObject;
2. var positionOfEntity : Vector2;
3.  
4. function Start () {
5.  
6. }
7.  
8. function Update () {
9.  
10.     if (Input.GetButtonDown ("Fire1")) {
11.         Instantiate (debugSpawnEntity, positionOfEntity, transform.rotation);
12.     }
13.  
14. }

I should mention that I'm not yet on the latest version.

Did this make it into the release? I can't seem to access it under this name.

edit: I updated to the latest version and the problem persists.

 

Ha. I was just about to post my own question about this. Here's my code (though it's in C#), same issue.

Code (csharp):

1.  
2.     void Update ()
3.     {
4.         if (Input.GetKeyDown(KeyCode.Z))
5.         {
6.             Attack();
7.         }
8.        
9.     }
10.    
11.     void Attack()
12.     {
13.             GameObject g =  OT.CreateObject("SlashSprite");
14.             g.transform.position = player.transform.position;  
15.  
16.     }
17.  

I've noticed this with Orthello's object pooling - if it has to create a new object (i.e., instantiate it, as above), it spawns on the center of the screen. If it can use a recently deleted object instead, it will move the object appropriately.

So the quick-fix is to prefabricate some objects so you don't have to instantiate them each time. But yes, this does appear to be a bug.

 

@MarigoldFleur

If you can not find OT.painterAlgorithm, you are not on the 2.0 release. Please download the 2.0 version from our website, as the AssetStore has some bug that seems to not update the AssetStore Package contents.

@MarigoldFleur + GeneralV

Please make sure you are on the 2.0 version. You are if you have an Orthello/Examples/0 - simple examples and an TextSprite Object.
There have been some fixes regarding positioning so they could be solved.

 

Hey.
I have a problem with a prefab of animatingSprite floor tile resizing to the frame size. When i pull it in i can manually change it back but this makes level editing overly long. Is there a solution to this?

I have seen what seems to be a similar problem mentioned on these forums before:
"Assigning a container (the first time) should reset this size to the first frame
or assigning an image should reset this to the size of the image texture;"

Any help would be much appreciated.

And thanks for the great product!

 

I've downloaded the latest version of Orthello and set OT.painterAlgorithm to false and now the sprites don't change their z position based on their xy position which is great, but I still have a slight other problem. The only way I can set the sprite z position myself is to update it every frame. Is there a way I can individually set sprite z positions just once and not have to keep updating them?

 

The z-vertex value on OT.world=World2DSide or y-vertex on OT.world = World2DTopDown is controlled by the int OTSprite.depth property. To set the z-value to a fractured number is not possible.

 

Could you send us a package with instructions ( info at wyrmtale dot com ) that demonstrates the problem? This way we can dive in and fix it for you.

 

I am working on an iPad project for cocos2d and trying to evaluate switching to Unity with a 2d framework. I have been trying Orthello this weekend but hit some snags.

I have imported some sprites and a texture atlas made with TexturePacker and I have encountered the folllowing 2 issues:

1. The texture atlas loaded properly but the image was scaled down to 50% so none of the coordinates were correct. When I would select the frame index to display, the sprite would update its image and size, but the sprite boundaries were always double what the pixels were showing, so lots of extra pixels got shown from other frames in the atlas.

I saved out a new atlas from TexturePacker just to make sure and the same thing happened again. I had to go into the texture atlas data in the inspector and change every position and size value to 50% in order to get them to appear correctly. I did finally get it working but would love to know why the sprites render at half the size they are supposed to be at.

2. Every time I try to add a sprite to my scene using an image that does not come from a Container (texture atlas), it turns white as soon as I hit Play.

First, I add the sprite and drag on the texture. It looks good in the game camera and the editor.


Here is what the material looks like in the editor before I hit Play:


Then as soon as I hit Play the sprite turns completely white and the Material no longer shows up in the inspector.


Finally, this error shows up in the console when the Inspector blanks out:



I've tried this with a bunch of images, PNG 8 bit and 24 bit color, and TIFF 16 bit. Same behavior on all.

 

I have a similar problem to this. (I *think*) Though I'm also having an issue where I can't set the starting frame index on OTAnimatingSprites. Well, I can set it, it'll just reset back to 0 the next time I open the Scene or adjust the OTAnimatedSprite script component.

I'll go ahead and send a package so y'all can hopefully figure out what's buggin' out.

Thanks for your assistance thus far!

 

@VictorB

Can you send me your test-project so I can check what is wrong?

 

Private message sent with link to project zip file.

 

Hi there victorb.

Thanks and no bugs there.. just some things you have to setup in another way.

Regarding the sprite turning white

It looks to me that you creating a seperate material for your sky and are assigning it manualy to the sprite object. This won't work!. Orthello mangages the materials for you. If you want to use a custom material you have to do this by expanding the Orthello material system.

You can so so by :

1. Add a your custom material to the OT.materials (material references)
2. Assign the custom material reference to OTSprite.materialReference

( if you also would like to use tinting and alpha values on your sprite, you will have to set the right shader field names in the custom material reference that you created. )

| read more about orthello materials here |

However .... The simpler solution to reach your goal here and create your blue, textured sky is just to ..

1. assign the OTSprite.image to your sky-texture
( you will have to resize it , because asigning it the first time will set the size to its base size)

Regarding the atlas

When calculating the correct uv-mappings, orthello will use by default the image dimensions that Unity provides in combination with the info from your exported atlas meta data ( that does not include the original width and height). In your case 512x1024.

Now because the dimensions in the atlas meta data are based on the original 1024x2048, things will not be displayed correctly.

You have 2 possible solutions :

1. Set the max size of your texture using the texture importer to 2048 instead of the 1024. This could be not advisable if you are publishing to an iPhone, because some of them have a max of 1024.

or (probably the best solution in your case)

2. Specify the original size (1024x2048) in your atlas.sheetSize ( defaults to 0,0 )

This way the atlas will 'know' the original size and can calculate the uv coordinates properly.

| read more about spritesheets and atlases |

Hope this makes sense and helps ..

 

Yes, that makes sense and I finally figured it out. Thanks for the response.

But this means that there is no way to just "drag" an image onto a sprite? I have to make a material reference on OT with a new unique name, then type that name into a field on the sprite every time I need to add a new image that is not inside a sprite atlas?

 

No , that kind of workflow would be terrible! .. Orthello life should be easy .. no custom material is needed here ...

.... The simple solution to reach your goal to create your blue, textured sky is to ..

1. Select your sprite in your scene

2. Drag your image/texture from your project view on to the sprite.image property in the property inspector.

You will have to resize your sprite because when assigning an image, the dimensions (corrected by OT.view.customSize) will be set automaticly.

GL

 

I was just checking out what's new in Orthello 2.0 and saw this note in the readme file:

This is great news! I was one of the people asking for this feature here a few months ago. Thanks for making this change!

 

Does Orthello have any kind of support for Pixel Perfect collisions? Specifically, I did some tests with oddly shaped OTSprites that had transparency, and I noticed that collisions were registering when one sprite was colliding with the other's transparent bits.

Ideally, I'm looking for a way to ignore transparent pixels in the collision, but right now, it's looking like I might have to write my own code to do so (or break one big sprite into a couple of linked, smaller, rectangular ones that avoid the majority of the transparent pixels).

 

No , at this time per pixel based collisions are not possible.

I am working on a 'collision shape' solution for Orthello PRO. The collisions shapes will be created from OTShape objects like the OTSpline or OTCircle where you can create a BSpline shape and use it as a base for collisions.

 

That's good to hear! In the meantime, I have another question:

Are FilledSprites supposed to have unique textures? (Image attribute)

I have 2 FilledSprites in my scene, and when I try to drag the same texture onto the 2nd sprite, the first sprite stops displaying according to its fill size settings (i.e., the image is stretched instead of tiled) and the 2nd one behaves normally.

 

mmm ... sounds like some material cache problem ..
again .. send me your package please...

 

I've been doing some tests with Orthello on NaCl. It seems to work really well! But there's one catch. NaCl doesn't support the XmlDocument class, so XML-based sprite atlases in Orthello don't work. Luckily there's an easy workaround. As long as you set up your containers in the editor (at design time) you can use any type of sprite atlas, load the atlas data, and then drag a vanilla OTSpriteAtlas script on top of the existing atlas script (i.e. to replace it). Since the atlas data is actually stored in OTSpriteAtlas Unity will keep the data that has already been loaded, and since OTSpriteAtlas doesn't depend on XmlDocument NaCl will be happy.

I'm not sure if this is worth fixing in Orthello itself... I can't think of an easy fix. But hardly anyone seems to use NaCl with Unity anyway so it's probably fine. I thought I'd share this info for anyone who might be interested.

EDIT: It looks like Unity 3.5.3 may have broken XmlDocument support in NaCl. That is, Orthello probably worked perfectly fine in Unity 3.5.2. I'm still investigating the issue...

 

I use Unity3d and Orthello package to build fruit ninja gam 2d.
I can't create slash effect with orthello, somebody help me, please !

Thanks,

 

Hi there,

Thanks for making such a powerful 2D rendering solution!

I've considering using Orthello to render our game UI and wanted to try using the Scale9Sprite to render windows.

However, when trying to use a sprite container for the Scale9Sprite, this error appears:

Mesh.uv is out of bounds. The supplied array needs to be the same size as the Mesh.vertices array.

The Scale9Sprite has 16 uv coordinates while the frame only has 4.

Is there no way to use containers with a Scale9Sprite?

Thanks.

 

At this time the OTScale9Sprite only works when using it with the 'image' field. So working with a container is a known buggy 'feature'.

 

The best way to create a slash effect is to continuesly capture your touch input and create
a changing/animating mesh from that.

This is a difficult task.

 

Thank you for clarifying that! Might a container supported Scale9Sprite be available some time soon?

 

Thanks mas for this solutions,
I found other solution : using effect of Unity3d : create a GameObject and choose Component -> Effect -> Trail Renderer


I have other question : How to split sprites (2D, images) when slash on to this?

 

Hey, Martijn!

Another day, another bug.

Orthello Prototypes don't appear to obey the Pivot function. E.g., if you set the pivot of a Prototype to "Bottom", the pivot point won't update to 0, -.5. Though it will still prevent you from manually editing the vector, it remains at 0,0 (or whatever you've set it to, if you've a custom pivot point).

Simplest workaround in the meantime is to set a custom pivot point (which appears to work correctly).

 

I will put it on my todo list. But I dont think it will be some time soon...

 

That is not possible with Orthello. You will have to code your own custom solution for that. Probably creating custom 2D sliced meshes.

 

Do you mean .. If a Prototype has a 'centered' pivot by default .. And you try and set the instanced (OT.CreateObject) sprite to another pivot?

 

When you change the pivot value (Centered, Top, Bottom, etc) of a disabled sprite within the unity editor, the pivot point does not update, and, additionally, can be set to whatever values you wish, as if it were set to Custom.

In retrospect of my case, it wasn't the fact that it was a prototype, but rather the fact that I'd disabled that particular game object.

 

Ah .. that explains it .. What you are experiencing is caused by the fact that scripts of disabled Unity GameObjects are not executed. Because an Orthello Object is just your regular GameObject, this also applies here.

I would recommend you to disable your prototypes after you have finished setting them up.

or

I often see myself, not disabling my prototypes at all, but merely locating them out of view. Makes it also easier to tweak them while I am building my game, not having to dis- and enabling them each time.

If what you seek is just to hide them, you can also simply disable the mesh-renderer. You could also de-activate them when your game starts.

 

Forgive me if this question has already been answered.

I've been exploring the Orthello free framework to see if it would suit my needs. So far, I've been extremely impressed with it and am giving serious thought to buying the pro-version. One little thing I'm struggling with is this: my spritesheet is comprised of images that are 64x64pixels, and when I create a sprite object in the scene, it automatically defaults to a size of 64x64 (instead of 1x1). Although this is relatively easy to get around, I'm curious as to whether I've missed a step in setting things up. Should individual objects not have a size of 1x1 to simplify the correct placement of objects from script?

Either way, I'm thoroughly enjoying the ease of building a scene and incorporating animations. Well done!

 

@Nomad72 I'm not sure what you're asking - position is a separate property from size.


@Martijin / Wyrmtale

When two sprites are at the same depth, the left-most one always winds up in front of the other. This would be fine when you've got still sprites, but if you're moving from left to right, it can be a little bit jarring when the sprites suddenly appear to swap depth positions. Is there a way to get Orthello to draw same-depth sprites more consistently?

 

OK, lets put it this way: I setup my atlas and created a simple sprite object as a block. I then put one more to the left, and one to the right of this first block, as the first few blocks in a grid. The blocks are positioned at (-64,0) , (0,0) and (64,0) - not my choice of transform positions, that's just how it's turned out after visually placing them in the scene.

This is the situation I found myself in after placing 3 instances of the same block. I noticed this... and found that the scale was set to 64x64. I tried to change the scaling to (1,1) so that I could have the blocks at (-1,0), (0,0) and (1,0) but then the blocks were too small to see with the default camera size that the Orthello framework had set.

This seems weird to me, so I was wondering if I'd missed a step in setting things up... or more simply if I had messed something up.

 

@Nomad - Orthello changes unity's default units from 'meters / unit' to 'pixels / unit'. If your block sprites are 64 pixels wide, it makes sense that the offset of adjacent blocks is 64. If you want 64 pixels to equal one "unit", I think you'll have to do the unit conversions yourself.

(Or perhaps I'm still not understanding you?)