[Ohrrpgce] SVN: teeemcee/8539 Hold Shift in sprite and maptile editor to move faster, type a pal index

[Ralph Versteegen]

On 17 March 2017 at 01:11, James Paige <Bob at hamsterrepublic.com> wrote:

>
>
> On Thursday, March 16, 2017, Ralph Versteegen <teeemcee at gmail.com> wrote:
>
>>
>>
>> On 15 March 2017 at 04:18, James Paige <Bob at hamsterrepublic.com> wrote:
>>
>>>
>>> On Tue, Mar 14, 2017 at 7:36 AM, Ralph Versteegen <teeemcee at gmail.com>
>>> wrote:
>>>
>>>>
>>>>
>>>> On 15 March 2017 at 03:21, James Paige <Bob at hamsterrepublic.com> wrote:
>>>>
>>>>> Interesting!
>>>>>
>>>>> Right away, the palette numbers felt off-by-one to me, because typing
>>>>> 1 selected 0, and typing 0 got me nothing-- but when I started thinking of
>>>>> them as palette hot-keys rather than typing in a number, it felt
>>>>> comfortable again.
>>>>>
>>>>
>>>> Considering that the palette numbers aren't actually displayed
>>>> anywhere, I'm inclined to argue that it's all in your head!
>>>> However, this is going to be a problem once the sprite editor supports
>>>> using the master palette directly without a subpalette. I guess in that
>>>> mode it will have to switch to 0-based input.
>>>>
>>>
>>> Indexes are always zero-based! Anyone who says otherwise is mathing
>>> wrong! I am prepared to holy-war over this! ... j/k no i'm not ;)
>>>
>>> But seriously, it does seem like a good idea to make it zero-based for
>>> when we have bigger palettes-- also, 0 is the transparent color, so the 0
>>> key not being next to the 1 key is probably no big deal.
>>>
>>
>> I was actually thinking of using 1-based indexing when using a palette
>> and 0-based when not, but this must just me be exercising no common sense
>> aversion to complexity, as usual.
>> The reason being that I figured that colour 0, the background, is
>> actually the most important and common one, so it should have a key that's
>> easy to find and reach, which the '0' key isn't.
>> But the tilde key could double for colour 0. It's current used for
>> toggling cursor visibility, which could be moved elsewhere.
>>
>
> Hehe! This sounds like a funny and only moderately cruel prank to play on
> our future selves ;)
>
> I'm still gonna vote for 0-based, but I will be okay with 1 based if that
> is what you settle on.
>

No, I'm happy with 0-based.

What we actually need is an easier way to delete the pixel under than
cursor, rather than changing the palette colour. Delete is available.
Ctrl+Space or Ctrl+Click are also options (Alt+Space isn't available, and
shift+space isn't an option because then you'll hit shift+arrow keys
accidently as you try to delete multiple pixels). Or we could use Z or D
and Shift+click. Ctrl+Space isn't terrible, but not as nice as space or
Z/D. The delete key needs to be very easy to hit in alternation to space
and G (for eyedropper). D is near G; Z is also easy to reach with your
pinky while pressing G and space... even on a German keyboard :) But wait,
people probably keep their hand near < and > to change colours, so the key
should be near those too, on the right of the keyboard. Maybe K for kill.

If you hit the delete key-comb on a pixel that is already zero, it could
insert the colour of last deleted pixel. Then you can very quickly move a
pixel over a bit. Or it could insert the current colour. (And then trying
to draw the current colour on a pixel already that colour could delete it
instead)

And if you do have colour 0 selected, the delete function can paint with
the last selected colour.

I might still add ~ for colour 0. Or maybe I'll make it an alias for the
eyedropper, since that's what it is in grafx2, very convenient.

Or... as you probably saw, Wendigo was complaining about brokeness on a
German keyboard. I think converting just the sprite editor to portable and
remappable keys is not that huge a project. The mapping can be displayed on
the help page using embed codes pretty easily.  Argh! When will I find the
time?


>
>
>>
>>>
>>>> Also, 0 selects the tenth colour.
>>>>
>>>>
>>>>> The time-out for typing two digit numbers is very well tuned, and
>>>>> after playing with it for a while, my original misgivings melted away, and
>>>>> I am very happy with it.
>>>>>
>>>>
>>>> First I tried a second, but that was too much, so I reduced it to half
>>>> a second, and that was good enough. And coincidentally, that's also how
>>>> long the colour index displays for after you change palette index :)
>>>>
>>>>
>>>>> I like that I can treat my first 9 colors like hotkeys, and at the
>>>>> same time, I still have quick access to the other colors.
>>>>>
>>>>
>>>> I wouldn't have bothered allowing access to colours above the tenth,
>>>> but of course the plan is to increase the Palette16 palette size soon
>>>> anyway. I still haven't figured out how to display the UI for that,
>>>> probably in rows of 16, and maybe show at most 2-3 rows at once... or
>>>> switch between showing the whole master palette at once vs the whole
>>>> subpalette.
>>>>
>>>> (Having a subpalette with over 100 colours is of course useless in most
>>>> cases, except when you take a sprite imported or drawn to use the master
>>>> palette directly and then want to palette swap it.)
>>>>
>>>
>>> This is exciting! :)
>>>
>>> I like the idea of being able to show just a few rows of a sprite
>>> palette. For limited-color sprites, that is exactly what I would want.
>>>
>>
>> Oh actually, I was imagining that sprite palettes could be variable size,
>> a multiple of 16. The size could just displayed as variable for display
>> (all indices up to 255 would always be treated as 0). A prompt to add
>> another row when you reach the end, I guess, or maybe that's confusing (not
>> obvious that you can expand it). It would prevent ever having to look at
>> 240 empty palette entries.
>>
>  I'm sure people would complain about that, and besides, there are several
>> places where palettes are displayed (in full) where it would be nice to be
>> able to avoid that.
>>
>
> Ooh! I like this! I don't think this will be confused at all.
>
>
>
>>
>>> How about if the master palette display can be shrunk, or entirely
>>> minimized when we don't need to see it?
>>>
>>> Also, although I still want to have hotkeys for keyboard controls of
>>> things like master-palette-minimizing or changing the number of displayed
>>> spritepalette rows, having a mouse-driven menu for that type of stuff will
>>> probably be good.
>>>
>>
>> Switching between views sounds good.
>> The master palette could even automatically pop to full size whenever you
>> use the keys to select a master palette index, and the sprite palette could
>> pop to full size when selecting a colour in it. Then we wouldn't even need
>> key combinations for those (though could still have clickable buttons for
>> them). Or maybe that will be jarring.
>>
>
> I think it will work fine.
>
>
>
>> The current size of each color block in the master palette display is
>>> totally arbitrary, and copied from an ancestral sprite editor even older
>>> than the ohrrpgce itself (I think most of the current sprite editor layout
>>> is from the Cowbobs sprite editor, maybe?)
>>>
>>> ---
>>> James
>>>
>>>
>>> _______________________________________________
>>> Ohrrpgce mailing list
>>> ohrrpgce at lists.motherhamster.org
>>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>>>
>>>
>>
> _______________________________________________
> Ohrrpgce mailing list
> ohrrpgce at lists.motherhamster.org
> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.motherhamster.org/pipermail/ohrrpgce-motherhamster.org/attachments/20170317/32b78066/attachment.htm>