в статье о DoF http://steps3d.narod.ru/tutorials/depth … orial.html в конце есть два скриншота, они одинаковые (оба dof-1), при этом на сервере лежит файл dof-2

Так же главная страница (да и небось не только она) не проходит валидацию, а ссылочка на неё есть...

Отредактировано st0ke (2008-11-25 18:58:20)

Нашел несколько ошибок в статье "Интеграция скриптов на Lua с С++" в шаблонных враперах.

1. В callLua0 (lua-templ.h) в строке 170 пропущен индекс, из-за чего при использовании этого шаблона происходит ошибка компиляции:
           
             fromLua      ( lua, res ); заменить на fromLua (lua, -1, res)

2. Этот же шаблон callLua0 построен таким образом, что при вызове нам нужно специфицировать вручную тип возвращаемого значения (например, целым): callLua0<int>(L, "myFunc"), что не удобно, и отличается от вызовов подобных функций callLua1,2 и 3. Можно этот шаблон сделать по тому же подобию, что и callLua1, 2 и 3 т.е. тип возвращаемого значения передавать через аргументы:

template <typename R>
bool callLua0 ( lua_State * lua, const char * funcName, R& res )

3. В этих же шаблонах callLuaX отсутствуют функции, которые ничего не возвращают. Например, для callLua0 можно было бы сделать перегрузку (подобное можно сделать для всех callLuaX):

bool callLua0 ( lua_State * lua, const char * funcName )
{
            lua_getfield ( lua, LUA_GLOBALSINDEX, funcName );
lua_pcall    ( lua, 0, 0, 0 );                   

return true;
}

4. Все шаблоны определены как обычные функции, что не позволяет их использовать в разных С++ модулях. Одно из решений, определить их как static или даже static inline.

5. Не очистка стека после вызова callLuaX. Можно было бы вызывать lua_pop() в callLuaX после вызова fromLua.

После всех исправлений и усовершенствований у меня получилось примерно вот что:

//для вызова луа функций, которые не возвращают значения (без агрументов)
static inline bool callLua0 ( lua_State * lua, const char * funcName )
{
lua_getfield                 ( lua, LUA_GLOBALSINDEX, funcName );
lua_pcall                     ( lua, 0, 0, 0 );                   

return true;
}

//для вызова луа фукнции, которая возвращает 1 значение (без агрументов)
template <typename R>
static inline bool callLua0 ( lua_State * lua, const char * funcName, R& res )
{
lua_getfield     ( lua, LUA_GLOBALSINDEX, funcName );
lua_pcall        ( lua, 0, 1, 0 );                   
bool ret = fromLua                     ( lua, -1, res );   
lua_pop    (lua, 1);
return ret;
}

//тоже самое для callLua1
template <typename R, typename A>
static inline bool callLua1 ( lua_State * lua, const char * funcName, R& res, A arg )
{
lua_getfield ( lua, LUA_GLOBALSINDEX, funcName ); 
toLua            ( lua, arg );                      
lua_pcall    ( lua, 1, 1, 0 );                   
bool ret = fromLua ( lua, -1, res );   
lua_pop    (lua, 1);
return ret;
}

template <typename A>
static inline bool callLua1 ( lua_State * lua, const char * funcName, A arg )
{
lua_getfield ( lua, LUA_GLOBALSINDEX, funcName );   
toLua          ( lua, arg );                      
lua_pcall     ( lua, 1, 0, 0 );
return true;
}
//и так далее...

Добрый день!
В Вашей статье "Расширения NV_transform_feedback и EXT_transform_feedback" (http://steps3d.narod.ru/tutorials/nv-tr … orial.html)
есть небольшая опечаточка - glEbdTransformFeedbackNV вместо  glEndTransformFeedbackNV

C ув. =[ 0r@ngE ]=

Отредактировано =[ 0r@ngE ]= (2009-03-30 16:49:14)

И снова в RSS пусто ):

StepsFramework/3D/Vector4D.h:
Очень странный код функций length(), lengthSq(), distanceToSq() и distanceTo().
В них напрочь отсутствует какое-либо упоминание четвертой компоненты вектора.

PS: Судя по съехавшему форматированию в определении этих функций - это последствия копипаста.

Отредактировано matr (2009-10-27 11:26:05)

"О зыках", а не "О языках" хотят поведать нам здесь: http://steps3d.narod.ru/humour.html

Алексей, есть пожелание разместить ваши библиотеки и фреймворк в каком-нибудь публичном репозитории SVN/Git/Mercurial,
чтобы отслеживать изменения было удобнее.

Я не предлагаю весь сайт целиком перевозить, а только разместить framework и libtexture где-нибудь на sf.net, bitbucket.org, code.google.com, etc.

Как вариант, я так же могу предоставить instance trac'a с удобной вики для статей (и возможностью переноса туда старых статей без каких либо проблем). Вики великолепно работает с Latex, GraphViz, имеет интеграцию с SVN и разделом закачек.

Вы видимо не очень внимательно читали эту статью. А точнее презентацию. А она, как и все подобные работы SCEE R&D является просто перлом оптимизаторской мысли. Но с жесткой привязкой к конкретному железу. А точнее, даже модулю железа. В данном случае к PPU. Правда и Q&A отдел там дерет так, что описанное является просто детским лепетом.

Дык вот. В этой статье Сонивцы пропогандировали две вещи - реорганизаци кода с целью улучшения branch prediction и линеаризацию памяти с агрессивным подходом к кешериванию (опять же, все хорошо только в ос реального времени. Появление тяжелой многопоточности (и уж боже упаси многозадачности) приводит к тому, что после переключения потоков ранее выполненный префетч оказывается бесполезным.) Нигде и не было речи ни о красночерных из STL (при том что от его использования отказываться авторы отнюдь не торопились), использование которых даже не стандартизированно и уж тем более о B деревьях. Речь шла не о снижении обращений к памяти (дерево обходилось полностью, что делает это невозможным), а о жестком, тщательно оптимизированном кешировании данных.

У меня серьезные сомнения, что B-деревья будут сильно эффектвней в описанном в статье случае. И уж тем более на операциях вставки/удаления. Они используются только там, где операции чтения/изменения происходят значительно чаще операций вставки/удаления. И используют их только тогда, когда объем данных не помещается в оперативную память. О кеше там ни слова - деревья не бывают cache-friendly.

Бгг. 11к нод - сранительно малый объем данных. Во-вторых проблемы с кешем при использовании "дерева" начинались с 3-го элемента и происходили от невозможности префетча не линейно расположенных данных. Ни о каком уменьшении обращений к памяти не шло - дерево в любом случае обходилось полностью. Речь шла о возможности предсказания обращения к памяти.

Что значит у STL? У стандарта? Там сказанно - "делайте не кеш-френдли код"? У векторов? У списков?
Никто, нигде и никогда не говорил, что ассоциативные контейнеры должны использовать только красно-черные деревья. Гарантируется только ассимптотика операций над контейнером. Красно-черные деревья выбираются из расчета оптимальной производительности в общем случае. Естественно, что алгоритм, заточенный для частного случая скорее всего будет быстрее. Только вот работа программиста нынче не очень дешева. И для большинства простых ситуаций тот же std::map великолепно подойдет. А вот когда становится понятно, где приложение упираемся в производительность, тогда и надо менять generic алгоритм/контейнер на специфичный. И при адекватном использовании С++ делается это абсолютно безболезненно.

C процессорным - нет. А вот значительно уменьшить колличество чтений они могут.

INSERT/DELETE опреции значительно медленнее SELECT/ALTER

Вы, при этом, ссылаясь на статью говорилили о B деревьях. Я лишь поправил Вас в том, что деревья не причем. Ибо в противном случае некоторые посетители сего форума тут же ломанутся их писать, а потом на гд.ру будут всем компостировать мозг тем, что их гениальная реализации работает не так, как они хотели.

Речь шла о ассоциативных контенерах, разве нет? Мне, например, крайне редко нужен функционал из "разницы" между std::string и QString. Остро не хватает только возможности работы с форматными строками. И то, нужна эта функциональность кране редко.