>>399636
Двачую. Я правда ещё сам вкатун, и у меня обратное поведение. Я всегда с детства бросал кодить на первом же уроке пайтона, потому что я не понимал "а зачем все эти if-else, еще какая то аутическая срань. Возьмите да на языке схем сделайте все что нужно, и понятее и удобнее. Что за глупым каким-то бесполезным вещам нас учат". Учится программированию я начал вовсе не последних курсах унивеситета, когда начались микроконтроллеры, релейные схемы. Вот тогда уже был создан так сказать "лор" компьютерного знания. То есть стало отдаленно понятно, что из себя представляет железо, и как оно должно работать. После чего естественно пошел Паскаль, ассемблер и С.
Так вот, если Паскаль просто был не особо интересен ввиду довольно кривого синтаксиса, ассемблер мне показался довольно бессплодным в плане написания прикладных программ. Ну а С как-то затянул своим подходом. Говорят что в нем нетипичный синтаксис для языков тех лет, а мне он наоборот показался каким то догичным и понятным. Собственно, около года я на этом сраном С прокодил, и понял, что с такими знаниями я никогда в жизни работы не найду. Надо переходить на С++ потом на Python или Java где больше платят. В общем то пока что обучение С++ не задаётся - синтаксис кажется таким тупым и нелогичным, что вот порой думаешь, что кроссворды какие-то решаешь, а не код пишешь. Вроде как классы должны упрощать построение программы, но в итоге по несколько часов чешишь репу как это класс правильно сделать, чтобы не выскочило непредвиденных ошибок. И порой кажется что обычны С куда более предсказуем и понятен, чем С++ со всеми его наворотами.
Ну а Python с его производительностью вообще непонятно как может полноценно использоваться. Ладно если ещё нужно сделать то, для чего и предназначены скрипты: различные парсеры, обработка текста, сортировка, статистика, машинное обучение в конце концов. Но писать " прикладную программу" или игру на python? Зачем? Все ведь явно будет тормозить. У меня сложилось впечатление, что вообще не существует ни одного языка общего назначения помимо С.

>>405027
Могу впринципе иерархию рассказать. В большинстве своём преобладает паттерн "фабрика".

I.НЕЗАВИСИМЫЙ УРОВЕНЬ.
-GRAPH/tgatool.c , можно вообще использовать самостоятельно, без всяких там других модулей. То есть можешь в отдельный каталог откомпилить tgatool и пользоваться им как инструментом для обработки tga картинок. Сам tgatool включён только в render3d, для того чтобы загрузить текстуру, и дальше елозить по ней, просто как по массиву памяти.

- IO/xlib_io.c Тоже можно использовать отдельно. Это просто обётки для стандартных функций xlib. Она описывает два обьекта - контролы, и "окно". Всё просто, окно - это в твоей графической оболочке какая-то область, на которой можно рисовать. КОнтролы - это клаво/мышь.
На окне можно рисовать.
Контролы можно "опрашивать" ожидая изменения состояния. (Точнее, опрашываются не контролы, опрашивается сервер, на наличие изменений, сам "тип" контролы обозначат состояние клавиатуры и мыши, т.е. в нём содержится массив по всем кнопкам и об их состоянии). Тут таже есть макросы типо "нажата ли кнопка".
Зачем эта херота нужна? Очевидно, чтобы инкапсулировать ввод. Теперь достаточно переписать этот модуль под винду, а обёртки функций останётся те же. То есть переписав этот модуль, вся ебучая программа портируется на Windows одним кликом!!! Все остальные модули не используют xlib, они используют только обёртки из этой функции, чтобы быть платформо-независимыми.

- GRAPHIC/algebra.с - тут даже никакого паттерна нет. Это просто чисто немного математических функций. Тут, конечно описан тип "вектор", который представляет собой массив из трёх чисел. Также описаны векторные операции, типо скалярное произведение, векторное произведение. Под вектором подразумевается только трёхмерный вектор. Двухмерных веторов у меня нет, посчитал их бесполезными. Собственно, этот модуль также можно использовать отдельно, он ни с чем не связан. Можно просто взять и начать использовать векторные операции где-то у себя в коде. Также тут реализован Fixed-point типо, т.е. числа с фиксированной точкой. Никакой скорости по сравнению с FPU он не даёт, зато смотри эффект (см скришоты) - типо погрешность, красиво.

II. ЗАВИСИМЫЙ УРОВЕНЬ

- GRAPHIC/wavefront.h - Парсер wavefront obj, 3д моделей. Также, "фабрика", есть тип "3d модель", её можно открыть, удалить, повернуть, передвинуть из неё отдельные точки, распечатать лог о модели, реканкулировать нормали. Для последних функций типо "повернуть" и "реканкултровать нормали" нужны вектора. Поэтому он зависим от модуля algebra.c.

- GRAPHIC/basics.c - тут описаны базовые примитивы для рисования. Как в паскалике на уроке "DrawLine, DrawRectangle". Исключение составляет лишь треугольник, как говорилось, треугольники требуют отработчика. Для тех кто не хочет ебать мозг есть макрос TRIANGLE(w,x1,y1,x2,y2,x3,y3,color) который использует стандартный отработчик default_plot (просто закрасить пикселы указанным цветом, без особенностей).
Данный модуль, к сожалению, зависим от IO/io.h. Ему для вывода необходимы какие-то функции вывода в окно. Я когда только разрабатывал, фантазировал сделать полносью независимый модуль который бы "рисовал ни на чём", а при подкрутке к нему графики рисовал бы графику итд. Но я не додумался как это реализовать и решил просто захардкодить. Кроме того, этот модуль поддерживает fixed-point так что если используются фикседы, то нужно и algebra.c подключеить. Впрочем, по-умолчанию тут на флоатах всё.

- GRAPHIC/render3d.c - Ну и финальный модуль, для его работы необходимо очевидно и algebra, и basics и wavefront_obj, да к тому же и tgatool.c в него включён. Собственно, в модуле описаны такие обьекты как "камера", и методы рендера. Сами модели тут не описаны, так как они уже были описаны в wavefront.
Камеру мы можем создать двух типов: перспективная, и ортогональная. Вроде всё очевидно. Схема работы такая: создаём камеру, инициализируем камеру, загружаем 3d модель, загружаем текстуру (при необходимости). И далее "фотографируем" нашу модель при помощи любой из следующих процедур:
RenderWireframe - отрендерить проволочную модель.
RenderZBuffer - отрендерить отдельно значения буфера глубины для данной модели.
RenderShaded - отреднерить плоско-затенённую фигуру
RenderTextured - отрендерить плоско-затенённую фигуру, со следующей текстурой.
RenderGouraud - отрендерить сглаженную по-Гуро обьект с текстурой.
Солнце тут захардкожено, настраивается макросом SUN, который представляет собой вектор. Т.е. чтобы изменить направление солнца - нужно изменить направление этого вектора.
Падающие тени отсутствуют.

РЕФАКТОРИТЕ!! (если хотите. если не хотите - то и пох)

-

>>409363
>>409395
Размеры полей компилятор не меняет. Но каждое поле выравнивается в памяти на размер этого поля. Т.е. int16_t на 2 байта, int32_t на 4 байта и т.д. Между полями, если это нужно для выравнивания, компилятор оставляет дырки. В конце структуры, если нужно, компилятор тоже добавляет дырок до границы слова.
Размер структуры можно узнать с помощью sizeof.

#include <stdio.h>
#include <stdint.h>
struct
{
int8_t val1;
int16_t val2;
int32_t val3;
int8_t val4;
} my_struct;
int main()
{
printf("%li\n",sizeof(my_struct));

return 0;
}

Для 32-х систем размер структуры будет равен 12 байт (для 64-х битных может добавит ещё дырок до 64-х битного слова, точно не знаю.).
Эта структура будет располагаться в памяти так (дырки обозначаю нулями):
val1 0 val2 val3 val4 0 0 0

Никакого рандома в размещении дырок нет.

Можно сказать компилятору, чтобы он не оставлял дырок в структуре, для каждого компилятора это делается по разному. Для gcc используй __attribute__((__packed__))
Естественно, тогда снизится скорость работы со структурой и нельзя будет использовать указатели на поля структуры, т.к. они не будут выровнены на размер поля.