2D Toolkit Forum
2D Toolkit => Support => Topic started by: Dreamkind on December 03, 2013, 09:41:26 pm
-
Hi,
I have noticed some issues with trying to create sprites at runtime and dealing with platform support. I remember testing this a while ago, so I think its a relatively new thing. The only way I can get hd graphics to show up is to have a sprite already instantiated in the editor and to leave its collection data alone.
here is the code that I am using to set the sprites at run time. The first modifies a test sprite in the scene, and the next adds a tk2dsprite to an empty game object and then sets its sprites. both of these show up as the standard graphic(i drew SD and HD on the graphics so that i would know), and the one that uses the same collection, but is not touched by code shows up as HD.
// Load the sprite collection data
tk2dSpriteCollectionData data = tk2dSystem.LoadResourceByName<tk2dSpriteCollectionData>("dataName");
// Set the sprite with the loaded data.
_testSprite.SetSprite(data, "CardBack");
// Add a sprite component and then set the sprite
tk2dSprite testSprite1 = _testGameObject.AddComponent<tk2dSprite>();
testSprite1.SetSprite(data, "CardBack");
-
Would it be possible to create/email a repro case for this to support at unikronsoftware.com?
-
Unfortunately I will have to ask a little higher up the food chain to get you that repo, but I can tell you the temporary fix that I have found. I noticed that the data it was loading didn't have any platform data. This got me looking at the data prefabs in the editor. I noticed that when you have platform support the managed data prefabs are checked as loadable, and the shared one with the platform data was not checked off as loadable. I unchecked loadable on the sub data prefabs and made the root data prefab loadable and set the asset name. This fixed the problem and allowed that collection to show up with hd in all 3 examples.
I think the problem was that since both of the sub data collections were checked as loadable, and named the same thing, resources would just load the first one it found which would be the 1x version. Will this help enough or should I get to work on trying to get a repo together?
-
If thats the case, then the 1x & 2x assets shouldn't be in a resources directory. You shouldn't need to load them explicitly, and the tk2d resource system handles that transparently when needed.
-
None of the collections or data are in the resources directory. The collections swap out fine when they are inside a prefab or instantiated in the scene. Unless I manually go into the data and swap around which collections are considered loadable the tk2dSystem.LoadResourceByName function always grabs the 1x version of that data instead of the root data that i'm guessing it should.
-
Sorry, I misread the code snippet in the first part. You should never load the 1x / 2x assets explicitly. You should always load the main sprite collection data object - one way to guarantee you're loading the right thing is to load using the guid. You can work out what it is from the index object
-
Ok, However the reason for loading the collections manually is because our game is built to have the art "Swapped" based on a theme. At runtime we have access to the theme name so we append that with a suffix to get the correct collection. Is there a way to turn this into the correct GUID?
-
The collection itself isn't put in the loadable list by default.
ABCollection (not loadable)
ABCollection@1x (managed, loadable)
ABCollection@2x (managed, loadable)
If you put ABCollection (just the data object) into a resources directory, you will be able to use Resources.Load(...) to load just that.
-
That was the solution that we used on a previous project, however It leads to some confusion and issues. First off if someone doesn't commit correctly across version control some times we have to delete the managed data and remake the collection in the editor. This then pops the 1x and 2x stuff down into resources. It also just allows more area's where things can stop working because things are in the wrong place. We can change this, but were hoping that it would be possible to avoid this and just use the tk2d loading system. If the loading is working as intended, will changing the "ABCollection (not loadable)" to being loadable instead of the 1x and 2x cause major issues?
-
1x & 2x will need to be loadable for the system to be able to pick the correct one to load. It is possible to make this work with the loadable system, just that it isn't tested thoroughly enough to support as "feature". You shouldn't make the others unload able, but perhaps add something to the build to set the names differently to avoid random name collisions.
-
Am I correct in assuming that tk2d behind the scenes just uses the GUID to load everything when dealing with platforms? If so that changing the 1x and 2x collection asset names to have 1x and 2x shouldn't break anything. Then all I need to do is make it so that the root data prefab is loadable and has the correct asset name it will work.
-
It uses guids to load them. Changing asset names shouldn't break it, but it hasn't been tested.
-
Ok, I will let you know if it causes any issues.
-
I am having trouble finding a place to make the collection automatically make the non 1x or 2x collection be loadable. I have looked through the sprite collection builder, but I can't figure out why this data prefab is marked loadable for collections with out platform data, but then not marked as loadable with platform data.
The closest I can figure out is that the function tk2dSystemUtility.UpdateAssetName(gen.spriteCollection, gen.assetName); On line 1389 makes is where the non platform data is made loadable, but for some reason if it has platform data this function does not make it loadable. We have somewhere around 25 sprite collections and I would rather not have to go through all of them every time I make a build.
-
Ok what is the status of everything right now? I don't think I see the entire picture here.
For each sprite collection with platform data (1x, 2x) you'll have 2 corresponding entries in tk2dSystem. You can verify this by looking through Resources/tk2d_??? in there. The asset names should be empty on the 1x and 2x assets. If yours aren't empty strings - how did that happen?
Next - if you tick "Loadable asset" on the main sprite collection + commit, you should see one more entry in tk2dSystem. This one should have the asset name in there. If you load by name, this is what you should get.
What do you see in your setup?
-
In my setup the 1x and 2x have their entries in tk2dSystem. When I click Loadable asset, none are added because the it only checks of loadable on the 1x and 2x, but not the main collection that manages the platforms.
After changing the code that creates the collections to save the Loadable setting and the AssetName. Now there is an extra entry in tk2dSystem for the collection that manages the platforms.
-
What version of tk2d / unity are you using? Whatever I posted in the previous post works fine in 2.3?
-
We are on 2.3.0. No matter what I have checked in the sprite collection editor for loadable a collection that has 1x and 2x platforms will only generate an entry int he tk2d resources folder for the 1x and the 2x data. I cant get it to generate a 3rd for the default one unless I modify the editor code.
I just made a fresh project and tried this, and it worked exactly how you said. Maybe our code didn't get fully carried over or the sprite collections upgraded. Is there anyway to check the version of the collection in the editor.
Edit: I am sorry for all of the confusion but I think I pinpointed the issue. In the fresh install it did create a 3rd entry in the tk2d resources folder, but when i did Rebuild Index that entry was deleted.
-
I was trying to hold off on bumping this because I don't want to be spammy, but here is what I have found so far.
Making a sprite collection with platform support for 1x and 2x loadable means that it has 3 entries in the tk2dSystem, 1 for the collection, 1 for the 1x, and 1 for the 2x. Rebuilding the index removes the entry for the collection but keeps the entries for the 1x and 2x.
We are using svn, so this means that the tk2d Resource folder is ignored, and everyone rebuilds the index after updating causing the entry for the collection to be removed. It is possible to get this back by opening the collection editor and checking the loadable box on and off again (This does not require the collection to be committed). When this is present the data that gets loaded is not the platform data, and the sprite that shows up is for the correct platform.
If I rebuild the tk2d Index then the data that is loaded is always the 1x collection data. Normally this can be solved with the fix that I mentioned above, by toggling the collection loadable check box. However if unity is restarted after the index is rebuild (before the resource entry has been recreated) then it will continue to load the 1x graphics. Even if I toggle the loadable check box I need to commit the collection for it to load the platforms correctly, which is time consuming when we have around 45 collections to worry about.
This is with out any modifications to the source code.
-
I think you've found the issue here, and that explains why I wasn't seeing it. Building the index was incorrectly indexing things. It didn't matter for what the system was designed for, as it never used the name for anything but it broke for you as you did.
Try these changes - it should fix the names properly, and the loadable flag works as expected too.
tk2dSystemUtility.cs, around line 285
- MakeLoadableAsset(data, data.assetName);
+ MakeLoadableAsset(data, indexEntry.managedSpriteCollection ? " " : data.assetName);
tk2dSpriteCollectionBuilder.cs, around line 668
+ gen.spriteCollection.loadable = gen.loadable;
gen.spriteCollection.hasPlatformData = true;
gen.spriteCollection.spriteCollectionPlatforms = platformNames.ToArray();
These are from a current WIP build so line numbers might not match, but there should be enough context there to find those lines.
After that, rebuild the sprite collection. Subsequent reindexing should work fine.
Let me know how that goes for you.
-
Thanks, This works perfectly in our test project. I will let you know if I encounter any problems but it seems to work fine.