Вышел Tribal Trouble

Java... системные требования: 5Ghz cpu, 4Gb RAM

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

> 700MHz/128MB/Geforce или Radeon 7200

Нихера себе у вас понятия о небольших требованиях.

а ты думал, на своём 386 XML конфиги парсить?

> Нихера себе у вас понятия о небольших требованиях.

Наверное правильные небольшие требования - это чтоб консоль работала, все что выше - происки врагов :)

Ниже 700MHz даже фильмы не все пойдут, в зависимости от способа оцифровки некоторые могут притормаживать (хотя я даже на K6-2 400MHz умудрялся что-то смотреть :)

A Java и в гейм-индустрии рулит, см. например стрелялку Chrome или леталку Ил-2.

Молодые ещё. Что с них взять?

>A Java и в гейм-индустрии рулит, см. например стрелялку Chrome или леталку Ил-2.

ил-2 тот еще тормоз,

а рулит она понятно почему - позволит перенести на смартфоны потом без проблем,

но для кончного пользователя игры на java не нужны,

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

Классная игрушка
Ява рулит!

что еще порадовало - игрушку можно купить и за рубли :)

это требования на видеокарту? 128Mb - это видеопамять? :)

> ил-2 тот еще тормоз,

На Lock On взгляни, на С++ написанный. Компьютер, чтобы на оном Lock On без тормозов летал, ещё не изобрели.

после некоторого времени игры она начала подтормаживать,

потом перестала, но через некоторое время вылетела, эксепшион и все дела.


о самой игре:

пара юнитов, два-три типа строений, убогая графика,
и за это хотят 30$?

возможно для смартфонов это нечего, а вот по сравнению
с обычными играми x86 - фигня полная.

Загрузил демку, посмотрел - понравилась. Но покупать не стану. Мне не денег жалко, мне принцип жалко!

> Нихера себе у вас понятия о небольших требованиях.

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

> Ниже 700MHz даже фильмы не все пойдут

Celeron 566, идут как DVD так и домашние (720x480 5Mbps вроде бы, не помню точно), никаких проблем/пропусков (mplayer для видео/xine для DVD).

Если говорить о системных требованиях то 700 это скромно, для warcraft чтобы поиграть без разрушения нервной системы нужен не ниже 800-900, при этом попускать все эффекты и разрешения, а игры эти вроде однотипные. Правда графика конечно страшная но хз если говорить о других играх то кроме убить била, больше и посмотреть не начто так что разработчикам сенкс, правда дорого ждем когда пираты сделают игру ближе к народу

эх маладешь. mov ax, 13h int 10h

Серёжа, обьясни мне, что значит пoяcнение в треде - "Ограничение на отправку комментариев: только для зарегистрированных пользователей" а то, вроде как, зарегистрированный, а сообщения то не сохраняются.. и что же это? неужели для статуса зарегистрированного пользователя уже, ну, просто-таки необходима звездочка на погонах?.. я прав?.. это разочаровывает..

она с баннерами?

21 век на носу, графика ужас...............ну почему все так плохо с Линуксом, ни нормального софта ни игр ни ......

>MiracleMan (Score: 42 MaxScore: 70) (*) (03.04.2005 2:36:24)

http://www.linux.org.ru/view-message.jsp?msgid=852600

Здесь это не обсуждаем, плиз.

а нах линуксу нормальный софт? он же свою изюминку потеряет..

Клевая игруха, наверное куплю. Конечно, это не Warcraft 3, но она и не претендует на его место. За месяц это вторая достойная программа на Java, о которой сказали на ЛОРе. Первая была RSSOWL. И опять я скажу - разве нельзя на Java писать хорошие программы? Можно! Просто руки нужно иметь прямые. А то тормоз-тормоз. В головах только тормоза, а Java вовсе не тормоз (причем уже давно).

Большинство тормозов Java-приложений от того, что большинство считает, что программируя на C/C++, нужно напрягать извилины, а на Java -- нет.

AMD 2k+ (работает на заниженной частоте 1400), 256MB RAM, GF2Pro 32MB video. Запускал из KDE + куча всяких сервисов (свободно было ~56MB в оперативе и ~480MB в свопе). Медленно загружается только в начале (до главного меню) и между уровнями. В самой игре тормозов практически нет, если не считать кратковременные лаги (видимо, это GC перетрАхивает кучу(и)), но это не раздражает. Модельки сделаны достаточно качественно, но в игре не хватает детализации. Например, когда рабы валят дерево, оно тут же погружается в землю, бесследно "тонет" в траве. Статичная вода тоже не радует. Понравилось управление - простое и удобное. ИИ тоже вроде неплохой (хотя я его особенно не мучил). И сам процесс захвата ресурсов затягивает... Итого: очень хорошее начало, игру можно довести до приличного уровня.

и много ты так напишешь????

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

Так что, друзья, кто больше всех кричит о "плохой Яве", тот, по-моему, просто пустобрёх.

мальчик, ты хоть про метод брезенхейма слышал? иди в песочницу и молчи в свою тряпочку (жаба, делфя, пайтон)

Оказалось что половина дистрибутива игры это jre,

игра максимум тянет на раний альфа релиз, но никак на релиз

пустобрех - тот кто свистит о том что жаба не тормозит. я такой аппликухи еще не видел, даже на современном массовом железе (ну ясен пень найдутся упрямые эссттонцыы готовые оспаривать это :) как не зайдещь на жаба проект на форже - там от 10-15 мег (я и 30 видал). в то время как програмка схожей функциональности и переносимости на плюсах - не больше мега. а вот питон шустро бегает. потому смысла в жабе - нет. еслиб большинство недопрограммеров жаберских написали бы пару программок для пк-52, то те что не отсеялись бы убирать дворы, были бы толковыми программистами. а так что имеем то имеем. и чтоб не свистели пустобрехи жабовские: вот у меня PyBookReader и jbookreader. первый летает. второй - тормозит. не ловит колесо мыши. и вид имеет преотвратный. люди-фанаты жавы, бросьте ее. посадите дерево, займитесь садоводничеством, человечеству намного больше будет. оно вам спасибо скажет!

>ну почему все так плохо с Линуксом, ни нормального софта ни игр ни ..

Где там сказано, что игра только под Linux? Графика конечно убогая, но
к ОС это вообще не относится, т.к. везде выглядит убого одинаково...

> мальчик, ты хоть про метод брезенхейма слышал?

Хоть не мне был пост, но отвечу. Ты наверное в школе учишься? Или еще в ясли-сад ходишь? Кого-то хочешь удивить умным словом "метод Брезенхейма"? Наверное вчера листал книжку по графике и вычитал, что есть такой метод. :) Смешной.

> там от 10-15 мег (я и 30 видал). в то время как програмка схожей функциональности и переносимости на плюсах - не больше мега

Пример приведи.

> еслиб большинство недопрограммеров жаберских написали бы пару программок для пк-52...

Что есть "пк-52"? Может тебя заставить написать программу для TMS320? Дворник, блин.

А для разминки попробуй скомпили GNOME или KDE на соляре с использованием оптимизирующего санового компилятора. Посмотри что такое кроссплатформенность C/C++.

> Ниже 700MHz даже фильмы не все пойдут, в зависимости от способа оцифровки некоторые могут притормаживать (хотя я даже на K6-2 400MHz умудрялся что-то смотреть :)

Ну-ну, у вас под виндам всё тормозит.

>А для разминки попробуй скомпили GNOME или KDE на соляре с использованием >оптимизирующего санового компилятора

и что из этго?

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

>Что есть "пк-52"? Может тебя заставить написать программу для TMS320? Дворник, блин.

Видимо имеется в виду мощнейший Программируемый МикроКалькулятор 52. 109 байт памяти. 4 разряда. 1.5 операции в секунду. И в эту фиговину люди умудрялись воткнуть даже шашки.

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

"Удивительно нам это - жопа есть, а слова нету!"

Что же это за стандарты такие, которые для каждого компилятора разные? Или хотите сказать, что только GCC придерживается стандартов?

> Видимо имеется в виду мощнейший Программируемый МикроКалькулятор > 52. 109 байт памяти. 4 разряда. 1.5 операции в секунду. И в эту > фиговину люди умудрялись воткнуть даже шашки.

Тогда конечно, программирование калькулятора - высший пилотаж программистского ремесла! :))

>Что же это за стандарты такие, которые для каждого компилятора разные? Или >хотите сказать, что только GCC придерживается стандартов?

да g++ наиболее полно соотвествует последнему стандарту C++,
в отличие от многих C++ комерчиских компиляторов,

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

> Видимо имеется в виду мощнейший Программируемый МикроКалькулятор 52. 109 байт памяти. 4 разряда. 1.5 операции в секунду. И в эту фиговину люди умудрялись воткнуть даже шашки.

Настоящих шашек там, кстати, так и не было... Зато было ППЗУ, правда небольшое, но три-четыре здоровых программулин там умещалось. Вообще, этот "реликт" второй половины 80-x до сих пор лежит у меня в письменном в столе, и находится в полном рабочем состоянии :)

> да g++ наиболее полно соотвествует последнему стандарту C++, в отличие от многих C++ комерчиских компиляторов,

Преимуществом GCC от "многих C++ _комерчиских_ компиляторов" является совсем не это, а его бесплатность и распространенность среди множества платформ. Собственно как компилятор GCC часто проигрывает своим конкурентам.

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

Многие гнутые программы, написанные на C/C++, используют _нестандартные_ GNU-расширения. Как следствие, такие программы могут компилироваться только с помощью GCC. Теперь понимаете разницу между GNU C/C++ и ANSI C/C++ ?..

> Оказалось что половина дистрибутива игры это jre,

Обычно только так и поступают, к сожалению. Хотя, есть и хорошие примеры, когда инсталятор распространяется также в виде исполняемого jar-архива без JRE (кому надо - те разберуться). Очень жаль, что здесь не так - загружать не буду :(

>Преимуществом GCC от "многих C++ _комерчиских_ компиляторов" является совсем >не это, а его бесплатность и распространенность среди множества платформ. >Собственно как компилятор GCC часто проигрывает своим конкурентам.

в свое время gcc установил новые стандарты по оптимизации и поддержке последних стандартов.

сейчас на часте платформ он уступает в плане оптимизации. что не удивительно.
т.к. производитель процессора соптемезирует лучше.

но вот в плане соотв. стандартов он все еще впереди.

а насчет GNU расширений, это чушь, ядро да использует,
да и то в последний стандарт включили большиство фич,

остальные приложения почти не исп. GNU расширения.

> Собственно как компилятор GCC часто проигрывает своим конкурентам.

в плане поддержки последних расширений C/C++ gcc выигрывает.

ЗЫ

если не знаешь то лучше промолчать

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

>> Собственно как компилятор GCC часто проигрывает своим конкурентам. > >в плане поддержки последних расширений C/C++ gcc выигрывает. > >ЗЫ > >если не знаешь то лучше промолчать

Что, опять со своими советам лезешь?

Речь идет не о поддержке расширений и прочей фигни, а речь идет о _качестве_ генерируемого кода. Кстати, одним из лучших C/C++ компиляторов для x86 многими признается Visual C++. правда его шестая версия была "не очень" ANSI-совместимой. Надеюсь, сейчас там дела обстоят лучше.

> а насчет GNU расширений, это чушь, ядро да использует, > да и то в последний стандарт включили большиство фич, > > остальные приложения почти не исп. GNU расширения.

Ты опять не в теме... :(

Между прочим, одной из основных "технических" причин, по которой Sun для Solaris в свое время выбрал Gnome вместо KDE была следующая.

Все C++ компиляторы при генерации объектных файлов "искажают" сигнатуры функций для поддержки так называемой "перегрузки". Так вот, не существует единого стандарта, который бы строго определял как именно нужно проводить это "искажение" имен. Это ведет к тому, что С++ -библиотеку, сгенерированную компилятором GCC, нельзя в общем случае напрямую использовать с другими C++ компиляторами - они просто не понимают "искаженных" имен.

Теперь смотри. Основа KDE написана на C++, а вот основа Gnome - на "голом" C.

Что касается программ на C, то там тоже есть свои заморочки с объектными файлами, но видимо, GCC и сановский C-компилятор более-менее совместимы друг с другом [см. книгу Страуструпа "Дизайн и эволюция языка программирования C++"].

Собственно, исходный посыл (не мой) был, что языкам C/C++ очень далеко до Java в поддержке многоплатформенности и единых стандартов. Причем на Java вполне можно создавать _быстрые_ программы. Или еще хочешь спорить?

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

"Коммерческий" - значит продается за деньги. Ты думаешь иначе?

>еперь смотри. Основа KDE написана на C++, а вот основа Gnome - на "голом" C.

и что?

общеизвестно что собранные одним компилятор объектные файлы, не воспрмет
не родной линкировшик.

и что?

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

другое дело что сановский компилятор не до конца поддерживает стандарт C++.

можешь например посмотреть список рассыки aspell, про портирование на сан.

у них просто старый компилятор и нет сил реализовывать все фичи.

описание C++ - это около 1000 страниц тескта и не так легко все реализовать.

>Причем на Java вполне можно создавать _быстрые_ программы.

из личного опыта:
однажды так получилось что критическое место ПО было реализованы
на Java, так исторически сложилось,
и когда пошла речь не только о том соотвествует ли ПО ТЗ, но и о том
насколько быстро оно работает,
тогда переписали критический участок на C++, алгоритм при это не меняя
и о чудо: быстродействие выросло в несколько раз.

ну и что естественно что в стандарте C++ не описан как
должен выглядеть объектный файл, это было бы ограничение на реализацию.

но как это может помешать собрать KDE и помочь собрать Gnome я не понимаю.

> языкам C/C++ очень далеко до Java в поддержке многоплатформенности и единых >стандартов

а это говорит о том что вы еще из десткого возраста не вышли

> Причем на Java вполне можно создавать _быстрые_ программы.

быстрые это абстрактное понятие, вы хотите сказать что один и тот же
алгоритм записанный на C/C++ и Java. будет работать с одинаковой скоростью?

> тогда переписали критический участок на C++, алгоритм при это не меняя и о чудо: быстродействие выросло в несколько раз.

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

;)