Войти
ПроектыФорумУтилиты

Движок 'Сухарь Ванильный' (58 стр)

Страницы: 157 58 59 6062 Следующая »
#855
10:53, 29 дек. 2012

=A=L=X=
> Встречный вопрос - а как?
> Хотелось бы сравнить подходы.
Я достаточно неизящно решил этот вопрос. Так что твой подход скорее всего заметно лучше.
От системы требовалось проверить, будет ли ускорение от попадания в кэш цп. Поэтому саму эту систему я писал как тестовую. В лоб, без красивого кода.

В самых общих чертах решение было такое: обёртка не только поверх new и delete, а и поверх копирования указателей. В результате, когда я контролирую все копирования указателей, система всегда имела ссылку на валидные указатели. То есть в случае, описанном выше: пользователь копирует локальный указатель, и потом локальный указатель перестаёт существовать. Но раз система перехватывает копирования указателей, то знает, где теперь валидный. В примере он там, куда был скопирован локальный.

В общем, там всё достаточно страшненько было сделано. Поэтому код не покажу, извини. :)

> А так то обычная куча тоже положит всё рядом и плотненько, если спрайты
> допустим инициализировались в одном месте и между ними не было активной и
> грузной работы с кучей.
А эта работа была. Некоторая, по крайней мере.

Предположим, спрайты загрузились подряд. Но уже при этой операции между памятью спрайтов были освобождённые блоки памяти. Это буфер для чтения файла спрайта. Поэтому даже при загрузке картинок подряд уже имеем: буфер-спрайт-буфер-спрайт-буфер-спрайт. Потом каждый буфер освобождается, конечно.

Далее, спрайты обрабатываются. На основе изначального прямоугольника пикселов создаётся новая структура спрайта. Там в общем всё немного запутанно, вкратце: описание,палитра, и участки без прозрачных пикселей. Понятно, что это ещё выделения и освобождения памяти.

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

Mikle
> В некоторых случаях не сильно большие куски памяти для локальных нужд процедуры
> можно выделять на стэке, смотри, к примеру, код моей процедуры RESIZE()
Ага, отыскал. Это ты используешь alloca().
К сожалению, ядро движка у меня написано на ANSI стандарте, без include вообще. Поэтому не очень хочется нарушать это и подключать malloc.h

Скажи, ты так выделяешь память потому, что она быстро выделяется? Или потому, что к такой памяти более быстрый доступ? Первое мне не столь важно, вся эта бодяга из-за второго: хочу более быстрого доступа к памяти.

RPG
> Надо было писать менеджер для частных случаев, когда вы пишете менеджер,
> заранее зная, какие данные там будут храниться
Для этого и менеджера не нужно. Каждая подсистема движка знает заранее, какие данные будет хранить, и пытается их более удобно для процессора разместить.
Видимо, ты прав. Этим путём и нужно идти. Брать конкретную подсистему двига и пытаться уже что-то конкретно перераспределить.


#856
11:00, 29 дек. 2012

sb3d

Ясно. Просто на всякий случай опишу свою систему: у меня все ссылки были в интрузивном списке (поэтому требовали каждая 2 указателя внутре себя - next/prev) прикрепленном к "голове" - тому самому блоку выделенной памяти на который они ссылаются.
Конструкторы/деструкторы ссылки просто перецепляли себя в этом списке по месту (поэтому однонаправленного списка с одним только next было недостаточно - надо еще prev) и поэтому за константное время в конструкторе/деструкторе просто вычеркивали себя из списка или вписывали себя в начало списка. Всё реально выходило так, что копируй, передавай, возвращай - как хочешь и в каком угодно порядке - список не рушился даже во всяких изощеренных RVO (ну просто код логичен был) и семантика была как обычная value-переменная с которой делай всё что хочешь.
В то же время если список полностью опустошался - сборщик мусора мог понять что объект можно удалять.
Если блок перемещался - логичный однопроходный цикл по всем ссылкам данного блока из "головы", которой является сам блок, исправляющий базовый адрес, ни одной как говорится лишней операции.
Более того - можно было легко сделать weak reference, как бонус.
Ну это я просто на всякий случай.

#857
11:21, 29 дек. 2012

sb3d
> ты так выделяешь память потому, что она быстро выделяется? Или потому, что к
> такой памяти более быстрый доступ?
Выделяется несколько быстрее, освобождения не требует вообще, доступ быстрее, когда активно используется вместе с простыми локальными переменными процедуры, а, как правило, это так и есть.
Обычно у тебя кэшируемая память делится на три куска:
1. Данные, с которыми работает процедура, на куче.
2. Временно выделенная под локальные массивы в процедуре память, тоже на куче, но в другом месте.
3. Рабочие локальные переменные на стэке.
Это для оптимизированного случая, когда ты заранее сгруппировал всё, что в п.1.
В моём случае пункты 2 и 3 объединяются.

#858
21:44, 31 дек. 2012

sb3d

Побыстрее никак нельзя движок пилить? :)) Игру уже хочется!!!

#859
23:21, 31 дек. 2012

qwqwqw
> Побыстрее никак нельзя движок пилить? :)) Игру уже хочется!!!
Я сейчас в конкурсе трэша и угара участвую: http://www.gamedev.ru/flame/forum/?id=170732&page=16#m231
Не знаю уж, захочется ли тебе трэш со старой графикой, но полноценная игра очень не скоро.

И кстати, зачем тебе игра? Ты ещё коньки не сносил в gnh20 не прошёл. :)

#860
12:21, 2 янв. 2013

Отчёт о последних достижениях в движке.

Написал тут ещё один свой формат хранения картинок и анимации. Особенность его в том, что он хорошо сжимается архиваторами, например зипом.
Вот тест, это анимация моего полёта дракона. Саму анимацию можно увидеть тут, если пойти влево: http://www.gamedev.ru/flame/forum/?id=170732&page=21#m306
В одном изображении содержатся кадры этой анимации. И для теста я при помощи гимпа запаковал эту анимацию в разные форматы. Гимп достаточно хорошо создаёт картинки, лучше, чем виндовый паинт.

Что мы видим: в лидерах по размеру изображения - gif и jpeg. Но как только мы помещаем все эти картинки в зип архив - то сразу же в лидерах мой формат, sb5. Поэтому его очень удобно использовать для огромных анимаций крупных боссов. В архиве такую игру будет легко передавать по интернету.

Картинка:
Изображение удалено

#861
12:33, 2 янв. 2013

sb3d
> Саму анимацию можно увидеть тут, если пойти влево:
> http://www.gamedev.ru/flame/forum/?id=170732&page=21#m306
И куда, простите, вы там посылаете?:)

Сжатие без потерь?

#862
12:39, 2 янв. 2013

RPG
> Сжатие без потерь?
По сравнению с 32битнапиксел - с потерями.
Заметь, я не случайно сравниваю с gif и jpeg, которые в этом случае тоже дают сжатие с потерями.

Оценить степень потерь сложно. Я тестировал на самых разных изображениях, и в целом, на глаз, потерь меньше, чем при jpeg'е 90-процентном.
Кстати, отличие от того же джпега ещё и в том, что он бОльшие потери по умолчанию даёт на красном канале цвета. Мой же формат - на синем. Создатели джпега основывались на том, что потери в красном канале слабее заметны, но мой опыт говорит, что в _играх_ красный канал используется активнее синего. Поэтому лучше терять в синем.

[чуть позже добавил:]
В общем, этот формат подразумевает достаточно специфические потери. Поэтому иногда может оказаться хуже jpega. Но как альтернативный формату без потерь, который игра тоже поддерживает (.sb3), он вполне годен.

#863
17:52, 2 янв. 2013

sb3d
> Оценить степень потерь сложно. Я тестировал на самых разных изображениях, и в
> целом, на глаз, потерь меньше, чем при jpeg'е 90-процентном.
PSNR, эта метрика очень хорошо отражает визуальное восприятие, по сути - соотношение сигнал/шум на изображении. Данная метрика есть в ImageMagick, делаем $ compare -metric psnr compressed.bmp original.bmp diff.bmp и готово, inf означает что изображения равны.
sb3d
> Кстати, отличие от того же джпега ещё и в том, что он бОльшие потери по
> умолчанию даёт на красном канале цвета.
Ммм бред ИМХО. jped алгоритм работает в цвтовом пространстве YUV, Y - интенсивность, она сжимается с наименьшими потерями, так как глаз к ней наиболее чувствителен, UV - цветность, здесь лучше всего сохраняется зелёный цвет как наиболее значимый, затем идёт красный и синий, но на цветность отдаётся много меньше бит, чем на интенсивность в любом случае. В JPEG основывались на знании того, что глаз наиболее чувствителен к яркости, потом к зеленому, затем к красному и синему. Да к синему у нас самая низкая чувствительность, лучше всего - зелёный спектр и яркость.

Я так понимаю ваше сжатие основано на уменьшении битности цветовых пространств? Ну в целом померяйте для разных случаев PSNR - самый лучший общепризнанный независимый судья качества сжатия изображений, метрика PSNR ближе всего считается к восприятию человеком. Если есть трудности - кидайте картинки, попробую погонять, заодно сравнить с DDS, тоже хитрый алгоритм, который без особых проблем жмется zip-ом.

Для того, чтобы не заставлять игрока распаковывать ваши хитросжатые картинки, я рекомендую читать ресурсы прямо из zip-архива, как из файловой системы. Это очень легко, исходники в движке кваки можно посмотреть. Плюсы - быстро грузится и не терзает жесткий диск. У меня по скорости загрузки конечно всех уделал dds, но после него идёт jpg, причем чем меньше жпег - тем лучше.

#864
19:04, 2 янв. 2013

RPG
> PSNR, эта метрика очень хорошо отражает визуальное восприятие, по сути -
> соотношение сигнал/шум на изображении.
Да, спасибо. На будущее может пригодится.

Но в лоб считать разницу не всегда уместно. На тех же фотографиях искажения джпега менее неприятны, чем искажения гиф формата. А на пиксельарте наоборот, гиф рулит, а джпег привносит недопустимую муть и шум по краям перепадов яркости. Поэтому самый лучший прибор, это человек. Он гораздо точнее оценит качество.

> Я так понимаю ваше сжатие основано на уменьшении битности цветовых пространств?
Угумс. А сам формат весьма примитивен. За счёт чего и сжимается хорошо зипом.

> Плюсы - быстро грузится и не терзает жесткий диск.
Говоря откровенно, терзания жд перестали быть актуальными с появлением 95 виндоуса. Да, собственно, под дос уже был драйвер кэширования, с которым я помню играл, и диск не жевался, как без этого драйвера. В общем под современные оси жёсткий диск настолько хорошо кэшируется, что паковать все игровые файлы в один убер-архив не очень и нужно.

На самом деле да, это иногда актуально даже сейчас. Но только в том случае, если файлов и данных действительно много. Гигабайты. В случае же маленькой авторской игры и пары сотен файликов это лишняя морока.

#865
19:08, 2 янв. 2013

sb3d
> На самом деле да, это иногда актуально даже сейчас. Но только в том случае,
> если файлов и данных действительно много. Гигабайты. В случае же маленькой
> авторской игры и пары сотен файликов это лишняя морока.
Я кажется вам уже говорил, и ещё раз повторю, что ваши игры грузятся дольше, чем Portal 2 с 16 гигабайтами ресурсов. Просто это значит, что там есть над чем работать.

#866
19:12, 2 янв. 2013

RPG
> Я кажется вам уже говорил, и ещё раз повторю, что ваши игры грузятся дольше,
> чем Portal 2 с 16 гигабайтами ресурсов.
Ты всё перепутал. Игр на этом движке ещё нет.

Считай, что ни одной. За исключением вот той, на конкурс трэша и угара. Которую уже убрал из доступа.

Ты говоришь про игры на старом движке. Который я уже превзошёл, думаю, в десятки раз по скорости загрузки ресурсов. Но ты эту скорость пока не можешь оценить, тестов нет. Если только ты не успел скачать игру на конкурс трэша.

---
чуть позже:
Да, прошу, гораздо привычнее обращение на 'ты'. Если, конечно, этому ничего не препятствует.

#867
15:14, 4 янв. 2013

Первая скромная игра на новом, ещё не готовом движке: http://www.gamedev.ru/projects/forum/?id=171204

#868
15:26, 4 янв. 2013

Одного взгляда на скриншот хватило, чтобы понять в чём суть сжатия:)

#869
15:28, 4 янв. 2013

RPG
> Одного взгляда на скриншот хватило, чтобы понять в чём суть сжатия
Да, в общем то, это секретом и не было. :) А сжатие такое очень актуально: для пиксельарта. На нём оно даёт почти нулевые искажения, зато размер в архиве опережает гиф.

Страницы: 157 58 59 6062 Следующая »
ПроектыФорумУтилиты

Тема в архиве.