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

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

интерфейс графической части движка27 ноя. 201216:44#40
innuendo
> Получал кучу аллокаций\smart_prt\boost ? :)
упс, наоборот не делал это.Короче было все реализовано на хендлах без STL,boost.
SNVampyre
> Вопрос о том, зачем делать два разных класса, если внутри код одинаковый. Можно
> же просто сделать класс Buffer.
А, ну для OpenGL таки так и есть, незабыть только про разницу GL_ARRAY_BUFFER/GL_ELEMENT_BUFFER, но  для Direct3D там разные интерфейсы.
SNVampyre
> То есть для геометрических, контрол и эвалуэйт будут ещё три одинаковых класса?
Тут я ничего сказать не могу. Не работал с геометрическими. Если там разница только в enum, то в OpenGL будет только единственный класс с 1 параметром.
>И при переключении шейдеров эти данные будут заливаться по новой?
Нет. Вообще это технические делали. Можно помечать изменения констант, заливать частично и т.д. если уж так хочется, Но лучше лить все за 1 раз, чем частично.
Универсальным решением является хранение часто изменяемых констант в непрерывной области буфера, лить за 1 раз, вроде бы через glBindBufferRange.
интерфейс графической части движка27 ноя. 201216:30#38
SNVampyre
> Может мне кто-нибудь объяснит, зачем разделять IndexBuffer и VertexBuffer, а
> также VertexShader и FragmentShader? Если нужны будут какие-то ещё буферы
> (например юниформов) или
Насчет индексного буфер. К примеру у тебя есть много текста. Ведь вершинный буфер может быть разный, в вот индексный одинаковый, обновляем разные буферы для текста но индексный используем один и тот-же. Для ландшафта для лодов, можно подсовывать разные индексные буферы.
С шейдерам все понятно для совместимость с Direct3D, для подмены лодов, вершинный тот-же, пиксельный подставляем упрощенные к примеру.
Насчет буферов юниформов. Тут спорный момент, все зависит от архитектуры. Можно вообще хранить весь буфер констант и заливать его прямо в реализации шейдера, и сам класс буфера для юниформов может отсутствовать, ведь он нужен только внутри шейдера.
интерфейс графической части движка27 ноя. 201215:24#33
innuendo
>а ты предлагаешь ему фичу одного API ?
опять не угадал.
> спрашиваю - что сие значит ?
сие значит использовать это расширение(что-бы убрать объединение 2 шейдеров в программу) и работать отдельно с шейдерами(пиксельный вершинный) для каждого API через классовую обертку VertexShader/PixelShader
> Скажи, это твоё личное мнение или "отцов" ? :)
это мое мнение я так делал в нескольких проектах.
интерфейс графической части движка27 ноя. 201214:24#30
nes
>С хендлами не очень удобно работать,
у тебя будут классы буферов, текстур, шейдеров наследуемых от хендлов. Удобство остается, я же писал про это.
> по сути весь функционал описанных мной интерфейсов придется перенести в
> VideoDevice, и получится каша.
Еще большая каша будет с виртуальностью и кучей методов в классах. Кучей выделений памяти, умных указателей boost и т.д.
innuendo
> Какой смысл хранить api dependency реализацию ?
Где было предложение это хранить? Если ты что-то не понимаешь то лучше спросить, что имелось ввиду, а не писать бред.
Вообще я предложил использовать это расширение в случае OpenGL, что-бы не городить лишний класс ShaderProgram, но странно что ты про это не подумал.
интерфейс графической части движка27 ноя. 201212:55#24
nes
...
virtual ~Raster(void) = 0 {};
...
virtual ~VertexBuffer(void) = 0 {};
...
virtual ~IndexBuffer(void) = 0 {};
...
Итак, у тебя будет 1000 буферов будет?. Зачем это все наследовать так сильно, ради ООП ? зачем виртуальный деструктор? что-бы лишние 4 байта хранить и гонять CPU по современному C++ коду?

sizeof(IndexBuffer) ? явно десяток байт. И статически хранить можно. Больше 1000 буферов, текстур шейдеров, на сцену это уже не так хорошо.

Лучше иметь некий Handle, класс хранящий индекс в массиве уже созданных для конкретного API буферов, текстур, шейдеров, рендер таргетов. Этот Handle будет просто обращаться к
VideoDevice и звать у него соответствующие методы.

Мы сохраняем интерфейс доступа к ресурсам, избегая динамической памяти для отдельных ресурсов. Ведь явно ты будешь хранить типа std::vector<IndexBuffer *> или std::vector<shared_ptr<IndexBuffer> >. Релизация упрощается. можно избавится от ненужного наследования.
А так будет еще проще, типа: std::vector<Direct3DIndexBuffer> или еще проще ConstArray<Direct3DIndexBuffer, MAX_BUFFERS>

..
virtual u16 getIndexCount(void) const = 0;
..
Нафига это? число индексов обычно хранить некая RenderOperation.
virtual void update(const void* data, u16 startIndex, u16 indexCount) = 0;
Я бы возвращал успешность обновления буфера.А где некий:
bool Lock(Map)(void** data, size_t offset, sizeo_size) = 0;
bool Unlock(Unmap)() = 0;
?
  virtual VertexShader* getVertexShader(void) const = 0;
  virtual void setVertexShader(VertexShader* value) = 0;
  
  virtual PixelShader* getPixelShader(void) const = 0;
  virtual void setPixelShader(PixelShader* value) = 0;
Если  это для мультирендера? Лучше посмотри в строну GL_ARB_separate_shader_objects.
Не устраивает производительность std::map26 ноя. 201212:50#75
laMer007
>Есть можете попробовать (но надежд не питайте) boost::flat_map - более кешфрендли (поговаривают, что и консолифрендли)
случайно не тестировал в сравнении с stdext:hash_map, std::map, boost::unordered_map ?
OpenGLow-Problems26 ноя. 201210:41#8
Executor
> ибо фильтрацию ты не меняешь в рантайме и выставлять каждый кадр не имеет
> смысла.
Вдалеке можно отрубать анизотропную фильтрацию, что может повысить производительность.
QeffectsGL (графический мод для OpenGL-игр)23 ноя. 201218:27#45
FROL
>Хм, пардон если вопрос уже задавали, так у тебя транслятор GLSL=> HLSL ко всему прочему есть?
Direct3D не в этом проекте. Тут просто улучшенная библиотека для OpenGL ты глянь описание что за эффекты она добавляет.
Глянул исходники. Шейдера Doom 3 используются как обычно. Финальную картинку автор просто наверняка делает постпроцессом используя шейдера написанные на GLSL + остальные эффекты.
QeffectsGL (графический мод для OpenGL-игр)23 ноя. 201218:15#44
FROL
> Или там на Cg ?
В Doom3 голые asm шейдера
Моласар
Кстати да, что ты с шейдерами сделал??? Неужели переписал на Direct3D asm ?

Правка: ступил.

Правка: 23 ноя. 2012 18:28

std::bad_alloc at memory location с чего ето вдруг23 ноя. 201218:06#8
Anders333
если Visual C++ то воткни _heapchk
Космический движок SpaceEngine23 ноя. 201213:09#2609
RPG
> - OpenGL можно предварительно собрать в ассемблер - он быстрее грузится
про какой ассемблер  идет речь? arbvp/arbfp ? если да то это врядли возможно с OpenGL 3.3 и выше. glEnable(GL_ARB_*_PROGRAM); даст GL_INVALID_OPERATION
и это уже очень устарело.
Если GL_NV_vertex_program4/GL_NV_fragment_program4 и выше то по возможностям это потянет, но опять таки не уверен насчет работоспособности, ну и это только nVidia. Компилить в asm через Cg скорей всего.
т.е. с совместимостью будут проблемы. Единственное использовать старый контекст со современными расширениями.
BBox для заскиненного меша21 ноя. 201219:06#20
Executor
> Можно подробнее? Не понятно как это.
Ну я думаю для каждого кадра у тебя BBox всей модели.
Ты когда получаешь позицию кости между кадрами делаешь интерполяцию позиций. Сделай так-же для min/max точек BBox.
По поводу трансформации BBox программным способом просто точки min/max пересчитывай зная поворот, смещение, масштаб
BBox для заскиненного меша21 ноя. 201218:01#6
Executor
Интерполяция min/max точек при расчете иерархии костей.
При изменении трансформации программно, пересчитывать min/max точки бокса.
3DSMax Export Bounding box + Animation21 ноя. 201216:41#4
Aroch
если попробовать getTriObjectFromNode(нода с твои мешем, нужный кадр анимации, ...)->GetMesh()->getBoundingBox(...
Я думаю IGame внутри это делает уже. А она наверное это вызывает.
Windows vs MacOS21 ноя. 201215:36#102
innuendo
>Это что, вот когда отваливается gdb - совсем печально :)
отваливался вроде уже. Это мне еще все предстоит пережить.
> linux обычный не поможет ?
Его нужно ставить и т.д., и Linux не полностью POSIX совместимый хотя это наверное фигня, а вот Mac комп с MAC OS X нахаляву на время появился.
Кирюшык
> Ну да, Xcode значит отстой а Code::Blocks рулит?
Ну естественно Code::Blocks по уровню наверное сливает XCode. Просто он привычнее после Visual Studio, и на нем я быстрее собрал исполняемый файл. Мое мнение по поводу XCode еще не полностью сформированное. Скорей всего я проект переведу на него. И я его полюблю несмотря на ненависть к Objective C(это не буду обсуждать, даже не стоит начинать)

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

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