Войти
ПрограммированиеФорумГрафика

Текстурный кэш (3 стр)

Страницы: 1 2 3 4 5 Следующая »
#30
0:23, 22 окт. 2013

Еще один вариант это поидее грузить первые кадры анимации, и подгружать остальные пока проигрываются первые в отедльном потоке.


#31
0:36, 22 окт. 2013

ИМХО, это ненужный гемор. К тому же решающий проблему лишь отчасти ;-)

Тебе просто лениво нормальное решение сделать или чего?

#32
0:55, 22 окт. 2013

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

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

#33
11:06, 22 окт. 2013

Поковырялся я побольше и оказалось, что Deponia и другие 2д адвенчуры не используют компрессию и тем не менее играются на ура. Я так подозреваю они генерируют атласы на ходу и обновляют текстуру кусками.
В основном компрессия используется в 3д играх, например Half-Life, Amnesia и др.

Поэтому буду копать в другое направление теперь.

#34
13:44, 22 окт. 2013

> И таки звучит как-то безумно хранить все анимации персонажей в RAM.
SoulSharer, выше же написал - если их пожать, то хранить их в RAM незачем - они влезут в "видео"-память.

>Deponia
Там, я так понимаю, не скроллящиеся отдельные фоны. Их, естественно, легко подгружать.

#35
17:59, 24 окт. 2013

Arxon
> > > ужели подгрузка всего одной текстуры, в один кадр, размером 2048х2048,
> > > непосредственного перед отрисовкой должна сопровождаться подвисанием?
> ДА

Ваше "ДА" оказалось пустословным, сегодня сохранил из png в чистый формат данных и все как по маслу.  Это я еще быстрого сжатия не добавил, что должно увеличить скорость считывания с HDD. (без сжатия считываю 16 мб с диска)
Это все потому, что libpng добавляет существенный оверхед, вот замеры перформенс таймером:
[24.10.2013 | 17:58:45] [INFO] PNG: 0.177367s | RAW: 0.00611072s

Если всетаки будут проблемы с этим в дальнейшем, то решил просто держать текстуры в RAM в сжатом виде и передавать в VRAM по-надобности.

#36
18:18, 24 окт. 2013

Чтото мне подсказывает, что грузишь текстуру в том же потоке, что и отрисовка...иначе бы явно не тормозило.

#37
18:22, 24 окт. 2013

Che@ter
Так и есть, да и иначе в данной ситуации нельзя. Текстура запрашивается в момент когда она уже нужна.
Опять же, еслиб это было 3D - то можно, конечно, было бы с мипмапами и стримингом химичить. (в отдельных потоках)

#38
19:11, 24 окт. 2013

SoulSharer
Значит нужно уметь предугадывать. Считать где будет игрок через секунд 5 и подгружать нужные текстуры уже сейчас. Или сделать виртуальное окно размерами больше, чем реальное. И требовать грузить текстуры для виртуального окна.

#39
20:35, 24 окт. 2013

Che@ter
> Значит нужно уметь предугадывать. Считать где будет игрок через секунд 5 и
> подгружать нужные текстуры уже сейчас. Или сделать виртуальное окно размерами
> больше, чем реальное. И требовать грузить текстуры для виртуального окна.
Было, уже предлагали и я говорил почему здесь предсказать не получится. :)

#40
11:05, 27 окт. 2013

И я тоже краб :D, забыл что у меня SSD, попробовал на HDD и shared memory - подвисает на полсекунды.
Думаю давать скриптерам предзагружать нужные и выгружать ненужные анимации. Иначе никак. Еслиб были доступны шейдеры компьютеционные (DX11 железо), то есть еще вариант писать свой алгоритм декомпресса без потерь.
Вот "paper" на эту тему, от разработчиков Civ 5 http://www.csee.umbc.edu/~olano/papers/texcompress.pdf может кому пригодится. У них такая же проблема была с подгрузкой лидеров, которые требовали много памяти и компресс с потерями был непозволителен.

#41
18:48, 27 окт. 2013

Если pvrtc не нравится, то как вариант можно попробовать 8битный png с палитрой ну и шейдером которые все это рисует.

#42
19:41, 27 окт. 2013

Frankinshtein
Ха, я не так давно тоже думал об этом.

Однако непонятно как хранить AA (который миксует цвета и делает пиксели полупрозрачными, тем самым добавляя еще больше уникального цвета).
Думаю тут можно взять 16 бит, и тогда в принципе 65к уникальных цветов должно хватить, чтобы все закодировать.
Но чего-то не решился идти на такое, не уверен, что тут нет подвоха. Есть у кого опыт с этим?

Этой техникой можно выиграть много памяти, если разобраться с АА и граблями.
Вот пример персонажа, много цветов ему базовых ненадо:

+ Показать

Худ сказал, что с АА выходит здесь около 7 тысяч уникальных цветов, если он не ошибается. Получается все можно вместить в 16 бит (65к цветов лимит). Но вопросы все те же, граблей не очень хочется схватить.

#43
19:52, 27 окт. 2013

> Еслиб были доступны шейдеры компьютеционные
SoulSharer, если бы ты насиловал мозг и сделал бы через PVRTC, на что бы у тебя ушло максимум 2 вечера - давно бы имел готовое и полностью работающее решение. Вместо этого ты 2ую неделю какой-то дурью занимаешься.

>взять 16 бит
>не уверен, что тут нет подвоха. Есть у кого опыт с этим?
подвох есть. на 64к цветов градиенты превращаются в "ступеньки" и это очень хорошо заметно.

>Худ сказал, что с АА выходит здесь около 7 тысяч уникальных цветов, если он не ошибается.
Он может и не ошибается, но на такого перса вполне хватит 32, самый максимум 64 цвета.

#44
19:57, 27 окт. 2013

slava_mib
> SoulSharer, если бы ты насиловал мозг и сделал бы через PVRTC, на что бы у тебя
> ушло максимум 2 вечера - давно бы имел готовое и полностью работающее решение.
> Вместо этого ты 2ую неделю какой-то дурью занимаешься.
Не могу не согласиться, но в тоже время была просьба сохранить 1:1 качество со стороны команды. Учитывая то, что еще и в Deponia все было с этим хорошо - есть некое давление со стороны. Правда судя по Deponia, я подозреваю, им пришлось анимации резать, чтобы все вместилось и результат - они в игре не плавные. (отчего много критики)

Насчет градиентов - да, верно подмечено. Но для персонажей их не намечается.

Страницы: 1 2 3 4 5 Следующая »
ПрограммированиеФорумГрафика

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