Как известно, старшие STM'ки имеют приличные частоты и объёмы ОЗУ. Ну а раз так, то почему бы не запустить 3D-графику на таких контроллерах? Да нет ничего проще!
Демонстрационная картинка
Для отображения 3D графики я подключил к плате STM32F4Discovery на базе STM32F407 дисплей с разрешением 320x240. Нет, не по FSMC — у этой платы заняты нужные контакты. Впрочем, для наших экспериментов хватит и обычных портов.
Дисплей подключается вот так:
В репозитории есть классы для трёх разных вариантов дисплея (IL9325, SPFD5408, HX8347D).
Внешний вид
Для рисования 3D-графики я когда-то очень давно делал некое подобие фрагмента библиотеки OpenGL первой версии. Вот это подобие я и приделал к STM32. На один пиксель эта библиотека требует 6 байт (2 на цвет и 4 на Z-буфер). Памяти у STM32F407 в этом варианте хватит только на 160x120. Ну что ж, значит, растянем картинку в два раза по вертикали и по горизонтали.
Данное поделие умеет:
1) Текстурирование текстурой с размерами, кратными степени двойки;
2) Z-отсечение;
3) Интерполяцию цвета вершин внутри грани;
4) Расчёт освещения для восьми источников с настройкой затухания от расстояния.
Порядок работы с библиотекой следующий:
Сперва нужно инициализировать библиотеку (она выделит память под экран). Затем, как и у OpenGL, нужно настроить матрицу проецирования и видовой порт.
Собственно, теперь можно и рисовать, практически так же, как и в OpenGL (для аналогичных команд).
Например, можно задать источник света:
Можно задать материал для поверхности:
Можно включить расчёт освещения cSGL.Enable(CSGL::SGL_LIGHTING); и конкретный источник света cSGL.Enable(CSGL::SGL_LIGHT0);
Освещённость одинаково считается для передней и задней стороны. Более того, отсечения задних граней я не делал (оно редко бывает мне нужно). Но при желании сделать его пара пустяков.
Создавать источники света не обязательно. Вполне можно задать цвет граней самим, используя cSGL.Color3f. Цвет (и параметры цвета материала тоже) задаётся нормированный [0..1];
Текстура подключается командой cSGL.BindTexture. Обращаю внимание, что библиотека использует текстурирование всегда! При этом массив цветов текстуры задаётся как последовательность четырёх байт (r,g,b,alpha) и вот тут r,g,b,alpha числа от 0 до 255. Строго говоря, именно на эти числа и умножается интенсивность каналов R,G,B, задаваемая glColor3f (или рассчитанная по данным источников света) при отрисовке. Массив данных текстуры должен сохраняться на всё время вывода грани.
Вывод грани осуществляется следующим образом:
cSGL.Begin включает рисование грани, cSGL.End завершает этот режим. Внутри этих команд помещаются команды задания параметров точки (нормаль, нормированная текстурная координата, нормированный цвет точки) и отрисовки точки cSGL.Vertex3f. Количество точек внутри begin/end может быть произвольным и в целом составляет выводимый выпуклый многоугольник.
Управление текстурированием, проецированием и моделированием осуществляется, как и в OpenGL тремя матрицами, выбираемыми командами
Операции с этими матрицами выполняются командами
Для рисования библиотека использует класс точки CGLScreenColor. Это влияет на быстродействие не в лучшую сторону, но позволяет легко переносить библиотеку между разными дисплеями и архитектурами.
Какой сейчас получился FPS? Для данного октаэдра без одной грани (я её снял) замеры длительности, собственно, процедур отрисовок дают около 150-200 FPS. А вот переброска через порты буфера на дисплей с удвоением картинки существенно снижает FPS, примерно до 10-15 (да-да, я даже не думал это оптимизировать пока что).
Обращаю внимание, что библиотека не оптимизировалась практически ни в одном месте. Её задача была просто сделать понятный инструмент 3D-рисования с возможностью модернизации. Полагаю, оптимизировав можно ускорить вывод графики на STM32 ещё раз в 5-10 (например, применив FSMC, оптимизировав рисование и переброску данных дисплею).
Для чего может пригодиться такая библиотека? Ну, например, выводить какие-либо показания пользователю в наглядном виде. Например, ориентацию простенького 3D объекта.
Видео работы:
Репозиторий для STM32
Репозиторий для Windows.
Удачи в развитии проекта! :)
Демонстрационная картинка
Для отображения 3D графики я подключил к плате STM32F4Discovery на базе STM32F407 дисплей с разрешением 320x240. Нет, не по FSMC — у этой платы заняты нужные контакты. Впрочем, для наших экспериментов хватит и обычных портов.
Дисплей подключается вот так:
- CS -> E12
- RST -> E2
- RS -> E15
- WR -> E14
- RD -> E13
- D0 -> E4
- D1 -> E5
- D2 -> E6
- D3 -> E7
- D4 -> E8
- D5 -> E9
- D6 -> E10
- D7 -> E11
В репозитории есть классы для трёх разных вариантов дисплея (IL9325, SPFD5408, HX8347D).
Внешний вид
Для рисования 3D-графики я когда-то очень давно делал некое подобие фрагмента библиотеки OpenGL первой версии. Вот это подобие я и приделал к STM32. На один пиксель эта библиотека требует 6 байт (2 на цвет и 4 на Z-буфер). Памяти у STM32F407 в этом варианте хватит только на 160x120. Ну что ж, значит, растянем картинку в два раза по вертикали и по горизонтали.
Данное поделие умеет:
1) Текстурирование текстурой с размерами, кратными степени двойки;
2) Z-отсечение;
3) Интерполяцию цвета вершин внутри грани;
4) Расчёт освещения для восьми источников с настройкой затухания от расстояния.
Порядок работы с библиотекой следующий:
Сперва нужно инициализировать библиотеку (она выделит память под экран). Затем, как и у OpenGL, нужно настроить матрицу проецирования и видовой порт.
const int32_t WIDTH=160;
const int32_t HEIGHT=120;
const float VISIBLE_ANGLE=60;
const float NEAR_PLANE=1;
const float FAR_PLANE=1000;
float aspect=static_cast<float>(WIDTH)/static_cast<float>(HEIGHT);
cSGL.Init(WIDTH,HEIGHT);
cSGL.Perspective(VISIBLE_ANGLE,aspect,NEAR_PLANE,FAR_PLANE);
cSGL.SetViewport(0,0,WIDTH,HEIGHT);
Собственно, теперь можно и рисовать, практически так же, как и в OpenGL (для аналогичных команд).
Например, можно задать источник света:
cSGL.MatrixMode(CSGL::SGL_MATRIX_MODELVIEW);
cSGL.LoadIdentity();
float l0_position[]={0,0,0};
float l0_ambient[]={0.1,0.1,0.1};
float l0_diffuse[]={0.7,0.7,0.7};
float l0_specular[]={1,1,1};
float l0_shininess[]={1};
cSGL.Lightfv(CSGL::SGL_LIGHT0,CSGL::SGL_POSITION,l0_position);
cSGL.Lightfv(CSGL::SGL_LIGHT0,CSGL::SGL_AMBIENT,l0_ambient);
cSGL.Lightfv(CSGL::SGL_LIGHT0,CSGL::SGL_DIFFUSE,l0_diffuse);
cSGL.Lightfv(CSGL::SGL_LIGHT0,CSGL::SGL_SPECULAR,l0_specular);
cSGL.Lightfv(CSGL::SGL_LIGHT0,CSGL::SGL_SHININESS,l0_shininess);
Можно задать материал для поверхности:
float m0_ambient[]={0.1,0.1,0.1};
float m0_diffuse[]={0.5,0.5,0.5};
float m0_specular[]={0.5,0.5,0.5};
float m0_emission[]={0.1,0.1,0.1};
cSGL.Materialfv(CSGL::SGL_AMBIENT,m0_ambient);
cSGL.Materialfv(CSGL::SGL_DIFFUSE,m0_diffuse);
cSGL.Materialfv(CSGL::SGL_SPECULAR,m0_specular);
cSGL.Materialfv(CSGL::SGL_EMISSION,m0_emission);
Можно включить расчёт освещения cSGL.Enable(CSGL::SGL_LIGHTING); и конкретный источник света cSGL.Enable(CSGL::SGL_LIGHT0);
Освещённость одинаково считается для передней и задней стороны. Более того, отсечения задних граней я не делал (оно редко бывает мне нужно). Но при желании сделать его пара пустяков.
Создавать источники света не обязательно. Вполне можно задать цвет граней самим, используя cSGL.Color3f. Цвет (и параметры цвета материала тоже) задаётся нормированный [0..1];
Текстура подключается командой cSGL.BindTexture. Обращаю внимание, что библиотека использует текстурирование всегда! При этом массив цветов текстуры задаётся как последовательность четырёх байт (r,g,b,alpha) и вот тут r,g,b,alpha числа от 0 до 255. Строго говоря, именно на эти числа и умножается интенсивность каналов R,G,B, задаваемая glColor3f (или рассчитанная по данным источников света) при отрисовке. Массив данных текстуры должен сохраняться на всё время вывода грани.
Вывод грани осуществляется следующим образом:
cSGL.Begin();
cSGL.TexCoordf(0,0);
cSGL.Vertex3f(x6,y6,z6);
cSGL.TexCoordf(0,1);
cSGL.Vertex3f(x4,y4,z4);
cSGL.TexCoordf(1,0);
cSGL.Vertex3f(x2,y2,z2);
cSGL.End();
cSGL.Begin включает рисование грани, cSGL.End завершает этот режим. Внутри этих команд помещаются команды задания параметров точки (нормаль, нормированная текстурная координата, нормированный цвет точки) и отрисовки точки cSGL.Vertex3f. Количество точек внутри begin/end может быть произвольным и в целом составляет выводимый выпуклый многоугольник.
Управление текстурированием, проецированием и моделированием осуществляется, как и в OpenGL тремя матрицами, выбираемыми командами
MatrixMode(SGL_MATRIX_TEXTURE);
MatrixMode(SGL_MATRIX_PROJECTION);
MatrixMode(SGL_MATRIX_MODELVIEW);
Операции с этими матрицами выполняются командами
LoadIdentity();
cSGL.Rotatef(angle,0,0,1);
cSGL.Translatef(-0.5,-0.5,0);
Для рисования библиотека использует класс точки CGLScreenColor. Это влияет на быстродействие не в лучшую сторону, но позволяет легко переносить библиотеку между разными дисплеями и архитектурами.
Какой сейчас получился FPS? Для данного октаэдра без одной грани (я её снял) замеры длительности, собственно, процедур отрисовок дают около 150-200 FPS. А вот переброска через порты буфера на дисплей с удвоением картинки существенно снижает FPS, примерно до 10-15 (да-да, я даже не думал это оптимизировать пока что).
Обращаю внимание, что библиотека не оптимизировалась практически ни в одном месте. Её задача была просто сделать понятный инструмент 3D-рисования с возможностью модернизации. Полагаю, оптимизировав можно ускорить вывод графики на STM32 ещё раз в 5-10 (например, применив FSMC, оптимизировав рисование и переброску данных дисплею).
Для чего может пригодиться такая библиотека? Ну, например, выводить какие-либо показания пользователю в наглядном виде. Например, ориентацию простенького 3D объекта.
Видео работы:
Репозиторий для STM32
Репозиторий для Windows.
Удачи в развитии проекта! :)
LibrarianOok
Пожалуйста, приведите комментарии в сорцах к человекочитаемому виду.
da-nie Автор
Так они в человекочитаемом виде (за исключением в одном из модулей дисплея — там не мои комментарии). Вопрос только в кодировке отображения.
LibrarianOok
Ага, поменяйте её пожалуйста на человеческую.
da-nie Автор
Как?
Это ведь кодировка среды разработки. Более того, там в разных файлах разная кодировка (потому что часть была вообще из Linux взята). Visual Studio это не мешает отображать файлы верно. Вы скачайте репозиторий и всё будет отображаться правильно в среде разработки.
LibrarianOok
da-nie Автор
Я решительно не понимаю, зачем? Ради просмотра в github.com? А смысл?
Среда разработки вам всё покажет верно. Просто скачайте репозиторий и откройте — всё будет показываться правильно. Тем более, в notepad++ или akelpad.
EighthMayer
Во-первых спасибо за Вашу статью и исходники. Во-вторых это вопрос скорее уважения к собственному труду и чужому времени — раз уж основная часть работы сделана, то и мелкие косяки можно бы и подправить.
da-nie Автор
Дело в том, что «косяками» они являются только для некоторых читателей. Какая им разница, что за кодировка у текста? Они могут преобразовать в любую за десять секунд.
EighthMayer
Могут, только зачем? Дело Ваше конечно, я просто говорю про то что если чем-то пользоваться не удобно то этим будут пользоваться меньше.
da-nie Автор
Ладно, ладно. Можно я воспользуюсь «я художник, я так вижу»? :)
HardWrMan
Ну вот, наконец-то. Я тоже сам догадался до этого (ниже в нашей с вами ветке обсуждения), но сказали бы это сразу на первый же вопрос и всё, инцидент исчерпан. :)
HardWrMan
А разве она не поддерживает уникод? Я вот Эклипсом пользуюсь, там выставляешь для проекта, скажем, UTF8 и всё пучком на всех системах.
da-nie Автор
Всё там поддерживается. Но это не означает обязательного использования именно юникода. :)
staticmain
Означает. Никто не будет качать многогигабайтную среду разработки только для того, чтобы правильно увидеть ваши комментарии. Зачем вы вообще используете CP-1252 в 2020м году?
da-nie Автор
А что мешает поставить тот же akelpad? Он не многогигабайтный. Да я думаю, он у вас уже и так установлен. На худой конец, откройте просто браузером он с вероятностью 90% распознает сам.
В 2020 году не уметь поменять кодировку файла несколько странно. ;) А использую я то, что исторически получилось. Вы что думаете, все эти файлы сделаны были в одном редакторе одномоментно? Да там минимум четыре среды разработки поучаствовало (Keil 4, Keil 5, VS6, VS2010, CodeBlocks, IDE Momentics).
staticmain
da-nie Автор
Поздравляю.
… то не русскоязычные пользователи требуют от вас комментариев на английском языке, поскольку им плевать на вашу кодировку, они даже буквы не знают, как читаются. ;)
Извините, но всем не угодишь. ;)
Andrew_Pinkerton
Поддерживаю насчёт utf-8 и Linux.
На Маке тоже кракозябры.
moroz69off
Да-да, поддерживаю!
Разработчикам в наше время стыдно жаловаться на кракозябры.
Тот же EditPlus умеет в десятки кодировок, включая deprecated.
Взяли, зачем-то минусы понапоставили, эх...
LibrarianOok
da-nie Автор
О, у вас получилось. ;) А разговоров-то… :) Только с utf-8 не торопитесь. А то вдруг в Keil (или ещё где) решите русские буквы на экран вывести и будете удивлены, что они двухбайтные и на экране дисплея будет хрень — модуль дисплея не рассчитан на юникод.
LibrarianOok
Ну, спасибо, что хоть теперь предупредили. Есть какие-нибудь ещё сюрпризы?
da-nie Автор
А это было не очевидно?
Понятия не имею, что для вас является сюрпризом, если смена кодировки стала проблемой. :)
HardWrMan
Я вот тоже использую что-то вроде (uint8_t *)«Любой_Текст\r\nНа_Другой_Строке\0», среда, естественно, сделает utf8 во флеше, и если мне не нужен конкретно utf8, я делаю конверсию в любую необходимую кодировку уже самим контроллером. Ничего сложного в этом нет.
da-nie Автор
А именно? Собственная функция?
Сделать-то можно что угодно, вопрос в том, стоит ли.
HardWrMan
Например, в UCS2 — своя. И да, всегда стоит. Это уважение как минимум к себе, как максимум к тем, кто захочет использовать твои труды.
da-nie Автор
Проблема в том, что вы всё равно привязываетесь к исходной кодировке. У вас это utf8, а у кого-то, будет utf16 или utf32. А может и cp-1251. И ваша функция всё равно потребует переделки. Вы для себя решили, что вам лучше так. Я же для себя лучше потрачу время на другое.
Удивительно, представляя наработки 3D-библиотеки самая большая проблема — это почему она не в utf-8. Вот уж такого идиотизма не ожидал. :)
HardWrMan
Дык, проблема то в читабельности для программиста же, верно? Если человек вдруг сменит кодировку исходника сам, то он сам сменит условную utf8_to_ucs2 на cp1251_to_ucs2 и у него всё будет отлично: и исходник продолжит читаться и программа работать. Поэтому, лучше делать сразу правильно или не делать совсем.
Я хочу ещё раз уточнить: придрались к кодировке не потому, что захотели придраться, а потому что она реально нарушена. Не все гуру настолько, чтобы понимать код напрямую без комментариев, тем более чужой. Вы по какой-то причине не захотели это сделать, вы своё время цените, а вот читатель пусть сам разбирается, у него времени много, раз он пришёл читать Хабр.
Ещё раз: это нисколько не умаляет ценность самого кода касаемо темы топика, но лишь показывает отношение к читателям. Ну, либо статья делалась в спешке поделиться и требует некоторой доработки.
da-nie Автор
Кодировка не бывает нарушена. Она просто есть.
А раз для программиста — открывайте в IDE и всё там будет нормально.
Она показывает уровень читателей. ;) В статье кодировка нормальная. А код репозитория предназначен для конкретной среды разработки и нечего ожидать, что github сумеет верно всё отобразить. Кстати, вот и напишите авторам github, что их сайт не умеет верно определять кодировку — это неуважение к пользователям. Visual Studio почему-то умеет, а github нет. ;)
HardWrMan
Ну вот, опять. Нужен мой исходник? Откроете его в том IDE, которым я и пользуюсь (хотя я не назову вам его). Ну или сами сконвертируете в удобную для вас кодировку. Автор не виноват, автор так видит.
Ну да, VS ведь работает только под Windows и для русскоговорящего сегмента использует строго cp. А то, что есть люди, работающие на других системах ему не важно. И гит тут ни причём — он RAW отдаёт как есть, а в как есть как раз cp. Тогда, по моему мнению, просто сразу бы следовало хотя-бы назвать те IDE, которыми эти исходники создавались и этой ветки с кодировкой вообще бы не появилось, верно? Но нет, зачем тратить своё время на это, пусть другие тратят своё, если им так надо. А если не справятся, то это всего лишь показывает их уровень.
Считаю бессмысленным дальнейшее поддержание этой ветки про кодировки. В любом случае, я напомню, что считаю статью интересной, но следует всё-же внести некоторые апдейты, которые сразу снимут кучу возникших вопросов. Удачи и не болейте.
da-nie Автор
Сдаётся мне, некоторые читатели опустились настолько, что даже простейших действий сделать не желают, но зато очень хотят, чтобы всё положили в рот и пожевали за них. Уж кодировку-то под себя не уметь настроить — это что-то. И не надо про RAW в Git — он web-страницу формирует? Вот пусть и определяет кодировку и выставляет её правильно. А то ему можно и это не неуважение, а фича, а мне оставить как есть нельзя — это почему-то неуважение. Считайте, что у меня тоже RAW. :)
А вообще, странно, как у вас вообще получается без проблем сборка проектов с исходников с git'а? В системе вообще может не быть половины библиотек — что ж за это автору пенять?
Ну, это с самого начала так.
HardWrMan
Сомнение присутствует у меня. Пользовались ли вы RAW в гите? Вот, например, RAW на файл из вашего репозитория:
raw.githubusercontent.com/da-nie/STM32F407_3D/master/Src/main.c
Это прямая ссылка и файл отдаётся в исходном виде текущей версии, гиту нельзя туда что-либо втыкать. Как и, впрочем, в web предпросмотре.
da-nie Автор
Да вот же с чего началось:
А вот тут он может переключить кодировку сам.
Ну а коли вы именно файл в браузере открыли, то какие вообще претензии могут быть? Тут уж браузер виноват, что не распознал. :)
HardWrMan
Ну, начнём с того, что в браузере открывал не я, и жаловался на это не я. Просто я обратил внимание, что в гите оно хранится в конкретной кодировке, т.к. гит не имеет права что-либо менять в файлах. Т.е., в какой кодировке выгрузите в той и будут.
А сыр-бор произошел из-за того, что люди не обязаны устанавливать вашу IDE и импортировать туда ваш проект чтобы просто быстро посмотреть что к чему. И браузера, как раз, тут предостаточно. И тут никто не виноват. Это другого уровня социальная проблема.
И лично мне не трудно руками переключить кодировку при просмотре исходников не в уникоде, всё равно я только часть кода копирую прямо из браузера, если меня что-то заинтересует.
da-nie Автор
Сыр-бор произошёл из-за уверенности некоторых читателей, что им должны обеспечить что-то плюс просмотр в нативном виде в их ОС и их браузере. Странно, что ещё никто компилируемость в конкретном компиляторе на ОС любой версии не потребовал.
Gordon01
А вы для кого эту статью написали? Какой в ней смысл, если часть материала читателям недоступны?
Зачем вы потратили свою жизнь на бесполезную работу и продолжаете ее тратить в тщетных попытках оправдать свою позицию?
А где здесь смеяться? Это стандартное современное требование, компилировать сишные исходники хотя бы gcc и clang. Clang нормально собирает ваши исходники?
da-nie Автор
Не читателям, а некоторым читателям. И речь не о статье, а об исходниках в конкретно моём репозитории. Но если у конкретного читателя возникают проблемы с кодировкой, так может, ему рано вообще с исходниками связываться?
А хорошие у вас аппетиты. ;)
Gordon01
В Visual Studio это делается вот так:
Ваши комментарии не видно на гитхабе
da-nie Автор
А это какая студия? У меня 2010.
Gordon01
Мои соболезнования, бумер ©
siryoshka
мне радует, всё понятно и без лишних циклов, как я сам называю переходы в стек
COKPOWEHEU
Похоже на то, что я делал когда-то. Только у меня контроллер stm32f103
da-nie Автор
Интересно! А как вам памяти хватило на 103-ем для буфера экрана? Или вы сразу же рисуете без буферизации?
COKPOWEHEU
Буферизации хватило на один столбец (передний + задний буферы) плюс Z-буфер. Плюс «полуфабрикатные» координаты всех примитивов.
Исходный код там есть. Или считаете, что достойно полноценной статьи?
axe_chita
Не знаю как другие, но я за статью! Желательно с разбором «полетов» ;)
da-nie Автор
Конечно! :)
Inobelar
Олдскулы свело — у вас модельки из Gothic! :)
sami777
В кайле с кодировкой всегда были проблемы. Я по этой причине старался в нем делать коменты на инглише.
da-nie Автор
Проблема в том, что, видимо, большая часть придравшихся к кодировке никогда в Keil не работали и не понимают, что файлы переносятся с Keil в Visual Studio, в другие среды и обратно.
HardWrMan
А почему все должны пользоваться именно Keil'ом? Звучит как довод «не пробовал, значит не имеешь права обсуждать». Мир не ограничен только Keil.
da-nie Автор
Ну а зачем нам себя вообще ограничивать IBM PC? :) А вдруг я на ZX-Spectrum в HiSoft-C текст открыть захочу — там вообще на всё 96 символов в таблице и русских букв нет, зато есть признанные замены ряда символов при русификации. А тут никакой совместимости с ними в ZX! Бардак! Срамота! :)
HardWrMan
Ну вот, понимаете же абсурдность своих доводов, но продолжаете пользоваться. Поделитесь мотивами?
Просто я действительно Кеил видел только на скриншотах. Как-то сразу в Эклипс влился, хотя многих он пугает только самой настройкой, кодировки при этом вообще детские шалости. И конкретно там с кодировками проблем нет вообще. И рассчитан он не только на Windows.
da-nie Автор
Абсурдность тут желать, чтобы у всех всё работало в любых средах и условиях. Вы же не ждёте, что программы от MacOS работают в Windows?
HardWrMan
Del
DX168B
Интересно, что можно было бы выжать с платы STM32F429-Disco, на борту которой более мощный камень, внешняя оперативка на 8МБ, контроллер дисплея, буфер которого можно разместить во внешней ОЗУ и модуль DMA2D для некоторого ускорения графики.
da-nie Автор
Ну что ж, исходник библиотеки есть, осталось найти энтузиаста, который всё это сделает. :) Думаю, можно получить интересную игрушку. :)
screwer
Текстурирование простое аффинное или перспективно — скорректированное ?
da-nie Автор
Там каждые 16 точек вычисляется точное значение текстуры с учётом перспективы, а в промежутке линейная интерполяция по экрану.
quwy
Зачем эти полумеры? Когда DOOM будет?
da-nie Автор
Doom не требует истинной 3D-графики. Текстурирование именно горизонталей и вертикалей делается более быстрым способом. А эта библиотека позволяет выводить истинное 3D со всеми обработками.
Однако, Doom я теоретически могу запустить на этом stm — у меня есть такой собственный проект 18 летней давности. Вот он. Однако, он под MS-DOS с жёсткой привязкой к аппаратуре. И — что гораздо хуже — там код мне не нравится совершенно (не удивительно, я тогда едва с Си познакомился — так и писал). Я периодически пытаюсь взяться за переделку, но терпения не хватает сделать всё сразу, а через некоторое время после перерыва я начинаю забывать о новых созданных при рефакторинге абстракциях и продолжать переделку дальше не хочется. :)
quwy
Мой вопрос не по сабжевой библиотеке, он более общий. Сейчас модно запускать Doom на старых фотоаппаратах, экранах принтеров, инженерных калькуляторах, электронных книгах, на всем, что имеет CPU и экран, короче. Производительность ARM-ядра с частотой около сотни МГц должно быть достаточно.
da-nie Автор
Памяти очень мало у stm32. Вот если внешнюю подключать, тогда хватит.