Одно из немногих увлечений, от которых еще не тошнит — программирование.
И далее будут размышления о личном прогрессе.
1. Язык Си — почти идеальный медианный инструмент на годы вперед. Максимальный охват задач: от расчетных или распределенных задач до графического фронта, от десктопа до микроконтроллеров.
2. Оптимальный проект, в котором еще способен разобраться = Минимальное месиво + минимальный оверхед.
Сделал выбор в пользу Freeglut, с помощью которого тестировал функции OpenGL. Отличный инструментарий для меня как нуба. Но: OpenGL (при установленных драйверах Nvidia) тутже включает аппаратное ускорение. Попробовал софтверный рендер mesa3d: получается llvm-реализация, ни в какую не работает embree-версия. Самому пересобирать mesa3d — не справлюсь. И вдобавок, ИМХО, любой и каждый софтварный продукт от Интела — переполненый мусором шлак, требующий полной переработки в простые открытые Си-библиотеки.
3. Реализация OpenGL требует UI-слоя, то есть либо самому писать логику UI, либо еще один оверхед. От идеального UI-слоя нужно не так уж много: буффер, шрифт, прямоугольник. То есть «редактируемая таблица». «Идеальный UI» — это по смыслу, Excel.
4. CPU в том или ином виде, никуда не уйдет. И грузить его (для десктопных приложений) имеет смысл по максмиму. Подробно личные предпочтения рассматривал в очерке «ХардКот №1, отчет за 2020».
Таким неспешным макаром пришел к Win32 Api, ибо в нем:
— Есть простой модифицируемый UI-слой,
— Есть GDI как софтварный рендер, и даже если BitBlt использует GPU, возможно написать собственный Blt.
— Все еще возможно использовать Си.
— Вероятность перехода с Windows на *nix ОС около 1%.
Для текущего уровня личных знаний и умений в программировании, комбинацию десктоп + win32 api считаю оптимальной. И далее будет «вопреки».
Ценник за возможности Win32 Api — лютое месиво процедур, функций, итераций, выборов, кейсов, свитчей. Слой win32 становится скелетом приложения, все что придумает программист — мясом. Портирование с Windows усложняется с каждым использованием api функции. Ну допустим, минимальный WinMain (первый си файл). В него включаю все Win32 Api функции в первом заголовочном файле. Выделяю память, создаю буффер, отрисовываю. Далее, работа в буфере на прототипе собственного «движитель» (второй заголовочный файл), линии Брезенхама и далее. Загрузка файлов — через слой win32. Обработка файлов через слой «движитель».
Тут возникает спагетти: в слой win32 нужно отдавать готовый буффер. Из слоя win32 нужно получать параметры, размеры буффера или значения UI. То есть требуется третий заголовочный файл с функциями win32 + слой «движитель». Либо в основном си-файл с WinMain есть 2 функции, у которых есть доступ к структурам обоих слоев и которые могут микшировать (перекидывать) значения между слоями. Возможно, ИМХО, это будет наиболее чистое проектное решение.
Постепенный отказ от Api функций — сомнительное занятие: GDI все равно останется, переписывание Api функций — пересобранный велосипед, при том что win32 даже с таким оверхедом — очень шустрый Api (если сравнить с оверхедом, например, Nuklear GDI).
Еще возможен вариант отдельного расчетного модуля, без GUI (чистый backend), к которому по необходимости (или по свитчам) идет фронт. Только это потребует скриптования входящих файлов и параметров.
Пока не тошнит — продолжаю изучение.
