I'm currently considering getting seriously into making some stuff with Orx and fell in love with the feature list on first sight, but the way the Animation system works currently put me off a little since it seems awfully tedious.
I need to tell it what Animations there are, then I have to define pretty much all transitions, including the looping, and put them in a linked list, then have to tell each individual animation what kind of Keys its made up of and then have to create a new image object for each of those keys telling it what position of the original texture to look for the frame. That's easily over 200 lines of code (or, well, data) for just six frames of animations making up Idling and Walking. I'm dreading to think of the kind of work it'd be to implement bigger spritesheets or even multiple bigger spritesheets. I'd probably spend entire weekends just writing hundreds of lines full of Animation inis.
Now, I'm not complaining, I was really just wondering if this is the only way to do Animations or if this is just the "I want full control of everything" way to do it and if there's maybe a "Just give me some Animations, I don't care too much about their inner workings" way.
It just feels so backwards that in an engine that's so trimmed towards fast and easy prototyping animations are such boring, long and tedious work.
Comments
You're totally right, defining the animations is definitely the biggest weakness of orx as we speak. When the system was designed an editor was supposed to be created that would handle all this for the user. Unfortunately that never happened yet, and one has to write that huge quantity of info to create animations (and it used to be worse!).
I've been trying to refactor all that in the process of adding support for skeletal animation but this isn't done yet and doesn't have any ETA.
Right now, defining the whole animation graph in config (ie. including all the possible transitions) will make it very easy to use in code as you do not need to need to write pull-code for chaining animations.
The classic example being a character sitting and needing to run, if you define the sit->stand up, stand up->start run and start run->run transitions in config, all you have to do in code is call orxObject_SetTargetAnim("run").
No matter where he was all the transitions will be executed in time, the way they were defined in config.
That being said you don't need to define the whole graph and can then skip the links. You'll then have to chain the animations yourself in code.
As for the animations themselves, you need to define every frame and every frame has to be an orxGRAPHIC so I'm not sure how you modify the config aspect of it in this case.
However you don't have to write everything by hand! You can actually write code to fill all the config info at runtime for you. I think this approach has been discussed a couple of times in those forum, here for example: https://forum.orx-project.org/discussion/1467#Comment_1476
More generally, all the config info can be modified/created at runtime which works pretty well when it comes to parts that can easily be automated (like animations).
If you have any propositions on how to make the whole system better/easier to use, don't hesitate, when one is too familiar with the system it's not always easy to stand back to come with better ways of doing things.
I'll either just sit tight and wait or if I do decide to pick up Orx for what I'm planning will just write a quick and dirty animation editor for myself (or generate them at runtime, like you described)
Just wanted to make doubly sure this is currently the only way animations work. I can't even count how many times I tried to simplify a process for myself only to find out there already is a simple way to do it.
My pleasure!
Let us know if you encounter any other issue or if you have any other questions, of course!
That's the best approach I think.
Did you have a look at Scroll/ScrollEd, btw?
It even simplifies more things than to a vanilla orx use does.
There are a few threads on the forum as well as some tutorials being written by acksys: http://orx-project.org/wiki/en/orx/tutorials/community/acksys
Then the templated code would be something like...
The TemplatedParameter.SpriteSheet is really SoldierGraphic.SpriteSheet--just passed down. Now if we wanted to create another animation we simply do:
And so forth for each monster. Naturally the AnimSet could be extended to include walking in all directions as well. This way we can build a simple database of animation templates in the .ini.
The basic difference between the inheritance and parameteric polymorphism(PP) is that PP would create a new object per instance while the simple inheritance would be just one object. Naturally I'd keep the same restrictions as the .ini's simple inheritance to make things simple.
I know we can do something similar in code/Scroll, but I think it would be cleaner if it was supported in the .ini Thoughts? I can't be the first person to think of this...
~Paul
Hi PauloftheWest,
You're entirely right about the cumbersome animation/graph declaration in config.
Historically orx was supposed to come with an editor that would have hidden all those verbose and ugly sections for the user. Unfortunately the editor was never made.
You're actually not the first one to propose templates to solve that particular issue, I'm sure it has been discussed at least once on those forums (though my search-fu is too weak to find it) and it has been discussed a couple of other times via different means of communications.
I completely agree with the fact that this is an elegant feature, however I'm not sure if it would apply to other common cases/scenarios than animation/graph.
I have a task (that you can find on orx's issue page on bitbucket) about adding support for vectorial animations (as well as adding the concept of channels to that same system).
Part of this task is also to provide a much more concise way of describing animations via config (while still allowing for a more verbose option in case the user needs fine-tuning). There's a branch that was created over 2 years ago (ouch!) that you can see on the repository.
I should really to focus on this in short-term future as I think it's currently one of the weakest, if not the weakest, part of orx.
If you have any idea about how to make the description of animations/links less verbose and not such a pain in the ass without resorting to new features (actually it still look pretty verbose with templates: it allows a user to easily duplicate a graph for different characters however the graph template itself still looks annoying to write), please let me know.
That being said, the template feature per se might be interesting, I just need to find out better use cases as this precise one might (hopefully) disappear in the future.