![]() |
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
А не устраивать ли нам небольшие конкурсы по кодингу? (ч.4)
OSokin © (2005-05-06 19:09:00)
Страницы: < 1 2 ... 23 24 25 26 27 28 29 30 31 32 >
Будут ли еще конкурсы?
Zak3D[@Tm] (2005-05-29 23:30:00) [581]Вот стало интересно, кто будет учавстовать(или уже учавствует) в конкурсе? Ну и на какой стадии игруха =)?.
Обо мне:
1) Учавствую.
2) Один день пописал, а щас зачётная неделя =(... (надеюсь дописать).
-----------------
Высказывайтесь плз. =)
OSokin (2005-05-27 21:21:00) [582]Отправил.
XProger (2005-05-18 18:13:00) [583]Sphinx, я не язва, я врач...
А компрессор использовался ;)
Zer0 (2005-05-18 15:12:00) [584]omgwtflol!
We do .not. have some kind of magical data compressionmachine that is able to squeeze hundreds of megabytes of mesh/texture and sound data into 96k. We merely store the individual steps employed by the artists to produce their textures and meshes, in a very compact way.
Они говорят что используют процедуральные методы генерации текстур, моделей и звуков(музыки) а не сжимают уже готовые.
Про комрессию ексзефайла нет ни слова.
Если делать статистический анализ несжатого файла то должны быть видны явно выраженные пики (часто используемые команды процессора, обращения к определенным участкам памяти и тд), но анализируя kkrieger можно увидеть что распределение по байтам и словам примерно равномерное, которое достигается только за счет сжатия.
ну и контрольный выстрел в голову - вот заголовок exe файла:
MZfarbrauschPE L\x1\x1 _¼y@ ˆ \xF\x1\xB\x1\x7
à\x1 Ð z\x1 \x10 | \x10 \x2 \x4 \x4 pØ \x10 \x2 \x10 \x10 \x10 \x10 \x5 ×{\x1 ( kkrunchyWRØ \x10 l\x1 \x10 à à¾ÿÿK&\xCN¢\x10L"ÞÝ
а kkrunchy появляется в списке exe-пакеров http://www.maximumcompression.com/benchmarks/Squeeze%20Chart%202005.pdf
dismissed =)
Sphinx (2005-05-18 07:26:00) [585]>XProger © (18.05.05 00:17) [51]
Я давно знаю что ты еще та язва ;)
Про UPX не знаю...но ради тебя нашел эту демку у себя на компе...цитирую:
.kkrieger, chapter I - Beta Version
.a game in 96k
by .theprodukkt
(released at breakpoint 2004)
- We do .not. have some kind of magical data compression machine that is able to squeeze hundreds of megabytes of mesh/texture and sound data into 96k. We merely store the individual steps employed by the artists to produce their textures and meshes, in a very compact way. This allows us to get .much. higher data density than is achievable with normal data compression techniques, at some expense in artistic freedom and loading times.
- .kkrieger is not written in 100% assembler/machine language. Not even nearly. Like the vast majority of game projects being developed today, .kkrieger was mostly written in C++, with some tiny bits of assembler where it is actually advantageous (notably, there are a lot of MMX optimisations in the texture generator).
- A kilobyte is, historically, defined to be 1024 (2^10) bytes, not 1000. Thus .kkrieger is a game in 96k even though it's actually 98304 bytes.
- The concept of the texture/mesh generators was developed by fiver2. We do .not. want to claim that the techniques we used to develop .kkrieger are new inventions. Itґs rather a selection of useful operations and their parameters to optimise the results.
Zer0 (2005-05-18 00:41:00) [586]был еще много чего. могу сказать точно что упаковку не используют в демах на 256 байт типа tunnel http://www.pouet.net/prod.php?which=3397
XProger (2005-05-18 00:17:00) [587]kkrieger beta
Не использовал упаковщиков говоришь...
А почему же тогда даже UPX её сжать на 1 кб не может? ;)))
Sphinx (2005-05-17 23:18:00) [588].kkr***** - 96 кб демо
демка была такая...название забыл полное, но они много 64к демо делали...полноценная игрушка....со звуками, неплохой графикой и при этом в readme к демке автор указывал что он не пользовался ни какими упаковщиками и писал код на сях с небольшими asm-скими вставками в генераторах текстур...в .exe была вшита midi музыка к тому же...
Zer0 (2005-05-17 17:59:00) [589][47] XProger
абижаешь. я жы написал - шейдерный язык. в кутрике это были верктех шейдеры реализованные программно =) обозвал их шейдерам тов. кармак. хотя по сути это surface properties.
если уж копать до конца то "pixel shader" еще перевариваемо по смыслу (обычно на нем реализуюут всякие светотени), а вот "vertex shader" который занимается не просчетом освещенности вершин, а их смещением - это уже перебор. какой тут нахрен shading?
возвращаясь к теме беседы - применяя грамотные алгоритмические ходы можно значительно уменьшить размер всего дистриба.
в том числе и с использованием генератора паттернов/шумов. (perlin,gauss, musgrave,регулярные решетки) если добавить к шумелкам простые математические функции и операции, сделать небольшой скрипт язык то можно получить огромное количество тектстур.
применением только кода вместо ресурсов и сжатием можно добиться неплохих результатов типа всем извесного TheProduct.
если же например пристегивать к екзешнику готовые текстуры и пытатся зажать при помощи UPX результат будет фиговый. такшто даже UPX нужно использовать с умом.
Darth (2005-05-17 10:20:00) [590]А какая нафиг разница какие там шейдеры? шейдеры это не обязательно то что сейчас встраивают в видеокарточки. Никто не мешает тебе писать свои шейдеры и делать свой шейдерный язык.
XProger (2005-05-17 04:11:00) [591]Zer0, Ку3 и без них превосходно даже по сей день смотрится! А жейдеры там не пиксельные если что... ;)
Zer0 (2005-05-17 03:53:00) [592]Зашумленные картинки (если интервал корреляции очень небольшой) весят при том же качестве на порядок больше. Потому что количество ниформации в них больше (в данном случае вреднй). И сжимаются из-за этого они хуже. Весят больше и т.д. Короче никому не нужный расход ресурсов, т.к. пошуметь можно в одну строчку кода.
p.s. Меня убило в Quake 3 именно то что при всем богатстве шейдерного языка в нем нет генератора шумов... для телевизоров есть текстуры.... в TGA... =(
XProger (2005-05-17 03:45:00) [593]Zer0, в WinXP есть встроенные средства для распаковки JPEG, BMP, GIF, PNG, так что поддержка таких текстур будет занимать меньше, нежели реализация генератора шумов :) Да и шумы могут быть не совсем шумами... ;)
Zer0 (2005-05-17 03:29:00) [594]Чтобы UPX хорошо пажал экзешник у прогера должны быть правильно (к нужному месту) замаунчены /dev/brain/ и /dev/hands/.
Например нормальный прогер не станет пристыковывать к проге текстуру "шума" в виде ресурса-картинки Jpeg.
Однако есть мнение что в данном конкретном случае размер не является самоцелью, а скорее видом понтозакидывания.
(Ну вот блин докатились, взрослые мужики меряются у кого меньше =)
XProger (2005-05-16 20:07:00) [595]Darth, ну в действительности в демосцене юзают утилиты для сжатия exe и это считается нормой :)
Kerk (2005-05-16 19:44:00) [596]Darth (16.05.05 14:10) [40]
Так народ. Размер файла когда он учитывается, то после рекомпилинга. Тоесть UPX это только чтобы качать меньше. Сжатый файл разжимается и оценивается расжатый.
Что за бред? Для этого rar есть.
dRake (2005-05-16 19:42:00) [597]2 Sapersky
>Ты их все используешь? :)
>Загрузка bmp, tga - это "копейки". dds тоже по идее должно быть >не сложно и не много, т.к. там surface в "родном" формате, с >мипмэпами, может быть. png - где-то видел DLL в 50 кб. jpeg - от >70 (JpegObj из KOL) до 300 кб (Intel Jpeg Library - есть .>оптимизация под разные процессоры, поэтому работает заметно >быстрее).
Допустим я убью пару недель на собирание спецификаций с библиотеками и реализацию загрузчика... только нафик это нужно-то, причем я же не только загрузчик из этой либы пользую =)
К вопросу о скорости - загрузчик из D3DX конкретно делает ручную загрузку, особенно на нелокабельных текстурах. И еще - загрузчик D3DX умеет делать Dithering и разные варианты фильтрации...
Да и mipmap'ы cоздает (это мен не нужно, но все же ;)
>Конвертация форматов достаточно просто делается через FastLIB, .>разве что альфу нужно добавить...
Конвертацию я уже написал для всевозможных форматов,
когда грузил ручками ;)
Darth (2005-05-16 14:10:00) [598]Так народ. Размер файла когда он учитывается, то после рекомпилинга. Тоесть UPX это только чтобы качать меньше. Сжатый файл разжимается и оценивается расжатый.
Про демосцену заинтересовал. Мне аж захотелось оживить проектик свой по написанию демосцены в делфе :)
Darth (2005-05-16 14:09:00) [599]Так народ. Размер файла когда он учитывается, то после рекомпилинга. Тоесть UPX это только чтобы качать меньше. Сжатый файл разжимается и оценивается расжатый.
Про демосцену заинтересовал. Мне аж захотелось оживить проектик свой по написанию демосцены в делфе :)
Darth (2005-05-16 14:06:00) [600]Так народ. Размер файла когда он учитывается, то после рекомпилинга. Тоесть UPX это только чтобы качать меньше. Сжатый файл разжимается и оценивается расжатый.