QuoteAny particular reason? I always thought that, unless you're actually moving the player, that $D1-$D4 were the best to use.
Uh, actually nevermind what I said. For all this time I thought $94 held the current frame and $D1 the next frame.
QuoteI'm not sure that would help much, though, seeing as there's no more relevance when sorted alphabetically than when sorted categorically. As in, if they were sorted alphabetically, the list would look like a long string of "If the player's ..." followed by a long list of "Set the player's ...", and you'd still have to look around for the action you want. That's why the search bar is there.
Oh, you actually made a good point there. I overlooked the search bar. Yeah, sorting would probably be a bad idea.
Originally posted by AlessioBecause if this is possible for blocks, it is also for sprites.
A sprite maker won't be easy to create because sprites are far more complex than blocks. A block-creator only requires basic commands such as 'do X, if Y is Z, execute this code, set Y to Z' and most of the time you can merge two different code snippets into a single block without any problems. This is not the case with sprites. I frankly have no idea how a sprite-making tool would be able to make something like an SMB3 Hammer Bro or Boom-Boom accurately. They, like a lot of other sprites, have very dynamic graphics routines and plenty of different sprite states (e.g. diving, jumping, throwing, running) which wouldn't be practical to code with a simple system like this tool offers. Not saying it isn't possible, it'd just be very hard to make and often the sprites that could be made would be pretty limited. I don't want to hijack this thread with a different topic so I'll just stop here.