Messages

31

Support / Setting (and using) correct platform

« on: March 04, 2014, 06:11:13 am »

Hi,

I am trying to get along your platform support docs (and all the threads here around it). I am failing already early, because setting the platform support in code does not work correctly for me. I set it in a specific setup script really early in the startup phase (backed by an explicit early script execution order) like this: tk2dSystem.CurrentPlatform = "2x";
I added a log to your currentPlatform getter, and it is already correctly set to "2x" the first time it is being requested at all. However, at runtime the affected sprites are still pointing to the 4x atlasses. If I set it manually in tk2d Prefs, however, they correctly point to the 2x atlas.
I assume I missed one important additional step -- I simply don't know which...

Thanks, habitoti

32

Support / Issue in creating platform support?

« on: March 04, 2014, 06:02:54 am »

If I haven't overlooked something, I might have found two issues with platform support (I am cautious in my wording, since I sometimes fail to get the whole -- huge -- picture in the first place  )

I start off with a 4x platform, then introduce a 2x later on (anchor calculations are no issue here for me...). Two things happen (which I can workaround manually, so no _big_ deal, but maybe not so nice...)

• If max size of atlas is set to current size of 4x, I get "Assets do not fit in atlas" error and 2x isn't created on commit. Only if I make it larger than actual current 4x atlas, it works (and of course ends up smaller). So I have e.g. a 2048x2048 4x atlas, max size set to 2048. Only if I set max to 4096, also the 2x is created (at 1024x1024)
• If I use two materials on the original source platform, this won't be replicated into the new 4x and 2x platform. To better distinguish them, I renamed the original "atlas0 material" and "atlas0 material 1" into "transparent material" and "solid material" because otherwise you had no clue in the selection dropdown which one is which. The new 4x and 2x platform folders will contain only one "atlas0 material". As soon as I introduce manually a second one and rename those again, the initial assignements to individual assets will be immediately correct again.

Regards, habitoti

33

Support / Platform support only for multiples of 2?

« on: March 03, 2014, 04:05:54 pm »

Hi,

is there any technical (tk2d internal) reason top only have platform support in multiples of 2 (as the platform support creation process suggests), or can I switch to arbitrary source resolutions?
Reasoning: coming from iOS, I have all artwork as hires sources made for 2048x1536 iPad Retina resolution. For Android, lots of devices out there still have 1280 x <something>, and just a few phones have <= 1024 x <something>. So for the latter, it would be less worthwhile to create the 2x of 1024 (vs 4x/2048) platform, but creating a "native" 1280-based set of atlasses would be very much of a useful additional effort.

Thanks for clarification,
    habitoti

34

Support / Re: Mystical thin black line around sprite

« on: February 15, 2014, 06:44:38 pm »

Can you get me some repro steps and a texture that breaks?

Sent via mail...

35

Support / Re: How to increase size of textmesh without losing quality?

« on: February 15, 2014, 01:48:17 pm »

yup

36

Support / Re: How to increase size of textmesh without losing quality?

« on: February 15, 2014, 10:15:30 am »

You won't get any more pixel information than the underlying bitmap font provides. Filtering can only flatten so much, and it will look blurred then. So you need to provide at least the largest required font size as a bitmap source. Scaling down also might loose clarity, though, since the original antialias data doesn't scale well, so I provide the most common smaller sizes as additional original bitmaps.

37

Support / Mystical thin black line around sprite

« on: February 15, 2014, 08:55:10 am »

Hi,

I have a square sprite with a dark grey underground. It appears correctly in the atlas (Pic 1), but when put on screen as a sprite, it gets an annoying 1px black line around it (Pic 2). No compression has been applied (yet), so any clue how to avoid such artifacts? I already added a 2px padding in the atlas, but that didn't help...

EDIT: happens as soon as I use an RGB texture w/o alpha for the texture, even if I use the full 24 bits. The line disappears as soon as I add an alpha layer (however I don't want this specific texture to need alpha, since I want to compress it ultimately with a non-alpha compression...)

EDIT 2: I am using dicing now for these sprites, and the artifacts are gone, even w/o alpha channel (and ETC compression works great on that now!). Only when using the sprite in a whole they show up. So no prob any longer for me, I just have it diced and am happy...but maybe you can anyhow explain that effect (for future generations ;-)

 

Thanks, habitoti

38

Support / Re: Atlas Compression

« on: February 11, 2014, 09:44:05 pm »

Well, it's not wasteful at all in general. You are just splitting off one layer (24+8 bit vs. 32), so uncompressed it's basically the same total texture space consumption. And next you can define a per-platform compression that has the widest HW implementation adoption (e.g. ETC on Android, PVRTC for iOS etc.), and furthermore non-alpha compressions are usually better (even in SW) and have a broader availability, so there would be lot of applications for such a mode, I believe. I think this would be a big advantage to offer it (nobody _has_ to use it...), not just limited to Android.

Anyway, just my 2 cents 

39

Support / Re: Atlas Compression

« on: February 11, 2014, 10:31:29 am »

But wouldn't you just need to create one RGB and one Alpha texture on "commit" in the collection, and there is a special flavor of sprites that is based on such a "twin collection", including the special shader to rejoin both channels again? You just include two textures (both of which can then be ETC compressed), and beyond that it would be compeletely transparent for the developer...how would Unity prevent you from that?

40

Support / Re: Atlas Compression

« on: February 10, 2014, 06:02:58 pm »

After digging a bit deeper, it looks like ETC is really the only useful compression for Android deployments (since for all others you might end up with SW decompression, which makes no sense), but it works only on non-alpha atlasses (ETC2 is much better, but only available with GL3 and probably only on very few HW today)
So a great value prop for TK2D would be to support an RGB/Alpha split under the hood of an atlas, plus a shader that recombines them later on. Such atlasses could both be ETC compressed.
Not sure how much work that would be, but Android devs would love you for that!

41

Support / Re: Atlas Compression

« on: February 09, 2014, 09:35:13 pm »

Yeah, but I have quite a number of rectangular sprites that don't have alpha. Wish ETC2 would be available for GLE2 already -- it's so much better...

42

Support / Re: Atlas Compression

« on: February 09, 2014, 07:42:20 pm »

I think I found it myself 

I can simply override the compression for deployment to the device. This setting is retained even I re-commit the sprite collection...

43

Support / Atlas Compression

« on: February 09, 2014, 04:48:15 pm »

Hi,

a Unity texture can be compressed by a variety of formats (especially ETC for Android, see below). Is there a reason that it's rather limited for the TK2D Atlas when set to "Unity Texture"? I might be completely misled, but from what I read, at least for Android it's strongly recommended to use ETC.

I can change the compression to ETC2 once I created an atlas with uncompressed unity texture setting, but on every new commit it is then switched back to truecolor. It would be great if I could choose that compression upfront already, or if there would be a configurable postprocessing step to apply the desired compression to it.

Regards, habitoti

44

Support / Re: 2.4B1: Sprites sometimes not displaying in Editor

« on: February 01, 2014, 02:11:58 pm »

No, tried that already. But then, I don't have the time to really play around enough with the stripped down stuff to wait until it might occur. It's really not good reproducible at all, but happens pretty regularly while I am working. I understand that it's very unsatisfying for you as the programmer (had been in such situations as well) and would love to give you more data. Maybe you can provide a build with some additional logs or assertions around atlas access?

45

Support / Re: 2.4B1: Sprites sometimes not displaying in Editor

« on: February 01, 2014, 11:41:33 am »

I made a small video for you to demonstrate the issue, so that you have at least a better clue what symptoms I am describing here.
It happens seemingly when Unity decides to compile everything, not just the deltas from my current changes (not sure at what point it decides so, because I usually just change my stuff, and delta should always do...). You can spot that when all the warnings from the bit outdated SmartLocalization package (just deprecation, uncritical) show up in the console...
In the end you see that after running the scene everything is fine again. In the beginning I move the invisible sprites z-wise to -1, and then they show up as pink blobs only.

Regards, habitoti