Comments 66
Пожалуйста, приведите комментарии в сорцах к человекочитаемому виду.
//îïðåäåëèì ñêàëÿðíîå ïðîèçâåäåíèå ìåæäó íîðìàëüþ ê òî÷êå è âåêòîðîì ê èñòî÷íèêó ñâåòà
Так они в человекочитаемом виде (за исключением в одном из модулей дисплея — там не мои комментарии). Вопрос только в кодировке отображения.
Как?
Это ведь кодировка среды разработки. Более того, там в разных файлах разная кодировка (потому что часть была вообще из Linux взята). Visual Studio это не мешает отображать файлы верно. Вы скачайте репозиторий и всё будет отображаться правильно в среде разработки.
Я решительно не понимаю, зачем? Ради просмотра в github.com? А смысл?
Среда разработки вам всё покажет верно. Просто скачайте репозиторий и откройте — всё будет показываться правильно. Тем более, в notepad++ или akelpad.
Во-первых спасибо за Вашу статью и исходники. Во-вторых это вопрос скорее уважения к собственному труду и чужому времени — раз уж основная часть работы сделана, то и мелкие косяки можно бы и подправить.
то и мелкие косяки можно бы и подправить.


Дело в том, что «косяками» они являются только для некоторых читателей. Какая им разница, что за кодировка у текста? Они могут преобразовать в любую за десять секунд.
Могут, только зачем? Дело Ваше конечно, я просто говорю про то что если чем-то пользоваться не удобно то этим будут пользоваться меньше.
Ладно, ладно. Можно я воспользуюсь «я художник, я так вижу»? :)
Ну вот, наконец-то. Я тоже сам догадался до этого (ниже в нашей с вами ветке обсуждения), но сказали бы это сразу на первый же вопрос и всё, инцидент исчерпан. :)
А разве она не поддерживает уникод? Я вот Эклипсом пользуюсь, там выставляешь для проекта, скажем, UTF8 и всё пучком на всех системах.
Всё там поддерживается. Но это не означает обязательного использования именно юникода. :)
Означает. Никто не будет качать многогигабайтную среду разработки только для того, чтобы правильно увидеть ваши комментарии. Зачем вы вообще используете CP-1252 в 2020м году?
А что мешает поставить тот же akelpad? Он не многогигабайтный. Да я думаю, он у вас уже и так установлен. На худой конец, откройте просто браузером он с вероятностью 90% распознает сам.

Зачем вы вообще используете CP-1252 в 2020м году?


В 2020 году не уметь поменять кодировку файла несколько странно. ;) А использую я то, что исторически получилось. Вы что думаете, все эти файлы сделаны были в одном редакторе одномоментно? Да там минимум четыре среды разработки поучаствовало (Keil 4, Keil 5, VS6, VS2010, CodeBlocks, IDE Momentics).
Да я думаю, он у вас уже и так установлен.
У меня под linux принципиально нет проблем с кодировкой. Везде UTF-8. И когда я выкладываю исходники куда-то на обозрение — мне не нужно думать о том, что там поехали буквы или комментарии — там всегда будет UTF-8:
/*!
 * \brief Перемножает два числа с ограничением в 128 бит
 *
 * Деление на субструктуры осуществляется по следующему принципу:
 * ~~~~~~~~~~~
 * a₃a₂a₁a₀ # Полное 128-битное число
 * a₃a₂     # Суффикс l
 * a₃       # Суффикс ll
 *   a₂     # Суффикс lr
 *     a₁a₀ # Суффикс r
 *     a₁   # Суффикс rl
 *       a₀ # Суффикс rr
 * ~~~~~~~~~~~
 * \see _dh128_l
 * \see _dh128_ll
 * \see _dh128_lr
 * \see _dh128_r
 * \see _dh128_rl
 * \see _dh128_rr
 *
 * \param[in] a Множитель
 * \param[in] b Множитель
 * \return Произведение
 */
static struct frs_dh128 _dh128_mul(struct frs_dh128 a, struct frs_dh128 b) {
    /* Используем алгоритм Каратсубы с рекурсивным расщеплением */
    /* ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     * a₃a₂ + a₁a₀ → A
     *  x      x     x
     * b₃b₂ + b₁b₀ → B
     *  ↓      ↓     ↓
     * It₁    It₂   It₃
     *
     * P = It₃ - (It₁ + It₂)
     * или (для избежания опрокидывания при вычитании):
     * P = a₁a₀ x b₃b₂ + a₃a₂ x b₁b₀
     *
     * R = It₁ x z² + P x z + It₂
     * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
У меня под linux принципиально нет проблем с кодировкой. Везде UTF-8.


Поздравляю.

И когда я выкладываю исходники куда-то на обозрение


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

Извините, но всем не угодишь. ;)
У меня под linux принципиально нет проблем с кодировкой. Везде UTF-8.

Поддерживаю насчёт utf-8 и Linux.
На Маке тоже кракозябры.

Да-да, поддерживаю!
Разработчикам в наше время стыдно жаловаться на кракозябры.
Тот же EditPlus умеет в десятки кодировок, включая deprecated.
Взяли, зачем-то минусы понапоставили, эх...

О, у вас получилось. ;) А разговоров-то… :) Только с utf-8 не торопитесь. А то вдруг в Keil (или ещё где) решите русские буквы на экран вывести и будете удивлены, что они двухбайтные и на экране дисплея будет хрень — модуль дисплея не рассчитан на юникод.
модуль дисплея не рассчитан на юникод

Ну, спасибо, что хоть теперь предупредили. Есть какие-нибудь ещё сюрпризы?
Ну, спасибо, что хоть теперь предупредили.


А это было не очевидно?

Есть какие-нибудь ещё сюрпризы?


Понятия не имею, что для вас является сюрпризом, если смена кодировки стала проблемой. :)
Я вот тоже использую что-то вроде (uint8_t *)«Любой_Текст\r\nНа_Другой_Строке\0», среда, естественно, сделает utf8 во флеше, и если мне не нужен конкретно utf8, я делаю конверсию в любую необходимую кодировку уже самим контроллером. Ничего сложного в этом нет.
я делаю конверсию в любую необходимую кодировку уже самим контроллером


А именно? Собственная функция?
Сделать-то можно что угодно, вопрос в том, стоит ли.
Например, в UCS2 — своя. И да, всегда стоит. Это уважение как минимум к себе, как максимум к тем, кто захочет использовать твои труды.
Проблема в том, что вы всё равно привязываетесь к исходной кодировке. У вас это utf8, а у кого-то, будет utf16 или utf32. А может и cp-1251. И ваша функция всё равно потребует переделки. Вы для себя решили, что вам лучше так. Я же для себя лучше потрачу время на другое.

Удивительно, представляя наработки 3D-библиотеки самая большая проблема — это почему она не в utf-8. Вот уж такого идиотизма не ожидал. :)
Дык, проблема то в читабельности для программиста же, верно? Если человек вдруг сменит кодировку исходника сам, то он сам сменит условную utf8_to_ucs2 на cp1251_to_ucs2 и у него всё будет отлично: и исходник продолжит читаться и программа работать. Поэтому, лучше делать сразу правильно или не делать совсем.

Я хочу ещё раз уточнить: придрались к кодировке не потому, что захотели придраться, а потому что она реально нарушена. Не все гуру настолько, чтобы понимать код напрямую без комментариев, тем более чужой. Вы по какой-то причине не захотели это сделать, вы своё время цените, а вот читатель пусть сам разбирается, у него времени много, раз он пришёл читать Хабр.

Ещё раз: это нисколько не умаляет ценность самого кода касаемо темы топика, но лишь показывает отношение к читателям. Ну, либо статья делалась в спешке поделиться и требует некоторой доработки.
а потому что она реально нарушена.


Кодировка не бывает нарушена. Она просто есть.

Дык, проблема то в читабельности для программиста же, верно?


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


А раз для программиста — открывайте в IDE и всё там будет нормально.

но лишь показывает отношение к читателям.


Она показывает уровень читателей. ;) В статье кодировка нормальная. А код репозитория предназначен для конкретной среды разработки и нечего ожидать, что github сумеет верно всё отобразить. Кстати, вот и напишите авторам github, что их сайт не умеет верно определять кодировку — это неуважение к пользователям. Visual Studio почему-то умеет, а github нет. ;)
А раз для программиста — открывайте в IDE и всё там будет нормально.

Ну вот, опять. Нужен мой исходник? Откроете его в том IDE, которым я и пользуюсь (хотя я не назову вам его). Ну или сами сконвертируете в удобную для вас кодировку. Автор не виноват, автор так видит.
Visual Studio почему-то умеет, а github нет. ;)

Ну да, VS ведь работает только под Windows и для русскоговорящего сегмента использует строго cp. А то, что есть люди, работающие на других системах ему не важно. И гит тут ни причём — он RAW отдаёт как есть, а в как есть как раз cp. Тогда, по моему мнению, просто сразу бы следовало хотя-бы назвать те IDE, которыми эти исходники создавались и этой ветки с кодировкой вообще бы не появилось, верно? Но нет, зачем тратить своё время на это, пусть другие тратят своё, если им так надо. А если не справятся, то это всего лишь показывает их уровень.

Считаю бессмысленным дальнейшее поддержание этой ветки про кодировки. В любом случае, я напомню, что считаю статью интересной, но следует всё-же внести некоторые апдейты, которые сразу снимут кучу возникших вопросов. Удачи и не болейте.
Сдаётся мне, некоторые читатели опустились настолько, что даже простейших действий сделать не желают, но зато очень хотят, чтобы всё положили в рот и пожевали за них. Уж кодировку-то под себя не уметь настроить — это что-то. И не надо про RAW в Git — он web-страницу формирует? Вот пусть и определяет кодировку и выставляет её правильно. А то ему можно и это не неуважение, а фича, а мне оставить как есть нельзя — это почему-то неуважение. Считайте, что у меня тоже RAW. :)
А вообще, странно, как у вас вообще получается без проблем сборка проектов с исходников с git'а? В системе вообще может не быть половины библиотек — что ж за это автору пенять?

Считаю бессмысленным дальнейшее поддержание этой ветки про кодировки.


Ну, это с самого начала так.
И не надо про RAW в Git — он web-страницу формирует? Вот пусть и определяет кодировку и выставляет её правильно.

Сомнение присутствует у меня. Пользовались ли вы RAW в гите? Вот, например, RAW на файл из вашего репозитория:
raw.githubusercontent.com/da-nie/STM32F407_3D/master/Src/main.c
Это прямая ссылка и файл отдаётся в исходном виде текущей версии, гиту нельзя туда что-либо втыкать. Как и, впрочем, в web предпросмотре.
Сомнение присутствует у меня.


Да вот же с чего началось: image

Как и, впрочем, в web предпросмотре.


А вот тут он может переключить кодировку сам.

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


Ну а коли вы именно файл в браузере открыли, то какие вообще претензии могут быть? Тут уж браузер виноват, что не распознал. :)
Ну, начнём с того, что в браузере открывал не я, и жаловался на это не я. Просто я обратил внимание, что в гите оно хранится в конкретной кодировке, т.к. гит не имеет права что-либо менять в файлах. Т.е., в какой кодировке выгрузите в той и будут.

А сыр-бор произошел из-за того, что люди не обязаны устанавливать вашу IDE и импортировать туда ваш проект чтобы просто быстро посмотреть что к чему. И браузера, как раз, тут предостаточно. И тут никто не виноват. Это другого уровня социальная проблема.

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

А вы для кого эту статью написали? Какой в ней смысл, если часть материала читателям недоступны?

Зачем вы потратили свою жизнь на бесполезную работу и продолжаете ее тратить в тщетных попытках оправдать свою позицию?

Странно, что ещё никто компилируемость в конкретном компиляторе на ОС любой версии не потребовал.

А где здесь смеяться? Это стандартное современное требование, компилировать сишные исходники хотя бы gcc и clang. Clang нормально собирает ваши исходники?
А вы для кого эту статью написали? Какой в ней смысл, если часть материала читателям недоступны?


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

А где здесь смеяться? Это стандартное современное требование,


А хорошие у вас аппетиты. ;)
В Visual Studio это делается вот так:



Ваши комментарии не видно на гитхабе
мне радует, всё понятно и без лишних циклов, как я сам называю переходы в стек
Интересно! А как вам памяти хватило на 103-ем для буфера экрана? Или вы сразу же рисуете без буферизации?
Буферизации хватило на один столбец (передний + задний буферы) плюс Z-буфер. Плюс «полуфабрикатные» координаты всех примитивов.
Исходный код там есть. Или считаете, что достойно полноценной статьи?
Не знаю как другие, но я за статью! Желательно с разбором «полетов» ;)
В кайле с кодировкой всегда были проблемы. Я по этой причине старался в нем делать коменты на инглише.
Проблема в том, что, видимо, большая часть придравшихся к кодировке никогда в Keil не работали и не понимают, что файлы переносятся с Keil в Visual Studio, в другие среды и обратно.
А почему все должны пользоваться именно Keil'ом? Звучит как довод «не пробовал, значит не имеешь права обсуждать». Мир не ограничен только Keil.
Ну а зачем нам себя вообще ограничивать IBM PC? :) А вдруг я на ZX-Spectrum в HiSoft-C текст открыть захочу — там вообще на всё 96 символов в таблице и русских букв нет, зато есть признанные замены ряда символов при русификации. А тут никакой совместимости с ними в ZX! Бардак! Срамота! :)
Ну вот, понимаете же абсурдность своих доводов, но продолжаете пользоваться. Поделитесь мотивами?

Просто я действительно Кеил видел только на скриншотах. Как-то сразу в Эклипс влился, хотя многих он пугает только самой настройкой, кодировки при этом вообще детские шалости. И конкретно там с кодировками проблем нет вообще. И рассчитан он не только на Windows.
Абсурдность тут желать, чтобы у всех всё работало в любых средах и условиях. Вы же не ждёте, что программы от MacOS работают в Windows?
Интересно, что можно было бы выжать с платы STM32F429-Disco, на борту которой более мощный камень, внешняя оперативка на 8МБ, контроллер дисплея, буфер которого можно разместить во внешней ОЗУ и модуль DMA2D для некоторого ускорения графики.
Ну что ж, исходник библиотеки есть, осталось найти энтузиаста, который всё это сделает. :) Думаю, можно получить интересную игрушку. :)

Текстурирование простое аффинное или перспективно — скорректированное ?

Там каждые 16 точек вычисляется точное значение текстуры с учётом перспективы, а в промежутке линейная интерполяция по экрану.
Doom не требует истинной 3D-графики. Текстурирование именно горизонталей и вертикалей делается более быстрым способом. А эта библиотека позволяет выводить истинное 3D со всеми обработками.
Однако, Doom я теоретически могу запустить на этом stm — у меня есть такой собственный проект 18 летней давности. Вот он. Однако, он под MS-DOS с жёсткой привязкой к аппаратуре. И — что гораздо хуже — там код мне не нравится совершенно (не удивительно, я тогда едва с Си познакомился — так и писал). Я периодически пытаюсь взяться за переделку, но терпения не хватает сделать всё сразу, а через некоторое время после перерыва я начинаю забывать о новых созданных при рефакторинге абстракциях и продолжать переделку дальше не хочется. :)
Мой вопрос не по сабжевой библиотеке, он более общий. Сейчас модно запускать Doom на старых фотоаппаратах, экранах принтеров, инженерных калькуляторах, электронных книгах, на всем, что имеет CPU и экран, короче. Производительность ARM-ядра с частотой около сотни МГц должно быть достаточно.
Производительность ARM-ядра с частотой около сотни МГц должно быть достаточно.


Памяти очень мало у stm32. Вот если внешнюю подключать, тогда хватит.
Я его играл.
Речь не идёт о «поделке» со всевозможным урезанием графики. Речь о полноценной игре.
Only those users with full accounts are able to leave comments. Log in, please.