|
Результаты поиска
| |
| Xakep | Дата: Понедельник, 27 Мая 2019, 17:11 | Сообщение # 61 | Тема: Хакерский движок для линукс |
めちゃくちゃちゃ
Сейчас нет на сайте
| Цитата martuk (  ) Даже на очень отвратительном Английском будет в сто раз лучше, чем на Русском
чем лучше? что разработчики будут писать невнятные комментарии на ломаном английском?
Цитата martuk ( ) Ни разу не аргумент
и почему же - это не аргумент? Если в будущем и сейчас мы не работаем с зарубежными коллегами, а пишем софт, скажем для российской биржи, смысл писать комментарии на английском?
Другое дело, если команда ориентирована на запад, тогда это уже просто необходимость.
|
|
|
| |
| Xakep | Дата: Понедельник, 27 Мая 2019, 15:26 | Сообщение # 62 | Тема: Хакерский движок для линукс |
|
めちゃくちゃちゃ
Сейчас нет на сайте
| Цитата drcrack ( ) игру на с++ под линукс с русскими комментами? нет, не стоит
И почему русские комментарии - это плохо? У нас в компании принято писать комментарии исключительно на русском, коммиты тоже на русском, документацию на русском, а все потому, что у нас все разработчкие - русские, у многих есть проблемы с письменным английским (даже если свободно читают документацию), нанмого проще выражать свои мысли на родном языке и шанс, что комментарий будет адекватный и более детальный намного выше, чем, если бы ты писал на английском.
|
|
|
| |
| Xakep | Дата: Понедельник, 27 Мая 2019, 13:00 | Сообщение # 63 | Тема: Готовы ли вы выложить свой код? |
|
めちゃくちゃちゃ
Сейчас нет на сайте
| Цитата afq ( ) Готовы ли вы выложить код на github, чтобы любой желающий мог понять как ваша игра работает?
Я сейчас не делаю игры конечно, но все свои pet проекты выкладываю на гитхаб.
Цитата afq ( ) Да и как ты без общения с автором разберёшься где что добавлять?
Отладчик, реверс инженеринг
Цитата TimKruz ( ) Мне кажется, нечитабельный код пишут хейтеры begin..end из алгол-подобных языков. Ведь это они жалуются, что вынуждены писать 8 символов вместо двух. Конечно, быстрее набрать цепочку из спецсимволов, чем текст, но о том, как люди будут это читать (машине-то всё равно), никто почему-то не задумывается...
вкусовщина, мне вот например не нравится эти begin и end, болеее удобно пользоваться скобочками.
Цитата TimKruz ( ) Короче, хороший код – это когда ты ткнул пальцем в любую строчку, и уже знаешь, кому она принадлежит, чем занимается и зачем здесь нужна. Но для этого код нужно писать человеческим языком, а не кучей закорючек и спецсимволов. И любой ЯП это позволяет сделать (даже Ассемблер с макросами-вставками).
Ну фиг знает на счет ассемблера, это дикий лоу левел и 10 строк уже могут быть абсолютно не понятными, если писал его не ты, плюс условные и безусловные переходы вместо ветвлений и циклов очень сильно усложняют навигацию по коду (хотя может это и решается с помощью макрасов?).
Цитата TimKruz ( ) И я совершенно не понимаю, почему половина человечества мечтает "общаться с компьютером на человеческом языке", а другая общается с этими компьютерами на максимально нечеловеческих языках, несмотря на возможность так не делать... Можно было бы понять, если эти специальные коды было бы легче воспринимать, чем простой текст, но разве это так? Программирование ни разу не математика, мы оперируем реальными вещами (кроме случаев, когда вычисляется математическая формула, но это всегда делается для чего-то, а не просто так), так не надо втягивать сюда огромные формулы из отдельных символов.
Программирование и математика в том числе, и математика - это не просто набор символов, она тоже может быть красивой и выразительной, так и в программировании существует не одно лишь ООП, но так же и функциональное программирование, реактивное программирование, data orietned programming и каждая решает определенные проблемы, естественно, если ты не знаком с функциональной парадигмой, все что будет написано будет не понятно, хоть как ты обзови переменные (хотя конечно хорошо названные переменные и функции снизят порог), просто нужно учить новый подход. Код должен быть не только красивый и читабельный у него должны быть и другие качества, в том числе поддерживаемость, надежность, корректность, система не длолжна падать от малейшего чиха, и вто же время она должна работать корректно, ну и естественно поддерживаемость кода, я встречал не мало кода, который с виду выглядил чисто, красиво, опрятно, но черт ногу сломит чтобы понять как оно все работает, все раздроблена настолько мелко и не пойми как взаимодействует друг с другом.
Цитата TimKruz ( ) Их много. У Васи один стандарт, у Пети другой. Как им без начальника сработаться? Мы же тут обсуждаем опенсурс, в котором каждый может притащить кусок своего кода в общий проект, и никто никому не обязан. Кроме того, команда команде рознь, команда школьников без опыта работы – тоже "команда".
Обычно для open source добавляется файлик CONTRIBUTING.md, в котором и описываются правила работы с кодом, стиль кода, основные парадигмы итд, да и банально, если ты не будешь соблюдать эти правила, твои изменения просто напросто не примут.
Цитата afq ( ) С чего ты взял, что сможешь разобраться в сложном проекте, если даже в моём не можешь?
Я знаю что смогу, в сложном проекте обычно выдержанный стиль и есть определенная архитектура, и не обязательно вникать в детали всего проекта, можно сосредоточиться на определенных ее частях, я работал и котрибьютил в Intellij IDEA к примеру, у них там просто понятный хороший код, местами конечно сложно понять что к чему. Бывает наобором, большой проект, и там ничего не понятно и ридется весь день просидеть с отладчиком, чтобы понять как хоть маленькая часть работает, код бывает разный, что в большых проектах, что в маленьких и твой критерий оценки - "Если ты не разобрался даже в моем, то ты не сможешь разобраться в крупном проекте" не корректен.
Цитата TimKruz ( ) Эм, где-то вычитал, что по отношению к коду "красиво" = "понятно".
это не всегда так, бывает я знаю как решать сложную задачу, код получается громоздким, все понятно, но его много, и вот в один прекрасный день, ты просто смотришь как ту же самую задачу можно решить на функционально яп и она занимает жалкие 3-4 строчки, ты его можешь не понимать, но тебе это решение по умолчанию может показаться красивым, т.к. та же задача решается намного короче.
Цитата pixeye ( ) Тому кто тебе платит глубоко ***** красивый код или нет
Ну конкретно красивый или нет, действительно пофиг, но некоторым компаниям все же важно, чтобы код был поддерживаемый (а поддерживаемый код не всегда = красивый).
Цитата TimKruz ( ) Но почему-то я догадался, в чём суть процедурного подхода (назвать кусок кода именем, чтобы он был понятен), а большинство считает это чепухой и продолжает нагромождать безымянные горы команд, говоря "так быстрее".
Нужно просто сменить окружение, если находишься в окружении джунов, то чего ты еще ожидаешь от них? Они учаться еще и без должного менторства еще будут долго сами до этого доходить.
Цитата TimKruz ( ) Вот и хочется иметь инструмент, который не имел бы в себе всего этого мусора.
Просто не пользуйся не нужным мусором и пиши в своем стиле, скажем компании Insomniac (которая создала spider man новый) использует С++ и при этом очень сильно ограничивает функционал которым можно пользоваться, они не пользуются динамическим выдилением памяти в куче (у них свои аллокаторы памяти), не используют шаблоны, не используют исключения итд. Зато в C++ очень развитая инфраструктура и можно найти зрелые и хорошо отлаженные библиотеки, которыми можно просто пользоваться, а если не нравится интерфейс и он сильно выбивается из стиля проекта, просто создай свои обертки.
Цитата afq ( ) В си например мало что появляется. Выучил его и знаешь много лет, ничего нового не надо учить, все знания которые есть, их хватает, чтобы писать нормальный код
Ага, знать язык, даже очень хорошо, не достаточно чтобы писать нормальный код, не достаточно, чтобы писать работающий и стабильный код, тем более на Си, где даже на маленьких проектах, можно начать ловить сегфолты и поиметь проблемы с памятью, нужно уметь разрабатывать ПО в принципе, и тогда уже не сильно будет важно, какой яп использовать, ЯП - это просто инструмент.Добавлено (27 Мая 2019, 13:10)
---------------------------------------------
В принципе стремиться писать хороший читабельный код - это хорошо и в этом я полностью солидарен с TimKruz, но также надо понимать, что это не всегда возможно в принципе, бывает сложная предметная область и прятать эту сложность себе дороже, это будет просто заметанием под ковер и не решит проблемы с поддерживанием кода.
|
|
|
| |
| Xakep | Дата: Среда, 15 Мая 2019, 07:18 | Сообщение # 64 | Тема: Записки линуксоеда |
|
めちゃくちゃちゃ
Сейчас нет на сайте
| Цитата afq ( ) Ты попробуй подсунь в линукс вирус?
Ну во первых на линуксе тупо нету почти вирусов потому-что пользователей мало это раз, а два этот не большой процент пользователей зачастую опытные пользователи ОС, если ты хорошо знаешь ОС на которой работаешь ты и никогда не подцепишь ничего будть то линукс или винда.
Цитата TimKruz ( ) UPD: к слову, на том же нетбуке, Ubuntu при загрузке с флешки после первой же попытки открыть настройки ушла в dead freeze (нет, не паника ядра, а именно "мёртвая заморозка") и не смогла разморозиться даже спустя несколько часов. Видимо, 1 ГБ для Ubuntu – смерть, хотя Windows 7 на 1 ГБ вполне юзабельна.
Наверное ты забыл выделить swap, ну и Убунта тот еще кал, у меня девственно чистая убунта только после установки сразу же ошибки начинает выдавать какие-то.
Цитата TimKruz ( ) Потому что он там 100% нормально работает, а на Linux в большинстве случаев часть железа "отваливается", поскольку нет определённых драйверов. Вот даже Windows 10 отказалась ставиться, потому что не смогла найти подходящий драйвер звука...
Вот это правда, но популярное железо всегда работает нормально, я так свой нетбук собираюсь выкидывать, провозился с ним не мало, поставил туда Debian minimal, в общем работает, но проблема со звуковой картой, пришлось блочить драйвера и слушать музыку можно только в наушниках, индикатор батареи не работает. Да и в принципе в 2019м году 2ГБ оперативки это крайне мало (ну разве что пасьянсы раскладывать).
|
|
|
| |
| Xakep | Дата: Четверг, 25 Апреля 2019, 11:11 | Сообщение # 65 | Тема: На этом сайте есть линуксоиды? |
|
めちゃくちゃちゃ
Сейчас нет на сайте
| Цитата drcrack ( ) проблема в том что ты понимаешь как оно работает за пару дней, а потом еще месяц допиливаешь то что делал до более-менее продакшн-реди состояния :D
да, так и есть, но все же, когда нет адекватных альтернатив, очень хорошо, что разработчик может просто сделать свое решение и не сесть в лужу, в индустрии много людей, которые только ферймворк выучили и больше ничего не умеют делать.
Цитата drcrack ( ) у меня вот за пару лет инди дева появился навык коммитить с помощью макроса git add * && git commit -a -m "1" && git push
ну за коммит с содержанием "1" тебе руки поотрывают  лично я пользуюсь IDEA и через нее же коммичу через хоткеи.
|
|
|
| |
| Xakep | Дата: Четверг, 25 Апреля 2019, 10:46 | Сообщение # 66 | Тема: На этом сайте есть линуксоиды? |
|
めちゃくちゃちゃ
Сейчас нет на сайте
| Цитата drcrack ( ) но я ведь этого не говорил  где у меня написано что "с++ никто не пользуется"?
да точно, не говорил, почему-то казалось что говорил.
Цитата drcrack ( ) основная проблема с++ в том что разработка на нем на 50% дольше и дороже (чем на java/c#), что особенно критично для маленьких инди проектов
Далеко не факт, опытнай C++ разработчик сможет написать с такой же скоростью как и java/c# разработчик, другое дело что эти языки более дружелюбные к новичкам чем C++.
Цитата drcrack ( ) ничего личного, но тс — идеальный пример: его прогресс за 2 года напоминает первые главы учебника по opengl, а делал бы на юнити — уже бы пару игр зарелизил
Согласен с этим, сам с этим сталкивался в свое время, сейчас оглядываясь в прошлое думаю, что лучше бы игры делал на какомнить Unity, чем свои велосипеды изобретал, но и в велосипедостроительстве есть некоторые плюсы - начинаешь понимать как оно все работает и учишься решать очень сложные задачки и в будущем этот навык очень выручает уже в реальной разработке в какойнить компании.
|
|
|
| |
| Xakep | Дата: Четверг, 25 Апреля 2019, 04:22 | Сообщение # 67 | Тема: На этом сайте есть линуксоиды? |
|
めちゃくちゃちゃ
Сейчас нет на сайте
| Цитата на чистом — это когда ты в студии создаешь новый пустой проект и начинаешь писать все с нуля, от импорта fbx до пост процессинга
Что за бред, к таком контексте ни на одном яп не возможно будет писать, так вообще хоть где-то и хоть на каком-то языку программировантя делается? скажи еще что я должен свой рантайм писать и свою стандартную библиотеку писать.
Цитата drcrack ( ) ты упорно игнорируешь слово "чистый"
На "чистом", обычно подразумевает, что я использую только C++ для реализации, это не значит, что я не могу использоть библиотеки, написанные другими разработчиками.
Цитата c# и unity растут и решают свои проблемы, каждый год выходит что-то новое
C# решает проблемы которых никогда в C/C++ и не было. Если на C# выходит много всего нового - это не значит что язык лучше, это значит, что язык пользуется большой популярностью, и часто среди этого нового выходит бесполезный мусор.
Цитата drcrack ( ) https://blogs.unity3d.com/ru....lection
Ну вот хороший пример, решают проблемы дизайна языка, в C++ такой проблемы по факту возниктуь не может, т.к. там нету сборщика мусора. Это здорово что идет какое-то развитие GC, но сам движок написан по идеологии C# и ООП, а это уже считай тормоза. Лучше посмотри что Майк Актон делает сейчас в Unity, вот он по нормальному решает проблему C#
Собственно благодаря ему и Андерсону Фредериксону и принципиально отличной архитектуре стало возможным подобная производительность
Цитата а с++ как будто застрял в 80х, все последние релизы на 90% состоят из фич которые только позволяют сделать шаблоны еще запутаннее
C++ та еще какашка, но говорить что C++ никто не пользуется - это как минимум не корректно, многие студии продолжают его использовать из-за бескомпромиссной производительности. И не стоит одним геймдевом ограничиваться, почему же различные аудио и видео кодеки на C# тогда не пишут, если он такой супер быстры? У нас коллеги по работе используют C++ в аукционе, потому-что там каждая доля секунды может стоить кучи денег.
Цитата afq ( ) Xakep, много перечислять не стану, а их много. Например duskers, layer of fear, вроду бы stardew valley ( я помню вроде бы они описывали на habr как разрабатывали игру ), punch club. И много кто на этом форуме тоже пишеть на c# в unity. Да тот же dcrack, он тоже к их числу, к числу ( мелкие студии или инди разработчики ).
То что на unity пишут много инди и мелких студий это ни для кого не секрет, где пруфы, что только они это делают, тот же Blizzard выпустил несколько тайтлов на Unity - Hearthstone как пример, Ori and the blind forest на юнити, инди игра, но зато какого качества, выходцы из близарда опять же сделали ее.
Сообщение отредактировал Xakep - Четверг, 25 Апреля 2019, 04:22 |
|
|
| |
| Xakep | Дата: Среда, 24 Апреля 2019, 04:52 | Сообщение # 68 | Тема: LVE 2D MapEditor & Framework |
|
めちゃくちゃちゃ
Сейчас нет на сайте
| JackNazaryan Я когда писал эту программу не умел писать поддерживаемые проекты сложнее hello world'а, поэтому все очень глючное и постояно вылетает, мне не хочется выкладывать бинарники и не законченную работу, т.к. этим пользоваться нельзя. Я как раз таки начинал все это переписывать и даже успешно (текущий github репозиторий) но там только рендеринг UI есть, а дальше я уже потерял интерес к проекты.
|
|
|
| |
| Xakep | Дата: Среда, 24 Апреля 2019, 04:34 | Сообщение # 69 | Тема: На этом сайте есть линуксоиды? |
|
めちゃくちゃちゃ
Сейчас нет на сайте
| Цитата писать кроссплатформеную игру на чистом с++ это смешно, это как бить себя молотком по ноге и удивляться почему ноге больно
выходи из криокамеры, это уже давно в прошлом, сейчас, чтобы писать на C++ кроссплатформенный код, не нужно особо что-то делать, за тебя уже давно все сделали.
Цитата можно список ААА игр вышедших в последние 10 лет которые сделаны на чистом с++ без использования каких-либо движков?
я знаю одну - spiderman, ну скажем Battlefield тоже на чистых плюсах (Frostbite движок, но они его сам сделали, так что считается)
Цитата Вот твоя игра, если бы на c++ была написана, была бы она производительней чем на c#
Сильно зависит от прямоты рук, Майк Актон не плохо справляется с тем, чтобы писать на C# код, который намного будет производительнее написанного тобою на плюсах.
Цитата На c# и unity либо делают мелкие студии, либо инди разработчики
громкое заявление, пруфы пожалуйста.
Цитата ты вообще в курсе что в юнити щаз при сборке c# код транслируется в c++?
от этого мало толку, сборку мусора никто не отменял, весь C#'овский рантайм и стандартную библиотеку тоже никто не отменял, а это 90% всех тормозов.
|
|
|
| |
| Xakep | Дата: Суббота, 09 Марта 2019, 09:31 | Сообщение # 70 | Тема: свой графический движок |
|
めちゃくちゃちゃ
Сейчас нет на сайте
| Цитата Xakep, а как ты открывал opengl контекст? Я с помощью sdl2.
у меня сейчас sfml стоит, но и sdl2 тоже использовал, sfml уже и так записывает все в текстурный атлас для конкретного шрифта и конретного размера текста, новые символы появляются в текстуре по мере использования, т.к. всю таблицу unicode в текстуру тоже не запихаешь, у sdl2 можно либо вручную сохранять, либо можно рендерить не по одной букве, а сразу текст, тогда этот текст будет срендерен в текстуру, не особо заглядывал во внутренности sdl2 так что не уверен как там сделан рендеринг самого тексту и создание подобной текстуры.
|
|
|
| |
| Xakep | Дата: Пятница, 08 Марта 2019, 21:45 | Сообщение # 71 | Тема: свой графический движок |
|
めちゃくちゃちゃ
Сейчас нет на сайте
| Цитата drcrack ( ) я думаю что opengl мертв т.к. есть vulkan
это ерунда, OpenGL - это более высокоуровневое API, Vulkan же очень низкоуровневое API для большего контроля железа, что позволят писать наиболее оптимальный код, нужно для игр у которых графон запредельный. Да и Vulkan скорее OpenCL убъет, чем OpenGL, за счет того, что имеет прямой доступ к видеокарте и ее вычислительным ресурсам.
Цитата А ведь действительно, можно же не только движок, но и любую программу на opengl написать.
Ну собственно blender так и делают, у них полностью рендеринг интерфейса на OpenGL'е.
Цитата Первое время написать программу на opengl будет долгим, пока создашь все нужные виджеты, но потом, когда будет создана куча виджетов, можно будет уже быстрее создавать программы. Можно же любой какой захочешь виджет создать, это же супер. Я вот например не могу для qt создать виджет, а если говорить для gtk, то там вообще для меня не понятно. Другое же дело opengl, если в qt и gtk я не могу создать файловый менеджер, то в opengl могу
Это только кажется простым, на самом деле тут все намного сложнее, говорю как человек, который реализовывал рабочий UI на OpenGL, да и до сих пор пилю свой кроссплатформенный тулкит для работы с UI
На деле же, если хочется более менее сложный UI, нужно будет заморочиться над автоматическим расположением виждетов, над синхронизацией виджетов (размеры одних виджетов зависят от других), по хорошему нужно имет язык разметки, который в свою очередь создает дополнительные проблемы - нужно сделать удобную прослойку между кодом и языком разметки, нужен менеджер ресурсов (разные картинки, иконки, строки для разных локалей и не забываем про горячие клавишы, которые иногда хочется переназначить), нужно учитывать, что у людей разные мониторы и сейчас все чаще у людей HiDPI мониторы (с повышенной плотностью пикселей) на таких мониторах нужно автоматически подстраивать размеры, а если у тебя иконки растровые, то скорее всего нужно имет разные размеры этих иконок отмасштабированные под определенные мониторы (часто это просто 2 версии - x2 и для стандартных), кстати, рендеринг шрифтов это вообще отдельная тема и довольно не простая, в общем тема конечно интересная, но возможно не стоит заморачиваться так сильно и взять готовый UI тулкит.
Сообщение отредактировал Xakep - Пятница, 08 Марта 2019, 21:56 |
|
|
| |
| Xakep | Дата: Пятница, 08 Марта 2019, 21:18 | Сообщение # 72 | Тема: LVE 2D MapEditor & Framework |
|
めちゃくちゃちゃ
Сейчас нет на сайте
| Скорее нет чем да я сейчас работаю, конкретно на этот проект времени как-то нету, на работе сейчас большие перспективы, процент от проекта обещают, поэтом много времени на него трачу, в том числе и свободного. Ну и у меня в любом случае есть другой интересный проект для реализации не связанный с геймдевом, я как-то от геймдева отошел довольно давно, может когда-нибудь и вернусь.
|
|
|
| |
| Xakep | Дата: Суббота, 04 Августа 2018, 17:55 | Сообщение # 73 | Тема: Python и информационная безопасность |
|
めちゃくちゃちゃ
Сейчас нет на сайте
| pyca/cryptography
|
|
|
| |
| Xakep | Дата: Среда, 22 Ноября 2017, 12:49 | Сообщение # 74 | Тема: как рисовать в opengl? |
|
めちゃくちゃちゃ
Сейчас нет на сайте
| Цитата Ordan ( ) Я не спец в опенГЛе но звучит как ересь, если их нет в привычном виде значит они есть в другом виде. У меня версия 4.2 и все есть.
все правильно, нету больше этого, для работы с матрицами есть отдельные библиотеки, на C++ в основном - это glm, сейчас в OpenGL все делается через шейдеры, поэтому все эти вызовы устарели как и glPushMatrix, glPopMatrix итд.
afq glBegin и glEnd давно устарели, они работают намного медленнее чем glDraw*, именно их и используй для рисования, гугли VBO/VAO. Отличный ресурс для изучения нового OpenGL (ну как нового, давно уже не так): http://www.opengl-tutorial.org/
Сообщение отредактировал Xakep - Среда, 22 Ноября 2017, 12:49 |
|
|
| |
| Xakep | Дата: Суббота, 05 Августа 2017, 06:05 | Сообщение # 75 | Тема: Сравнение BGE и Unreal Engine 4 |
|
めちゃくちゃちゃ
Сейчас нет на сайте
| Цитата Kharagh ( ) ну так логика это и есть "простые вещи"
логика игры - это сама игра, ядро игры, не всегда логика игры простая.
Цитата Kharagh ( ) оэтому во всех движках уже давно используются для логики: C#, JS, UnrealScrip, Lua, AS, Python и т.д.
начнем с того, что C# - это не скриптовой язык программирования, и он в разы быстрее питона, в играх часто много различных математических расчетов, которые в питоне намного медленнее чем в C/C++/C#/..., поэтому я и написал, что удобно исопльзовать подобные языки для конфигурирования к примеру, когда все сложные вычисления выполняются на компилируемом яп. Кстати UnrealScript и BluePrint не простые скриптовые яп - они были заточенны имено под игры и под определенный движок, а следовательно можно максимально эффективно организовать работу с памятью, что является одной из самых частых проблем в производительности (скорость доступа и скорость выделения памяти), в то время как Python использует GC и много различных удобностей для работы с объектами, что сильно тормозит исполнение кода, более того циклы в питоне намного медленнее чем циклы в C/C++, поэтому для питона написаны различные библиотеки на C такие как Numpy и SciPy, которые позволяют быстро работать с большими массивами максимально эффективно.
Ну и к слову, у тебя может быть простая логика на один объект, и если на C++ она будет выполняться со скоростью скажем 1нс, а на python 1мс то пользователь и правда не заметит разницы, но если у тебя 1000 объектов, то на C++ - это 1мкс а на python уже 1с, что существенно.
Сообщение отредактировал Xakep - Суббота, 05 Августа 2017, 09:04 |
|
|
| |
| Xakep | Дата: Пятница, 04 Августа 2017, 18:50 | Сообщение # 76 | Тема: Сравнение BGE и Unreal Engine 4 |
|
めちゃくちゃちゃ
Сейчас нет на сайте
| Цитата Kharagh ( ) С++ вообще не скриптовый язык. А узким местом в плане производительности в играх обычно графика является, ну или физика (если руки из *опы), но никак не скрипты.
а на чем писать логику всю, если вся логика через скрипты идет (как в BGE), то у тебя будет большой провал в производительности. Вот именно что скрипторвые яп обычно используют для простых вещей либо в качестве конфигуратора, когда сложная логика уже написана и оптимизированна, а тебе остается только правльно задать ей поведение.
Сообщение отредактировал Xakep - Пятница, 04 Августа 2017, 18:50 |
|
|
| |
| Xakep | Дата: Четверг, 03 Августа 2017, 12:18 | Сообщение # 77 | Тема: Вопрос-Ответ (С) |
|
めちゃくちゃちゃ
Сейчас нет на сайте
| Цитата Vuvk ( ) и после этого оставшиеся 11 байт будут болтаться пустыми и бесхозными?
именно так - это называется внутренняя фрагментация памяти, можно просто использовать зоны более меньших размеров, чтобы более плотно ложилось все, я привер пример как можно реализовать, есть еще FreeList аллокаторы, но это простейшие примеры, соверменные менеджеры памяти сложнее устроены, к примеру вариант который я описал очень быстрый в плане выделения и освобождения, и в принципе внешняя фрагментация памяти вообще отсутствует (см. картинку). Часто используют такой способ, который я описал выше, для выделения маленьких объектов, для выделения чего-то по крупнее используют деревья или пирамды или еще что-то, но тут может возникнуть внешняя фрагментация памяти, когда у тебя вроде бы место есть, но выделить ты туда ничего не можешь, чтобы уменьшить фрагментацию как раз можно использовать выше описанный способ (так же известен как Pool Allocation) для выделения маленьких объектов, в статье про альтернативные аллокаторы памяти, который я приводил выше, немного рассказывают про это.
Сообщение отредактировал Xakep - Четверг, 03 Августа 2017, 12:22 |
|
|
| |
| Xakep | Дата: Четверг, 03 Августа 2017, 11:21 | Сообщение # 78 | Тема: Вопрос-Ответ (С) |
|
めちゃくちゃちゃ
Сейчас нет на сайте
| Цитата Vuvk ( ) так я с этим и не спорю, я говорю, что если бы, то.
Просто ты не ответил почему это было бы так, где можно прочитать про подобное поведение, что у упакованной структуры указатель должен оказаться в конце b? как вообще в этом может быть виноват malloc и его способность к выравниванию данных, при том что malloc вообще знать не знает о структуре, под которую ты пытаешься выделить память.
Цитата Vuvk ( ) 1 на современных машинах нулевые указатели равны 0, так что можно их каллокать.
Не на современных машинах, а компилятор их так представляет, с таким же успехом в другом яп нулевой указатель может быть предствлен в виде более сложной структуры.
Сообщение отредактировал Xakep - Четверг, 03 Августа 2017, 11:23 |
|
|
| |
| Xakep | Дата: Четверг, 03 Августа 2017, 08:44 | Сообщение # 79 | Тема: Вопрос-Ответ (С) |
|
めちゃくちゃちゃ
Сейчас нет на сайте
| Цитата Vuvk ( ) Если бы это было так, то запихав "сжатую" структуру в выровненные 8 байт, я бы при попытке доступа к b (поле в example_s) получал бы адрес последнего её байта вместо первого (смотри под спойлер "типа схема" здесь и в предыдущем моем посте)
и почему это? у тебя адрес у b начинается с адреса 1, а не с 4, какя тут связь не вижу, компилятор знает, что у тебя структура сжатая, вот и возвращает тебе смещение b немного по другому. А так у тебя получается примерно так:
Зоны по 16 байт к примеру, выравнивание пусть будет по 8 байт:
Код
[abbbb 00000000] [a0000000 bbbb0000]
Первая структура у тебя упакованная, вторая нет, и в любом случае при обращении к s.a или s.b у тебя будет ссылаться на начало, где лежит эта переменная, по сути зоны также выровнены по степени двойки.
Сообщение отредактировал Xakep - Четверг, 03 Августа 2017, 11:18 |
|
|
| |
| Xakep | Дата: Четверг, 03 Августа 2017, 06:20 | Сообщение # 80 | Тема: Сравнение BGE и Unreal Engine 4 |
|
めちゃくちゃちゃ
Сейчас нет на сайте
| то что в UE4 будет работать с 60 FPS на BGE будет работать с 10, инструментарий в UE4 намного удобнее для игр сделан, специально для этого заточен, blender в совю очередь не заточен под realtime. В Blender'е намного удобнее будет моделированием заниматься, делать какие-то декорации для уровней модели, персонажей итд, в UE, насколько я знаю, такого делать нельзя и UE4 удобно использовать вместе с blender'ом. Еще один минус BGE - он использует python в качестве скриптового языка, а он намного медленнее C++ (пруф)
Цитата LinCof ( ) дабы двиг имел "бесплатность" при создании коммерческих проектов с наименьшим количеством "подводных камней"
и чем тебя не устроил в этом плане UE4? ты думаешь у тебя будут такие обороты при продаже игры, что тебе придется хоть какой-то процент отчислять эпикам? А если будут такие продажи, то не все ли равно?
Сообщение отредактировал Xakep - Четверг, 03 Августа 2017, 06:24 |
|
|
| |
|
