Здравствуйте, Ikemefula, Вы писали:

I>>>По большому счету граф. движок это передача данных + шейдеры.
CC>>Движок БД например тогда тоже тупо данные на диск пишет, ага.
I>С геймдвом не вышло, решил на БД спрыгнуть ?
Не, привожу аналоги чтоб тебе понятно было что за фигню ты несёшь.

T>>>>3. В то время, когда все начинают переносить физику на PPU, переносить физику на вирт. машину — гордое дело Можно вот так вот похвастаться какие они не такие как все
I>>>Думаешь на PPU от сиплюса будет больше толку ?
CC>>Ты это вообще к чему спросил?
I>А ты внимательно перечитай, в каком контексте было спрошено.
А как ты думаешь, что будет более быстрым: interop с железом из C++ или из VM/managed?
Сразу подскажу из опыта работы с PhysX и CUDA: из C++

Здравствуйте, CreatorCray, Вы писали:

I>>Графческий движок не является самой главной частью игры.
CC>Главной это в каком плане? Если по потреблению вычислительных ресурсов то как минимум в action играх графика будет жрать весьма и весьма.
CC>Посмотри статистику сколько и на что тратится времени per frame в игре. Раз взялся учить и разъяснять — обязан знать как и в каких играх это можно сделать.

I>>Самая главная часть — это игровая модель и скрипты.
CC>Для геймплея. Если разумеется у тебя игра не шахматы.

А что такое игра по твоему и что такое геймплей ? Хочу услышать внятный ответ.

Одного без другого не бывает.

I>>Вот прикинь, сейчас практческ все серьезные игры логику окромя физики на скрипте пользуют. Распаковываешь файлы, правишь скрипты и получаешь хучь что хошь.
CC>И? Это, к сведению, эдак с дремучих 90х уже не новость.

Это значт, что глупо мусолить чего то про с++.

I>>Моды так и делаются. Кроме того, в физике от плюсов прироста не будет.
CC>Далась тебе эта физика.
CC>На чём писать числомолотилку по большому счёту пофигу, абы работало быстро да правильно.
CC>Касательно быстро: если у тебя двиг написан на С++ (а альтернативы на чём писать ядро игры де-факто нету) то и физика будет на С++.

Что ты вкладываешь в слово "двиг", не совсем ясно.

Здравствуйте, CreatorCray, Вы писали:

CC>Здравствуйте, mrTwister, Вы писали:

T>>Здравствуйте, Turyst, Вы писали:

T>>>Ты просто не в теме
T>>>Да, скрипты используют для многого. А теперь погугли на предмен архитектуры граф. движка и посмотри, что ты называешь вводом выводом.
T>>>Че то грустно здесь... Не в теме, так хоть почитайте что то, перед тем как спорить. А то бред пишите. Ето не только тебе пишу.

T>>А с чего ты взял, что не в теме. Я то как раз "в теме",
CC>Если ты прочитаешь ветку повнимательнее то сможешь заметить, что Turyst отвечал не тебе, а Ikemefula.

Вижу, ты хорошо умеешь читать. Сообщил Туристу, что он отвечал не Туристу

Здравствуйте, CreatorCray, Вы писали:

I>>То есть самая меньшая часть игры, ввод-ввывод, будет написана на с++
CC>Ты б хоть один двиг открыл посмотреть сколько там того "ввода-вывода" и что он делает.

Открыл и посмотрел. Шота не ясно, про чтоты говоришь.

CC>+ не забудь про realtime требования к коду. Т.е. чем быстрее рендерим — тем лучше.

Это и ежу ясно. Дальше то что ? Ты думаешь менеджед здесь чтото ухудшит ?

Здравствуйте, CreatorCray, Вы писали:

CC>Капец.
CC>Это банально неудобно.

это банально удобно — настраиваешь и подфикшивать можно в процессе игры, а не отдельно.

CC>Игра должна работать быстро без лишней шелухи.

Она и так будет работать быстро.

CC>А в тулсет можно и нужно повстраивать всякое логгирование на каждый пук.

А тулсет не обязательно бут работать постоянно. Если он не запускался специально, то и время на себя не потянет. Вместо него будет пустышка работать.

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, CreatorCray, Вы писали:

I>>>То есть самая меньшая часть игры, ввод-ввывод, будет написана на с++
CC>>Ты б хоть один двиг открыл посмотреть сколько там того "ввода-вывода" и что он делает.

I>Открыл и посмотрел. Шота не ясно
Вот вот

Здравствуйте, CreatorCray, Вы писали:

I>>Очень интересно, с учетом XNA того же
CC>На ХНЕ ничего серъёзного никто в здравом уме не пишет.

Это ты так думаешь.

CC>Что нить уровня COD MW2 — никак нет.

Это пока. Сейчас проще старые движки использовать, потому как портирование слишком много времени занимает.

Со временем экономия времени разработки перевесит убытки от портированя и игры будут манагед.

Здравствуйте, CreatorCray, Вы писали:

I>>Здесь С++ никакого преимущества в скорости не даст. С натяжкой — 10%, если кое какие вычисленяи джит соптимизирует похуже, нежели компилятор.
CC>Какой нафиг JIT в приложении с realtime требованиями.

Требования реалтайма даж ОС Виндовс не удовлетворяет.

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

Вот в тех же бизнес-прилагах это может быть затруднительно.

Здравствуйте, CreatorCray, Вы писали:

I>>Геймдевщики обычно не бегают с конторы на контору. Лет за 5-10 вполне возможно.
CC>Не ну а помыть?
CC>Противно жеж.

Он вслепую печатает и клавы не видит

Здравствуйте, CreatorCray, Вы писали:

CC>>>Ты это вообще к чему спросил?
I>>А ты внимательно перечитай, в каком контексте было спрошено.
CC>А как ты думаешь, что будет более быстрым: interop с железом из C++ или из VM/managed?
CC>Сразу подскажу из опыта работы с PhysX и CUDA: из C++

Это пока.

Здравствуйте, CreatorCray, Вы писали:

I>>>>По большому счету граф. движок это передача данных + шейдеры.
CC>>>Движок БД например тогда тоже тупо данные на диск пишет, ага.
I>>С геймдвом не вышло, решил на БД спрыгнуть ?
CC>Не, привожу аналоги чтоб тебе понятно было что за фигню ты несёшь.

Это, кстати, нихрена не аналог. Нагрузку на БД даже предсказать нельзя. Можно тоьлко сказать, что БД ориентирована на такое и такое то пользование.

А с игрой всё как раз наоборот.

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, CreatorCray, Вы писали:

I>>>Здесь С++ никакого преимущества в скорости не даст. С натяжкой — 10%, если кое какие вычисленяи джит соптимизирует похуже, нежели компилятор.
CC>>Какой нафиг JIT в приложении с realtime требованиями.

I>Требования реалтайма даж ОС Виндовс не удовлетворяет.

I>Единственно, памяти будет отожрано гораздо больше немного. Но это не проблема, потому что обычно в геймдеве требования ресурсов можно предсказать заранее оценкой сверху.

Качество игры упирается: в количество свободной памяти(как оперативной так и видео), частоте CPU, GPU, скоростю передачи данных на GPU.
Важным так же является скороть умножения матриц, работы с векторами.

Ни по одном пункте вирт. машина не даст роста производительности по сравнению с С++.

I>Вот в тех же бизнес-прилагах это может быть затруднительно.

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

Вопрос: на Джава, С# можно использовать MMX, SSE?

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, CreatorCray, Вы писали:

I>>>>>По большому счету граф. движок это передача данных + шейдеры.
CC>>>>Движок БД например тогда тоже тупо данные на диск пишет, ага.
I>>>С геймдвом не вышло, решил на БД спрыгнуть ?
CC>>Не, привожу аналоги чтоб тебе понятно было что за фигню ты несёшь.

I>Это, кстати, нихрена не аналог. Нагрузку на БД даже предсказать нельзя. Можно тоьлко сказать, что БД ориентирована на такое и такое то пользование.

I>А с игрой всё как раз наоборот.
А игру это то только ограничивает. То, что мы заем, что у нас на екране должно быть не больше 10 танков никак меня не спасет, если надо 200

Здравствуйте, Turyst, Вы писали:

I>>Это, кстати, нихрена не аналог. Нагрузку на БД даже предсказать нельзя. Можно тоьлко сказать, что БД ориентирована на такое и такое то пользование.

I>>А с игрой всё как раз наоборот.
T>А игру это то только ограничивает. То, что мы заем, что у нас на екране должно быть не больше 10 танков никак меня не спасет, если надо 200

Наоборот, это развязывает руки, т.к. ты можешь посчитать расход ресурсов.

В БД ты можешь ориентироваться на некие среднепотолочные показатели, ни о каком рассчете говорить не приходится. Хватит или не хватит ресурсв — хрен знает. С игрой ты на этот ответ можешь ответить точно и сообщить, на что хватит, на что не хватит.

Здравствуйте, Ikemefula, Вы писали:


I>Графческий движок не является самой главной частью игры.

I>Самая главная часть — это игровая модель и скрипты.

I>Вот прикинь, сейчас практческ все серьезные игры логику окромя физики на скрипте пользуют. Распаковываешь файлы, правишь скрипты и получаешь хучь что хошь.


Ясен пень. Писать логику на плюсах — трата времени и сил чистой воды. Вдобавок к кошмарной читабельности добавляются еще и стандартные глюки плюсов(лики и прочие последствия ручного управления памятью). Плюс, представьте отладку логики. Скрипт поправил, сохранил, запустил игру, проверил(или даже просто обновил какой-нить командой). А плюсы компилять надо.
Кроме того, подобный финт позволяет разработчикам сценария вообще не знать плюсов, нафиг оно им упало — у них другая задача, и мысли другим заняты — им надо интересный игроку мир создавать, а не бороться с низкоуровневыми багами.

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

Здравствуйте, Eugeny__, Вы писали:

E__>Здравствуйте, Ikemefula, Вы писали:


I>>Графческий движок не является самой главной частью игры.

I>>Самая главная часть — это игровая модель и скрипты.

I>>Вот прикинь, сейчас практческ все серьезные игры логику окромя физики на скрипте пользуют. Распаковываешь файлы, правишь скрипты и получаешь хучь что хошь.


E__>Ясен пень. Писать логику на плюсах — трата времени и сил чистой воды. Вдобавок к кошмарной читабельности добавляются еще и стандартные глюки плюсов(лики и прочие последствия ручного управления памятью). Плюс, представьте отладку логики. Скрипт поправил, сохранил, запустил игру, проверил(или даже просто обновил какой-нить командой). А плюсы компилять надо.
E__>Кроме того, подобный финт позволяет разработчикам сценария вообще не знать плюсов, нафиг оно им упало — у них другая задача, и мысли другим заняты — им надо интересный игроку мир создавать, а не бороться с низкоуровневыми багами.

E__>Так что все правильно. Числодробилки на плюсах, логика на шарпе/жабе/питоне/жскрипте/самописном скрипте и т.д., причем необязательно только на одном из них.

Да Eugeny__, все правильно, тут уже это писали.
Так как факты народ никак не хочет понять, то выражение "самая главная часть — это игровая модель и скрипты" такое же правдивое, как утверждение, что XML с параметрами есть главной частью вашего проекта

Здравствуйте, Turyst, Вы писали:

I>>Единственно, памяти будет отожрано гораздо больше немного. Но это не проблема, потому что обычно в геймдеве требования ресурсов можно предсказать заранее оценкой сверху.

T>Качество игры упирается: в количество свободной памяти(как оперативной так и видео), частоте CPU, GPU, скоростю передачи данных на GPU.
T>Важным так же является скороть умножения матриц, работы с векторами.

Я знаю, прикинь ?

T>Ни по одном пункте вирт. машина не даст роста производительности по сравнению с С++.

С памятью это так. + кое где будет интероп мешать.

I>>Вот в тех же бизнес-прилагах это может быть затруднительно.

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

T>Вопрос: на Джава, С# можно использовать MMX, SSE?

Можно например так

http://www.atrevido.net/blog/PermaLink.aspx?guid=ac03f447-d487-45a6-8119-dc4fa1e932e1

Но есть возможности и попроще. Джиттеры они разные. Есть и такие

DateTime start_time = DateTime.Now;

00000043 8D 4D A0 lea ecx,[ebp-60h]

00000046 E8 B5 B0 9C 74 call 749CB100

0000004b 8D 7D B8 lea edi,[ebp-48h]

0000004e 8D 75 A0 lea esi,[ebp-60h]

00000051 F3 0F 7E 06 movq xmm0,mmword ptr [esi]

00000055 66 0F D6 07 movq mmword ptr [edi],xmm0

Думаю сам поймешь что к чему.

Здравствуйте, CreatorCray, Вы писали:

CC>поделись тогда инсайдерскими данными что там сейчас за расклады.

Что именно тебя интересует?

Здравствуйте, mrTwister, Вы писали:

Это game logic который всегда писался на каком то скриптовом языке
а после появления .Net с его простой встройкой в нативный код если и не стал стандартом то скоро станет.

Здравствуйте, Ikemefula, Вы писали:

CC>>Противно жеж.

I>Он вслепую печатает и клавы не видит

Дак и наощупь тоже противно. А в перчатках — неудобно.