Tron

В перспективе, возможно планировалась. Я не сказал, что она реализована Вполне, у меня был редактор написан к 1ому движку на них. Потом поддерживать стало тяжело, чисто много кода. Отсутствие визуального редактора(тогда его еще не было или они были платные/ограниченные в чем-то) так же не сказывается положительно на поддержке кода. Это сильно зависит от архитектуры скриптовой системы. В ряде случаев это вполне подходит, например в случае моей скриптовой системы. У меня есть объект(был реализован враппер, он отыскивает объект в луа_стеке) с временем жизни и подсчетом ссылок - позволяет избежать постоянной перекомпиляции 1го и того же скрипта. Есть набор методов. Вызов которого осуществляется в своем отдельном потоке (GUIUpdate, SoundUpdate, AIUpdate и т.д), если он реализован для данного скрипта Т.Е есть GUIUpdateWorker, SoundUpdateWorker. А сами непосредственно Update методы могут дергать любые функции.

Подозреваю, что заточка под многопоточность, что эдакая "физ.сцена. Но могу ошибаться, не силен в ней. " Большие проекты на виджитах тяжело делать https://github.com/SonyWWS/SLED +еще BabeLua(Visual studio[editor+debugger]),Notepad++(Editor only) @Desertir, Смотря какой критерий. Если жесткая типизация - AngelScript/Squerell. К первому сейчас новый OA(кажется так) компилятор приделали. Jit делали уже. Но порог вхождения выше Возможно, но необходимо создавать отдельный lua_state в каждом потоке. EDIT: Не посмотрел на дату... Это SDK к движку, для создания новых компонентов, не более Ищи старые исходники на uraldev

Привет, а какая-нибудь движуха была за эти полгода/год, пока меня не было?

Так посмотри шейдеры и константы которые передаются в них Перенос проекта из 2005 в 2008 - просто смена 1 строки в файле версии(так во всех версиях до 2010 - там ввели новый формат файла проекта). Ничем не грозит.

Ошибка многопоточности (MSDN) Если проводить аналогию, с реальным миром - это что-то типа светофора на шоссе

Нет, это как раз уже новая версия. - см. дату последнего коммита. Как я понимаю, у них была ~эта(создание страницы 29 июня 2006 г) ​Edit:Добавлена дата

Bugtrap действительно по функционалу идентичен xrDebug, с одним лишь отличием - поддержка отправки крешдампа на сервер. Как я думаю: Выбор пал на BugTrap'a т.к он предоставляет еще и серверную часть - возможно в те времена этого еще не было. Я отключал bugtrap, т.к у меня были проблемы с его компиляцией под х64 - там много асм вставок

ах,да диалоги,я и забыл,что их можно в редакторе ресурсов создавать

Выходит я ошибся, признаю. Я по-моему собирал его без установленных MFC либ, на основании чего сделал этот вывод.

winapi

нет, не используется

@HESH, Да ты прав, не обратил внимание на ядро Только есть одно НО. Судя по википедии они изменили позиционирование индекса ядра. Ибо: У Haswell было: Стало:

Он тебе предлагает P/Invoke Вот туториал по нему. Минус техники - тебе придется это все писать в вручную. Это можно автоматизировать - взять SWIG. Но у него есть 2 минуса - надо будет тащить за собой две либы(Враппер над С++ кодом и враппер над C#, ну или включать сгенерированный код в файл проекта) + писать для него интерфейсы все равно в вручную. Я же предпочитаю C++/CLI, это помесь C# и C++, но с некоторыми особенностями. Из минусов - производительность. Но экспортировать проще - создаешь что-то типа такого: public ref class ManagedClass { public: ... void Method1 () { ptr->Method1(); } UnManagedClass* ptr; }; А в шарпах просто юзаешь ManagedClass. Полезные ссылки: http://habrahabr.ru/post/111071/ http://habrahabr.ru/post/47732/ http://www.codeproject.com/Articles/19354/Quick-C-CLI-Learn-C-CLI-in-less-than-minutes

@HESH, Нет, мне очень нравится этот подход, и я его одобряю - очень большая скорость разработки редакторов. Конкретно, с чем я столкнулся - у меня была C++/CLI либа - враппер+ редактор был написан на шарпах. Происходило где-то исключение, и все завершалось. Притом никак перехватить это исключение не получалось. И я думаю, что буду возраждать у себя эту версию, просто оконную систему перепишу(ее все равно надо переписывать) с 0 ээээ.. извини конечно, но как по мне это как-то бредово звучит,либо я тебя не понимаю.

Напрямую из С++ кода вызывать нельзя. Нужно делать C++/CLI, PInvoke библиотеку, тяжело дебажить (C++/CLI еще подхватывается дебаггером, а PInvoke при появлении исключения на низких уровнях, мне просто закрывал дебаггер) Qt я тоже так и не освоил, да и размеры мне его не нравятся и сама концепция(все в одном) Если я не ошибаюсь, то они переписывались, не знаю, как насчет внутренней структуры, но поддержка юникода там точно вводилась

Да, интел в этом году отошла от привычной схемы, и представила топы. Я же дал ссылку на Core i5-6600K Кстати, ходит слух про Skylake: http://www.3dnews.ru/918787?from=related-grid-auto&from-source=918846

Ну первая очевидная мысль - непереносимый код. Вторая это громоздкость кода. - много писать повторяющегося кода. Что из себя представляют элементы интерфейса WinAPI приложения? - это окна. Да-да, даже простая в понимании кнопка это окно, просто созданная с определенным дескриптором(числовая константа описывающая внешний вид). Например,обработку событий надо проводить в главной функции обработки событий. Epic Games писали под это свой фреймворк(WWindow), но потом забросили его и в 3ей версии все портировали на wxWidgets. Я в этом году, в плане типового расчета писал похожий(тема на выбор), но там не все предусмотрено(нет диалогов и т.д). Я не видел, что бы на чистом Wa делали, что-то сложное/красивое. Да и смысла нет писать сейчас на чистом WinAPI, ведь можно взять MFC/WxWidgets. Но MFC я бы тоже не советовал. (Аргументировать не могу, ибо ничего сильно сложного(не считая CryEngine Editor, но он написан на коммерческой реализации MFC-codejock) я лично не делал/ не видел на нем.) Можно с MFC портировать на wxWidgets, благо отличия не сильные. Что-то еще хотел написать, но вылетело из головы. Edit: WxWidgets по сути представляет собой враппер над WinAPI(под виндой), оконными системами под *nix (точно не знаю, надо посмотреть)

Нет, ты не понял. Они гонятся. Просто позиция интела относительно Devil's Canyon, что им нужны Z97 мамки. Он может завестись и гнаться на твоей мамке - но тут уже рулетка А чем мой вариант не устраивает? там разница 60 рублей, но ты получишь последнюю актуальную платформу(1151) +Можно найти гибридные мамки DDR3/4

EA-ничего не пилила, про рендер CE3 я ссылочку приложил CE2 - forward rendering+ ubershader(если верить gd просто ветвления шейдеров сделаны через дефайны, [управление дефайнами идет через код плюсов]) CE3-crysis2 - deferred lighting(aka light pre-pass, двойное рисование геометрии - сильная нагрузка на шину памяти[беда всех deferred техник]) CE3-crysis3 - deferred shading(единожды рисуется геометрия+притом gbuffer удалось "ужать") CE-Rome - там уже появился некий hybrid render, презентацию я помню смутно, а саму игру не смотрел. По коду, мне встречались упоминания Forward Shading техники, но мне кажется, они его "рядом" реализовали CE4-го поколения, действительно очень "чистый" по сравнению с предыдущими версиями. И читать его приятнее. А я не говорил, что там используется PhysX. У них свой физ. движок. PhysX, да прилагался как аддон(Edit: по слухам), при лицензировании CE3, но его как правило никто не брал(я таких случаев не знаю).(Не считая демок с партиклами от NV) Так они недавно появились и официально в PhysX сейчас не входят. ( Не путайте пакеты расширения Apex/Flex и Core версию). Волосы сейчас делают тесселяцией Эм.. вы лицензионное соглашение читали хоть раз? В корне неправильное утверждение WinApi уже deprecated и потихоньку выпиливается

Под H97 оффициально(я подчеркиваю, оффициальная позиция интела) процессоры K серии не гонятся. Если брать эту мамку,то любые процессоры 4 и 5го поколения, без литер(ну или с литерой К) Но вопрос-нужно ли тебе это?,Если можно купить skylake с разблокированным множителем http://www.ulmart.ru/goods/3565346 4690K оффициально не работает с Z87, для Devil's Canyon представили Z97

HESH, кажется просто не осилил его.. Сидорович, ты иногда выходи из своего бункера. Хорошая скорость-первая в мире, аргумент про AMD'шников не состоятелен, т.к там на CUDA только обработчик тканей(который кажется тоже является партиклом - во всяком случае в PVD он отображется как партикл) и партиклов, относительно легкая интеграция(дальше твердых тел не копался). Большая часть CUDA кода была удалена в 2.8х версиях. Спрашивается, как давно ты его смотрел? Встречный вопрос,что плохого в DXUT? - тебе дали уже готовый отлаженный код, который кстати говоря даже в CE используется Еще один встречный вопрос, как давно ты крутил его? - там уже с версии 3.0 свой фреймворк. Почему я написал "относительно легкая" - в документации отлично все расписано, но расписано все по принципу "Какой вопрос - такой и ответ", т.е интегрировав ты не поймешь почему у тебя тела не имеют угловой скорости и т.д, а семплы написаны отнюдь не очевидно. У меня были проблемы с Character Controller, а именно когда я делал FPS камеру - было продавливание геометрии, но там было сделано на скорую руку. Но вот готового класса,как в Havok, с уже готовыми методами Jump и т.д не жди. Все делать ручками.

Не помню,кто тут тредами интересовался https://github.com/SergeyMakeev/TaskScheduler

Я смотрю тут либу одну, для Task-Based Threading https://github.com/RichieSams/FiberTaskingLib там есть и книжка, и презентация с GDC EA STL отпиливается легко(Сам уже отпилил) Так же есть подобная либа в составе физикса (см. в исходниках) P.S привел пример,что бы не изобретать велосипед(TBB уже предлагали)

Нет,сразу крашится. - Я убрал bugtrap о чем жалею, но там выбора не было. Да,надо было бы. Я вечером все сделаю

Да все гораздо проще - тема диплома (и курсовых), в следующем году защищать. (Безусловно, первый рабочий опыт в GD у меня был, проект можно найти в showcase) В паблик, редко когда скидывал - тестил определенный функционал. В этом году сильно дебажил, попутно переписав часть подсистем. Вообще с этими курсовыми странная ситуация произошла: В 2014 тема трижды менялась - разработать главное меню (по аналогии с CS), потом сделай его на флеше (тыц1, тыц2), недоделав его (не была сделана отработка событий и загрузка из VFS движка) тему опять меняют - на этот раз физика твердых тел (прикрутил physx). В этом году должен был внедрить поддержку анимации, но засел дебажить и переписал рендер (с opengl2 FFP (фиксированный конвейер+шейдеры) -> =>GL4.3(на чисто шейдеры)) Самую старую демку(еще со старым автором), можно найти здесь Ну можно и так сказать. Пока есть возможность, отдыхаю таким своеобразным образом. Там тот баг плавающий - может повторяться (продавливание геометрии), а может и нет (но тогда не работает коллизия с кустами, тело после смерти может получить огромный импульс.). Вся ситуация осложняется еще тем, что иногда движок и не стартует. (раз из ~20 случаев, на другой конфигурации, с запакованной геймдатой) А вообще было пару подозрительных мест. Хотел разобраться как оно работает (что куда добавлять и т.д). Уже восстановил.