suggestions

[Norbert]

I was trying your 17 January 2014 release (at size 3x) and noticed that in the Jaffar level, when selecting a tile, one of the layer selections appears to be one off.


(mirror)
It also happens in other levels/sizes, like level 2 at size 1x. I've never noticed this before, so maybe something recently changed?

A more general suggestion: right now the editor shows a "Foreground tile", "Background tile", "Background layer of current tile" and "Foreground layer of current tile". Those two sets of layers may be a bit confusing for some users. Would it be possible to add an option to pick from the 30 most 'obvious' tiles (tile layer-combinations) that authors may want to use for the level type in use by temporarily displaying those tiles on the main screen (3 rows, 10 columns). Maybe frequent users of your editor could help decide which 30 tiles (tile layer-combinations) these should be for each level type. To the right of the door events (or wherever, really) could then be a button to bring up those 30 tiles to "Pick a basic <not sure what to call it> for the selected tile(s)." or something like that.

[David]

This is not a bug, just the odd way of how the graphics of this level is constructed. (But only in the top row!)
In the third dropdown you can see that the graphics is offset 24 pixels to the right.
Also, it seems to me that on this level, the background and foreground are swapped.

Would it be possible to add an option to pick from the 30 most 'obvious' tiles (tile layer-combinations)

The first drop-down stores the used combinations of the third (back), fourth (fore), fifth (object) dropdown and the floor+wall checkboxes.
(This is needed because of the way the level format works.)

temporarily displaying those tiles on the main screen (3 rows, 10 columns)

They would not fit there, because tiles are 48 pixels wide with their right half overlapping the next tile.
A pop-up window would be better.

[Norbert]

The first drop-down stores the used combinations of the third (back), fourth (fore), fifth (object) dropdown and the floor+wall checkboxes.
(This is needed because of the way the level format works.)

I see.
Then may I suggest the following:
- Change several tooltips to clarify that the background layer and the foreground layer of, what you call, the "current tile", are the background and foreground layers of, what you (also) call, the "Foreground tile". What I mean by this is that your application currently uses "current tile" to refer to the "Foreground tile". The tooltips for the third and fourth drop-down lists should mention the word or phrase used for the first drop-down list.
- When the user changes the image of the third or fourth drop-down list, update the image in the first drop-down list. (Immediately, instead of waiting for the user to (re-)click the applicable tile in the room.)

Also, another question. Not including black images, I count 84 (0x00-0x54) images in the third drop-down list, and 131 (0x00-0x83) in the fourth. How can (84x131=) 11004 combinations fit in the first drop-down list that holds 255 (0xff) entries? If the answer is that the first drop-down list changes in real-time, then what happens when the user uses more than 255 different image-combinations in a level? Wait... is that first drop-down list just an overview of recently used combinations? If so, then "Foreground tile" needs to be changed to "Recently used tile foregrounds".

[David]

- Change several tooltips to clarify that the background layer and the foreground layer of, what you call, the "current tile", are the background and foreground layers of, what you (also) call, the "Foreground tile". What I mean by this is that your application currently uses "current tile" to refer to the "Foreground tile". The tooltips for the third and fourth drop-down lists should mention the word or phrase used for the first drop-down list.

Ah, yes, the tooltips currently say these:
* Background layer of current tile
* Foreground layer of current tile
* Object of current tile
* Attributes of current tile
In these, "current tile" should be "foreground tile".
(In the SNES format document, it's called "block".)

- When the user changes the image of the third or fourth drop-down list, update the image in the first drop-down list. (Immediately, instead of waiting for the user to (re-)click the applicable tile in the room.)

Looks like I forgot some repainting.
While there, selecting an item in the fifth (object) list should also redraw the first.

Additionally, Mode->Floors and walls should cause the first list to show floors and walls.

Also, another question. Not including black images, I count 84 (0x00-0x54) images in the third drop-down list, and 131 (0x00-0x83) in the fourth. How can (84x131=) 11004 combinations fit in the first drop-down list that holds 255 (0xff) entries?

For the original levels, the list contains only those combinations that are used on the level.
(That list is part of the level format, so it might contain some unused tiles.)
If (in Automatic mode) someone tries to use a combination that is not there, then the first unused combination (that may be an empty one) is overwritten with the new one. (This is done in DoAuto(). I noticed that the code could use more comments and better identifiers.)

If the answer is that the first drop-down list changes in real-time, then what happens when the user uses more than 255 different image-combinations in a level?

I added an error message for this case ("No room for tile!"), though I did not test it.
The message could be replaced with something better.

[Norbert]

Now that I better understand the interface elements and functionality, I have some additional suggestions aimed at simplifying the user experience:
- maybe it's best to hide (or gray out) the "Door events:" panel if the "Object of current tile" does not accept door events,
- maybe it would be best to put everything in between the "Animation group for this background tile" and the "Door events:" panel into a frame labeled "Custom [or Add or New] foreground tile" or simply "Advanced", whose visibility is togglable and is not visible on startup (by default). Maybe also move that frame next to the "Foreground tile" drop-down list,
- maybe only show the "Animation group for this background tile" element when a new menu option View->Animation group is checked. Unless it's used a lot, of course, but I personally don't even know what it's for.

Also, how much work would it be to create an easy software tool/script or temporarily modify Pr1SnesLevEd to find out: a) how many different "Foreground tiles" (combinations) (and "Background tiles") - and which ones in the lists - are actually being used by the default levels, and b) how many different combos for each level when looking at both the original game and all known SNES mods (see popot.org) combined? By b) I mean, the following. Let's say, for example for level 1, that the original uses 100 "Foreground tile" images (combos), and the Dark Castle mod uses 80 combos from the original and 40 new/custom combos: this would give us (100+40=) 140 different combos combined. I'm asking for various reasons, including my idea that maybe entries in the "Foreground tile" drop-down list that are not in use in the original levels should be prefilled by the application with the most frequently used custom tiles (and most logical candidates if there's space left). Although maybe you cannot preset them without using them.

Finally, what are the Manual and Automatic modes all about. I'm wondering how a user would know. Is it a matter of experimenting, maybe searching this forum for answers? Should the application have a Help menu option that explains this and possibly some other things? What is the difference between the Manual and Automatic mode? Does it have any impact on one or more of my suggestions above?

[David]

- maybe it's best to hide (or gray out) the "Door events:" panel if the "Object of current tile" does not accept door events,

It could be handled in two parts:
The list stores the current modifier, and it makes sense for many tiles.
The room/tile/next part is meaningful only for buttons.

I have been thinking about making a new panel that shows all the door events (at least those that fit into a window), with commands like "go there" and "point event to selected tile".
Maybe also show (in the room) if a tile is the target of an event.

Finally I was thinking about how NESPrincEd solves the editing of door links: viewtopic.php?p=14312#p14312
I like how it abstracts from the actual way of how door links are stored.
(Note that the NES version stores door links differently from the DOS and SNES versions: It stores a list whose each element stores the room and tile of a button and a gate.)
I wonder how to make something like that if not all rooms are visible.
Maybe add an "Edit door links of this tile" to the context menu of buttons (or a button where the doorlinks are now), and an "Add/remove from current door link" (possibly with keyboard shortcuts insert/delete).
And of course show what tiles are triggered by the currently edited doorlink.

Speaking of keyboard shortcuts, there should be some for navigating between rooms.

- maybe it would be best to put everything in between the "Animation group for this background tile" and the "Door events:" panel into a frame labeled "Custom [or Add or New] foreground tile" or simply "Advanced", whose visibility is togglable and is not visible on startup (by default). Maybe also move that frame next to the "Foreground tile" drop-down list,

I agree with the frame and the moving, but i'm not sure about hiding them.

- maybe only show the "Animation group for this background tile" element when a new menu option View->Animation group is checked. Unless it's used a lot, of course, but I personally don't even know what it's for.

It is used with animated backgrounds, like water or clouds.
I added it because there were cases, when some backgrounds were animated but they should not be.
For example, here: viewtopic.php?p=11982#p11982

What is the difference between the Manual and Automatic mode?

When you change anything that is marked as "of current tile":
- In Manual mode, the current foreground tile (in the first list) will change. Other instances of the tile on the level will also change. (i.e. you're editing the current item in the first list.)
The first version had only Manual mode, because it was easier to implement.
- In Automatic mode, the editor will try to find a tile (in the first list) that has the needed properties, and use that. If there is no such tile, then a new tile is created. (i.e. you're editing the selected item(s) in the room.)

* Added automatic tile mode:
If this is set, the editor will create tiles for you from Background layer, Foreground layer, Object and Attributes, so if you change one of these for a tile, other instances of the tile will remain the same.

I'm wondering how a user would know. Is it a matter of experimenting, maybe searching this forum for answers?

Although it's written in the readme.txt (see above), that file is more like a changelog.
I agree that this should be explained better, possibly in a new readme (and rename the current readme to changelog).
Perhaps the Manual option should be removed, because it's counter-intuitive? (It can change tiles other than the selected.)