Я сейчас подумал насчёт случайных чисел, вместо слова ключа. Думаю, что здесь тоже есть свои минусы. Если в ключе будет число, которое меньше 0x20, то оно раскрывает почти полностью старший полубайт текста, ну или если символ будет больше 0x7f, будет 0x8X, то будет видно, что там есть число больше, чем ascii, так как 0x80 не будет ксорится. Но наверное сложность есть в символе ключа, который меньше, чем 0x20, надо сделать такую задачку себе.
Мне ИИ не нужна в таком случае, так как у меня есть для этого написанная программа, которая делает тоже самое. Расстояние хэмминга ещё не знаю что такое, позже почитаю про это.
Ну вот. Я наслаждался победой, что смог решить такую задачку, пускай она и простая для криптографов. Вы немного нагрузили меня новыми задачками, о которых я ещё не думал. Я на эту, на анализ, потратил несколько часов с ночи до утра. Теперь удовольствие сменилось на усталость.
Я о том, что кодировки как я правильно понимаю, такие как CP866, KOI8-R и возможно CP1251 основываются на том, что русская буква занимает один байт. Про CP1251 не уверен, а вот в CP866 и KOI8-R я уверен, что там один байт разделен на русскую и английскую разметку. Тогда не остается места для арта, который используется в этих модных BBS.
Я думаю, что можно сделать многобайтовый арт для терминала, если взять за основу UTF-8 и некоторые байты для расширения. Если мы зайдем через telnet обычный терминал, то получим латинские буквы, а не английские, ну там, где должен быть арт.
Насчёт сайта, это я вдохновился BBS и написал под влиянием этого драйва.
Не дочитал, потом дочитаю. Вот это кстати интересно. Кто же там сидит в этих BBS? Жаль, что такое возможно только для английского языка как я понимаю, ведь в UTF-8 есть биты, которые указывают на длину символа в байтах. Хотя если их не учитывать в разработке BBS, то можно сделать свой вариант. Как думаете, почему они не используют сайты? BBS похоже на место для избранных, куда не каждый сунется, да и не знал о том, что BBS ещё существует.
Спасибо за статью, интересно сделано у них, надо подумать как сделать свой сайт получше. :)
Да, если цель другая, то и метод другой понадобиться. У меня в игре всё же в помещении дело происходит и нужно устанавливать в каждой комнате освещение. Световых источников может быть до 20 кажется. Объекты отбрасывающие тень запекаются. Только пока отбрасывание тени у меня не реализовано.
Извините, я не понял вопрос. Объясню немного сначала. Есть оригинальная текстура. Её мы используем для совмещения со светом. Она же и рисуется в другой фреймбуфер. Потом берём эту текстуру и сохраняем в текстуру под другим id и вот эту текстуру, которую мы сохранили, теперь рисуем без просчета каждый раз света и не обращая внимания на нормали.
Таким образом в игре я могу динамически размещать свет в разных местах кофейни и когда поставлю новый свет, то только в этот момент произойдет просчет света. Запекуться текстуры с новыми данными и теперь будет запечённая текстура, которую опять можно рисовать без просчета света.
Так можно и с тенями работать думаю. Один раз прорисовать динамически тени, а потом рисуешь новую текстуру с тенью.
Это позволяет строить домик с освещением (якобы) и наслаждаться картинкой даже на встроенной карте (думаю).
Да и я осветил эту тему, потому что сначала не понимал как это сделать. Самое интересное, что про это никто почти не пишет и я не догадывался насколько это просто в реализации, пока не додумался до этого варианта. Код квейка не изучал и поэтому не знал об этом.
Ладно, спасибо за общение.
Я посмотрел в книге learnopengl по теме lightmap и обнаружил, что lightmap имеется ввиду, когда несколько разных материалов в одной текстуре, а у меня не это. У меня запекание baking texture. Или я опять неправильно понял? Просто в моём варианте можно один раз запечь со светом текстуры и потом без света рисовать текстуры как будто текстура со светом.
Возможно вы ошиблись с терминологией или я просто не понимаю что такое настоящее lightmap. Но вот описание lightmap.
Спасибо. Как ходить по террейну пока не думал. Пока игру делаю симулятор кофейни и там управляешь камерой с видом сверху. Потом когда потребуется ходить по террейну, буду думать и искать методы.
Я работаю над продуктом мечты. Всё-равно, велосипед ли изобретаю или нет. Все мы поначалу, когда обучаемся чему-то, изобретаем то, что уже изучено. Так я обучаюсь математике, которая изучена, делаю движок, который уже кем-то тоже сделан. Это нормально.
О, классно. Когда луч бросается в центр экрана то да, ваш способ ещё быстрее. Я же отрабатывал способ, чтобы можно было кликать на любую область экрана как в стратегиях. Но кстати, вы подали мне идею. Можно в движке сделать функцию, которая будет действительно работать только для центра экрана. Отличная идея, спасибо. Но кстати, если стрельба будет трясти прицел, то тогда подойдет мой способ, а если прицел остается на месте, то ваш в самый раз. Надо добавить в движок такой функционал.
Я обновил туториал. Показал на примере, что мой способ без умножения обратных матриц тоже работает на примере пересечения aabb
Мне всё-таки кажется, что мой способ несколько быстрее будет, чем использовать обратные матрицы, ведь там больше перемножений нужно делать, плюс ещё обратные матрицы найти.
Как в шейдере кстати пускать луч я не знаю или не совсем понимаю что вы имеете ввиду, так как у меня сам луч рисуется в шейдере, но вычисляется начальная точка и конечная на CPU. Без матриц.
Очень понравилась статья. Даже подумываю что бы такое на ассемблере пописать.
Я сейчас подумал насчёт случайных чисел, вместо слова ключа. Думаю, что здесь тоже есть свои минусы. Если в ключе будет число, которое меньше 0x20, то оно раскрывает почти полностью старший полубайт текста, ну или если символ будет больше 0x7f, будет 0x8X, то будет видно, что там есть число больше, чем ascii, так как 0x80 не будет ксорится. Но наверное сложность есть в символе ключа, который меньше, чем 0x20, надо сделать такую задачку себе.
Мне ИИ не нужна в таком случае, так как у меня есть для этого написанная программа, которая делает тоже самое. Расстояние хэмминга ещё не знаю что такое, позже почитаю про это.
Ну вот. Я наслаждался победой, что смог решить такую задачку, пускай она и простая для криптографов. Вы немного нагрузили меня новыми задачками, о которых я ещё не думал. Я на эту, на анализ, потратил несколько часов с ночи до утра. Теперь удовольствие сменилось на усталость.
Я о том, что кодировки как я правильно понимаю, такие как CP866, KOI8-R и возможно CP1251 основываются на том, что русская буква занимает один байт. Про CP1251 не уверен, а вот в CP866 и KOI8-R я уверен, что там один байт разделен на русскую и английскую разметку. Тогда не остается места для арта, который используется в этих модных BBS.
Я думаю, что можно сделать многобайтовый арт для терминала, если взять за основу UTF-8 и некоторые байты для расширения. Если мы зайдем через telnet обычный терминал, то получим латинские буквы, а не английские, ну там, где должен быть арт.
Насчёт сайта, это я вдохновился BBS и написал под влиянием этого драйва.
Запускай.
Не дочитал, потом дочитаю. Вот это кстати интересно. Кто же там сидит в этих BBS? Жаль, что такое возможно только для английского языка как я понимаю, ведь в UTF-8 есть биты, которые указывают на длину символа в байтах. Хотя если их не учитывать в разработке BBS, то можно сделать свой вариант. Как думаете, почему они не используют сайты? BBS похоже на место для избранных, куда не каждый сунется, да и не знал о том, что BBS ещё существует.
Спасибо за статью, интересно сделано у них, надо подумать как сделать свой сайт получше. :)
Можете пожалуйста перезалить на российский видео хостинг, чтобы можно было посмотреть документалку?
Да, если цель другая, то и метод другой понадобиться. У меня в игре всё же в помещении дело происходит и нужно устанавливать в каждой комнате освещение. Световых источников может быть до 20 кажется. Объекты отбрасывающие тень запекаются. Только пока отбрасывание тени у меня не реализовано.
Только пока каждая стеночка и пол отдельные. Но я написал в конце туториала, что буду менять на обычный большой по площади пол.
Да, дифуз со светом.
Извините, я не понял вопрос. Объясню немного сначала. Есть оригинальная текстура. Её мы используем для совмещения со светом. Она же и рисуется в другой фреймбуфер. Потом берём эту текстуру и сохраняем в текстуру под другим id и вот эту текстуру, которую мы сохранили, теперь рисуем без просчета каждый раз света и не обращая внимания на нормали.
Таким образом в игре я могу динамически размещать свет в разных местах кофейни и когда поставлю новый свет, то только в этот момент произойдет просчет света. Запекуться текстуры с новыми данными и теперь будет запечённая текстура, которую опять можно рисовать без просчета света.
Так можно и с тенями работать думаю. Один раз прорисовать динамически тени, а потом рисуешь новую текстуру с тенью.
Это позволяет строить домик с освещением (якобы) и наслаждаться картинкой даже на встроенной карте (думаю).
Да и я осветил эту тему, потому что сначала не понимал как это сделать. Самое интересное, что про это никто почти не пишет и я не догадывался насколько это просто в реализации, пока не додумался до этого варианта. Код квейка не изучал и поэтому не знал об этом.
Ладно, спасибо за общение.
Я посмотрел в книге learnopengl по теме lightmap и обнаружил, что lightmap имеется ввиду, когда несколько разных материалов в одной текстуре, а у меня не это. У меня запекание baking texture. Или я опять неправильно понял? Просто в моём варианте можно один раз запечь со светом текстуры и потом без света рисовать текстуры как будто текстура со светом.
Возможно вы ошиблись с терминологией или я просто не понимаю что такое настоящее lightmap. Но вот описание lightmap.
Спасибо.
Да за что минусы то? Вы хоть одну статью покажите, где эта тема освещается.
Спасибо. Как ходить по террейну пока не думал. Пока игру делаю симулятор кофейни и там управляешь камерой с видом сверху. Потом когда потребуется ходить по террейну, буду думать и искать методы.
Я работаю над продуктом мечты. Всё-равно, велосипед ли изобретаю или нет. Все мы поначалу, когда обучаемся чему-то, изобретаем то, что уже изучено. Так я обучаюсь математике, которая изучена, делаю движок, который уже кем-то тоже сделан. Это нормально.
О, это классно. В ortho ещё не пробовал.
О, классно. Когда луч бросается в центр экрана то да, ваш способ ещё быстрее. Я же отрабатывал способ, чтобы можно было кликать на любую область экрана как в стратегиях. Но кстати, вы подали мне идею. Можно в движке сделать функцию, которая будет действительно работать только для центра экрана. Отличная идея, спасибо. Но кстати, если стрельба будет трясти прицел, то тогда подойдет мой способ, а если прицел остается на месте, то ваш в самый раз. Надо добавить в движок такой функционал.
Я обновил туториал. Показал на примере, что мой способ без умножения обратных матриц тоже работает на примере пересечения aabb
Мне всё-таки кажется, что мой способ несколько быстрее будет, чем использовать обратные матрицы, ведь там больше перемножений нужно делать, плюс ещё обратные матрицы найти.
Как в шейдере кстати пускать луч я не знаю или не совсем понимаю что вы имеете ввиду, так как у меня сам луч рисуется в шейдере, но вычисляется начальная точка и конечная на CPU. Без матриц.