Replies (28)

  • @deep, может и не умрёт. у меня просто нет времени сейчас.
  • @blooddy, Да времени всегда не хватает. Хоть увольняйся :) А вспомнил я про этот двиг, потому что появилось желание потестировать его, а оказалось что до самого рендер вроде как и не дошло дело. Хотя архитектура весьма удобная как мне показалось, да и к тому же апи максимально привели похожим к flash.display. Это как раз то первое что я бы сделал и о чем еще давно писал
  • @deep, ну это я сделал. а потом попался фриланс, а сейчас мне ваще не до программирования
  • @blooddy, не очень удобно только вышло с неймспейсом, изза него все классы у тебя по сути в одном каталоге получились. Не было планов оптимизировать это?
  • @deep, всё там нормально. как ы обном апи
  • @blooddy, да все не плохо, но
    internal namespace $internal;
    как бы ограничивает возможность использовать namespace только в пределах этого каталога.
  • @deep, как так и задумано. что собственно делает систему не ломаемой от кривых рук
  • @blooddy, Ага. Возможно ты прав. Но все равно жаль что разработка приостановилась. Будь тут хотябы зачатки рендера, я бы мог попробовать помочь и чтото тестировать/дорабатывать.
  • @deep, можешь считать что я жду новой алхимии. так как я хотел АГЛ через неё фигачить. и сразу в байткод а с этими ебучими парсерами.
  • @blooddy, Выскажу одну мысль, к которой пришел изучая различные 3д движки и различные подходы к реализации шейдеров.
    На примере пяти 3Д движков есть 4 варианта записи шейдеров. Есть вариант с as3 шейдерами, которые компилируются в agal, есть вариант с as3 шейдером сразу в байткод, есть вообще вариант своего языка шейдеров у Flare3D (FLSL), и есть движки которые используют просто АГАЛ.
    По моему все это порождает только проблемы, я уж согласен писать на этом ужастном асм подобном агале, чем изучать все эти 4 реализации.
    Плюс в добавок есть PixelBender3D, который смотрится весьма не плохо и есть движок который все шейдеры реализовывает в нем
    github.com
    Я это все к тому, что может стоит использовать этот богомерзкий агал и PB3D и не колбасить свой новый BLOODDYSL :)
  • @deep, у меня ж не 3д =) ты там ващей шейдеры писать не будешь. как ты этим двигло занимается. да мне пох на чём ты будешь свои шейдеры писать. сделаю тебе БайтЭррэй на входе, а чем ты его сгенеришь — мне пох. а внутри я буду юзать то что работает быстрее
  • @blooddy, ну я и в 3д движках по идее шейдеры писать не буду, по крайней мере в 95% мне хватает готовых решений. Один раз один шейдер немного пофиксил и все :)
    Конечно если ты решил делать так как решил, то стоит идти до конца :)
  • @blooddy, какая связь между новой алхиимей и написанием шейдеров? шейдеры для 2д проще некуда, 2-3 конструкции на шейдер, откомпилить это в байтэррей нужно всего один раз и потом подставляй где нужно

    алхимия не заставит работать гпу шейдеры быстрее
  • @kutu, шейдеры — байтэррэй. его быстрее собирать на алхимии.
  • @blooddy, ты шейдеры собрался 60 раз в секунду пересобирать?
  • @kutu, Да я вот тоже хотел это спросить и рассказать что обычно их собирают один раз и на всю программу. Но как то постеснялся чтоли
  • @deep, а вы не в курсе что они бывают динамические? например ты делаешь фильтр Glow с настройками. каждый раз когда захочешь изменить параметр — собирай новый фильтр. этот фильтр Glow надо сложить ещё с 3ми фльтрами, и соотвественно со стандартным фильтром. как вы это один раз сделаете — я хз.
  • @blooddy, все настройки обычно передаются как константы и это не требует пересборку шейдера.
    А вот несколько фильтров вместе — да, надо собрать вместе, но опять таки сборка пройдет один раз, а дальше только константами передавать параметры.
    Так что 60 раз в секунду пересобирать шейдер надо будет только когда ты 60 раз в секунду будешь менять набор применяемых фильтров :)
  • @deep, размер шейдера бывает большой. для каждого нового объекта надо создавать новый щейдер. я не уверен, что объекты создаются только в начале. и дело не в количестве раз в секунду. всех юзают ЖСОН, который уж точно 60 раз в секунду не вызывается.
  • @blooddy, если ты будешь для каждого объекта создавать два новых шейдера, вертексный и пиксельный, то ты больше ресурсов потратишь на то, чтобы во время рендеринга менять их туда сюда для каждого объекта
    шейдеры пишут и компилируют один раз и для всех объектов он один и тот же, меняют только параметры чезе vertex constant и если нужно через fragment constant
  • @kutu, ок =) пиши. я останусь при своём мнении.
  • @blooddy, да не, просто возможно мы с deep не видим проблему так глубоко как ты, у тебя явно больше опыта в написании core движков, чем у меня точно
  • @kutu, kutu прав
  • @blooddy, кстати, я там немного подсмотрел код, так там у тебя для баблинга и ему подобных создается вектор родителей. Так это вот. Проход по ссылкам на parent через while(item=item.parent){} будет минимум на 20% шустрее + отпадет надобность в постоянном обновлении вектора $parent. Если хочешь — могу что-то типа бенчмарка где-нибудь выложить.
  • @doctorstal, твой вариант не будет работать как надо. это рас. а второе пробег по вектору будет быстрее =)
  • @blooddy, 1. Под "не так как надо" ты имеешь ввиду фазу захвата?
    2. Заморочился, сделал сделал пару дополнительных тестов. Вышло, что в случае с простыми объектами проход по ссылкам быстрее, но в случае с тяжеловесными, типа спрайтов — вектор и правда быстрее.
  • @doctorstal, а ты в релизе тестил? у меня вектор всегда быстрее
  • @doctorstal, 1. фазу захвата, и удаление в процессе диспатча