Power Render 6 Source Code for $100

Цікавая навіна ад распрацоўшчыка Power Render:

http://www.powerrender.com/2007/homepage.htm

''Power Render 6 is a commercial quality 3D engine and normally we license the source code to companies for $5500. A lot of work has gone into this engine but at this price we feel that not many people have a chance to see it. We would like to have a lot more people using and sharing content for the engine. We would like you to help participate and build this community. In this special promotion the first 500 developers can buy the engine with full source code (that's 300,000++ lines of stable DirectX9 C++ code, previously used in several commercial titles) for ONLY $100!

Sound too good to be true? There is nothing fishy about this offer. We are taking a different direction with this engine and opening it up to everybody. This special offer is available to new customers. Existing customers may also purchase a copy if they wish.''

Последняя правка: пн, 29/08/2011 - 22:09
Submitted by Siarzhuk Piatrouski on

Комментарии

А STL и С++ это уже задачи компилятора… Вот это обычно первый (и самый жестокий) облом -- STL и С++ могут весьма своеобразно поддерживаться на target-platform. Вообще STL в играх не очень разумно использовать, хотя бы потому что оно не очень предсказуемо с памятью работает (например ты можешь _уверенно_ сказать что произойдёт с памятью при std::vector::push_back()? На самом деле вопрос риторический, потому что не можешь в принципе). Про STL есть полезный док EASTL -- в деталях расписано почему STL сакс и что с этим делать. И думаю, если будут проблемы с портированием, то минимальные… Можно думать что угодно, а потом выясниться, например, что тормозят вызовы виртуальных функций (из-за двойного обращения к памяти, cash trashing) и вся красивая орхетектура летит к такой-то матери ибо ты банально не укладываешься в TRC/TCR (на консоли, если не в курсе, есть требования всякие, типа FPS _никогда_ не должен падать ниже чем столько-то, время загрузки не больше чем столько-то и т.д.). Плюс нюансы выравниваний, sizeof(int)/sizeof(void*), big-endinan/little-endian issues и т.д. и т.п. -- если например выясняется что конструкторы статических объектов не вызываются (а такое раз было, хотя и починилось со временем), то это не смешно ничуть. А ещё бывают ошибки компилятора (обычно на макс.оптимизации) -- буквально позавчера засубмитил пару таких глюков в сони. Короче, пугать могу долго и нудно :) А самая "переносимая, грамотная и красивая" архитектура, как правило, самая тормозная из возможных -- фактический факт. если хошь спорить, то довай делать это не тут… ибо от темы ушли ваще на камчатку не хочу; разговор всё ещё недалеко от темы "готового портабельного движка". а вообще смысла спорить нету… время покажет надо просто подождать… Угу. Время покажет. Пока правда статистика неутешительная -- практически все успешные игропродукты страшны внутри (в плане кода) неподетски; в смысле никому нафик не нуна красивость архитектуры, важнее вовремя сделать.
Submitted by BLK Dragon on
Есть один нюанс... В GoonWorld мы делаем собсвенно ядро... к которому подгружаются динамически либы...Что позволяет в каждой новой игре использовать одно и то же ядро, и многие либы... Дописывая лишь новые...

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

STL я знаю хорошо... знаю, что в юникс он не освобождает память из под вектора, после удаления его элементов...

а пугать багами компилятора не надо... ибо я тут не причем... и поделать с этим ничего не могу...

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

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

Скорость обратно пропорциональна кривости рук... (с)

Ато что STL сакс... так можно про все что угодно сказать и найти доказательства ибо нет ничего идеального

Submitted by Denis on
Есть один нюанс… В GoonWorld мы делаем собсвенно ядро… к которому подгружаются динамически либы… Что позволяет в каждой новой игре использовать одно и то же ядро, и многие либы… Дописывая лишь новые… Я думаю так скорость разработки очень высока, что касается производительности, то она тоже не в низу… Это ещё и добавляет проблем с возможной несовместимостью либ друг с другом. Плюс что ты будешь делать если на target-platform нет механизма дин.библиотек? Что до производительности, так дин.загрузка модулей -- дополнительные возможности для фрагментации памяти. Плюс inter-DLL calls тоже удовольствие небыстрое (хоть и минимизить его можно). Короче статик-линк самое надёжное решение. Скорость разработки такая же -- если кривизна рук маленькая и физ.зависимостей между файлами мало и компилится всё быстро (и если система сборки не на slow as hell визуале а на чём поприличнее). STL я знаю хорошо… знаю, что в юникс он не освобождает память из под вектора, после удаления его элементов… Клёво. А мне вот нужно _освободить_ 4мб темповых данных, потому как всего памяти есть около 16мб. Чё делать? Хацк со свопом векторов? Ну и нафик надо если в своём контейнере есть free() который точно _освободит_ память. И вот, например, попробуй сделать портабельный fix-up std::vector'а. а пугать багами компилятора не надо… ибо я тут не причем… и поделать с этим ничего не могу… Клёво. Ситуация -- код не работает из-за глюка компилера, будешь сидеть и плакать? :) насчет тормазнутости архитектуры ты не прав ибо тут вопрос в том, как она сделана… если все связи между объектами установить при загрузке, то дальше, что ты в коде прописал указатели на явные объекты, что они установились при загрузке, на скорость никак не влияет… Ещё раз. Самая гибкая архитектура -- самая тормозная по определению (тормоза как плата за дополнительные уровни абстракции). Это факт. Другой вопрос насколько это критично. Были случаи что критично. Ато что STL сакс… так можно про все что угодно сказать и найти доказательства ибо нет ничего идеального STL в приложении к играм создаёт ряд проблем, что и показала EA (Electronic Arts) обобщив опыт за годы разработки (Контора не мелкая, проектов много делала, я им склонен верить ибо их проекты работают шустро).
Submitted by BLK Dragon on
Unbalanced tokens, check your syntax
Submitted by Denis on
А что если завтра мы все умром от метиорита? вопрос из той же оперы… Хочешь доказать, что мы все делаем не правильно… не спеши это делать… потомучто можешь ошибится… и предлагаю просто ждать… Я хочу сказать что не везде есть механизм динамически загружаемых модулей (на первом хбохе например нет, если только "на ручной тяге"), а там где есть -- почти всегда лучше им не злоупотреблять (типа как сделать игру из двух десятков ДЛЛ). >Клёво. А мне вот нужно _освободить_ 4мб темповых данных, потому как > всего памяти есть около 16мб. Чё делать? Хацк со свопом векторов? > Ну и нафик надо если в своём контейнере есть free() который > точно _освободит_ память. И вот, например, попробуй сделать > портабельный fix–up std::vector'а. Мы копались над этой проблемой и по крайней мере в линукс есть возможность отключить эту опцию… Эээ Какую опцию? Опцию чего? Чтоб память освобождало? Проблему сделать fix-up (in-place load содержимого вектора) опции как затрагивают? Вспомни эти слова, с этого началось… получается сначала ты доказывал, что игры стоит делать под винду ("А ты собрался делать игру под что–то другое?"), а теперь пытаешься доказать что у нас не получится сделать ее под другие платформы… Я сказал ровно то что сказал. С такими подходами (как ты расписываешь) получиться что-то сделать только под винду. Встречный вопрос, а если это окажется действительно сложно, то почему мы не можем просто не делать… Потому что PC-only проект это неинтересно (очень маленький охват рынка, ~15% а то и меньше, с ММО конечно поболе) о чем мы вообще говорим щя? Я неспешно пытаюсь снять розовые очки с процесса разработки multi-platform игр у читающих :) Другими словами, если никогда не делали ничего ни для одной консоли, не стоит думать "я вот ща быстренько это всё туда портирую и будет мне счастье" -- так не будет.
Submitted by BLK Dragon on

Я сказал ровно то что сказал. С такими подходами (как ты расписываешь) получиться что–то сделать только под винду.

Ты этой фразой доказал, что ты нифига не читаешь что я пишу, а если бы читал, то покусал бы щя локти... Ибо я уже писал, что на mac, linux, windows работает...

''Я неспешно пытаюсь снять розовые очки с процесса разработки multi–platform игр у читающих

Другими словами, если никогда не делали ничего ни для одной консоли, не стоит думать "я вот ща быстренько это всё туда портирую и будет мне счастье" — так не будет.''

Еще раз повторяю... Мы сейчас не гонимся за консолями, но пишем с расчетом на то, что будем пытаться портировать под них...

И читай повнимательнее...

Submitted by Denis on
Ты этой фразой доказал, что ты нифига не читаешь что я пишу, а если бы читал, то покусал бы щя локти… Ибо я уже писал, что на mac, linux, windows работает… А? Локти то зачем кусать? Ты несколько раз упоминал фразу "под все платформы" -- в контексте разработки игр это значит все платформы (NDS/Wii/PS2/PSP/PS3/XBox360/PC). Возможно я чего-то не так понял, возможно ты намеренно пытался пускать пыль в глаза; факт в том, как выяснилось, что игра работает на одной платформе (PC); то что оно там на каких-то линухах/маках запускаеццо, ничуть не делает проект "мультиплатформенным", уж тем более "под все платформы" -- если ты скажешь какому издателю что "вот у нас крутой проэкт под все платформы", а потом выясниццо что оно тока под пейси, то будут смеяццо, да. Еще раз повторяю… Мы сейчас не гонимся за консолями, но пишем с расчетом на то, что будем пытаться портировать под них… И читай повнимательнее… Я уже понял. Пытайтесь. Успехов. И эта, не нуна пытацца учить меня читать/жить -- я ужо достаточно взрослый и вумный дядко, ага. :) 2moderator -- тему пора залочить или перенести "во флейм".
Submitted by BLK Dragon on

По просьбе трудящихся закрыто ...

Submitted by Relyer on

GameDev.by