пишем на java (:

5+, мне нравится

p.s. да простят меня за отсутствие версии ядра, аптайма, открытого на странице лора firefox`а и вторых часов (забыл сразу дописать)

спасибо, мне тоже (:

Респект брату по оружию.

Может, это и не моё дело, но чем Netbeans не угодил? Как раз сегодня попробую 6.0 - говорят, очень хорош даже по сравнению с 5.5.

А почему не maven?

Приятный скрин. Гном не вызывает чувства унылости...

netbeans хорош. именно тогда хорош когда проект создается, пишется система сборки, отлаживается система дефайнов и т.д., а потом когда начинается банальная правка багов мне он ни к чему, как то быстрее и удобнее мне быстренько в vim или emacs поправить.
а для больших проектов конечно же использую ide на стадии разработки и первичной отладки.

за Сусю +1

в maven появляются очень серъезные и в большом количестве косяки, когда к примеру нужно создать пару классов динамически на стадии сборки, да и вообще все серъезные проекты что я видел на maven пестрят maven-ant-plugin.
ant все же гибче, да и документирован получше, а про документацию к maven по сей день легенды слагают.
хотя.. давно на maven не смотрел, может быть дело привычки.

just for fun?

Молодец. Крут. По теме: java must die, а зачем NFS на мобиле? А не быстрее эмулятор Z80 запустить - куча игр проверенных?

> да и вообще все серъезные проекты что я видел на maven пестрят maven-ant-plugin

А я предпочитаю написать свой плагин для решения конкретной задачи в мавене, нежели исопльзовать ант-таски.

> ant все же гибче, да и документирован получше, а про документацию к maven по сей день легенды слагают.

Бесспорно, документация вроде как и есть, но при этом вроде бы и нету. :))

Буквально вчерашний опыт: есть модуль с packaging=pom, и у него есть два родительских модуля A и B. В модуле A прописана зависимость от B. На стадии mvn compile проблем нету. Теперь, если модуль A имеет подмодуль A1 с packaging=jar, то он автоматом наследует зависимость от модуля B. Но в таком случае maven не в состоянии предоставить эту зависимость на этапе компиляции и требует установленного в локальном репозитарии модуля B. Приходится делать mvn install.

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

в проектах где не нужно собирать ресурсы под каждый билд может и не нужно, а в ситуации с j2me непосредственно сборке и компиляции исходников и antenna, предшествует мучительная сборка ресурсов, отбор нужного по дефайнам, манипуляции с графическим контентом, плюс ко всему обычно необходимо создавать несколько билдов одной и той же версии под конкретный телефон с разным функционалом или к примеру с разными логотипами операторов-заказчиков. и тут ant как нельзя лучше подходит, так как все равно приходится писать скрипт сборки под каждый проект.
т.е. по сути универсального пути нет.
к примеру, один только скрипт сборки билдов в одном проекте из одних ресурсов под midp1.0 (где отсутствует как явление TRANSFORM и приходится или самому писать работу с матрицами или хранить разноотраженные текстуры), midp2.0 и jsr-184 с корявым m3g чего стоит.

ну, java может и must die, но пока платят хорошие деньги - меня устраивает.
зачем NFS на мобиле это ты письмо в ElectronicsArts напиши, они хотят.
зачем мне проверенные игры? (: если ты не заметил - я их пишу

А почему код не опенсорцевый?!;)

Да, и вот это вот nodei*3 + 0, nodei*3 + 1, nodei*3 + 2 вызывает грусть. Почему не завести какой-нибудь idx и не сделать idx++, idx++, idx++. И даже умножать на 3 не надо будет...

А вообще, единственное, чего мне реально не хватает жабке на уровне языка - эффективных итераторов по массивам. Одно из немногих (едва ли не единственное) разумное применение указателей.

Можно подробнее, чего не хватает? Какой эффективности? Чем не устраивает обычный цикл с индексом или ArrayList?

ну, в связи с тем, что я тоже отношусь к партии "я не вижу места c++ в нашем мире и, мне честно сказать, он не очень приятен" я развею миф о быдлокодерстве данного случая (:
дело в том, что вот эти вот три троечки и от нолика до двух до того как по коду пройдет препроцессор задефайненный являются константами, которые соответственно подставляются непосредственно в момент сборки, исходя из того что собирается и какие дефайны объявлены. т.е. там могут быть и не троечки, а 6, 2, 7, тоже самое и с остальными цифрами, в связи с чем оптимизировать данный кусок особой необходимости нет, тем паче что это все развернется в неимоверные конструкции на стадии обфускации, proguard`а.
так менее грустно? (:

может я не допонимаю сути заявление, но с итераторами по массивам и коллекциям никогда проблем не возникало.
или ключевое слово *эффективных*?

> Чем не устраивает обычный цикл с индексом или ArrayList?

Скоростью. ArrayList вообще не обсуждается - он медленнее даже массива с индексом. Но и массив с индексом - медленнее, чем работа с указателем.

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

Вместо

for (i=0;i<SIZE;i++)
a[i] = b[i];

правильнее делать

char* pa = a;
char* pb = b;

for (i=SIZE;--i>=0;)
*pa++ = *pb++;

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

PS Я в курсе про memcpy, пример специально взят бессмысленный.

> я развею миф о быдлокодерстве

Где ж я Вас так обругал? Вообще выставлять свой код в галерею - требуется известная смелость, так что я обычно до оскорблений не дохожу;)

Объяснение довольно туманное. Я так понял, что кроме указателей, в Вашем случае еще не хватает препроцессора;) Да, разумеется, мой комментарий взят вне контекста всего проекта. Но Вы все-таки подумайте - нафига вам 6 арифметических операций (да еще 3 умножения) - вместо трех инкрементов. Лишний раз подумать же никогда не вредно?;) Исправите что-нибудь - хорошо. Не исправите - это Ваш код, и Вам виднее.

Если обфускатор портит логику и снижает эффективность жабского кода, а не только корежит идентификаторы - как-то хочется сказать "фтопку".

> ключевое слово *эффективных*?

!

Потом еще говорят, что java тормозит:) И все же уж лучше java (сам на ней пишу) чем .Net.

Можно и так: int count = nodeCount << 1 + nodeCount - 1; // вместо * 3, думаю и на java такое должно правильно переводиться в машинные коды из байт кода for (int i = -1; i <= count;) { elm[++i] = elm[++i] = elm[++i] = } Это, если со всеми правилами оптимизации. ++i ведь предпочтительнее, чем i++. И операция вычитания перед циклом с лихвой окупится при проходе по элементам массиива.

Или в более привычном виде: int count = nodeCount << 1 + nodeCount; for (int i = 0; i < count;) { elm[i++] = elm[i++] = elm[i++] = }

ну в данном случае, указатели сработают быстрее, можно конечно проверить, но думаю не стоит.
хотя System.arraycopy конкретно для данного случая должен показать результат гораздо выше нежели инкремент.
суть ясна, но опять же сравнение C и java удел холиварщиков.

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

> сравнение C и java удел холиварщиков.

Отнюдь не собирался начинать какие бы то ни было холивары (тем более что мне придется разорваться в такой войне:). Просто есть хорошая вещь в С, которую (желательно без введения сущности "указатель") хотелось бы иметь в жабке на уровне языка. Может, однажды появится какой-нибудь JSR на эту тему...

> Объяснение довольно туманное. Я так понял, что кроме указателей, в Вашем случае еще не хватает препроцессора;)
это код после препроцессора, изначально эта конструкция выглядит примерно так:
x * CONST.MAP_SYNC_POINT_1 + CONST.MESH_INDEX
x * CONST.MAP_SYNC_POINT_2 + CONST.NO_TRANSFORM
x * CONST.MAP_SYNC_POINT_3 + CONST.DEFAULT

а после препроцессора, появляется увиденный Вами код, суть в том, что в каждом билде свои значения CONST и до момента сборки они явно не определены, т.е. туманны (:

насчет обфускатора я как нибудь напишу "хвалебную" оду, кровопийца еще тот.
был там печальный баг, который Thread.sleep в условии if разворачивал как for, искали долго...

А-а... Так это ПОсЛЕ препроцессора. Тогда ... У вас хреновый препроцессор %) Ну или надо б его (или входной код) как-нибудь вздрючить на предмет инкрементации вместо умножения. Использовать тот факт, что SYNC_POINT одинаковые и индексы последовательные... Если это так, конечно, в общем случае (или хотя бы в половине случаев).

А обфускатору нельзя опции помягче поставить? Или просто заопенсорсить код нафиг?;)

>p.s. шрифты на ноуте смотрятся хорошо

Нет, уважаемый, шрифты, кроме терминуса, который без сглаживания, смотрятся плохо. У меня vaio sz5mrn, и шрифты - терминус (консоль) и вердана (везде) без сглаживания смотрятся просто великолепно. Попробуйте.

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

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

Ну, Вам виднее

ЗЫ Я говорил про открытие кода игрушки, не обфускатора. Тогда обфускатор будет просто не нужен;)

насчет "виднее" конечно не дефакто, ибо с удовольствием слушаю мнения других людей и даже иногда соглашаюсь (:
они жмоты там, не дают опенсорсить даже то, что уже давно продано-перепродано и просто пылится чуть не на лентах.

Хочеться обругать скрин за java.. да никак... скрин зачетный.

Ну, в принципе неплохо, но мне цветовая схема в редакторе не нравиться, ничего не видно.

> netbeans хорош. именно тогда хорош когда проект создается, пишется система сборки, отлаживается система дефайнов и т.д.

Sorry, не сразу прочитал описание скрина. А конвертор для Blender - закрытая разработка или можно будет заценить?

открытая, как допишу - выложу.
сейчас есть конвертор из blender`а в m3g на Python`e, а обратного как бы нет. я вот все собираюсь написать письмо автору плагина на Python`e, чтобы и его функционал включить в утилиту, чтобы зоопарк не разводить.

>Ну, в принципе неплохо, но мне цветовая схема в редакторе не нравиться, ничего не видно.

дело сугубо привычки, мне удобно.

представьте что это mono, это будет легко (:

Правильно говорят - работа с неподходящими средствами разработки ведет к хардкодингу. :)

Зачем заниматься мазохизмом и приобретать жуткий стиль кодирования, когда есть мегарулезные Eclipse и/или NB?

???? А при чем тут эклипс и нетбинзы? Проект, который нельзя собрать в командной строке (ant/make/maven/...) - сразу фтопку.

вот такие мегарулезы потом не могут в блокноте написать HelloWorld без шаблона.
и понятия не имеют что происходит при инициализации приложения и т.д.
вот скажи, на java можно написать HelloWorld без метода main и чтобы это дело еще и эксепшены не выдавало?

>p.s. шрифты на ноуте смотрятся хорошо

Не соглашусь.

1) Быдло (ч.б., то есть) сглаживание на рабочем столе (gtk). "Ниасилил"? ..

2) Тем более странно смотрится хорошее субпиксельное сглаживание в эмуляторе телефона и memory monitor extention.. =\ Вероятно, это жабка так субпиксельное рисует, да? Или же были какие-то манипуляции?

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

>жаба сама сглаживает, ничего не трогал.

Хорошо сглаживает. 8)

>еще раз повторяю - на мониторе ноута смотрится все замечательно,

Еще раз повторяю - с субпиксельным смотрелось бы _еще_ лучше. ;) Только надо cleartype-like-патчики накатить и, желательно, шрифты от свисты. Тогда будет полный превед. 8) Неужели ты не видишь разницы между жабо и твоими шрифтами? Возможно, ты это и не замечаешь, если размер точки на ноуте мелкий. Но это не делает быдлосглаживание нормальным, тем более на жк-мониторе. Хз, решай сам, я лишь предложил.

попробую вечерком, о результатах отрапортую (:

SuSe - не зачтено.

Ключевые моменты:
- пересобрать freetype со включенными bci и субпиксельным сглаживанием
- патчик на libXft
- патчик на cairo (для нормального сглаживания в gtk приложениях)
- шрифты от говновисты (расчитаны на субпиксельное сглаживание, без него выглядят хреново, зато со сглаживанием наиболее вменяемы.)
- ~/.fonts.conf
<match target="font" >
<edit mode="assign" name="rgba" >
<const>rgb</const>
</edit>
</match>
<match target="font" >
<edit mode="assign" name="autohint" >
<bool>false</bool>
</edit>
</match>
<match target="font" >
<edit mode="assign" name="hinting" >
<bool>true</bool>
</edit>
</match>
<match target="font" >
<edit mode="assign" name="hintstyle" >
<const>hintslight</const>
</edit>
</match>
<match target="font" >
<edit mode="assign" name="antialias" >
<bool>true</bool>
</edit>
</match>

rgb, bgr .. зависит от монитора. скорее всего rgb

зы: constantina у меня не отображает цифры на курсиве и жирном. =( если у кого есть соображения.. :?

немного оффтоп, но ... m_trackStartFinishLinePoint ... ох и названия ... конечно должно быть понятно че в переменной записано но это уже перебор по-моему ... вообще префикс m_track у кучи переменных явно говорит о том что пора заводить структуру Track какую-нить и уже с ней работать ...

зы: все имхо ... сорри за оффтоп ...

>Со сдвигом, конечно, лучше, чем умножение. Но ИМХО хуже читается

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