How to add sprites

[Jam0864]

How do you add sprites in SGDK2?  I've got other stuff working but I can't figure out how to add the sprites.

[bluemonkmn]

Create a new sprite definition, add states to it (check the menus if you can't find the commands you need as buttons on the form).  Then you might need to add rules too.  I can help create the sprites if you're done with the graphics.  It might be tricky without any documentation yet .  You could also just import the sample player sprite and substitute your frames in place of its frames.

After you have the sprite definition, you should be able to go to the sprites tab in "Add Sprites" mode in the map editor, select "<All Sprites>" and see your sprite in the list.  Then you can select that and just click it onto the map in the map editor area.

[Jam0864]

Oh, yep I see how that works.  At first I was trying to drag tiles into the box from the graphics editor!    The solving of one problem only creates another, I can't figure out how to use the framesets page to 'flip' the sprites around. I can flip them alright but can't add them to the frameset after they have been 'flipped'.

[bluemonkmn]

Heh -- maybe I need a better UI  .  On the frameset screen, you do drag the transformed frame into the frameset if you want to add the transformed frame into it.  Or you can use the "Save" button to overwrite the selected frame with the transformed frame.

[durnurd]

Yes, I figured a better UI would be one of the things that would be made higher priority once the actual functionality was worked out.  Something more consistent, or... concrete... or maybe just something more obvious how to use.  Like big arrows pointing at the button to push next

[bluemonkmn]

A good UI should probably go in the first release because SGDK2 needs to make a spectacular first impression.  Think the frameset editor is the biggest opportunity for improvement there?  Got any ideas?

[durnurd]

The inconsistencies I find most are when I double-click on some things, it opens the properties, but when I double-click on other things, it opens the editor window.  Rather than having a sub-item in the tree to edit those objects, I'd think just have a Properties item in the right-click menu to access the properties, and double-clicking always edits.

Also, the editable textbox containing the name of the objects should be in a consistent place in all of the edit screens that have that.  Maybe add it to places that don't have it, or remove the editable textbox and just have a frame with the name as a caption and put Rename in the right-click menu.  Maybe single-clicking twice in the tree-menu could allow the user to rename an item, like in Windows Explorer.

For the Frameset editor specifically, the text arrows via ^, <<, and >> are kind of kludgy.  I'd either put graphics on them, or, more preferably, an overhaul of how it works.

First, get rid of the ^Load^ and ^Add^ buttons.  The drag-and-drop operation is sufficient, I think, and the buttons make it more confusing.  Also, make sure the view that shows all of the frames in the current frameset updates consistently.  I've noticed I often have to click in the window after I add something to make it appear.  Pressing the Save button when no frame is selected should save a new frame, just like dragging from the frame editor to the frameset does.

I think having a border around all of the tiles in the frameset view would also make it easier to tell what's going on.  Double-clicking on a frame in the frameset view or in the graphic sheet view should automatically load it into the frame editor.  Dragging from the frame editor to the frameset view to save a frame should allow the user to overwrite the frame they dragged it onto, or insert it in between if they drag it between frames.

Pressing the delete key while a frame is selected should delete it.  Likewise, the delete button is not necessary.  You might also want to think about making the color adjustments sliders instead of textboxes (vertical), and I don't think you need the parenthesis text if they can easily see what happens when adjusting the sliders.

If the currently edited frame is not saved, and the user tries to load another frame into the editor, it should prompt them that there are unsaved changes, and would they like to continue?

I think the Apply button is unnecessary.  The X-scale resetting to 0 is confusing.  I think it would be easier to understand if you just got rid of the Apply button and get the X&Y-Scale and X&Y-Offsets directly from the matrix by whatever calculations necessary (unless it's a lot of calculations).

Right-clicking on a frame in the frameset view should pop up an options menu including things like Duplicate, Delete, and all of the options in the More>> menu, so that you can apply some transformations without needing to load the frame into the editor.  Maybe Add Reset to that menu as well so that a reset can be done from outside the editor.  Also, placing the Reset button in the middle makes it seem like it's only resetting a portion of the transformation.  Placing it either at the top, or the bottom (somewhere conspicuous) more by itself would be more understandable.  Or add more reset buttons that reset individual parts of the transformation (rotation, size, offset, and color, or maybe just matrix and color).

The slider for rotation almost disappears where it is.  Having the textbox below it makes it look like they are unrelated, and having the slider right below the editor area, I often forget it's there.

The width of the dropdown combo for selecting graphic sheets seems excessive.  When selecting a new graphic sheet, I would expect the current selection of graphics to be reset.

When loading a frame into the frameset editor, maybe switch the graphic sheet selection to the graphic sheet the frame came from?  (Not so sure about this... could be annoying).

That's all for now.  And I'm about to fall asleep.  Maybe I will come up with more in future.  Oh, something about diamond background in the editor for transparent tiles.

[bluemonkmn]

On the one hand I'm thinking you might be misinterpreting some things, but on the other hand, if you are misinterpreting them, so will others.  So something should be done to clarify the UI.  But perhaps I should resort to a usability expert (hey, I know one of those! I wonder if improvements can be made without rethinking the whole interface.  Anyway, here are my comments on your comments:

The inconsistencies I find most are when I double-click on some things, it opens the properties, but when I double-click on other things, it opens the editor window.  Rather than having a sub-item in the tree to edit those objects, I'd think just have a Properties item in the right-click menu to access the properties, and double-clicking always edits.

Would you eliminate levels from the tree as you do that, then?  I thought the node's name/location in the tree made it clear that some were opening editors.  But if it's possible to edit a graphic sheet from the same node where you define its parameters, there wouldn't need to be an extra level, right?  The thing that makes me nervous about collapsing that is that people may then find it more difficult to figure out how to edit properties of an object.  They might think that once it's added, you can't change the properties you saw when adding it.

For the Frameset editor specifically, the text arrows via ^, <<, and >> are kind of kludgy.  I'd either put graphics on them, or, more preferably, an overhaul of how it works.

Yes, every time I see the frameset editor I wonder "what I was on" when I designed it .  I must have intended to go back and improve it at one point -- perhaps expecting some better button graphics from OrionPax.  But I'm not sure what to do about it.

First, get rid of the ^Load^ and ^Add^ buttons. The drag-and-drop operation is sufficient, I think, and the buttons make it more confusing.

I make it a rule to never rely on drag and drop as the only way to accomplish something.  I do think the buttons should be removed, but there should still be a way that doesn't require manual dexterity or even a mouse to accomplish the task.  So maybe I should remove the buttons, but then add the commands to a menu, and have keyboard shortcuts on the menus maybe.

Many of your other suggestions for the frameset editor I agree with.

Dragging from the frame editor to the frameset view to save a frame should allow the user to overwrite the frame they dragged it onto, or insert it in between if they drag it between frames.

If I do that I'll have to make the spaces between the frames significantly larger to limit the risk that someone accidentally overwrites a frame instead of inserting it.  And if I make it behave that way there, it would/should behave that way everywhere, and I'd have to increase the spacing everywhere, reducing the amount of information that you can fit on the screen.  But maybe I can use drag modifier keys (Ctrl/Alt/Shift) to determine whether an insert or an overwrite should be performed.  Would overwrite be a better default than insert, and then hold Ctrl to perform an insert (with the common "+" indicator on the mouse when inserting)?

I think the Apply button is unnecessary.

The apply button delimits transformations.  For example, notice the difference between scaling and rotating a frame as part of the same transformation versus scaling the frame, applying that, then rotating it.  If you don't apply the scaling first, you're effectively rotating the image before the scaling (which, I guess, is consistently the apparent sequence/behavior of a matrix transformation), whereas you might want to rotate the scaled image.  In making SGDK2 easy to understand for beginners, I don't want to take features/power/flexibility away from the experts unnecessarily, because I fear it will end up still being too complicated for beginners anyway.

The intention was to represent the controls above the buttons as intended modifications to the matrix, and treat the controls below the buttons as the persisted transformation/information.  So once you apply the current changes, they are "persisted" to the matrix and then you are once again treating it as an untransformed frame which you can manipulate as you would the original graphic.  Is there any way to make this clearer; I think it's an important feature, isn't it?

The slider for rotation almost disappears where it is.  Having the textbox below it makes it look like they are unrelated, and having the slider right below the editor area, I often forget it's there.

What would be better?  I worry that making the slider any shorter will reduce the resolution of the slider.  I myself don't usually use the slider just because I want to rotate frames to specific numeric increments anyway.  Do you think the slider is important enough that it needs to be more visible?

[durnurd]

Oh, I thought of a couple more things.  Add a grid and grid snapping (that can turned off, of course) to the frame editor.  Actually, that's the only other thing I can think of that I thought of now.  Perhaps I will remember something else in time.

Would you eliminate levels from the tree as you do that, then?

I would do that, yes.  In most programs, I would expect the properties to be in the right-click menu.  Taking a widespread example: Windows Explorer.  Double-clicking on any file opens it in its default program (an editor).  Right-clicking on it brings up a menu, where you can choose "Properties" to view and edit the properties of that file.

I do think the buttons should be removed, but there should still be a way that doesn't require manual dexterity or even a mouse to accomplish the task.  So maybe I should remove the buttons, but then add the commands to a menu, and have keyboard shortcuts on the menus maybe.

Perhaps using a tabstop to get to the graphics editor and moving the selection around with the keyboard arrow keys (Similar to explorer, Shift+Arrow extends selection, CTRL+Arrow moves current indicator, but doesn't change selection, space toggles current graphic, Arrow alone resets selection) and add them with the enter key.  Then to load it into the editor, just tab into the frameset view and use similar keyboard navigation.

f I do that I'll have to make the spaces between the frames significantly larger to limit the risk that someone accidentally overwrites a frame instead of inserting it ... Would overwrite be a better default than insert, and then hold Ctrl to perform an insert (with the common "+" indicator on the mouse when inserting)?

I think only one or two pixels more would be necessary if you don't go with the keyboard route.  However, experimenting with the Windows desktop, there seems to be a precedent for the following:  If the mouse is within, say, the middle 50% of the frame, then replace, otherwise, insert it into the nearest opening.  Of course, with significantly small frames, this would be difficult, which is why having the keyboard alternative is a good idea as well.

The apply button delimits transformations.

I wasn't too sure about removing the apply button.  It just seems like when I make a change, why should I have to hit apply when I can already see the changes have been made above?  Maybe just renaming it to something different would work.  Then again, I can't think of what.

I worry that making the slider any shorter will reduce the resolution of the slider.

Maybe the rotation could be an up-down control like the transformations.  That gets rid of the need for a slider.  Or maybe when they click in the textbox, a slider can pop up, so they can either enter a value or just alter the slider.  Then it just goes away when the textbox loses focus.  That way, it's quite obvious what it's for, and you don't forget it's there.

[bluemonkmn]

Perhaps using a tabstop to get to the graphics editor and moving the selection around with the keyboard arrow keys (Similar to explorer, Shift+Arrow extends selection, CTRL+Arrow moves current indicator, but doesn't change selection, space toggles current graphic, Arrow alone resets selection) and add them with the enter key.  Then to load it into the editor, just tab into the frameset view and use similar keyboard navigation.

Actually most of that is already how it's working.  You can already move the selection around with the arrow keys in the frame/graphic selectors and use CTRL+Arrow key to maintain the existing selection, and press space to toggle an item.

I wasn't too sure about removing the apply button.  It just seems like when I make a change, why should I have to hit apply when I can already see the changes have been made above?

I don't think you have to hit apply. You only need to use that if you want to delimit multiple transformations.  The pending (visible) changes will be automatically applied before saving the frame.

[durnurd]

Oh, I remembered some more things.  Some form of clicking or something on a graphic in the frameset editor could open it in the graphic sheet editor (i.e. CTRL-Click or CTRL-Shift click or whatever).  Then you could move that into the Tileset editor, where doing the same operation on a frame would open it in the frameset editor.

Are you going to add more wizards and automation eventually?  One thing I would like to see is tweening.  Say, set up two frames and select them and say "Tween" (or push a "tween" button if you don't want to implement voice recognition ) and the program prompts for how many frames go in between, and it automatically creates the necessary frames to move smoothly from the first selected frame to the second.  If the two that are selected aren't next to each other in the frameset, automatically put them next to each other probably.  Tweening would include the matrix transformation as well as the colors and the graphic used in the frame (so if they have an animation, it automatically advances through the graphics, if the frames use different graphics).

When clicking "New" in the Tileset editor, the tile value should automatically be set to the next free value, and/or have a preview of what that number looks like (so I don't have to close it and find it in the menu).

I don't know if it's the same on your computer, but the Animation Preview window has a label that says "Background:" and you can choose the background color.  It looks like there's another line of text beneath that which is being covered up by the speed slider (which, incidentally, is not labeled.  Is that what the label I can't see is?)

The Add Frames button in the tileset editor is similar to the Add button in the frameset editor in its kludgyness...

I would like to see the delete key be able to delete frames in a tile.  Also, the prompt to delete seems like something that should be more for bigger things, like tilesets, or graphic sheets, or maps, rather than frames within a tile.  Or at least have an ability to turn that off.

More later, perhaps.  Now I must leave.

[Jam0864]

I don't have time to read all the above posts, so I might say things people have already said. Anyway,
1. The menus look sloppy on my computer. Mainly in the frameset editor, the images display, but not correctly.
2. The ability to flip and save more than one image at a time would save people a lot of time when using a sprite with heaps of frames.
I had another one but I can't remember right now. Seeya!

[bluemonkmn]

Are you going to add more wizards and automation eventually?

Yes, primarily, I think I need to add some wizards for adding plans in the map editor to make it easier, for example, do create a teleporter/doorway without going to the plan editor.

When clicking "New" in the Tileset editor, the tile value should automatically be set to the next free value, and/or have a preview of what that number looks like (so I don't have to close it and find it in the menu).

What's the definition of a "free value"?  One that hasn't been explicitly assigned or one that doesn't correspond to anything in the Frameset.  For example, if I have a frameset with 100 frames, and I have mapped tile 50 to an animated tile, what's the next free value?  0? 51? 101?

I don't know if it's the same on your computer, but the Animation Preview window has a label that says "Background:" and you can choose the background color.  It looks like there's another line of text beneath that which is being covered up by the speed slider (which, incidentally, is not labeled.  Is that what the label I can't see is?)

It seems the XP desktop style behaves quite differently than classic style here (see attached pictures).

I would like to see the delete key be able to delete frames in a tile.

I have implemented support for the delete key in a number of places.  I think I did that after the release of the alpha.

[durnurd]

What's the definition of a "free value"?

I would say my only thought is that it's annoying that I have to find a value that doesn't cause an error message to pop up when I click OK.  Maybe you could have two buttons in the prompt, once for "Next unmapped value" and one for "Next unused value" and it will automatically just use the next value instead of you having to type in a number and click OK.  (Or maybe update the textbox only so you can change the number yourself?)

I see the difference in views... interesting.

[Jam0864]

I don't know if it's the same on your computer, but the Animation Preview window has a label that says "Background:" and you can choose the background color.  It looks like there's another line of text beneath that which is being covered up by the speed slider (which, incidentally, is not labeled.  Is that what the label I can't see is?)

I can't run the animation preview window at all. I get an error, here it is http://www.box.net/public/5hyzfkxm2d