Компьютерная графика

Информация о пользователе

Привет, Гость! Войдите или зарегистрируйтесь.


Вы здесь » Компьютерная графика » Дзен » На тему DеRьMа.


На тему DеRьMа.

Сообщений 1 страница 21 из 21

1

Уважаемый Steps3D, перестаньте выкладывать DеRьMо на главную страницу! Это вообще не актуально.
Мне такое  DеRьMо не приходит, моим друзьям тоже; нечего регистрироваться и подписываться на новости на сомнительных сайтах.

0

2

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

0

3

Steps3D написал(а):

Причем тут сомнительные сайты, подписка на новости и т.п. ?

Просто я такого не встречал. Или просто не обращал внимание...

Влюбом случае сайт не о DеRьMе, так зачем его сюда выкладывать?

0

4

Ещё на тему дерьма. Что-то хостинг, поддерживающий этот форум, совсем оборзел! Сначало эротику стали выкладывать в рекламе, сейчас вот встретил вопрос - "оргазм - лишённый окраски - это:". Это, на мой вгляд, совсем отвратительно.

0

5

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

0

6

Steps3D написал(а):

Это бесплатьнй хостинг, так что претензии к нему неуместны

Дык вам уже два раза предлагали совершенно бесплатно переехать на платный хостинг) Так что действительно, претензии не уместны

0

7

Дело не в претензии, просто я предпочитаю иметь контроль. Несколько лет назад была уже попытка подобного переезда и через несколько месяцев все вернулось снова сюда (не считая потерянных сообщений в форуме).
Код надо переносить в репозиторий, я склоняюсь к гуглокоду, просто код давно пора серьезно переписать и ориентировать на новые версии OpenGL
Скорее всего перенеся работу с текстурами и расширенями на существующие библиотеки (DevIL, GLEW) - насчет изображений я полностью уверен, про GLEW еще какие-то сомнения остались.
Ну и понятно, чтобы весь фреймворк компилировался в одну библиотеку и не надо было постоянное все файлы перекомпилировать.
Когда что-то более-менее работающее будет я собираюсь это перенести в репозиторий, а пока можно пообсуждать.
Мне интересны какие есть идеи

0

8

Steps3D написал(а):

Дело не в претензии, просто я предпочитаю иметь контроль.

Ok, whatever. Хотя я гарантирую работу минимум на ближайшие 14 месяцев))

Steps3D написал(а):

про GLEW еще какие-то сомнения остались.

Напрасно. GLEW не имеет runtime оверхедов GLEE, саму библиотеку можно генерировать прилагающимся скриптом по списку нужных расширений.

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

0

9

Насчет GLEW я наткнулся на непреятную фичу - без выставления glewExperimental у меня не подключились VAO (на последних драйверах и GeForce 460)
Иногда возникает ощущение, что проще допилить libExt - дать поддержку GL 4.1 и наиболее важных расширений. Как-то тот факт, что VAO почему-то оказались в разряде экспериментальных очень растроил

Еще очень хочется выкинуть вообще использование STL - меня уже достали дебильный класс string, не имеющий аналога strlwr/strupr, методы вроде remove_if, которые ничего не удаляют и ориентация на фактически макросы. Основное, что меня пока удерживает - это замена стандартных классов своими.
Интересно было бы узнать Ваше мнение.

А чем раздражает именно народ ?
У меня нет ощущения, что именно это сдерживает выход новых статей - там главное разобраться, сделать примеры и текст.

0

10

Steps3D написал(а):

Интересно было бы узнать Ваше мнение.

Я бы советовал вам посмотреть на то, что уже сделано.

http://www.nopper.tv/opengl.html - у этого человека есть примеры, вместе с которыми поставляются мего-класные, лаконичные, продуманные модули. Его талант даже на opengl.org ценят.

0

11

Steps3D написал(а):

А чем раздражает именно народ ?
У меня нет ощущения, что именно это сдерживает выход новых статей - там главное разобраться, сделать примеры и текст.

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

Steps3D написал(а):

методы вроде remove_if

remove_if очень оптимален, для контейнеров типо вектора. И вот честно, мне еще никто не показал, как сделать вектор лучше, чем он реализован в STL.

Steps3D написал(а):

меня уже достали дебильный класс string, не имеющий аналога strlwr/strupr

Если вы про чудо вброс с галвной страницы, то это оформляется в шаблонный метод из одной строчки и не имеет runtime оверхеда. Чего не скажешь, например о NSString, вызов каждого метода которой в лучшем (и крайне редком) случае имеет оверхед на вызов C-метода, в среднем эквивалентен виртуальной функции, в худшем - до 3 раз медленнее, чем виртуальный вызов (я уже приводил пруфлинки на эту тему). И я не могу сказать, что [NSString stringWithCString:"foo" ecoding:NSUTF8StringEncoding] выглядит гораздо лучше, учитывая, что подобные действия приходится делать чаще, чем toupper. При это std::transform имеет (в релизной сборке) нулевой оверхед на вызов и применим к любым контейнерам. Единственное, чего мне не хватает в std::string - метода, аналогичного QString::Arg. И то, необходимость в нем стоит достаточно редко. А весь тот бред на манер Osp::Base::String или, боже упаси, NSString - используется крайне редко, и по логике, не имеет отношения к строкам вообще. Мы с вами не однократно уже спорили на эту тему, и я отлично понимаю, что эти споры бесполезны, но все же, давайте к таким вбросам делать приписки "ИМХО", а не выдавать их за истину в последней инстанции. На gd.ru как-то был мего эпичный спор на тему STL. Противники STL в итоге сами загнали себя в угол, но при этом не прекращали крайне ожесточенных попыток убедить всех, что они правы. То, что вам очень не нравится С++ - уже всем давно понятно. Но зачем постоянно давать нелепые ссылки класса "C++ is bullshit", в которых цепляются к конкрентным вещам на конкретных платформах, причем то, к чему они цепляются одинаково справедливо для любого компилируемого языка? Зачем постоянно приводить некие методы из языка и постулировать, что "они bullshit, вот Obj-C сделанно все круче. Фиг с ним что в n раз медленнее (эпичный NSArray с около-логарифмическим временем доступа к элементу), но вы смотрите как круто"? Зачем, в конце концов, вообще использовать этот язык в своих примерах? Почему не писать на С? Или даже не на Python? То, что язык используется порядка 20 лет, и ему не нужен iPhone, что бы держаться на верху списка самых используемых языков уже говорит о том, что все ошибки в дизайне языка (да, они есть, и их достаточно много) компенсируются его возможностями. Особенно если уметь их применять, а не говорить, что жизнь язык - очень плохая вещь.

Скрытый текст:

Для просмотра скрытого текста - войдите или зарегистрируйтесь.

Steps3D написал(а):

Насчет GLEW я наткнулся на непреятную фичу - без выставления glewExperimental у меня не подключились VAO

Какая версия? Причем не GLEW, а драйвера? Разработчик говорит, что это связанно с тем, что драйвер не всегда корректно возвращает строку с расширениями, если часть из них является экспериментальными в драйвере. Код инициализации VAO (да вообще любого расширения) выглядит так:

Код:
#ifdef GL_ARB_vertex_array_object
  CONST_CAST(GLEW_ARB_vertex_array_object) = glewGetExtension("GL_ARB_vertex_array_object");
  if (glewExperimental || GLEW_ARB_vertex_array_object) CONST_CAST(GLEW_ARB_vertex_array_object) = !_glewInit_GL_ARB_vertex_array_object(GLEW_CONTEXT_ARG_VAR_INIT);
#endif /* GL_ARB_vertex_array_object */

Очевидно, что glewExperimental нужен для инициализации только в том случае, если драйвер не вернул VAO в строке расширений. Такая проблема есть, например, на 190.xx драйверах. В любом случае, на его поддержку не надо тратить собственного времени и он вообще не имеет зависимостей при сборке (не нужно даже наличие opengl хедеров).

0

12

Насчет remove_if - я имел в в иду уродское название метода, который вопреки названию ничего не удаляет
Про строки - тот же QString ууделывает std::string под удобству
Насчет нулвевого оверхеда - это в теории. А вот как на практике. В С++ inline необязателен и компилятор имеет право его игнорировать.
И просто удобно иметь в классе строки необходимый набор методов, который у std::string кривой и недостаточный.
Насчет QString::Arg полностью согласен - намного лучше всех этих стримов (которые кроме как для лога ни для чего больше не годятся)

Про obj-c я ничего в этот раз е писал и хорошо понимаю какой там оверхед - но за него я получаю гибкость на runtime.
Про GLEW -  я написал - драйвера самые свежие, glew-1.5.6, при этом GLEW говорит что _ARB_vertex_array_object поддерживается, т.е. IMHO это странность GLEW

У нас уже повторяется обсуждение C++/STL и т.п. - да я согласен, что для определенного (но узкого круга задач) С++ очень удобен. У него очень удобная модель работы с АДТ (вроде классов vec2, mat4 и т.п.). Но вот называть это ООП - это IMHO не верно

Мне было интересно узнать Ваше мнение на тему переписывания кода, а вместо этого Вы стали писать какой плохой obj-c :((

0

13

Steps3D написал(а):

Насчет нулвевого оверхеда - это в теории

C шаблонами компилятору всегда проще раскрутить в инлайн. Особенно с однострочными шаблонами. И уж тем более это будет слелано в релизной сборке. Про слово inline я не говорил. Я говорил про in-place инстанцирование.

Steps3D написал(а):

но за него я получаю гибкость на runtime.

В соседней ветке я уже задавал вопрос - когда она вам реально была нужна? То есть не в аккадемическом примере, что дескать можно вызвать метод по строчке его сигнатуры? Я могу хоть минимально представить себе ее необходимость в языках, понимающих eval. Но в компилируемых языках - увольте. К тому же по факту, ряд "супер" возможностей Оbj-C, например делегирование, реализуются на С++ чуть ли не построчно. Оно, конечно, нельзя использовать id (хотя можно, можно, было бы желание) в качестве типа делегата, но в промышленном коде никто и никогда не будет использовать id. В первую очередь это небезопастно, особенно для библиотечного интерфейса. Попытка сделать это безопасным приведет к резкому (и абсолютно не оправданному) падению производительности. Так что "гибскости рантайма" всегда будут стараться избежать за счет строгой, статичной типизации. Более того, это касается не только Obj-C.

Steps3D написал(а):

glew-1.5.6,

Попробуйте воспользоваться 1.5.7. Приведенный код из него.

Steps3D написал(а):

У нас уже повторяется обсуждение C++/STL и т.п. - да я согласен, что для определенного (но узкого круга задач) С++ очень удобен. У него очень удобная модель работы с АДТ (вроде классов vec2, mat4 и т.п.). Но вот называть это ООП - это IMHO не верно

Ну да, а Хелм и компания - сборище не понятных людей. Кстати они совершенно спокойно приводили примеры как C++, так и на Smalltalk.

Steps3D написал(а):

Мне было интересно узнать Ваше мнение на тему переписывания кода, а вместо этого Вы стали писать какой плохой obj-c

Простите, но фраза "омерзительный бред" принадлежит не мне. И я не говорил, что Obj-C плохой конкретно сейчас. А мнение, какое мнение? Что конкретно обсуждать? Замену libExt на GLEW? libTexture на Devil? Но с этим и так более менее все понятно. Выбрасывание STL из кода? А какие у этого плюсы? Что это даст? Сколько раз в конкретно коде фреймворка вы нуждались в недостающих методах string? Сколько раз вам мешала "убогость" алгоритмов (если вы вообще их использовали)? Как бы в чем от этого будет профит?

Steps3D написал(а):

Насчет remove_if - я имел в в иду уродское название метода, который вопреки названию ничего не удаляет

Он удаляет объекты, но по ряду причин не изменяет длину контейнера. Причины, кстати, хорошо описаны у Алены-С++

0

14

crsib написал(а):

Как бы в чем от этого будет профит?

Или Steps3D говорил о модулях для OpenGL 4 или я не в теме.

0

15

DungeonLords написал(а):

Или Steps3D говорил о модулях для OpenGL 4 или я не в теме.

И причем тут STL? O_O

0

16

Профит в том, что по побольшому счету STL  там нафиг не нужен - максимум строки и несколько мэпов. И мне лично больше нравится не template-код, а нормальные один раз откомпилированный код, которые легко отлаживается и полностью предсказуем
И не кидает exception-ов, намного быстроее компилируется.

А мне например постоянно мешается кривизна std::string, когда надо парсить текстовый файл и хочется иметь простые и понятные контейнеры
Почему remove_if сделан так, что он не соотствует название -мне по барабану, просто зачем тогда было выбирать заведомо неверное имя

Мне было бы действительно интересно услышать мнение насчет фреймворка для GL4, а не продолжать старый флейм (я уважаю Ваше мнение, но я с ним не согласен и не вижу повода соглашаться - на каждый язык/фреймворк найдется достаточно дейстивтельно поддерживающих людей, Вы поддерживаете одно, я другое)

ЗЫ. А Вы согласны у высказыванием Страуструпа, что c00x сделан для облегчения изучения зыка ? :))))
ЗЗЫ. Давайте все-таки закончим флейм и перейдем на графику ?

0

17

Steps3D написал(а):

И не кидает exception-ов, намного быстроее компилируется.

После самсунговской бады я исключения вообще вдвойне полюбил. Уберубогий способ, основанный на goto вообще не приносит счастья. Эти молодцы даже SjLj умудрились отрубить...

Steps3D написал(а):

А Вы согласны у высказыванием Страуструпа, что c00x сделан для облегчения изучения зыка

Ну да. Он местами очень забавно шутит. Мне, в принципе, нравятся лямбды и decltype с auto. Глубины дао r-value reference и move-only конструкторов я пока не познал во всей полноте. variadic темплейты применимы сранительно редко, поэтому мне на них глубоко все равно. Нормальных атомиков оченьма хочется, но разработчики компиляторов на них, почему-то, забили. То, как в стандарт внесли многопоточность тоже не потрясает воображения. При этом 90% процентов нововведений охватывет супертонкие материи, которые явно новичкам жизнь не улучшат.

Steps3D написал(а):

Давайте все-таки закончим флейм и перейдем на графику?

Да, согласен, это очень разумно.

Steps3D написал(а):

Мне было бы действительно интересно услышать мнение насчет фреймворка для GL4

Ну, он видимо нужен) Просто не совсем ясно, что понимается в данном случае под фреймворком...

0

18

Ну, он видимо нужен) Просто не совсем ясно, что понимается в данном случае под фреймворком...

Некоторый набор простых классов и примеров - обертки над основны GL-сущностями
Например - Program, VertexBuffer, Texture, Sampler и т.п.
Работу с текстурами по-видимому проще перевести на DevIL, добавить поддержку 1-2 простызх форматов для моделей (ase, obj и т.п.)

0

19

А что такого в самсунговской баде ? :)

0

20

Steps3D написал(а):

А что такого в самсунговской баде ?

Они решили, что исключения дают нечто, под названиям large runtime overhead (что бы это не значило на gcc 4.4.1, с его полной поддержкой RAII и принципом "нет броска - нет оверхеда"), хотя на айфонах с тем же компилятором его почему-то нет. Да, я не спорю, в случае броска оверхед есть. Но исключение оно на то и исключение, что бы не происходить от каждого дуновения. Затем чуваки решили, что SjLj это архаично и не безопасно. Финал абсолютно эпичем. Самсунг на полном серъезе предлагает использовать goto для обработки исключений.
То есть делать прмерно следующее:

Код:
Osp::SomeOspClass foo;
if( IsFailed(foo.Construct ( some strange args ) )
     goto Catch;
...

    Catch:
//Try to do a cleanup, if you can figure out, what to clean
   return E_FAILED;

Более того, у них есть специальный макрос для верхнего if.

На этом их эпичность не заканчивается. Вообще, такое ощущение, что чуваки, которые проектировали и разрабатывали это всю жизнь работали только с Java и даже до старта разработки не знали о том, что С++ существует. Это приводит к тому, что чуваки везде пытаются громоздить Java-style конструкции. Например, у них есть библиотека контейнеров. Сделана она по, гм, идеологии, Java (хотя в данном случае больше похоже на Obj-C). Только вот что такое refcount (ну или GC) мама им не рассказывала. Зато они делают вид, что осознают проблемы владения объекта. Из-за этого у них:
1. Есть метод Clean(bool), который при передаче в него true вызывает delete у содержащихся в нем объектов. Деструктор вызывает Clean(false), так что если перед ним забыть в нужных случаях написать этот самый Clean(true), то случится утечка.
2. Есть 2n  методов, заканчивающихся на N. Это означает, что контейнер возвращаемый (а в ряде случаев, у делегатов, передаваемый) методом сам владеет объектами внутри себя. То есть без Clean(true) утечет память. Ну и естественно контейнер может хранить только наследников Osp::Base::Object, как же можно иначе.

Ну и бесит, например, подход к libc. Используют сильно порезанную версию newlib, при этом хедеры от полной версии libc. В купе с weak-linkage это доставляет много счастья при переносе чужих библиотек на Bada.

Зато в последней официальной прошивке вейва для России (это важно, с евро прошивкой все тип-топ) драйвер GPU может случайным образом уйти в deadlock при загрузке текстуры. Потом аппарат минуты две просто намертво висит (только вытаскивание аккумулятора может его выключить), а затем демонстрирует красивое, нежно-голубенькое окошко, где говорит, что дедлок-ма в видеоподсистеме-ма. Причем из этого своеобразного BSOD телефон можно вывести только вытаскиванием батареи. Так что плохо все в самсунговской баде...

Отредактировано crsib (2010-11-08 17:59:51)

0

21

Забористую траву ребята где-то нашли :)))

0


Вы здесь » Компьютерная графика » Дзен » На тему DеRьMа.


создать свой форум бесплатно