there is aa involved one cannot turn off.
I just tried this myself, and there is no AA affecting the frames if you use whole number offsets for the dx and dy properties of the frame.
i do post suggestions and problems for every future user and newbie and non-programmer. i would like to make sgdk easier to use for all people.
And you see that some of your suggestions have already improved SGDK2 (thank you!). The option to suspend rules as a group instead of one-by-one (and see which rules are suspended in the tree) resulted from your comments. Also, the new tutorials were added based on your comments. However, a change to the program is not always the best solution to a problem. First of all, the program was recently in beta (and is currently a release candidate) so changes are very restricted right now. But also, I really don't want this program to become overblown with unnecessary features that will overwhelm new users. So it's important to try to provide an optimum set of features that accomplishes the most flexibility and power with the minimum number of features. Maintaining a minimum number of features is important to usability (how easy is it to learn), maintainability (how quickly can a new release/changes be implemented) and stability (how reliable are the changes).
i get sometimes the response "you could make it so and this way and that way", but this expects every future user with the same problem, to has the same knowledge like you, who know sgdk inside out. i mean, i can do it the way you suggested, but there will be other users who will have the same problems as me. please understand all my questions as questions from a not-so-good-scripting, graphically thinking person.
That's why these forums are important. Hopefully other users with similar issues will be able to find similar answers by reviewing the forums. Of course I don't mean to rely too heavily on the forums; a user should be able to use the program without having to visit the forums with every question (which is why I also provide tutorials and try to make the program somewhat easy to understand by looking at the UI). But if SGDK2 can find a good balance that limits the features, and still provides an easy way to accomplish a large range of tasks (even if the user has to do a little research on some kinds of tasks), then it will be clean and usable. I think users will appreciate being able to deal with a few powerful features than a zillion detailed (harder to remember) features. And if they can get used to solving their problems with the limited features available, then they will be more able to come up with their own solutions without having to wait for new features or do extra research.
So I don't think I misinterpreted you. I know that you are making suggestions based on usability for all users. But I too have to carefully consider each feature and weigh the costs and the benefits. If there is a work-around that doesn't require too much effort, the feature may have to wait, or maybe be left out entirely in favor of keeping the interface simple. The graphics editor especially was designed to be a basic editor for the most
common tasks in 2D game development because there are plenty of other high powered and free drawing programs available, and SGDK2 can easily import graphics. I did not want to support all the features of a full-blown drawing package like the GIMP. But I did want to have some reasonably complete drawing capabilities built in to support 2D games.
but it is true, i didn't know about the tweenig wizard, and when aa could be turned off, it would be the fastest solution.
Just make sure that the result yields whole numbers and not decimals, otherwise AA will affect it. But I think you can already avoid AA if you ensure this.
btw, i get for every single value field (scales and offsets) an error message when i don't touch them. i have to change the 1.0 values to normal 1 values, without dot.
Does your system use "," for a decimal separator instead of "."? I wonder if I mixed up "," and "." parsing for foreign systems.
BTW, just because I provide an alternate solution doesn't mean that a feature will never be included in SGDK2. Of course it's nice to be able to solve the problem immediately without adding a new feature, so I'll provide work-arounds when possible. But in order to help find the most important features that are really worth adding (and avoid extra unnecessary features), I will tend to delay adding features that have good work-arounds until/unless I find that more people are agreeing that I should be focusing my efforts on such features. Otherwise there are always more important and more powerful features to work on that might be more worthwhile. I also like to solve multiple problems with fewer features, and thinking and discussing a challenge for a while before jumping in with a quick fix helps this. (For example, the tree view in the rule editor now shows you which rules are enabled and what kinds of rules are there with the same icon.) Your customizable offset suggestion could also solve multiple challenges with a single feature, but I think this needs further consideration. If the frame tweening wizard is a better solution, SGDK2 is better off forcing the user to find out about the best way to do this instead of allowing them to easily jump to a solution that is not as good. (If you use the frame tweening wizard, you don't have to re-do all your work of you want to change a pixel in the graphic.)
So I hope you see why I don't jump in to include every suggested change, and that I do understand that your comments are intended for the benefit of all users.
