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

[James Paige]

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
> <javascript:_e(%7B%7D,'cvml','Bob at hamsterrepublic.com');>> wrote:
>
>>
>> On Tue, Mar 14, 2017 at 7:36 AM, Ralph Versteegen <teeemcee at gmail.com
>> <javascript:_e(%7B%7D,'cvml','teeemcee at gmail.com');>> wrote:
>>
>>>
>>>
>>> On 15 March 2017 at 03:21, James Paige <Bob at hamsterrepublic.com
>>> <javascript:_e(%7B%7D,'cvml','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.


>
>>
>>> 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
>> <javascript:_e(%7B%7D,'cvml','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/20170316/22cbe6ab/attachment-0001.htm>