Jump to content

Dengar

Members
  • Posts

    189
  • Joined

  • Last visited

  • Days Won

    7

Posts posted by Dengar

  1. Ok so I thought I made this clear but uhhh... Maybe I should just spell his out. I'm not actively developing this thing anymore. I haven't been for quite a while. I originally just started it as a mental exercise project hoping that it would inspire others to contribute as well but so far I've only had a handful of pull requests or noticeable forks. I ended up running into a lot of problems and lacking outside input on the project just kind of made it... not fun.

  2. I haven't really worked on this project in ages. And to be honest, I don't intend to work on it in the near future either. It was just a little pet project to see the extent of my scripting abilities.

    Also I have gotten a bit fed up with Unity. It just doesn't do the things I want it to in the way I want it to do them.

    As I said before though, the code is out there for everyone to tinker with, I made it as understandable as I possibly could, and I'm willing to answer any questions I can. I still handle pull requests as well.

     

     

    I think SpriterDotNet is fully featured though, including Character Maps. It requires a bit more programming than Spriter2Unity does, but if you're willing to learn how it works. I wrote a little addon for it too that allows you to use the Animator's state machines.

    EDIT: I just realised Loodakrawa sent you here from SdN. I'm sorry I really couldn't be more help. While the basic features were easy enough to implement I just kept running into all kinds of glitches that are beyond my current skill level. Such things get frustrating after a while.

  3. When I said "programmer's paradise" it means literally a paradise for a programmer. Someone who focuses more on visuals or designing the game itself might not find it very appealing. That said, if you want to improve your programming skills and learn to program a game at its base level, I can't think of a better framework tbh.

  4. The main advantage of using an actual prefab (which can't be constructed at runtime) is the fact that prefabs are serialized using Unity's native serialization system. All Unity assets are deserialized at the actual engine layer (where the engine does its job) rather than the scripting layer (where all of our scripts are run). It stands to reason that Unity's deserializer is more optimized than anything we can come up with on the scripting layer. Instantiating a preconstructed prefab will most definitely be significantly faster than first creating a GameObject from scratch, add components to it, and then populate the components' fields with values read from an XML file.

    MonoGame is a programmer's paradise, really. It gives you absolute control over absolutely everything. The downside? It's not a game engine at all. You will have to write all the rendering and physics code yourself (or borrow it from an open source), and there is no editor at all, let alone a fancy one like Unity. That said, I much prefer it over Unity for 2D games since Unity does many unnecessary things that you can't really turn off. And SpriterDotNet also works with it.

     

    @loodakrawa You use Unity as a level editor? What do you do then? Write the assets to disk as text and then import those into your MonoGame project using a custom importer?

  5. It's been a while since I fiddled with anything Spriter or Unity, but either way, the process for creating a prefab from a script is basically.

    1) Create an empty GameObject
    2) Instantiate supporting objects (like the data container ScriptableObject that SDN.Unity uses)
    3) Add Components to the GameObject
    4) Set the values in said Components
    5) Save the GameObject as a prefab
    6) Save supporting objects as assets
    7) Delete the GameObject

    Steps 5 and 6 are possible at Editor Time only, and I'm fairly sure steps 1 through 4 don't even need any Editor code. You would need a different "Step 0" (acquiring and reading the .scml file) though.

    Regardless, creating a spriter object at runtime would skip steps 5 through 7.

    A word of caution though, from my understanding, there would be two possible problems, and solving one could possibly cause the other. Although there's probably fixes for these, I can't think of any right now.

    Basically, the first issue is that reading the .scml file and creating the GameObject takes a while. Depending on the size of the .scml and the amount of .scmls you are trying to read, this might not be a huge issue.

    The second issue has to do with the fact that the resulting GameObject can't be saved as a prefab at runtime, since this requires Editor code. The only way to retain easy access to the spriter object is to keep it in memory the entire time. Depending on how often the spriter object is used in your game, this might not be a huge issue.

    The first problem can be solved by only reading the .scml file once and keeping the GameObject in memory.
    The second problem can be solved by destroying the GameObject when you no longer need it and rebuild it from the .scml when you need it again.

    So... yes, the solution to one problem causes the other. That being said, depending on how your game works, one of these problems might not be a huge issue.

     

    Of course there might be something I'm missing here and there's not really that much of an issue. If you want to speed up the read process, you could alternately import the .scml data once, then save that data to a faster medium, such as MessagePack. It's sad that Unity doesn't let you use its own native serialization system at runtime, that would be ideal.

    Oh and there's also the issue of using external image files. I mean it's quite possible, but the code for reading them is different (and possibly slower?) at Runtime than it is at Editor Time.

  6. Folder structure should be completely irrelevant. The packing tag is all that matters.

    Also, the spriter file isn't included in the build so it's irrelevant.

    Bones have no sprites. They are also irrelevant.

    The fact of the matter is, if there's so many draw calls then something's not packed correctly. Or maybe not packed at all.

×
×
  • Create New...