61
Support / Re: Non power of two atlas
« on: November 14, 2012, 06:13:37 am »
Ok thanks, so I will avoid for now. I want to stay with the "mainstream" release.
Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
62
Support / Re: iPhone 5 texture best practices
« on: November 13, 2012, 10:04:40 pm »
I was afraid of that...
I do not have many backgrounds that will require work, but all my code assumes >1024 is outside of the screen + I have a delicate parallax controller that took me a long time to make it work smoothly on that 1024 wide resolution.
I will have to change a lot of stuff for this to be dynamic based on screen size.
So what you are basically saying is that in all my 2x atlases, I can do one of two things:
1. Allow 2048 atlas size or
2. Continue using 1024 atlas, and split my backgrounds to two, either manually or with dicing.
And in any case, the 1x atlas will automatically be half the size, so it will max at 1024.
Right?
I never used dicing, so am not sure what it can do really, but I am sure I can follow the docs on that.
I do not have many backgrounds that will require work, but all my code assumes >1024 is outside of the screen + I have a delicate parallax controller that took me a long time to make it work smoothly on that 1024 wide resolution.
I will have to change a lot of stuff for this to be dynamic based on screen size.
So what you are basically saying is that in all my 2x atlases, I can do one of two things:
1. Allow 2048 atlas size or
2. Continue using 1024 atlas, and split my backgrounds to two, either manually or with dicing.
And in any case, the 1x atlas will automatically be half the size, so it will max at 1024.
Right?
I never used dicing, so am not sure what it can do really, but I am sure I can follow the docs on that.
63
Support / Re: Non power of two atlas
« on: November 13, 2012, 09:51:46 pm »
Well, I was not talking about fonts, no.
Most of my atlases have over 30% wastage.
I am sure I can organize them better, but I always like to keep the atlases logically organized as well, so I am not mixing elements in one atlas just because I have space available.
I am never using mipmapping, as it is my understanding that for 2D, pixel perfect, I dont need any.
If indeed a smaller PNG means it takes less space in the final build, then I suspect most of my atlas.png files will enjoy 20-30% reduction in size, which is quite a lot.
Of course, if I am wrong in my assumptions, or the addition of such feature will bloat the plugin, then lets skip it, but if I am right, I would love to enjoy this reduced size.
Most of my atlases have over 30% wastage.
I am sure I can organize them better, but I always like to keep the atlases logically organized as well, so I am not mixing elements in one atlas just because I have space available.
I am never using mipmapping, as it is my understanding that for 2D, pixel perfect, I dont need any.
If indeed a smaller PNG means it takes less space in the final build, then I suspect most of my atlas.png files will enjoy 20-30% reduction in size, which is quite a lot.
Of course, if I am wrong in my assumptions, or the addition of such feature will bloat the plugin, then lets skip it, but if I am right, I would love to enjoy this reduced size.
64
Support / Non power of two atlas
« on: November 13, 2012, 07:42:29 pm »
Hello,
I understand that square shaped, power of two textures are only required on iOS when you are using compression.
If this understanding is correct - shouldn't there be a way for me to tell tk2d that I am not going to need compression, and therefore the generated atlas0.png should not have any extra padding? Won't that save some space?
I understand that square shaped, power of two textures are only required on iOS when you are using compression.
If this understanding is correct - shouldn't there be a way for me to tell tk2d that I am not going to need compression, and therefore the generated atlas0.png should not have any extra padding? Won't that save some space?
65
Support / iPhone 5 texture best practices
« on: November 13, 2012, 06:59:44 pm »
Hello everybody,
I was wondering if anyone has any tips in regards to the handling of iPhone 5 textures.
To be less vague - up until now, I have developed assuming 1024x768 resolution, and then I was planning on doing some cropping on iPhone - so my textures would remain pixel perfect.
The introduction of the iPhone 5 with the 1136 pixel wide screen changes everything.
Now, as far as I understand, I have two options:
1. Either fit to scale ("fit width") - which will enlarge my 1024 pixel textures a little (I am not sure what is the quality loss here), or
2. Redo my "native" game textures to use 1136 wide, and then crop on iPad and iPhone 4.
As if this isn't enough of a headache, using 1136 as a texture size (e.g. for background) would mean that I have to use an atlas size of 2048x2048, and then I am not sure how it will all work on devices that limit texture size to 1024.
Any insights are appreciated.
I was wondering if anyone has any tips in regards to the handling of iPhone 5 textures.
To be less vague - up until now, I have developed assuming 1024x768 resolution, and then I was planning on doing some cropping on iPhone - so my textures would remain pixel perfect.
The introduction of the iPhone 5 with the 1136 pixel wide screen changes everything.
Now, as far as I understand, I have two options:
1. Either fit to scale ("fit width") - which will enlarge my 1024 pixel textures a little (I am not sure what is the quality loss here), or
2. Redo my "native" game textures to use 1136 wide, and then crop on iPad and iPhone 4.
As if this isn't enough of a headache, using 1136 as a texture size (e.g. for background) would mean that I have to use an atlas size of 2048x2048, and then I am not sure how it will all work on devices that limit texture size to 1024.
Any insights are appreciated.
66
Releases / Re: 2D Toolkit 1.80 + patch 2
« on: November 10, 2012, 07:22:41 pm »
This is not yet on the asset store? I am usually updating from there.
Also, does this version solve the menu bug that happens when deleting an animation clip?
When deleting a clip (with the minus button), the animation menu contains a separator where this clip once was.
Not sure if its the same cleanup issue as the font problem that I see was fixed.
Also, does this version solve the menu bug that happens when deleting an animation clip?
When deleting a clip (with the minus button), the animation menu contains a separator where this clip once was.
Not sure if its the same cleanup issue as the font problem that I see was fixed.
67
Support / Re: Camera Depth Performance Impact
« on: October 22, 2012, 02:33:35 pm »
Excellent! Thanks for the quick reply.
68
Support / Camera Depth Performance Impact
« on: October 22, 2012, 02:15:48 pm »
Hello everybody,
I am now organizing the layers of my game, so each layer have enough room to add and remove elements.
So my background will naturally be far into the Z, and the HUD will be closer the camera, etc.
I was wondering if having a large camera depth - say 800 pixels - has any significant performance penalty I should worry about.
I mean, it is easy for me to say that Background layers all live in 600-700, the game itself happens at 200-600 and the HUD and overlays live at 0-200.
The primary reason I am looking to use these large numbers is that in the game I am sometimes using 3D particle effects, so they do take up more Z than needed, and I want them all to stay within their layer (for example, a sphere shaped explosion with a sphere of 100 pixels, will originate at 400 but will send particles to 350-450 - and I want them to not appear on top of the HUD).
Thanks in advance for any input.
I am now organizing the layers of my game, so each layer have enough room to add and remove elements.
So my background will naturally be far into the Z, and the HUD will be closer the camera, etc.
I was wondering if having a large camera depth - say 800 pixels - has any significant performance penalty I should worry about.
I mean, it is easy for me to say that Background layers all live in 600-700, the game itself happens at 200-600 and the HUD and overlays live at 0-200.
The primary reason I am looking to use these large numbers is that in the game I am sometimes using 3D particle effects, so they do take up more Z than needed, and I want them all to stay within their layer (for example, a sphere shaped explosion with a sphere of 100 pixels, will originate at 400 but will send particles to 350-450 - and I want them to not appear on top of the HUD).
Thanks in advance for any input.
69
Releases / Re: 2D Toolkit 1.80 final
« on: October 17, 2012, 04:40:59 pm »
So, I have merged the new version into my main develop branch, and things look great!
An added bonus for me, is that in previous versions every time I played the scene, it became "unsaved" and saving it, would save something different to the scene.unity file even though I haven't changed a thing. So I have a lot of commits with "Save" as a comment. At first look, this behavior seems to be gone now as well as the leak notices in the console.
Fantastic work.
An added bonus for me, is that in previous versions every time I played the scene, it became "unsaved" and saving it, would save something different to the scene.unity file even though I haven't changed a thing. So I have a lot of commits with "Save" as a comment. At first look, this behavior seems to be gone now as well as the leak notices in the console.
Fantastic work.
70
Support / Re: Creating a scalable overlay sprite
« on: October 14, 2012, 06:59:14 pm »
Will do.
I actually submit about one or two every release they have.
I actually submit about one or two every release they have.
71
Support / Re: Creating a scalable overlay sprite
« on: October 14, 2012, 05:23:13 pm »
Well, I have that animated GIF to prove I am not crazy.... 
72
Support / Re: Creating a scalable overlay sprite
« on: October 13, 2012, 07:45:09 pm »
This is a clean new project, only with imported tk2d (the public version, not beta).
I am on Windows as well, so if you see something different, it is bizarre.
If you think of anything else, let me know.
Thanks for all the tips and help - I will post a Unity Answer thread and will cross-link it with this thread.
EDIT:
Seems like someone else started a thread on the same subject earlier today, so I am joining his thread.
EDIT 2:
When running on a Mac, I do see "batched" above zero, so the problem is not in the project but in Unity for Windows.
I am on Windows as well, so if you see something different, it is bizarre.
If you think of anything else, let me know.
Thanks for all the tips and help - I will post a Unity Answer thread and will cross-link it with this thread.
EDIT:
Seems like someone else started a thread on the same subject earlier today, so I am joining his thread.
EDIT 2:
When running on a Mac, I do see "batched" above zero, so the problem is not in the project but in Unity for Windows.
73
Support / Re: Creating a scalable overlay sprite
« on: October 13, 2012, 07:39:11 pm »
Unity 3.5.6f4
Targeting either desktop or web player.
Yeah - it seems like it does batch, there are 2 draw calls instead of 10, but it doesnt show it in stats.
Should I take this to Unity Answers?
Targeting either desktop or web player.
Yeah - it seems like it does batch, there are 2 draw calls instead of 10, but it doesnt show it in stats.
Should I take this to Unity Answers?
74
Support / Re: Creating a scalable overlay sprite
« on: October 13, 2012, 06:14:04 pm »
Thanks.
Im doing just this test now, batching at 0
The draw calls number is not increased, but batching is definitely stubborn at 0.
Will try the test scene, but even if I see it does work, I do not know what is the difference between it and my setup.
EDIT:
Started a new project, imported tk2d and all test scenes show 0 batching.
I am testing this on Windows, in the editor, using Unity Free.
EDIT 3:
Well - if I go to player settings and disable Dynamic Batching, draw calls number jumps from 2 to 10 - so I guess it DOES do some batching, it just doesnt tell me about it in the "batching" value in the stats window.
Any clue why?
Im doing just this test now, batching at 0
The draw calls number is not increased, but batching is definitely stubborn at 0.
Will try the test scene, but even if I see it does work, I do not know what is the difference between it and my setup.
EDIT:
Started a new project, imported tk2d and all test scenes show 0 batching.
I am testing this on Windows, in the editor, using Unity Free.
EDIT 3:
Well - if I go to player settings and disable Dynamic Batching, draw calls number jumps from 2 to 10 - so I guess it DOES do some batching, it just doesnt tell me about it in the "batching" value in the stats window.
Any clue why?
75
Support / Re: Creating a scalable overlay sprite
« on: October 13, 2012, 05:50:08 pm »
Thanks for the tips.
I see I have ~20 draw calls in my level, 0 batching no matter what I do.
Is there some Unity / tk2d setting I am missing?
Is 20 considered a lot?
I see I have ~20 draw calls in my level, 0 batching no matter what I do.
Is there some Unity / tk2d setting I am missing?
Is 20 considered a lot?