"То что в ООП было Релизно, в ECS еще Дебаг"
Решил вечерком потыкать злополучный ECS и что могу сказать... мне нравится. Нет, мне правда нравится
Даже не то скорость, а само... ощущение. Ощущение снова чувствовать железо. Обычно я убегалв эскапизм тыкать AVR, ибо я любил ее из-за непередаваемого ощущения железа в руках
А сейчас... потыкав ECS, я испытал это же чувство! Когда нет виртуальных таблиц, лишних прыжков, аллокаций. Каждый байт жестко контролируешь именно ты. И это.... прекрасно
Кстати когда впервые запускал ECS то вспомнился клип: Can You Hear The Speed
Решил вечерком потыкать злополучный ECS и что могу сказать... мне нравится. Нет, мне правда нравится
Даже не то скорость, а само... ощущение. Ощущение снова чувствовать железо. Обычно я убегал
А сейчас... потыкав ECS, я испытал это же чувство! Когда нет виртуальных таблиц, лишних прыжков, аллокаций. Каждый байт жестко контролируешь именно ты. И это.... прекрасно
Кстати когда впервые запускал ECS то вспомнился клип: Can You Hear The Speed
❤1💯1
Епрст. Пока писал компилятор, буквально ОСОЗНАЛ одну историческую штуку из C
В общем, помните из C этот странный синтаксис?
Но почему в скобках в foo мы пишем (void)?
Конечно, официально говорят, чтобы функция принимала 0 аргументов
Но пока писал однопроходный компилятор, заметил 1 штуку: Вот читаю я посимвольно... Увидел foo, увидел скобку, как мне понять что функция объявляется или вызывается, не заглядывая в аргументы? (так как компилятор однопроходный)
Правильно: Проверить после скобки, что там? Если
Но что если.... у меня 0 аргументов? Если у меня
В общем, ясно одно: Если тебе кажется что в C эта вещь бесполезна, значит ты не понимаешь зачем эта вещь вообще нужна
В общем, помните из C этот странный синтаксис?
void foo(void) {
// ....
}
foo();Но почему в скобках в foo мы пишем (void)?
Конечно, официально говорят, чтобы функция принимала 0 аргументов
Но пока писал однопроходный компилятор, заметил 1 штуку: Вот читаю я посимвольно... Увидел foo, увидел скобку, как мне понять что функция объявляется или вызывается, не заглядывая в аргументы? (так как компилятор однопроходный)
Правильно: Проверить после скобки, что там? Если
int - значит дальше мы встретим переменные, значит, объявляем функцию. А если не так - (если просто переменная или число) - вызываем эту функциюНо что если.... у меня 0 аргументов? Если у меня
()? Как мне понять где объявление, а где вызов? Ха, правильно - поставить (void)!В общем, ясно одно: Если тебе кажется что в C эта вещь бесполезна, значит ты не понимаешь зачем эта вещь вообще нужна
❤1💯1
𝐑𝐨𝐨𝐭𝐓𝐨𝐨𝐥 𝐁𝐥𝐨𝐠
Почему в час ночи вместо работы в UE я должен разбираться почему он падает нафиг И сюрприз сюрприз - падает из-за Race Condition в сборщике мусора (на скрине FGCReferenceTokenStream и UGCObjectReferencer) Когда объект еще не успел удалиться и сборщик мусора…
Помните как у меня слетал GC Анрила из-за поломки vtable?
Так вот. Нашел я решение. почти...
Хорошие новости: Я смог увеличить время срабатывания GC до космических цифр, и теперь ближайшие 272 млрд лет он меня не потревожит
Плохие новости: Теперь память НЕ будет очищаться. И раз в час (наверное) у меня Анрил просто тупо будет лагать и вылетать из-за нехватки память
То есть буквально движок будет ходить под себя и захлебывается в собственным же дерьме
Лучший просто, братец Тим Суини, продолжай!
Так вот. Нашел я решение. почти...
Хорошие новости: Я смог увеличить время срабатывания GC до космических цифр, и теперь ближайшие 272 млрд лет он меня не потревожит
Плохие новости: Теперь память НЕ будет очищаться. И раз в час (наверное) у меня Анрил просто тупо будет лагать и вылетать из-за нехватки память
Лучший просто, братец Тим Суини, продолжай!
❤2🤣2❤🔥1👍1😁1👀1
void Subleq(int* Memory)
{
int PC = 0; // Program Counter
while(PC >= 0)
{
const int A = Memory[PC + 0];
const int B = Memory[PC + 1];
const int C = Memory[PC + 2];
memory[B] -= Memory[A];
if(Memory[B] <= 0) PC = C;
else PC += 3;
}
}
👀2
Нет, мне определенно надо ехать в казино
Чтобы вы понимали: Шанс поймать ICE (Internal Compiler Error) обычному рядовому программисту - менее 0.01%
Для embedded - уже чуть выше, но в пределах 1-2%
А я уже как второй день словил АЖ 2 ICE В ОДНОМ ПРОЕКТЕ СУКА
2 раза ломать компилятор от своего же кода - это определенно талант
Чтобы вы понимали: Шанс поймать ICE (Internal Compiler Error) обычному рядовому программисту - менее 0.01%
Для embedded - уже чуть выше, но в пределах 1-2%
А я уже как второй день словил АЖ 2 ICE В ОДНОМ ПРОЕКТЕ СУКА
2 раза ломать компилятор от своего же кода - это определенно талант
❤🔥5👻1
В общем, что-то лежал, рефлексировал, и подумал
А ведь действительно произошло то, что говорят "всё новое - хорошо забытое старое"
Вспомнил про новую технологию из UE5 под названием Nanite - когда мы берем меш, разбиваем его на кластеры по 64-128 полигонам, и нумеруем их по ID
А дальше просто из камеры, по каждому пикселю, пускаем луч. И если тот попал в полигон - записываем в специальный буфер (VisBuffer) ID Меша, Кластера и Полигона (а затем на втором рендер-пассе раскрашиваем/растеризуем их, но не суть)
К чему все это? Так к тому, что эти последовательные 2 шага.... Чертовски напоминают мне Wolfenstein 3D аж из 1992 года!
Ведь вспомните - тогда математика на процессорах была чертовски дорога. Проходиться циклом по каждой стенке/псевдо-полигону, проецировать его точки, считать матрицы, а потом еще закрашивать - непозволительная роскошь...
И тогда молодой Кармак придумал - а что если просто пускать луч из камеры, находить стену, расстояние до нее, и сразу же красить? Так и родился легендарный метод под названием "Рейкастинг"!
И в чем моя мысль: Если так посудить... Nanite - это идеальное продолжение идеи Кармака, возведенная в абсолют!
Вместо 2д лучей - 3д. А вместо прямого "сделал пересечение - покрасил" у нас сначала запоминание пересечений во временный буфер (VisBuffer), а уже затем - покраска по этому буферу
всё новое - хорошо забытое староe ;P
А ведь действительно произошло то, что говорят "всё новое - хорошо забытое старое"
Вспомнил про новую технологию из UE5 под названием Nanite - когда мы берем меш, разбиваем его на кластеры по 64-128 полигонам, и нумеруем их по ID
А дальше просто из камеры, по каждому пикселю, пускаем луч. И если тот попал в полигон - записываем в специальный буфер (VisBuffer) ID Меша, Кластера и Полигона (а затем на втором рендер-пассе раскрашиваем/растеризуем их, но не суть)
К чему все это? Так к тому, что эти последовательные 2 шага.... Чертовски напоминают мне Wolfenstein 3D аж из 1992 года!
Ведь вспомните - тогда математика на процессорах была чертовски дорога. Проходиться циклом по каждой стенке/псевдо-полигону, проецировать его точки, считать матрицы, а потом еще закрашивать - непозволительная роскошь...
И тогда молодой Кармак придумал - а что если просто пускать луч из камеры, находить стену, расстояние до нее, и сразу же красить? Так и родился легендарный метод под названием "Рейкастинг"!
И в чем моя мысль: Если так посудить... Nanite - это идеальное продолжение идеи Кармака, возведенная в абсолют!
Вместо 2д лучей - 3д. А вместо прямого "сделал пересечение - покрасил" у нас сначала запоминание пересечений во временный буфер (VisBuffer), а уже затем - покраска по этому буферу
всё новое - хорошо забытое староe ;P
❤🔥4👀1
80286 в Unreal Engine
АААХ ЗЛА НЕ ХВАТАЕТ... UNREAL ENGINE...
Для контекста: В мультиплеерной архитектуре GameState - хранит состояние игры (напр. время матча), а PlayerState - состояние игрока (напр. его здоровье)
Так вот, при переходе между уровнями, Анрил имеет возможность "перенести" данные у PlayerState между уровнями
А вот GameState сука!... нет
И знаете как выкручиваться? Ага, брать заводить в GameInstance (экземпляр игры) временные переменные, копировать туда, а после - восстанавливать их обратно..
И знаете что это мне напоминает?
Гребанный 80286!
Когда инженеры Intel добавили защищенный режим (пра-пра-дед многозадачности), ОС могла зайти туда.... Но не могла выйти! И что сделали программисты MS-DOS?
Использовали энергонезависимую память ПК (CMOS, от Биоса) чтобы записать туда "текущую задачу", затем через PS/2 порта клавиатуры отправил сигнал на перезагрузку. Процессор перезагружался, и из CMOS памяти подтягивал данные обратно!
Конечно, я люблю когда история повторяется, но черт побери...
АААХ ЗЛА НЕ ХВАТАЕТ... UNREAL ENGINE...
Для контекста: В мультиплеерной архитектуре GameState - хранит состояние игры (напр. время матча), а PlayerState - состояние игрока (напр. его здоровье)
Так вот, при переходе между уровнями, Анрил имеет возможность "перенести" данные у PlayerState между уровнями
А вот GameState сука!... нет
И знаете как выкручиваться? Ага, брать заводить в GameInstance (экземпляр игры) временные переменные, копировать туда, а после - восстанавливать их обратно..
И знаете что это мне напоминает?
Гребанный 80286!
Когда инженеры Intel добавили защищенный режим (пра-пра-дед многозадачности), ОС могла зайти туда.... Но не могла выйти! И что сделали программисты MS-DOS?
Использовали энергонезависимую память ПК (CMOS, от Биоса) чтобы записать туда "текущую задачу", затем через PS/2 порта клавиатуры отправил сигнал на перезагрузку. Процессор перезагружался, и из CMOS памяти подтягивал данные обратно!
Конечно, я люблю когда история повторяется, но черт побери...
💯3❤1
Yo, гайс
https://ascii-city-p1-k7m4k5.grownowgames.workers.dev
Не благодарите )
(но автора поддержите!)
Не благодарите )
(но автора поддержите!)
❤4🔥1🙏1
Знаете, я так подумал
А ведь для ARG с какими-нибудь экзешниками, лучше всего прятать секреты не в коде.... а прямо в заглушку DOS!
Исторически для обратной совместимости (когда был переход между 16- и 32- битными системами) в начале любого .exe или .dll файла пишут небольшой код, с тексом "This program cannot be run in DOS mode."
Что он делает? Вызывает консоль, печатает туда текст, и останавливает программу (так как она для 32 битных систем)
Сейчас конечно это исторический костыль..... но для ARG - самый раз ))
Пока все пойдут через Ghidra читать .data и .text участки, секрет будет лежать в начале файла...
Буквально лучший способ спрятать код - оставить его на самом видном месте :P
А ведь для ARG с какими-нибудь экзешниками, лучше всего прятать секреты не в коде.... а прямо в заглушку DOS!
Исторически для обратной совместимости (когда был переход между 16- и 32- битными системами) в начале любого .exe или .dll файла пишут небольшой код, с тексом "This program cannot be run in DOS mode."
Что он делает? Вызывает консоль, печатает туда текст, и останавливает программу (так как она для 32 битных систем)
Сейчас конечно это исторический костыль..... но для ARG - самый раз ))
Пока все пойдут через Ghidra читать .data и .text участки, секрет будет лежать в начале файла...
Буквально лучший способ спрятать код - оставить его на самом видном месте :P
❤2💯1