1

Testując potencjalne możliwości przeróbek CMC i przy okazji testując i wystawiając cierpliwość czytających te moje "niskopoziomowe" wywody na niemała, jak obawiam się, próbę, chciałbym otworzyć nowy wątek.

Gdyby dodać do CMC (a perspektywicznie myśląc, raczej do SDCMC) obsługę większej liczby patternów ponad limit 100, to z uwagi na system dziesiętny komunikacji tego kompozera z użytkownikiem (który nie warto zmieniać w mojej ocenie), powstaje problem, jak reprezentować wartości przekraczające ten limit, pamiętając o ograniczeniach fizycznych ekranu (najlepiej nie wychodzić więc z tą liczbą ponad przydzielone, jak dotąd, dwie kolumny).
Nie jest też zupełnie jasne jaką powinien przyjąć formę sposób wprowadzania takich (>99) wartości z klawiatury.
W tym względzie należy zwrócić uwagę, że w CMC kompozer reaguje pozytywnie (sprawdza czy w granicy dopuszczalnych wartości i akcepuje) na parę cyfr wprowadzonych z klawiatury łacznie, a nie na pojedyńczą cyfrę z większej liczby, wprowadzane kolejno.

Stąd uważam, że problem wydaje się nie taki oczywisty do rozwiązania. Dlatego chciałem pewne rozwiązanie zaproponować i poddać ocenie, albo przeczytać jakiś pomysł na inne, lepsze, rozwiązanie tego problemu (czyli wprowadzenia liczby >99 w CMC i jej reprezentacji wizualnej, najlepiej w dwóch kolumnach i najlepiej żeby to było wciąż w systemie dziesiętnym :) ).

Mi przyszło na myśl następujące rozwiązanie:
Wizualnie liczbę >99 w systemie dziesiętnym na dwóch kolumnach można przedstawić w CMC następująco: wyciągamy modulo 100 z tej liczby (inaczej pisząc, to jest część dziesiętna i jednostek tej liczby i to idzie do wyświetlenia). Informacja o tym, że wartość przekracza >99 jest natomiast umieszczona na kolorze jednej z cyfr tej wyświetlanej części liczby, a oczywiście reprezentującej ją całą.

Czyli, przykład dla jasności: jeśli zadaniem jest wyświetlić liczbę 123, to wyświetlamy 23 i podświetlamy (to jest ta informacja na kolorze, o której napisałem wyżej) cyfrę 3 z "23".
Gdybyśmy potrzebowali wyświetlić wartość 223, to podświetlenie wypadło by na cyfrę 2 z "23".


Propozycja jak można rozwiązać wprowadzenie z klawiatury wartości >99:
1.) cntr+1 (lub +2) , 2.)  spacja, 3.) dziesiętna część, 4.) część jednostek całej liczby.

Wyjaśnię skąd w propozycji jaką przedkładam dwa pierwsze kroki:
kombinacje typu shift+1 odpadają, bo mają już swoje inne przeznaczenie (w SDCMC jest to wyłączanie | włączanie kanałów).
Niestety cntr+1 nie pozostawia śladu w systetemowym $2FC (764), stąd wspomaganie spacją w drugim kroku.

Przygotowałem przeróbkę CMC wg tych założeń (poza tym że krok drugi ( spacja ) jest potraktowany bardziej "liberalnie" - może to być w tej uproszczonej wersji, każdy inny klawisz poza cyfrą, a limit liczby jaką można wprowadzić to 127) żeby ewentualnie sprawdzić jak praktycznie się to ma szansę sprawdzać. Ale generalnie do niczego się ta przeróbka innego nie nadaje niż tylko do tych specyficznych zastosowań (testów tych rozwiązań), bo wpisywanie czegoś do patternów >99 powoduje zwis przy wyjściu z takiego patternu (nie ma potrzeby na tą chwilę tego prostować).

No coż, może nie jest to specjalnie ciekawe zagadnienie do rozważań, ale jeśli kogoś zainteresuje ten problem i zechciałby podzielić się spostrzeżeniami, pomysłami może, to będę za to wdzięczny.

Jeśli będę miał jakieś jeszcze inne praktyczne problemy do roztrzygnięcia także w przyszłości (różnie może być), to być może w tym wątku będę jeszcze dopytywał o zdanie i opinie.

Post's attachments

test_onto_cmc.zip 7.83 kb, liczba pobrań: 1 (od 2015-06-16) 

Tylko zalogowani mogą pobierać załączniki.

2

Ctrl+1 ma odzwierciedlenie w SSFLAG ($2FF) na zasadzie odwrócenia wartości (przerwanie klawiatury robi EOR #$FF).

A dlaczego nie przesunąć jedynki w prawo w ramach definicji znaku i użyć jednak trzyznakowych liczb? Coś w guście:

..o. .ooo
..o. ...o
..o. .ooo
..o. .o..
..o. .ooo

Liczba będzie czytelna, bo od poprzedniej kolumny będzie jednak odstęp dwóch pikseli multicolor. Oczywiście 2xx w ten sposób już nie zrobimy :/

Większe pole do popisu daje oczywiście hires co wiąże się z redefinicją zestawu znaków, no i zmianą sposobu reprezentacji niektórych elementów ekranu (może podkolorowanie sprajtami?) oraz podświetlenia kursora (tradycyjny inverse).
Co do wprowadzania liczb - sugerowałbym wtedy wprowadzanie 1..3 cyfr na zasadzie znanej z kalkulatora:
1. Pierwsza cyfra wchodzi w tryb wprowadzania liczby.
2. Cyfry przesuwają się w lewo podczas wprowadzania (intuicyjne).
3. 3 cyfra wychodzi z trybu, aktualizuje pole i przesuwa kursor (albo nie - zależnie od potrzeby).
4. Strzałka lub RETURN wychodzi z trybu i aktualizuje pole.
5. ESC wychodzi z trybu i przywraca poprzednią wartość pola.
6. BKSP połyka cyfrę i przesuwa resztę w prawo.
7. Po połknięciu wszystkich cyfr mamy 0 ale trwamy w edycji.

Mam wrażenie, że markowanie setki kolorem będzie mocno nieintuicyjne szczególnie dla użytkowników mających awersję do dokumentacji.

hex, code and ror'n'rol
niewiedza buduje, wiedza rujnuje

3

Przesunięcie jedynki w ramach definicji znaków jest pomysłem wartym rozważenia, ale nie jest to rozwiązanie takie zupełnie proste do zaimplementowania.
Wtedy trzeba też roztrzygnąć, czy mamy mieć dwie definicje jedynki (tą używaną zwyczajnie i tą specjalną do "setki"), czy jedną, co byłoby prostrze do wprowadzenia, ale wizualnie może to już nie być takie "fajne".

Teoretycznie wydaje się jednak, że jedynka w takiej formie (przesuniętej w prawo) by chyba się zmieściła na standardowym ekranie CMC, przy czym widzę, że kursor wskazujący aktualną pozycję w songu trzeba by cofnąć o pozycję (na co jest miejsce, ale może to się lekko odbić na ogólnej estetyce ekranu, ale w sumie trudno mi to teraz z tej perspektywy dobrze ocenić).

Co do wprowadzania liczby (z nieoreślonej długości cyfr, bo chcemy mieć możliwość zapisu liczby >99), to proponujesz rozwiązanie zupełnie rewolucyjne w stosunku do "zastanego". Wydaje się ono całkowicie prawidłowe i chyba wzorcowe nawet, ale kłóci się z pewnymi fundamentamentalnymi założeniami.

Moja ogólna filozofia w przypadku przeróbek programów takich jak CMC, jest taka, żeby możliwie w pełni utrzymywać rozwizania już funkcjonujące, do których nawykliśmy w przypadku danego programu. Ma to także uzasadnienie mocno praktyczne, bo nie trzeba tak bardzo zmieniać poszczególnych procedur, tak gruntownie ingerować w podstawowe założenia na jakich opiera się program, tym samym czasem "wywracać" kod "do góry nogami" lub pisać od nowa.

Dlatego także wprowadzanie liczb >99 nie chciałbym żeby spowodowało zmianę dotychczasowej formuły wprowadzania liczb z dotychczasowego zakresu, aby "feeling" pozostał ten sam (w końcu to cmc, ze swoimi jakimiś ograniczeniami, ale w założeniu, przynajmniej w pełni "kompatybilny" z pierwotną wersją, pomimo że oferujący więcej - to póki co fikcja, ale taki miałby być cel).

Na dobrą sprawę, to pracując pod tak przerobionym programem można nawet przez jakiś czas nie zauważać dodatkowych możliwości kompozera, w tym także sposobu wyświetlania liczb >99.
Odtwarzasz stary kawałek, wszystko możliwie w pełni wygląda i działa dokłądnie jak wcześniej.

Natomiast co jeśli użytkownik pierwszy raz zauważy taką dziwną sytuację, kiedy ma jakąś wartość i jedna z cyfr jest podświetlona? Czy się domyśli jej znaczenia sam bez podpowiadania?

Na to pytanie łatwo jest mi odpowiedzieć, że domyśli się prawidłowego znaczenia takiej formy reprezentacji "pełnej" liczby, bo kontekst kiedy ją zobaczy najprędzej będzie podpowiedzią do tego wystarczającą.
Te "dziwne" liczby zobaczy przewijąjąc kolejne poza granicę 99, albo patterny albo pozycje song. I stanie się to jasne i oczywiste.

Natomiast naniesienie takiej liczby z klawiatury wg sposoby który zaproponowałem idzie też (chociaż wciąż nie jest dla mnie) w kierunku intuicyjnym.
Użytkownik bez podpowiedzi powinien przy pewnym wysiłku woli i namyśle, samodzielnie dość do tego jak to się to robi.
Tak powinno być i chciałbym żeby w tym wypadku też było.

A na koniec, to ogólnie dziękuję Mono za dobre chęci w stosunku do moich poczynań (dość nieporadnych) na forum (wiem po czasie, że często wręcz "bredze" myląć, czy przeinaczając oczywiste tutaj sprawy, tym bardziej dzięki). Traktuję to jako wsparcie i tak oficjalną drogą deklaruję ze swojej strony, że jak będziesz miał "zawał" pracy koderskiej (a "widzę" że bierzesz na siebie tego dużo) i uznasz w danym momencie, że warto byłoby się nią z kimś podzielić, to o ile uznasz, że mam jakąś szansę dane zadanie wykonać, to możesz śmiało do mnie z tym "udzerzać" przez emaila. Postaram się wtedy pomóc, mając też w pamięci Twoją pomoc i dobrą wolę. Pozdrawiam.

4

Rozumiem. Pobawiłem się chwilę programikiem i myślę że pomysł jest jednak całkiem fajny. Jedyne co mi w sumie przeszkadza to konieczność wciskania spacji między częścią setek a częścią dziesiątek (no ale to myślę da się łatwo wyeliminować).
Przyszło mi do głowy, że może pewną pomocą byłoby podpowiadanie gdzieś na obrzeżach ekranu liczby, którą do tej pory wpisaliśmy. Np. wciskamy ctrl+1 i pojawia się "1__", ctrl+2 - "2__", 0-" 0_" itd. Może nie wymagałoby to wielkiej ingerencji w kod programu a widzielibyśmy co się dzieje.
I chyba warto by dodać HELP na wciśnięcie klawisza HELP :) No ale to zupełnie inna bajka.

P.S. Dziękuję za ofertę pomocy, to bardzo miłe i będę o tym pamiętał. W razie potrzeby oczywiście też uderzaj w moim kierunku.

hex, code and ror'n'rol
niewiedza buduje, wiedza rujnuje