GameDev.ru
/ GameDev.ru / Пользователи / Andrey / Сообщения на форуме пользователя Andrey (37 стр.)

Сообщения на форуме пользователя Andrey (37 стр.)

История про то, как Пятачок оптимизировал простой цикл14 дек. 201017:56#102
kas
> возможно про садка еще на Load hit Store.
> на пц такое не заметить.
я так и подумал, Значит остался толстый итератор для MSVC реализации STL
История про то, как Пятачок оптимизировал простой цикл14 дек. 201016:32#98
Suslik
>1) Почему итератор работает так медленно?
> 2) Почему operator[] работает так медленно?
В стандартной реализации от MS идет вызов через итератор, последний класс обертка над указателем, нужно asm код сравнить с STLPort, там итератор это тупо указатель, возможно про садка еще на Load hit Store.
Yet another совет по `Орхитектуре`11 дек. 201015:51#598
Z
> > осталось разобраться как фиксировать указатели для конкретных задач и сильно
> > ли
> > нужно последнее? много дает выигрыша и т.д. ?
> Не понял.
Все, сам разобрался.
Yet another совет по `Орхитектуре`11 дек. 201010:49#547
Z
> Вот кстати, про запись и чтение блобов - небольшой примерчик, своего рода
> влобнъй first generation код + мелкий пример:
спасибо! Отлично я на верном пути! осталось разобраться как фиксировать указатели для конкретных задач и сильно ли нужно последнее? много дает выигрыша и т.д. ?
Yet another совет по `Орхитектуре`9 дек. 201012:23#284
Executor
> Покажи как это устроено, я примерно понял, но так до конца и не смог понять как
> по этому int32 можно чтото делать с текстурой или любым другим объектом 3Д
> Апи...
> Вот есть IDirect3DTexture9, как до неё достучаться через int32?
int32 это тупо индекс массива где твои ресурсы и хранятся, вот и все, линейно все храниться в памяти никакого говно ООП и кучи интерфейсов, никакого abstraction penalty и всего остального.
struct Direct3DTexture {
IDirect3DTexture9* tex;
// other data
};

array<Direct3DTexture > textures; // где-то в классе рендер девайс
 
// внешний вызов
render->BindTexture(const Texture& tex, 1)
// примерная реализация
BindTexture(const Texture& tex, uint stage)
{

....
uint id = tex;
assert(id < textures.size());
pDevice->SetTexture(stage, textures[id].tex);
....
}
ReeV
> грубым c-cast'ом, я бы за это.....руки..отрывал
Ты наверное не понял реализацию. Какие касты?? ты про что вообще?
Yet another совет по `Орхитектуре`9 дек. 201011:09#274
Executor
> Не пойдёт?
Не пойдет, зачем тут виртуальный вызов и лишние абстракции, типа ООП круто? оборачиваем int32 в класс и подаем этот id в рендер девай/контекс и сразу имеем доступ к graphics API без лишнего кода и все в 1 классе, причем реализация работает для разных API.
Пишем отладчик для Lua 5.1 (комментарии)9 дек. 201010:47#3
Cherk
> Очень полезная вещь. Исходники я так понимаю закрыты...
Было бы еще на C++ лучше было бы.
Структура данных для вершинного буфера9 дек. 201010:42#12
Sergio
> На данные, которые будут заливаться в видеопамять
Так... этот указатель будет не валидный после того как ты залил все в видеопамять, вопрос зачем его хранить как членом класса?
Класс вершинного буфера должен хранить - API specific указатель и т.д., формат, размер, и режим использования(статический динамический). Больше в классе ничего не должно быть.
Зачем там указатель на видео память? Вся эта логика будет в методе Lock/Unlock/WriteData и т.д. и указатель будет временным в виде локальной переменной или как входной параметр.
> > в этот-же буфер? дак не влезет,
> Вот я про это и говорю.
И какой из вывод из этой идеи? Непонятная функциональность просчета нормалей прямо в вершинном буфере, формат которого физически не имеет нормалей, да непонятно для чего нужна? Ты по видео памяти хочешь шарахать и BSOD создавать?
innuendo
> так какой % ускорения ? 0.1 ? это какой-то синтетический тест ? вся сцена в
> одном vbo ?
Сравнивал на ландшафте. Общий вершинный буфер для всего ландшафта. Уменьшил число вызовов функция gl*Pointer, FPS возрос, где-то 10%. Почему бы не добавить это если там 3 строчки кода.
Структура данных для вершинного буфера8 дек. 201023:34#6
innuendo
> ну не смешите мои тапочки, это сильно ускорило FPS ?
у меня ускорило, ты число вызовов сравни для 100 патчей и подумай, потом пиши в таком контексте.
Структура данных для вершинного буфера8 дек. 201023:32#5
Sergio
>void* data;
не понял это указатель на что? На видео память или откуда данные в буфер заливать?
>
> > Залочить буфер посчитать нормали и разлочить или как???
> А если в данных буфера изначально не предусмотрены нормали?
Так ладно посчитал нормали, куда массив нормалей присабачивать будешь? в этот-же буфер? дак не влезет, или для других целей? если так то можно на этапе загрузки посчитать. Я что-то не понимаю твою идею.
Структура данных для вершинного буфера8 дек. 201023:19#1
Sergio
> и неплохо было бы менять формат эитх данных на лету (например в существующем
> буфере с координатами посчитать нормали)
Интересно зачем это нужно?
Залочить буфер посчитать нормали и разлочить или как???
> Ответ напрашивается сам собой - void*
это как понимать ?  или это имеется ввиду gl*Pointer ?
> с другой стороны теряется скорость
как тут теряется скорость, если это единственное решение, или я не так понял?
> Это довольно быстро и удобно, но не гибко
Зачем тут гибкость? имеем 4-5 форматов на весь движок, а больше и не нужно. Зачем все усложнять?
Вообще загадочно ты как-то все написал.
Кстати про буферы. Рекомендую GL_ARB_draw_elements_base_vertex, сокращает число вызовов gl*Pointer если рисовать со смещением. Додумались это добавить спустя много лет, причем начиная с версии OpenGL 3.0, хотя в Direct3D9 это можно делать еще самого начала.
gDEBugger теперь бесплатен! (комментарии)8 дек. 201013:33#13
Опа! круто однако!
Yet another совет по `Орхитектуре`7 дек. 201022:44#140
Pushkoff
> хочется сказать: поднимите руку все у кого GAPI подменяется на лету!!
у меня с команды в консоли в движке можно рендер менять :))) причем работает. Правда падает иногда - появляются иногда ошибки. Это конечно экспериментальная реализация.

Следующие темы >>

2001—2012 © GameDev.ru — Разработка игр