3) Tile Based Deferred Lighting - наконец в двигло внедрили систему отложенного рендеринга. Да еще и какую! Данный тип отложенного рендеринга основывается на экранных "тайлах". Представьте что ваш экран разбит на виртуальную сетку с ячейкой размером 32х32 пиксела (с моим разрешение 1280х1024 ----> это сетка с 40 ячейками по горизонтали и 32 по вертикали). Чтобы разгрузить шину видеокарты очень выгодно не каждый кадр перерисовывать всю сцену, а только отдельные ее фрагменты. Информация о сетке хранится в ОЗУ, своевременно отсылая инфу для отрисовки на видеокарту. Это все очень продвинуто и круто но есть 2 минуса:
----- можно рисовать сотни разноцветных источников света без падения производительности, но только до тех пор пока они не используют ТЕНИ sad точечные источники света работают на основе куб-мап и 5-6 таких "ламп" с нормальным качеством теней (без видимой ступенчатости) убьют производительность в ХЛАМ (и тут не нужно много детализированных объектов в сцене).
----- производительность техники отложенного освещения ОЧЕНЬ сильно зависит от разрешения экрана --- для большого экрана нужно на MRT (экранные буферы) выделять больше памяти которой в итоге может и не хватить

Ага. Так им, этим япошкам up

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

скачай "Filemenu Tools" и пройдись по диск "Size Of folders", найдёшь разжиревшую папку. А после, пройдись стандартной проверкой диска на ошибки.

Но корректнее писать с заглавных букв, так как в примерах именно так показано.

Developer, дык, в обществе читали тех авторов, о которых я поминал.

После таких слов, не верится что у вас 30 лет практики.

Эх... печалит производительность Здума.
На нём даже Hexen в некоторых моментах падает до 12-ти fps на 225-ти мегагерцовом пентиуме MMX (даже при разрешении 320*240).
А если включить эмуляцию генерал-миди сэмплов fmod, так сожрётся ещё половина кадров.

C++/STL/deque ::: 2.6 ::: 11.2 ::: 70
C++/STL/list ::: 1.7 ::: 1.5 ::: 70

Строки = 100 / 50 * (Доход - 20 * floor(Опоздания / 3)).

FlyOfFly, нет, C сам умеет делить нацело.

Кстати, с точки зрения гибкости замены структур на классы Python гораздо гибче

A = A / B * B + A % B

Строки = 100 / 50 * (Доход - 20 * (int)(Опоздания / 3)).

FlyOfFly, это к чему? Я спросил о целях такого преобразования:
1. Для построения иерархической семантической вселенной программы.
2. Для совместимости с OO-библиотеками
3. Для инкапсуляции отдельных фрагментов вычислений
На каком из этих путей Вы видите выгоды?

Нет. Лучше использовать движок, который написан на C++, а скрипты писать на JavaScript, Lua, Python, C# и т.д. C++ для скриптинга сложноват в сопровождении, так как требует повышенного внимания и осторожности.

Слишком узкие рамки.

Я за новогоднюю тематику, к тому же идеи появились по реализации этого.

Планируете ввести жанровые ограничения? Я думаю, что новогодняя или праздничная тематика - это не очень хорошо. Игры получатся однообразными и малоинтересными (как последствие первого везде будут Деды Морозы). Просто придумайте тему, которая не ограничит возможность создания праздничной игры.