А я так скажу: каков вопрос, такой и ответ. Я тоже могу так писать, подразумевая под одним словом другое.
На мой взгляд, я на этот вопрос уже исчерпывающе ответил в предыдущем сообщении.
Речи о Винде не шло, это уже моветон и уход в сторону от первоначальной дискуссии. Но если когда-то кому-то требовался прямой доступ к диску, он писал свою функцию, идущую в обход системных вызовов.
Хоть вопрос и моветон, но отвечу: пользовательская программа.
Секундочку. В моем вопросе нет слов о WINAPI. И под одним словом другого я не подразумевал. Это два существующих и разных термина. В вопросе есть слова о системных вызовах и это термин. И сразу же тут написано, что вопрос касается Windows. Цитирую:
Это первоначальный вопрос и вопрос 10, который - копия данного вопроса. Это легко проверить, всего пара сообщений выше. Я воздержусь от комментирования того, что я считаю моветоном в вашем ответе, вопросы я задаю не за этим.
Я же специально цитирую. И я специально показал вам вырезкой из книги, которая принята научным сообществом за стандарт, тем самым показал однозначно, что WINAPI и системные вызовы - это разные вещи. Но давайте не будем спорить о том как я говорил. Я попробую интерпретировать ваш ответ задавая вопросы на “Да/Нет”.
Давайте договоримся о следующем. Дальнейшая дискуссия со мной ведется об операционной системе Windows, а в случае необходимости я или вы будем уточнять версию. Согласны? Да или нет.
Про “свою функцию” позднее прокомментирую.
Уточните, пожалуйста, точно, язык и библиотеку, в которой находится функция с названием read, которая, по вашему мнению, не реализована с помощью системных вызовов Windows. Дело в том, что стандартных библиотек, как вы выразились, много, как и их версий. Можете дать ссылку на документацию с данной функцией? А то, например, я подумаю, что вы имели в виду fread() из Си. Или может быть еще какую-то. Уточните, пожалуйста.
Да ну?
Вот не надо тут пудрить мозги. Если назвал нечто функцией, то и говори о функции, а не перепрыгивай на системные вызовы. А то хитрый какой нашелся. Уже не первый раз так тебя ловлю на словах.
Категорически нет.
То, что требовалось уточнить, я уже уточнил.
Тоже используется во вполне современных игровых движках и безотказно работает. Даже больше скажу: в современных игровых движках используется полным-полно библиотек из С и других языков, а сборка проектов может осуществляться посредством собственных инструментов, написанных на C#. Одним-единственным языком программирования разработка игрового движка уже много лет как не ограничивается.
А, вас смутило использование мной противоречивых терминов. Давайте в дальнейшем стараться сразу писать собеседнику, о том, что использование того или иного слова некорректно? Нет никакого смысла раздувать тему лишними вопросами. Если вы считаете, что называть системный вызов функцией для упрощения дискуссии некорректно, то не буду. Но смотрите почему я спросил именно про функцию:
Вот ваша фраза, после которой я спросил:
Я выделил слово функция у себя и у вас. Так как вы писали о каких-то произвольных функциях, то я и попросил привести пример.
Если же вас смутил тот факт, что функции не могут быть реализованы системными вызовами (терминологически или практически), то давайте тогда конкретно этот вопрос отложим.
Почему нет? После того, как я задаю общие вопросы - я начинаю сужать тему до хотса, который как раз работает на Windows. Вы и тут считаете, что нецелесообразно говорить о Windows, если речь о хотсе? В крайнем случае сразу скажу, что я готов говорить практически о любой ОС, ваше право, просто вы могли бы пояснить причину.
Хорошо, я могу считать, что fread() http:// www.c-cpp .ru/content/fread из stdio.h (Си) - это ваш пример той функции, о которой вы говорите вот тут:
?
Считаете ли вы, что с помощью данной функции fread(), которая
, подходит для примера чтения запакованных данных ресурсов с диска для последующего декодирования?
Также, подходит ли для примера чтения запакованных данных ресурсов с диска для последующего декодирования следующая функция read() http :// www.cplusplus .com/reference/istream/istream/read/ (C++) ?
Если да (если нет - этого вопроса нет), Построен ли с ее помощью хоть один игровой движок, который читая данные с диска распаковывает их таким образом, что с помощью нее:
?
Не просто некорректно, а недопустимо, поскольку иначе возникает ситуация а-ля Вавилонское Столпотворение, когда каждый вокруг лопочет на своем языке и понять никого не может. Вроде и слышит знакомые слова, а значат они совершенно другое, нежели он привык понимать.
А вот это уже откровенное хамство: передергивать и приписывать чужим словам свою интерпретацию их смысла.
Мы говорили о принципиально разных вещах.
Это не обсуждается.
А вот это уже явно вопрос от Лукавого. Мы пишем метод foo(), в котором сначала открываем файл через нужные нам функции, и обращаемся по адресу со смещением offset и размером size. Считываем, проверяем, сжаты ли данные по нужному нам адресу, и если да, то декодируем средствами нужной нам для этого библиотеки\библиотек.
Абсурдный вопрос. Если метод предназначен для чтения данных, то он прочитает нужные данные.
Я тебе больше скажу: есть игровые движки, построенные даже с помощью библиотеки boost. Electronic Arts, помнится, несколько лет назад опубликовала исходники своей библиотеки EASTL, в которой они заменили своими аналогами значительную долю функционала из стандартной библиотеки языка С++. У них на базе этой библиотеки построено много знаковых игр, и там тоже есть своя функция read() и не одна.
Слово функция и у вас, и у меня - одинаковые. Раз по вашему я придал вашим словам иной смысл, то придать его я мог этим
? Если да, и если я об этом сам заметил, и при этом предложил оставить этот вопрос в стороне, то в чем это хамство? Но это оффтоп. Продолжу.
Хорошо. В таком случае представьте ситуацию, когда запакованный и лежащий на диске ресурс игры упакован в 1 единственный контейнер целиком, без разбивки на несколько запакованных частей. Т.е. для того, чтобы его распаковать нам надо, как вы сказали, считать его целиком, проверить и распаковать, если сжат. Как вы сказали, данные ранее примеры fread и read нам подходят для этой цели. В случае с fread, весь ли объем считанных с диска данных запакованной модели (мне не важно где при этом будет заголовок) будет находиться в ОЗУ перед тем, как будет применена распаковка? Поясните, где ещё он может находиться, если ответ нет.
Категорически не согласен, об этом я уже написал выше.
Повторюсь: не надо передергивать. Я такого не говорил. Напротив, я уже не раз говорил о том, что чтение медиа-контента ведется частями.
Нам надо загрузить модель, мы идем, открываем файл на чтение, считываем по нужному нам адресу нужный фрагмент данных, разжимаем, если модель сжата, и интерпретируем полученные данные как модель.
Данными игра может вертеть абсолютно как захочется программисту. Она может загрузить, условно говоря, только часть данных модели за одну процедуру чтения. Также, в файле с моделью может лежать пакет ее анимаций и прочие данные, какие захочется разработчикам в него поместить. Поэтому утверждение о полном объеме данных является в корне неверным.
Скажите, сколько по-вашему фрагментов данных в ресурсе игры, который:
?
Теоретически - сколько угодно. Зависит от его формата данных.
Вы неправильно меня поняли. И видимо потому изменили мою цитату.
Скажите, возможно ли по-вашему сохранить медиа-ресурс со сжатием таким образом, чтобы фрагментов сжатых было ровно 1?
В медиа-контент компьютерных игр входят разные данные и некоторые из них сжать затруднительно: как отдельные их части, так и целиком. Отсюда, как нетрудно догадаться, возникают несжатые фрагменты и начинается разбухание всех архивов\паков игры. Устройство контейнеров для медиа-контента игр может позволять сжимать данные выборочно - что-то сжать, а что-то не сжимать, и хранить все это вместе.
Вопрос был возможно или нет.
Ответ: и да и нет. В один фрагмент сжимаются только некоторые форматы данных.
Но если кроме одного сжатого есть и несжатые фрагменты, то сжатых все равно 1. Верно?
Нет, неверно, так как зависит от структуры данных объекта и от методов, которыми выполняется упаковка в контейнер.
Таким образом вы утверждаете, что разработчик не решает на сколько фрагментов разбить медиа-ресурс и ни при каких обстоятельствах не может добиться того, что в сжатом медиа-ресурс будет только 1 сжатый фрагмент. Верно?
Нет, неверно, потому что разработчик определяет формат данных своей игры и методы чтения\записи данных в контейнер.
Смотрите. В утверждении было два условия через логическую “и”. Так как вы ответили
на вопрос с двумя условиями, перечисленными через “и”, то из вашего ответа и закона де Моргана (https :// ru.wikipedia .org/wiki/%D0%97%D0%B0%D0%BA%D0%BE%D0%BD%D1%8B_%D0%B4%D0%B5_%D0%9C%D0%BE%D1%80%D0%B3%D0%B0%D0%BD%D0%B0) следует, что разработчик решает на сколько фрагментов разбить ресурс, ИЛИ существуют обстоятельства, при которых он может добиться того, что в сжатом медиа-ресурс будет только 1 сжатый фрагмент. Таким образом, так как оба условия друг другу не противоположны, то они ведут к тому, что существуют обстоятельства, при которых в сжатом медиа-ресурс будет только 1 сжатый фрагмент.
Подтвердите, пожалуйста, данный вывод, либо, если вы ошиблись/неправильно меня поняли/не дописали, перефразируйте свой ответ. Либо, если считаете, что и вывод ложный, и вы не ошиблись, то поясните каким образом мне понимать ваш ответ.
P.S. Если вы под выбором формата данных имели в виду именно это утверждение, то согласитесь. Такая длинная цепочка утверждений сейчас потому что вы не отвечаете на вопрос словами из вопроса, а начинаете говорить “потому что…”. Вопрос ожидал “верно” или “нет”. Получил ответ “нет”, но еще и приписку, которую расценить можно неоднозначно. Чтобы снова не было проблем с тем, что я не понял смысл ваших слов, предлагаю все же ответ укоротить до “да” или “нет”.
Эти обстоятельства - выбор самого разработчика. Но всегда НО, не будем о них забывать. И, к тому же
Здесь оператор или выставлен неверно. И вот почему. В ходе разработки игрового движка принимается множество различных решений. Среди них могут мелькнуть решения о использовании сразу нескольких форматов записи данных, которые послужат ± одной цели, о их сжатии в контейнере, методах чтения\записи и обработки, и о многом другом. Но даже и без этого можно ожидать увидеть в данных одной игры и сложные структуры данных и простые, сжатые и несжатые. Более того, в случае ряда игр их данные можно увидеть вне каких-либо контейнеров. Так что наиболее правильным ответом на вопрос может стать не да или нет, а только “и да и нет”.