Ждём Ваших отзывов о материале.
Соблюдение Правил конференции строго обязательно!
Флуд, флейм и оффтоп преследуются по всей строгости закона!

ЗАЧЕМ???

GLSL, HLSL не зря приддумали, SM тоже не для бумаги. Если бы представители АТИ и НВ не придерживались бы этих стандартов, то была бы такая путаница, что толку от них было бы мало.

Arioch
Это именно синтез. А про сжатие - тут две вещи. Во-первых, это просто такая шутка для непосвященных про новый супер-кодек. Во-вторых, чтобы не забывали, что здесь в 64 килобайта уложены, к примеру, 80 мегабайт текстур и 120 мегабайт модели, или 6 ГБ несжатого видео.

Но происходит там не паковка вроде мпега, а именно синтез текстур и моделей. Можно взять ADDICT, с conspiracy.intro.hu, посмотреть, как делаются текстуры. Модели же описываются формулами или алгоритмами. Никакое сжатие такой объем графики в 64 килобайта не упакует - даже модель для простейшей сцены больше весит.

Принцип, на деле, не очень сложен. Ведь ту же шестеренку можно описать как сложной моделью, так и набором команд, выполняемых в CAD для создания этой модели, и последний будет весить куда меньше. Примерно так это и делается. Ну, шестеренки - это так, заставки, ценится, конечно, создание живой природы, правдоподобных зданий, городов. С текстурами идея похожа - ведь, по сути, текстуру тоже можно представить компактным набором операций или формул, только чуть менее прямолинеен.
К трекерной музыке внутри все уже привыкли, интерес вызывает уже синтез речи в 64 килобайтах, как в Zoom 3.

А есть еще 4-килобайтные, как Gaia ( http://demoscene.ru/demo/demo1a.php3?2006 ), где в объем этого поста уложена не самая простая графика даже для полных демок. Здесь уже даже мелкую текстуру не поставить, идет чистый синтез ландшафта. Причем, надо заметить, неплохого.




Зачем под каждый? Общую, просто на 4 шейдерах. Продвинутые шейдеры - простор для демосцены, где все равно все строится на синтезе. Прорыва по паковке может и не быть, но открываются очень интересные возможности.

Вообще, игростроителям надо бы многому поучиться у демосцены. Скажем, здесь упоминался угловатый "круглый" мотор - а как насчет того, чтобы вместо этого задать его функцией, выдающей такую гладкость модели, какая нужна?

http://www.theprodukkt.com/faq

Помнишь знаменитый Pentium FDIV bug ? Там можно было подобрать два таких числа, что при делении одного на другое возникала ошибка в какомто 123-м знаке после запятой. Из за этого меняли процессоры сотнями тысяч, м.б. миллионами. Потому что процессор должен считать точно.
Более того, в операционках такие пентиумы определяли и отключали у них FPU на всякий случай.
У тебя скорее всего Windows NT - попробуй Пуск / Выполнить / "cmd /k pentNT.exe"

А видюшки считают "на глазок" чтобы игрок видел правдоподобную картинку и если что-то глюкнет в одном кадре из 60 в секунду - он не заметит. А если картинка на ATi, nVidia и S3 выглядит по разному - это в порядке вещей (представь, что 2.0*2.0 было бы чуть-чуть разным на процессорах AMD, Intel и VIA...). И вот это "на глазок", когда функции и формулы вызывают друг друга тысячи раз кругами чтоюы сгенерить текстуры - выдают разницу, разваливающую все построения. И придётся подбирать под каждый чип свои формулы/функции, приспособленные именно к его неточностям в вычислениях.



Это типа ATi TruForm ? А то в кадре мнооого объектов, и периодически их заново генерить - проблемно будет. MipMapping, однако.


...или может быть имелся в виду exe-packer, только сказано было коряво. Сейчас не найду в текстовиках, а пересматривать все - долго. Я и запомнил-то потому что звучало несколько дико.
Вообще какое-то сжатие наверняка слегка используется. Что-нибудь типа RLE, ADPCM (когда надо функцию запускать с разными но близкими значениями), хотя это не основное.


Впечатляет. Причем тут судя по всему на лету еще и код генерится. Привет функциональному программированию

По крайней мере в первый раз её DEP прибил - давно я не видел этого окошка с двумя кнопками OK

Arioch Только не надо сравнивать это с 2*2. Так и задумано. Это связано не с ошибками расчетов, а с тем, что видеокарте дается задание довести картинку до приличного вида самостоятельно. И тут уже придумываются разные алгоритмы. Это не ошибки.
Выполнение GPGPU шейдера к такому не приведет. Этот результат дают функции фильтрации, а также по сути своей неспособного быть точным АА.


Что касается неточности вычислений, то на данном этапе это легко исправляется дублированием. Видеокарты все же считают не "на глазок". Всего лишь считается допустимым большее число ошибок; не будем забывать, что не-ECC память тоже вносит ошибки в работу CPU.


Видеопамять не случайно придумана. Но перегенерировать регулярно - без проблем. Там считать-то нечего.
Труформ похож лишь очень отдаленно. Это лишь сглаживание готовых моделей. Я же имею в виду изначально параметрическое их задание. NURBS-поверхности вместо meshes, хотя бы.



Конечно, паковка экзешника присутствует, но это так, последний штрих. Из общей степени "сжатия" в тысячи она дает в лучшем случае несколько раз.


Ну так упаковать в 4 килобайта - не шутка...

А в 64-килобайтных как раз сочетаются паковка и место для качество, и они остаются самыми интересными. Вот, кстати, неплохая подборка (1 метр, 16 демок):
http://forum.fullrest.ru/index.php?act= ... ost&id=398

To ALL Прочитал все 6 страниц и подумал, что Вам парни в форум 3ds Max & Maya прямая дорога. А тут вроде как обсуждаем причины задержки Radeon HD 2900 XT.

Точно. Хватит уже оффтопа. Хотите, отделю тему про демки и упаковку? Пишите ЛС.

Весьма редко. Даже крайне редко.
Иначе программы, а то и операционки вылетают с ошибками, архивы не распаковываются и т.д., потому что вовсе не всякая ошибка памяти проходит малозаметной.

Hil Но ошибки - есть. Не знаю, с чем связано то, что о них не рапортуется, но они происходят. Возможно, элементарно не все замечаются. Возможно, есть дублирование или внутренняя коррекция. Возможно, они не влияют в той степени, или область недостаточна.

Тем не менее, именно так, при большом объеме памяти ошибки происходят ежедневно. Поэтому на рабстанции ECC и ставят.

Varg 'Euthanasiologist' Какие ваши доказательства?