А, вас фризы интересуют? У меня их нет. Почему? Железо выше среднего, т.е. выше минимальных требований. Чудеса.
Но у меня было и плохое железо. Знаете почему на нем были фризы? Потому что память может дампится на диск в файл подкачки, а скорость чтения диска в разы меньше скорости чтения даже старой оперативки.
А два белых квадрата не подходят по приоритетам, к тому же не влияют на производительность. Попытайтесь все же честно дочитать ответ выше и ответить.
Знаете, а у меня вот Ваших вопросов почему-то нет на экране. Почему? Монитор Фулл ХД вроде, для интернет-сёрфинга годится. Чудеса, да и только. По приоритетам, лично для меня, например, очень важен вопрос: в каком году Гена Букин сделал Хет-Трик в финале турнира Кожаный мяч? Если Вы такой всезнайка, то можете просветить меня в этом очередным форумным полотном. Не забудьте только отпечатки пальцев ноги и ткань с покрытия мяча приложить. Это очень важно.
Понимаете, этих полотен не было бы, если бы вы, понимая то, что не разбираетесь в вопросе, не требовали бы от тех, кто разбирается, неадекватных решений. Я же вам показал, что их решение обосновано и технически, и экономически, но вы разбираться не хотите и при этом все еще считаете себя правым. Т.е. просто говорите “я прав потому что я прав, а аргументы читать не буду”. Захотите - прочитайте. Если в последующих ответах не будет конструктивного разбора, вопросов по делу или контраргументов - я диалог не продолжаю, извиняйте.
Просто Вы не хотите признать то, что отказ HoTSа от 32бит абсолютно ничего не поменял, пытаясь загрузить меня вещами, в которых у Вас больше навыков. Вот и всё. Пока не будет тканевого обрывка от кожаного мяча и Мясника 15 0 вместо 0 10, то свою точку зрения я также не изменю.
Какая унылая простыня. Только она ещё бесполезней чем все темы про возвращение x86. Ты реально думаешь что всё что ты написал как-то интересует людей которые играли в 32-х битную версию игры? Они возмущаются не потому не понимают что это не выгодно компании, им вообще всё равно как это компании, возмущаются они потому что им не удобно.
Я не против того, что они поддерживают. Если ты в силах настроить эту поддержку - пожалуйста, играй так. Только попробуй объяснить это школьникам, а потом представь себя на месте близов, которые обязаны отталкиваться от официальных источников и статистики и при этом как-то убедить людей использовать pae. Людям нужна работа из коробки и при том, чтобы не лагало, вот и вся проблема.
По этой же логике люди могут не только использовать PAE, но и реверснуть игру, переписать для совместимости и собрать как им захочется. Все же достаточно образованные для этого, правда?
Ты с какого то Дикого мира.
Сейчас школьники уже гранты на работу в Apple и прочии корпорации выигрывают. Сидят нейросетки клепая под хотсы на каком нибудть питоне с библиотеками вроде OpenAI. И херачат с вяскими TF Keras на облачных сервкаха.
Не могут. Ибо закрытый код движка. Если бы исходники открыли. Там бы вполне без проблем приспособили бы уже. Энтузиасты.
Никогда не любил просто заявления подобные твоим.
Категорическое - 32 не может больше 4 гигабай. Может.
Тут нужно объяснять так - игра не приносит настолько хорошей прибыли что бы нанимать дополнительных разработчиков в бэкэнд.
Не, это ты с какой-то Силиконовой долины. Твои примеры - единицы и решение им подходит. В моем же случае, в довольно престижном столичном вузе ребята заканчивают без базовых знаний программирования, когда должны как раз клепать разные нейросетки и проектировать защитное гос. ПО.
Ну реверс на то и реверс, что исходники надо получить. Если не в курсе жаргона, то читай это как “дизассемблирование”. Не вижу технических проблем, вперед энтузиасты.
Да, мое заявление было категорическим и я в курсе, что может. Просто это не реализуемо. Автомобиль на 3х колесах тоже может ездить, только почему-то никто не экономит на 4-м. Если претензия только в возможности, то мы друг друга поняли, я думаю.
Ну это далеко не единственная причина. Технические проблемы кроме памяти в x86 тоже имеются. Разработчики не хотят себя ограничивать набором x86 инструкций и загонять в себя в рамки нехватки рабочего инструмента, так как в этом случае ни о каком развитии речи просто не будет, так как x86 из мелкомягких поддерживать никто не собирается.
Люблю, когда несведущий человек пытается что-то объяснить другим несведущим людям. Отрисовкой Валлы занимается не сам движок, ему на это вообще по боку, а модуль рендеринга - либо DX9\10, либо DX11\12. Модуль рендеринга получает на обработку массив вершин, шейдерных программ и текстур и выдает нам на экран красивую картинку. Никакой задачи “Нарисовать Валлу x64” или “Нарисовать Валлу x86” не существует и не ставится. Существуют или ставятся совершенно другие задачи, такие как “Нарисовать мир”, “Нарисовать персонажей”, “Нарисовать тени”, “Нарисовать освещение” и так далее, и все они выполняются в рамках сложного цикла, не зависящего от разрядности процессора. Зависят они только от техники рендеринга. Хочешь - возьми софтовый рендер, хочешь - OpenGL 1.1, хочешь - Vulkan и так далее. Движку вообще должно быть побоку, какой техникой и что ты хочешь отрисовать, для него существует только одна конкретная задача - вывести на экран картинку, используя ряд определенных настроек для этого. Модуль рендеринга выбирается до загрузки игры, и функционирует до ее завершения.
Почитал дальнейшую часть поста, и просто посыпался с выводов. Батенька, это несерьезно, лучше оставь другим объяснения. Просто не твое это. Какое-то там на пустом взявшееся “x86-инструкции не могут использовать более 4ГБ оперативной памяти”, расчеты графики на процессоре. Спасибо, что не пообещал, что однажды компьютеры научатся обрабатывать картинку попиксельно и тогда это будет настоящий прорыв. Все могут х86-программы, все могут. Когда-то x64-процессоры не имели широкого распространения, и на базе x86-процессоров собирали кластеры с колоссальными объемами оперативной памяти для решения архисложных задач, и там уж точно побольше объемы были, чем 4ГБ. А до этого и на 16-битных и на 8-битных процессорах собирали. Оперативная память заполнялась ровно в таком объеме, в каком требовалось для решения задачи. Надо 6 гигабайт - выделялось 6 гигабайт, надо больше - выделилось больше. Никаких проблем не возникало. И сейчас не возникает, так что не надо людей дезинформировать. И графика сегодня считается вовсе не на центральном процессоре, ей занимается графический чип видеокарты, значительно более мощный, в сравнении с центральным процессором. Видеокарты сегодня тем хороши, что с их помощью можно почти в реальном времени рендерить анимационные ролики в различных пакетах трехмерной графики, а там, на секундочку, графика значительно превосходит возможности движка Starcraft II.
А кто против-то? Это все надо объяснять не разработчику, а школьнику. А значит нужно упрощать в пользу понятности.
Я в курсе Но ты ведь не будешь спорить с тем, что исполнение инструкций происходит на уровне машинного кода, который строго архитектурно зависим и x64 машинный код (или грубо op-code, в который преобразуется основной код компилятором) отличается от x86? Ты же выше говоришь о высокоуровневом программировании, а я о машинном коде.
А тот факт, что модуль рендеринга выбирается один раз - не означает, что в коде отсутствуют проверки архитектуры системы и ветвление, которое гарантированно выдает меньшую производительность.
А вы не согласны? Тогда прошу рассказать мне о том, как в 32-битный адрес засунуть значение, ссылающееся на ячейку памяти, лежащую за пределами 4 гб. Скажем, в области 5 гб.
Кто спорит-то с этим? Выше было упомянуто про PAE и про то, что рядовой игрок совершенно не в состоянии его использовать в силу образования и, кроме того, это не остается аргументом для близов остаться на архитектуре x86.
А тут где противоречие мне? Я же написал про память. И написал на уровне аналогии на пальцах. Где я писал про процессор? Процессор действительно участвует в отрисовке и рассчетах, с этим бесполезно спортить, хоть это и не основное устройство для этой задачи.
Давайте лучше по пунктам и без всяких “батенька”, “да это не ваше” и т.д., чтобы было о чем говорить.
Зачем мне это школьникам объяснять? Я это тебе объясняю.
Не заметно, иначе подошел бы сразу к задаче с другого ракурса.
Ау, ты из 60-ых или иной старины, что ли прибыл в будущее и считаешь, что все сегодня по сей день пишут программы машинным кодом? Хотя даже в 60-ых уже были языки высокого уровня. Сегодня можно легко написать код на ассемблере, а можно написать код на языке высокого уровня и он даже самим компилятором без ручной правки адаптируется к выполнению процессором с любой архитектурой.
Отличается и будет отличаться в случае применения оптимизаций, предназначенных для определенной архитектуры процессора. Но, к твоему сведению, компьютерные игры никто машинным кодом не пишет. Их пишут исключительно на языках высокого уровня и никогда одним не обходятся. Ассемблер, С\С++, сборочные системы на C# и python, и прочие языки. Это еще не считая скриптов, коим подчиняется логика игры: персонажи и внутриигровые события. Но производительность графики, а ты вел речь именно о графике, не зависит от производительности центрального процессора. Она исполняется в другом месте.
Решительно не согласен.
Нечего тут рассказывать. Если для тебя боль - задать адрес выше 4 гигабайт в машинном коде, то ты пропустил полвека в истории программирования. Рекомендую заглянуть в учебники, там все найдешь.
Очевидно, что с этим пытаешься пободаться у нас ты. Тем более, что те же 32-разрядные операционные системы (и даже более ранние) сегодня умеют распоряжаться объемами оперативной памяти свыше 8 гигабайт. Давно уже есть патчи под это дело даже для операционных систем Windows из семейства 9x. Люди работают и успешно их применяют. Ну а что касается “недостаточно образованного пользователя”, так это очевидное принижение возможностей стандартного юзера. Если юзер захочет - он найдет способ настроить все, что ему нужно. Ну а если не хочет, то ему и так нормально.
Процессор в отрисовке не участвует, он только дает команду к отрисовке, больше от него никто ничего не просит. Ту же передачу данных можно реализовать средствами самой видеокарты, благо существуют языки программирования высокого уровня, исполняемые целиком на ней. В чем процессор действительно участвует, так это в оперировании игровой логикой. Именно это его основная задача в современной компьютерной игре. Процессор принимал бы больше участия, если бы мы говорили не о HotS, а о каком-нибудь первом DooM, но сегодня уже существуют порты того же дума, где участие процессора также сведено к минимуму. Процессор целиком и полностью оказывается открыт для решения множества дополнительных задач, пока графикой и физическими взаимодействиями занимается видеокарта. И память тут тоже не причем - всю графику можно целиком загрузить в память видеокарты, не трогая оперативную память компьютера и оставить ее для других нужд. А другие нужды у игры есть, и это все та же банальная игровая логика, ведь каждая сущность этой самой логики тоже требует под себя память. Понимаю, что сейчас кто-нибудь заявит о дублировании DirectX графических данных в оперативную память и в память видеокарты и не скажу, что это не так. Но, какие там расходы на это дело? 2 мегабайта на одну текстуру, к примеру. Не так уж и много, если разобраться, да и HotS выглядит не больше, чем на 1ГБ. Вот что действительно память в HotS захламляет, так это кэширование игровых данных в ней. Если убрать этот кэш (как будто мы вернулись в доисторическую эпоху, когда по Земле еще мамонты гуляли), то расход памяти значительно снизится и вырастет производительность. Но, кому это надо в штате хотстим? А никому. Вот и решением проблемы никто не хочет заниматься.
А это действительно не ваше, батенька. Если не разбираешься в какой-то области - просто промолчи. Сойдешь за умного. Или попроси объяснить того, кто в этой сфере разбирается лучше тебя. Такие люди найдутся и поделятся опытом.