?

Log in

No account? Create an account

Ранее | Позднее

Про приставки

Ну что-ж, друзья мои. Поскольку никакого позитивного фидбека по поводу своих рассуждений об упаковке данных и прочей шенноновщине я не получил, то на эту тему я решил забить. А то, присылаете только всякое «ты бы лучше вторую серию про программеров написал, чем про котельникова-шеннона графоманить». Вторую серию про программеров я писать не буду, потому что мне к первой нечего добавить. Кстати, идея пожалуй сойдет - этот маразм про программеров я тоже сегодня выложу на всякий случай. Пусть будет до кучи. Я его написал лет пять назад и он теперь гуляет по Интернету без авторства. А мы, графоманы, очень ценим любую написанную нами строчку. В отличие от настоящих писателей, которые если взбредет в голову, могут и Мертвые Души в печку швырнуть. Я, вообще-то, тоже могу Мертвые Души в печку швырнуть. Не уверен, правда, есть ли они у меня – кажется в Москве остались – лежат в коробках, ждут пока я их вывезу. Но не важно, я могу скачать, распечатать и сжечь. Пусть все знают, что я тоже настоящий писатель, а не графоман какой...

Впрочем, мертвые не мертвые, но все, что я вчера понаписал я выкладывать не стал. Потому что получилось совсем не смешно и очень нудно. Я пытался перевести статью про Cell архитектуру со своими комментариями. Но уж больно статья заунывная и серьезная. Я лучше вам сегодня своими словами расскажу, что такое ps3 и что такое xbox360, как их программируют и что я об этом всем думаю. Кому не интересен треп о программировании, тем предлагается печально вздохнуть и отойти в сторону недовольно ворча. Сегодня явно не их день.

Для полных олухов даю вводную. PS3 aka Play Station 3, Xbox360 aka Xenon и Wii aka Revolution – это игровые приставки для балбесов. PS3 – творчество фирмы Sony – следующее поколение по сравнению с PS3; Xbox360 – поделка фирмы Microsoft – следующее поколение по сравнению с Xbox; Wii – достижение фирмы Nintendo – следующее поколение по сравнению с GameCube. Всех их объединяет то, что они следующее поколение по сравнению с чем нибудь. Поэтому их обычно называют NextGen consoles, а кто хочет выпендриться - седьмым поколением приставок.

Победителем прошлого поколения несомненно стала PS2. Сейчас примерное равенство с некоторым преимуществом Wii и некоторым отставанием PS3, которое они наверняка наверстают благодаря тому, что Sony победил врагов на рынке Hi-def.

Сравним платформы. Сразу скажу, что видео карточки я рассматривать не буду. Я в них мало понимаю, потому что занимаюсь rig animation и ни одного шедера в жизни не написал. Вру, правда, писал на занятиях, когда брал курс по рендерингу для ознакомления, но это не в счет. Поэтому оставлю графику тем кто в ней понимает, а сам сравню собственно платформы.

Microsoft поперся простецким путем наращивания мощности. Сменили Intell на PowerPC, сделали 3 ядра вместо одного на 3.2 гигагерцах, поставили пол гига памяти и на этом успокоились. Повторюсь, что графику я оставляю в стороне, хотя это и есть, чуть ли не самое важное, но меня это не очень интересует (в данном случае, разумеется).

Wii выступили еще проще. Взяли GameCube и почти ничего не меняя приделали к нему смешные контроллеры. И были, кстати, абсолютно правы. Народу не нужна суперграфика и вычислительные мощности. Народу нужен фан. Чтобы было необычно и нестандартно.

Sony решили выпендриться и реализовать у себя IBM-овскую Cell архитектуру. Состоит она в том, что кроме центрального процессора (он называется PPE) ставится до 8 периферийных (они называются SPE). На PS3 этих SPE поставлено 7 штук, но один зарезервирован системой. Так что пользоваться можно только 6-ю. PPE – это обычный процессор PowerPC, у которого формально полгига памяти, но верить этому не советую. Я вообще не советую воспринимать буквально то, что говорит фирма Sony. Эти друзья занимаются булшитингом столько, что даже на общем корпоративном фоне неприлично. Микрософт по сравнению с ними, просто овечки. В техническом описании, разумеется написаны 512Mb. Ведь это написано у Xbox360 и Sony просто обязана предложить покупателям не меньше. Но: « Total 512 MB, split into: 256 MB Rambus XDR DRAM clocked at CPU die speed (3.2 GHz) * 256 MB GDDR3 VRAM clocked at 700 MHz». Ай-яй-яй-яй-яй, какая неожиданность, памяти-то оказывается всего 256, а остальное, это, извините, VRAM. Замечательно. И эти примеры полуправды лично я наблюдаю в каждом описании от Sony. Так что, не обольщайтесь, друзья мои, когда вы покупаете PS3 гордые от сознания, что взяли не-Microsoft, не думайте, что вы купили то, что на коробке написано. Мало ли, что на сарае написано, а там дрова лежат.

Впрочем, я отвлекся от описания архитектуры. Итак, есть центральный процессор с 256Mb памяти, как мы выяснили. И семь (хотя на самом деле шесть и, поверьте мне, Sony не забывает умалчивать и о том, что поставили 7 процессоров вместо 8, и о том, что один зарезервировали) периферийных. Периферийные процессоры по замыслу должны использоваться в вычислениях. То есть, когда у главного есть, что вычислять, он скидывает данные периферийному, а сам занимается своими делами. То есть, модель не симметричная, как у Xbox и PC, когда система решает, какому из равноправных ядер доверить вычисления, а модель хозяин и шесть рабов. Приложение само должно решать, какому процессору доверить вычисления и как распределить нагрузку.

Каждый из SPE имеет 256K локальной памяти. Работает SPE только с векторными регистрами, которых у него аж 128 штук. Векторный регистр это регистр в котором 128 бит. Обычно он воспринимается как набор из четырех 32-битовых чисел. Но можно и как из 8 16-битовых, или 16 8-битовых. В зависимости от команды и того, что вам нужно. Соответственно, команды процессора работают сразу с несколькими числами. Ну, например, пишете вы следующую несложную программу, которая перемножает массив floats:

static float myArray[1024];

… // ну тут типа какая-то инициализация

float result = 1.0f;

for (int i=0; i < 1024; ++i)

{

result *= myArray[i];

}

А это превращается в примерно такой псевдокод (естественно, это не assembler PowerPC – я сильно упростил):

1. Заполнить регистр v1 значениями 1.0f. [в v1 валяется четыре единицы с плавающей точкой]

2. Заполнить v2 целыми нулями [в v2 валяется четыре целых нуля]

3. Положить в v3 адрес myArray [в v3 валяется четыре адреса myArray]

4. Положить в v4 значения по адресу v3+v2 [в v4 валяются myArray[v2=0], myArray[v2+1=1], myArray[v2+2=2], myArray[v2+3=3]]

5. Положить произведение v4 и v1 в v1. Произведение, разумеется выполняется почленно и в итоге в v1 оказывается сразу четыре произведения – myArray[0]*1.0f, myArray[1]*1.0f, myArray[2]*1.0f, myArray[3]*1.0f.

6. Увеличить v1 на единицу [все четыре члена v1 становятся целой единицей].

7. Повторить шаг 4 с новым v1. [в v4 валяются myArray[v2=1], myArray[v2+1=2], myArray[v2+2=3], myArray[v2+3=4]]

8. Повторить шаг 5. [в v1 оказываются: myArray[0]*myArray[1], myArray[1]*myArray[2], myArray[2]*myArray[3], myArray[3]*myArray[4].

9. Повторить шаг 6. [все четыре члена v1 становятся целой двойкой]

10. И так далее.

11. В итоге, в v1 оказывается четыре произведения массива mul(0,1024), mul(1,1025) , mul(2,1026) , mul(3,1027). Первое значение – то что нам нужно и его можно использовать дальше.

Ну, разумеется, я сильно упростил. Потому что выкинул всякую заботу о выравнивании, а об этом в векторном ассемблере приходится много заботиться, и вообще, много чего. Разумеется, этот код можно здорово оптимизировать прыгая через четыре значения. Тогда в v1 окажется четыре произведения:

  1. myArray[0]*myArray[4]*…* myArray[1020]
  2. myArray[1]*myArray[5]*…* myArray[1021]
  3. myArray[2]*myArray[6]*…* myArray[1022]
  4. myArray[3]*myArray[7]*…* myArray[1023]

И перемножив теперь эти значения (это можно сделать немного повозившись с операциями, которые распостраняют одино из слов на все четыре значения) мы и получим искомое произведение. То есть, операция выполнена за вчетверо меньше проходов. Собственно, для подобных оптимизаций все эти векторные регистры и придуманы.

Но вернемся к архитектуре. Итак у каждого SPE 256K (вы не ослышались, именно K) памяти и 128 128-битных регистров. Любопытно заметить, что у небезызвестного PC XT было 512K памяти и 8-битные регистры. То есть, у SPE в памяти помещается 16K значений регистров 256K/(128бит=16байт), а у PC XT 512К = 512K/(8бит=1байт). PC XT выиграл нокаутом.

У SPE нет branch prediction, но есть инструкции которые ему говорят, какая ветка более вероятна. У SPE нет кеша. По сути, у него вся память это кеш. К тому же она на том же камне, так что, кеш и есть. А DMA можно рассматривать как cache loss. Да оно и по цифрам производительности очень похоже. То есть, получается процессор у которого кеш управляется вручную.

Память каждого SPE отображается в адресное пространство центрального процессора. Так что, принципиально, PPE может обмениваться данными с SPE просто читая/записывая по соответствующим адресам. Но это не рекомендуемый способ. Рекомендуемый способ – это управление DMA контроллером. И PPE и SPE может дать задание DMA контроллеру скопировать данные из/в своего адресного пространства в/из чужое. DMA контроллер делает это асинхронно. PPE управляет контроллером путем записи в регистры контроллера, которые отображаются в адресное пространство PPE. Так что, это просто запись команд по спец адресам в памяти. А SPE управляет контроллером через каналы. Каналы управляются соответствующими инструкциями процессора, туда можно читать/писать. То есть SPE попросту посылает сигналы DMA контроллеру по специально отведенным каналам.

Про прямую запись в локальную память SPE, когда мы находимся на PPE написано, что это менее эффективно, чем через DMA контроллер. Почему, не написано. Подозреваю, что имеется в виду просто синхронность операции. Что, типа мы не используем асинхронной мощи DMA. На самом деле, эта асинхронность в большинстве случаев нафиг не нужна, так что я бы попробовал и сравнил производительность. Все таки, напрямую в память писать – намного проще, чем управлять мутными регистрами DMA.

В общем, навертели такого, что не продерешься. Особенно весело приходится фирмам типа нашей, у которых куча существующего кода и теперь его надо как-то портировать на это безобразие. Можно конечно, попросту запустить все на PPE и жить так, как будто никаких SPE нету. Но, сами понимаете, там на этом PPE всего одно ядро и 256Mb памяти. Маловато по нашим временам. А главное, менеджмент крутится вокруг и жужжит на тему, что PS3 это наши партнеры и мы должны продемонстрировать невиданную производительность. Желательно, лучше, чем на Xbox360. А как, я вас спрашиваю? Как на одном ядре с 256M памяти обогнать 3 ядра с 512M? Я знаю только один способ – на Xbox слипов поставить, пустых циклов побольше и не дай бог не использовать многопоточность.

Поэтому пришлось нам честно портироваться на SPE. Да еще пытаться писать переносимый код. Потому что наши игры, кроме шуток, на четырех платформах работают. А как писать переносимый код, если у тебя вместо потоков периферийные процессоры? И как его переносить, если на SPE даже команды new нету. Да что там new, там printf-то толком не реализован. А первые дебагеры не только не умели трейсить SPE, они PPE-то так трейсили, что мозги иногда через ухо из головы выскакивали от удивления.

Ну и, смотрите, что получается. Вот был у нас код. Выделяет что-то в памяти, потом работает с этим, потом удаляет. Потом что-то еще выделяет, работает, удаляет. Предположим, двинули мы этот код на SPE. Секундочку, SPE в главной памяти выделять не умеет – у него своя локальная. Значит оба этих массива надо заранее выделить, чтобы SPE с ними там поработал – сначала перегнал их в свою локальную, а потом записал обратно. То есть, если один массив мегабайт и другой мегабайт, то раньше нагрузка на хип была мегабайт, а теперь-то два. SPE-то не может сказать, что первый массив ему больше не нужен и его можно удалить. Значит нужно заранее выделить оба, а потом звать SPE. Ну, то есть, можно конечно задизайнить что-то, чтобы смог. Но эффективность будет сомнительная – там же придется с синхронизацией биться. В общем, выходит, что памяти мы расходуем больше, чем на Xbox360, потому что надо держать выделенными буффера для локальных процессоров. Время жизни аллокаций-то растет, а с ним и расход памяти. А ее, не забудем, у ps3 вдвое меньше, чем у xbox. Вилы, друзья мои.

В общем, в борьбе симметричной, как у PC/Xbox и ассимитричной, как у PS3 архитектур, я бы сказал побеждают контроллеры от Wii. У которых вообще никаких многих ядер нет, а есть просто красивая белая палка, которой можно размахивать. А пользователю эти вычислительные мощности нафиг не нужны. Gameplay решает все.

Тем не менее, нам с вами, друзья мои, интереснее куда идет компьютерная индустрия. Потому что плотность микросхем продолжает расти экспоненциально, а кривая роста частоты завалилась. Это значит, что в процессорах будущего много лишнего места, которое надо для чего-то использовать. Для чего? Ну, разумеется, плодить ядра. То есть, скоро мы столкнемся с реально многоядерными процессорами. Со всеми вытекающими проблемами. По моему, сейчас уже можно точно сказать, что мир по пути Cell не пойдет. Не нужно никому ручное управление кешем и ресурсами. Гораздо удобнее, когда система сама распределяет куда чего сколько.

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

Ну хватит. Чего-то опять как-то не смешно все.. Ну и ладно. Видимо это тема такая не смешная. Если кому интересно могу про приемчики векторизации кода рассказать. Это когда код оптимизируется под эти 128 битные регистры. Там забавные вещи бывают. Но это по заявкам. Что-то нет у меня уверенности, что кого-то это интересует.

Comments

( 27 высказались — Хочу высказаться )
kunaifusu
Apr. 2nd, 2008 12:40 am (UTC)
Вы, я так понимаю, не писали ничего для PS2?
szotin
Apr. 2nd, 2008 12:53 am (UTC)
Не писал.
kunaifusu
Apr. 2nd, 2008 01:08 am (UTC)
Просто напомнили рассказы писишных "игроделов" circa 2000 пересевших на PS2. Только на PS2 было еще брутальнее - любимый тип double, например, железом не поддерживался, на ЦПУ еще как-то перебивались эмулятором (подумаешь, одно умножение - 2000 тактов?) а на VU труба была, с битами там не поработаешь особо да, и вообще, С и, тем более, С++ компилятора для него не было, да и по количеству слов в локальной памяти сливал не то, что ХТ, калькулятору от TI сливал. И ничего, научлись в конце-концов.
szotin
Apr. 2nd, 2008 01:23 am (UTC)
Говорят, хуже всего было c GameCube. Там даже network некуда втыкать - соединение через ком-порт. Скорости перекачки, соответствующие.

Хочу сказать добрые слова в адрес Microsoft и лично Уильяма Гейтса. Самые беспроблемные дев-киты. Включаешь - просто работает. Причем, именно так, как описано в мануалах. Баги есть, но это баги, а не дыры в дизайне, которые вызывают желание выкинуть все это творчество в окно. Прямо через стекло на футбольное поле. На головы играющим. Чтобы знали, блин ;)

Знаете, сколько весит PS3 dev-kit? Лично я не знаю. Но много. Таскал однажды туда сюда, потому что, никак не могли решить, сломан он, или по жизни такой (оказалось, разумеется, что по жизни такой). В общем, в конце дня, я без труда уложил бы Сталоне плевком, такой стал сильный.
kunaifusu
Apr. 2nd, 2008 01:36 am (UTC)
Смотря какой пс3 девкит, те которые в 2005ом были весили дофига, те, которые в 19" плоских рэках весят не много, а тесткиты весят как пс3. Но, в общем-то, я инженером работаю а не грузчиком, мне вообще никаких девкитов никогда не приходилось таскать.

Насчет безпроблемных девкитов - мне тоже девкит от 360 нравится больше исключительно скоростью компилятора. Отладчик там - убогий, железо там горит, не так как в ритейловых китах, но дохнут 360ые киты переодически в отличие от пс3. Отлаживать код, однако, все же удобнее на пс3 (если не нужно перекомпилировать).
szotin
Apr. 2nd, 2008 03:00 am (UTC)
У xbox отладчик убогий? На ps3 удобнее отлаживать?
Это SNS-ом?
Мы случаем не в параллельных вселенных живем? Просто до сих пор не приходилось мне видеть человека, который SNS дебагер считает лучше xbox-овского.

По моему личному опыту, от этого SNS дебагера вообще редко когда удается добиться внятной информации. Особенно после того, как он мне однажды цинично соврал по поводу значения переменной. Просто, взял и соврал. Хорошо, что я был начеку, немедленно вставил printf и поймал на вранье. Еще он по заинлайненным функциям весело ходит - какие-то произвольные куски кода выбирает и показывает. В результате, даже ассемблер прочитать трудно, потому что непонятно, где я. Ну, я уже не говорю о текущей памяти и неубитых процессах по выходе.

У нас обычно все куски сначала отлаживают на Xbox, а уж потом переносят на ps3. Благо процессоры почти одинаковые. А иначе даже никто и не пытается делать - себе дороже.
kunaifusu
Apr. 2nd, 2008 03:18 am (UTC)
У меня СНС дебагер все время дает внятную информацию, просто, у нас, наверное, разные понятия о внятной информации. Мне вот неубитые процессы в винде на выходе - не уперлись совсем никуда, то есть вот абсолютно, я машину раз в неделю дай бог если выключаю, из отладчика не выхожу. А вот то, что вижуальниковский отладчик не понимает неймспейсов в 21ом-то веке мне упирается. И то, чтобы элементарные вещи вроде мемори брекпойнта или просмотра флоата в хексе проделать приходиццо долго и нудно чего-то печатать да мышкой туда-сюда тоскать удобства мне совсем не добавляет. Так же как и отсутсвие мемори брекпойнтов на чтение и дурацкий дизассемблер.
e_yes
Apr. 2nd, 2008 01:20 am (UTC)
На самом деле, brAnch prediction. Но не суть.
Читаю новости: Вот в следущем уже году обещают 32-ядерный процессор. Не удивлён. И видимо, с ядерностью (в новом смысле слова) придётся жить.
И врядли мануально менеджить ресурсы будут. Врядли.
Разработают библиотеки (Интел уже даже что-то там написало для поддержки многоядерности, даже под GPL доступно). Подточат процессоры.
Думаю, все претензии по Целл гораздо более по адресу к IBM, которые наличие 6-ти SPE не скрывают и точно я (ни разу Целл не програмировавший) помню в их статьях эту цифру.
И будет задача по программированию многоядрёных приложений (в том числе с раздельными адресными пространствами) несложнее обычных многопоточных приложений.

P.S. Вспомним середину девяностых. Много ли было библиотек, облегчающих создание многопоточных приложений?

P.P.S. Guitar Quiro -- аццтой:)
szotin
Apr. 2nd, 2008 01:26 am (UTC)
> P.P.S. Guitar Quiro -- аццтой:)

Huh! Задел за живое.

Rock Band - ruleZZZ. Купил и поставил у себя в бейсменте. Барабаню каждый день. Обычно сажусь на одну песенку и через пару часов взмокший отползаю, потому что физически уже не в состоянии барабанить.
szotin
Apr. 2nd, 2008 01:32 am (UTC)
> На самом деле, brAnch prediction. Но не суть.

Исправил. Виновные отделались легким замечанием. Не расстреливать же самого себя.

> Читаю новости: Вот в следущем уже году обещают 32-ядерный процессор.

К нам интеловцы приезжали где-то уже почти год назад, рассказывали, как трудятся над 80-ядреным процессором. Вот уж не знаю, на каком там они этапе. Не следил.
(Deleted comment)
(Anonymous)
Apr. 2nd, 2008 03:22 am (UTC)
Векторизация операции Lookup table
Вот в наборе SSE инструкций у Intel-а не хватает векторной операции для Lookup table - вот скажем в xmm0 у тебя адрес таблицы, в xmm1 - 16 8-битных индексов и хотелось бы получить в xmm2 значения из таблицы xmm0, соответствующие индексам в xmm1. Ручками всё приходится делать.
Так что про векторизацию очень интересно - пиши.
szotin
Apr. 2nd, 2008 05:06 am (UTC)
Re: Векторизация операции Lookup table
Сделаю. Но нескоро. У меня послезавтра отпуск начинается. А после отпуска, пока я с мыслями соберусь...
sermcl
Apr. 2nd, 2008 07:33 am (UTC)
Старина! При всей моей любви к программистским байкам, огромный просьб. Пользуйся катом, пожалуйста, а то у меня френдлента очень длинная и однородная получается.
szotin
Apr. 2nd, 2008 05:07 pm (UTC)
Оки-доки.
szotin
Apr. 2nd, 2008 06:25 pm (UTC)
Угу, сделано. Я тут в жж человек новый. Не в курсе ваших фич и правил.

Вопрос изучен, меры приняты. Спасибо за указание верного направления. Приношу извинения за причиненные неудобства.
(Deleted comment)
szotin
Apr. 2nd, 2008 11:06 pm (UTC)
Вроде, все правильно. А что не так?
Может, я просто фразу плохо построил, непонятно, что к чему относится?
(Anonymous)
Apr. 17th, 2008 10:41 am (UTC)
Вот небольшая статейка про железное сравнение приставок PS3 и X360. Практически один в один:

http://www.gameland.ru/post/39791/default.asp
szotin
Apr. 17th, 2008 05:49 pm (UTC)
Хорошая статья. Прямо зачитался. И даже узнал кое что новое. А что, не скажу, а то засмеете ;)
aklemator
May. 13th, 2008 01:35 pm (UTC)
Ну ващет в Cell действительно 8 ядер, но как тут сказано доступно только 6.
1 ядро вечно отключено и задействуется когда при производстве допускается брак, так что в на сборку консоли идут практически все изготовленные процессоры, что позволяет уменьшать себистоимость.
2 ядро задействовано под операционную систему.
aklemator
May. 13th, 2008 01:41 pm (UTC)
что-то редактирование не работает :)
Я имел ввиду Cell в PS3
al_zatv
Oct. 12th, 2008 07:32 am (UTC)
у "небезызвестного PC XT" были не 8-, а 16-тибитные регистры:)
al_zatv
Oct. 12th, 2008 07:46 am (UTC)
а вообще интересно, афтар пешы ысчо:)
(Anonymous)
Oct. 12th, 2008 04:58 pm (UTC)
"плохой" PS3
1. видяха в PS3 лучше и понятнее (т.к. это обычная нвидиа 7800). памяти не 10мб, а 256, поэтому графика на пс3 лучше на большинстве кроссплатформенных проектов
2. проблемы достаточно типичны для тех, кто писал в 1 потоке, ну максимум в 4 (0 - рендер, 1 - игра, 2 - физика, 3 - АИ). а ведь уже есть 8. и будет 16. как будем распределять нагрузку? только одним способом - брать и бить на задачи, для каждой делать список, что она берет и что она отдает. плюс шедулер. далее просто делаем интерфейс как в библиотечке (STRIPS). и все - она сама стриммит, сама распределяет, сама отдает - очень удобно.
3. на пс3 ппу умеет branch prediction, но не умеет out-of-order. cell-ы не умеют ничего, но зато их 6 и скорость к 256К хорошая.
4. по-моему, программы лучше всего писать под пс3, потом портировать под xbox - все, кроме видяхи будет очень просто, и под pc - будет все совсем просто.
szotin
Oct. 13th, 2008 11:54 am (UTC)
Re: "плохой" PS3
Я когда на SPU писал вообще программу на PC отлаживал, а потом портировал.
Там и сейчас хорошего дебагера нет, а когда писал, так и вообще никакого не было. И spu_printf у нас тогда не надежно работал.

У нас однажды случайно прилинковали position dependent library к position independent коду. Это уже когда дебаггер был. Так даже с дебагером, плясок с бубном было на пару недель. Ну там, правда все усложнялось тем, что сами мы эту либу не использовали, а пользовался ей автодесковский IK solver. Соответственно, мы сначала на них и погнали.

Честно говоря, так долго все на PS3. Такой рабочий цикл долгий, что если есть шанс разработать на чем-то другом, а потом портировать - надо пользоваться. Много времени съекономится. Так что, я категорически не согласен с идее писать на PS3, а потом портировать на xbox.
proforg
Oct. 12th, 2008 09:57 pm (UTC)
прекрасно !
спасибо :)
alariq
Oct. 16th, 2008 10:13 am (UTC)
>>PS3 – творчество фирмы Sony – следующее поколение по сравнению с PS3;

кто то может подумать что я чистоплюй? но правильнее написать
"по сравнению с PS2" :)
( 27 высказались — Хочу высказаться )