utf8 -> utf16 ... works!

Написать конвертер из utf-8 в utf-16 оказалось гораздо проще, чем я думал.

Пока читал различные статьи, форумы и документацию, я задумался, почему создатели сделали всё так тупо?

utf-32 требует 4 байта на символ, что очень много, но даёт произвольный доступ к символам.
utf-8 памяти требует от 1 до 4 байт на символ сам корректирует ошибки передачи байтов и имеет однозначный порядок их записи.

utf-16 ни то, ни это.
Странно это всё, мне не нравится по какому пути пошёл стандарт unicode.
Он превратился в сборную солянку и головную боль для программистов.

ссылка на канал | ссылка на группу

Так выглядит преобразование кодировки utf-8 в utf-16.

Вот как код итерации строки по символам вынести в отдельную функцию и оставить возможность получать дополнительные данные о символе (номер, размер, индекс символа и байта) без лишних действий?

Или, может, оставить всё в таком виде?
Иначе 100% придётся делать какую-то временную переменную или итератор, что, по-моему, только излишне усложнит код.

ссылка на канал | ссылка на группу

Обещали через 1-2 месяца доставить, а в итоге пришло через 2-3 недели).

ссылка на канал | ссылка на группу

Вот оно совершенство).
Не представляю, как разработчики в этом месиве символов что-то находят).

ссылка на канал | ссылка на группу

Главное всегда напоминать себе о цели.

ссылка на канал | ссылка на группу

Опыт написания игрового движка в прошлом очень помог совладать с этим ужасным winAPI.

Я наконец-то могу писать программу именно в своём стиле, а не в том, который диктует winAPI.

Плюсы моего стиля заключаются в простоте и скорости создания логики и графики.
На фото как раз есть пример создания меню.

ссылка на канал | ссылка на группу

Что ж, видимо, я буду не только строковую библиотеку писать, но и менеджер ввода.

А если буду разбивать проект на более-менее независимые модули (window, graphics, input, ...), то можно будет и исходники игрового движка посмотреть (там очень много готового сделано) и переписать по-новому.

ссылка на канал | ссылка на группу

За один оставшийся день нужно:
1) разработать дизайн и найти нормальные цвета
2) получать данные с последовательного порта
3) масштабировать, рисовать и сохранять в файл график
4) реализовать работу слайдера (полоса прокрутки), кнопкок и меню

Задач очень много, но реализация их несложная.
Очень хорошо, что у меня есть предыдущая версия рабочей программы, где уже есть всё, кроме интерфейса и сохранения в файл.

ссылка на канал | ссылка на группу

Что про дизайн скажете?

Хочется использовать небольшую палитру цветов для GUI.
Чёрный, светло- и тёмно-серый. Может быть ещё белый.
Размеры все кратные 2 или чётные.
Размер текста 14 px.

Хочется ещё рамку в 2 px у каждого элемента сделать, но пока не придумал, как это сделать, чтобы выглядело красиво.

И каким образом менять элемент при наведении курсора или клике?
Менять цвет фона или рамки?

Мне очень приглянулся стиль кнопок в WPF, надо будет подсмотреть).

ссылка на канал | ссылка на группу

Не вылезайте, ребятки, за границы массива и не пишите UB код).

Мне казалось, что в конце график не выводится полностью и просто обрезается.
Поэтому я намеренно сделал выход за границы массива, чтобы посмотреть, что там.

В конце графика видно, что некоторые точки меняются по значению других переменных в коде, которые лежат за границей массива.
Две точки меняются от экранных координат курсора, другая когда двигается слайдер

ссылка на канал | ссылка на группу

Я почти-почти понял, как масштабировать и рисовать график).

Осталось коэффициенты поправить, чтобы после масштабирования графики были пропорциональными.

ссылка на канал | ссылка на группу

От этих коэффициентов и выходов за границы массива уже болит голова).

Но методом проб и ошибок я понял, где нужно умножать, а где делить, чтобы масштабировать график и получать правильное значение от слайдера.

Если всё по-нормальному сделать, оформить в виде библиотеки, фреймворка или движка, будет неплохой плоттер).

ссылка на канал | ссылка на группу

Не могу определиться с названиями состояний клавиши для модуля input (отвечает за обработку ввода).
Возможные названия: key, state, press, release, hold, down, up, ...

На данный момент сделал так:
keyPressed (true, пока клавиша нажата)
keyReleased (true, пока клавиша отпущена)
(bool KeyReleased == !KeyPressed)

keyPressedOnce (true, если клавиша была нажата)
keyReleasedOnce (true, если клавиша была отпущена)

keyPressedDown (синоним pressedOnce)
keyPressedUp (синоним releasedOnce)

Потом хочу реализовать действие на двойной или тройной клик с заданной задержкой. (keyPressedTwice/Triple).
Поэтому keyPressedOnce версия должна иметь другое название (true, если клавиша была нажата кратковременно один раз или как?), чтобы не путать с twice и triple функциями.

ссылка на канал | ссылка на группу

Иногда баги бывают забавными).
При изменении масштаба графика, он почему-то начинает шагать).

ссылка на канал | ссылка на группу

Даже не знаю что сказать.
А я знаю что сказать, я отдыхать ***.
Столько времени на разработку и отладку ушло, а потом ещё и на корректировки от заказчика, а ещё я более 14 дней просто ничего не делал, думал всё будет просто.
Итого, времени на хобби и досуг не оставалось.

Вот такой результат получился.
По-моему, для человека, который почти в первый раз с нуля такое разрабатывает это очень даже неплохой результат.

Да, есть косяки и недоработки, это это только демонстрационная программа, дальше будет только жёстче и интереснее).

И да, моя первая программа за долгое время на 1000 строк кода.
Ну, если только не считать мой игровой движок в прошлом, там 5000, думаю, наберётся.

ссылка на канал | ссылка на группу

Хотел оптимизировать и облегчить перевод тактов в количество наносекунд при помощи QueryPerformanceCounter и QueryPerformanceFrequency.

Попробовал два способа перевести такты в секунды.

В моей системе прекрасно работают оба способа, но на другом компьютере при одинаковом количестве тактов из-за округления разница между двумя способами получилась в целых 200'000 наносекунд.

Предполагаю, чем больше количество тактов, чем выше будет разница.

ссылка на канал | ссылка на группу

Как же легко говнокодить, а потом тяжело переделывать по-нормальному).

В моей системе GUI при реализации slider, как отдельного компонента, я заметил несколько проблем.
У меня пока не реализовано такое понятие, как родительский и дочерний элемент.
Поэтому сразу не понял, почему slider не реагирует на курсор.

ссылка на канал | ссылка на группу

Ох, вот зачем я только решил рисовать графику при помощи GDI, это оказалось таким хардкором.
Благо я наконец-то нашёл!!
Нашёл, как рисовать внутри области, чтобы всё остальное, что выходит за её границы, отсекалось.

В opengl это решается за секунду (scissors), а вот решение для GDI я искал более недели.

В HTML это стиль overflow: hidden или scroll.

ссылка на канал | ссылка на группу

Какие ещё нужны элементы для графического интерфейса?

Думаю, пора переделывать GUI на компонентную систему + сделать древовидную структуру интерфейса.

ссылка на канал | ссылка на группу