LINUX.ORG.RU

пишем на java (:


0

0

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

собственно на скрине идет портирование 3d движка для игрушки с brew на j2me, игрушка как нетрудно заметить need for speed.
смотрю и плачу как оно кушает память, набирая аппетит, в почти статичном контенте.
портируется с использованием jsr-184, это такая штука, чтобы работать с 3D, почти что API для мобильников (: проблемы с тормозами, впрочем тут уж точно это плоды кроссплатформенности и т.д.
последнее время разработчики игрушек повадились писать утилиты для сборки на c#, что тоже геморойно, ибо раз раз не приходится с mono, иной раз приходится в virtualbox`е собирать проект...
сборка обычно делается с помощью ant`а, с приблудами типа обфускатора и т.д.
а так в принципе, работается нормально, тормозов нет, с кодом работаю в vim, в запущенном netbeans 6.0 пишется утилита для человеческого просмотра m3g файлов (с графическими объектами) и их экспорта в формат blender`а. в netbeans`е намного проще писать утилиты, половину делает IDE, половину ты, с критичным кодом так не получится, поэтому после отладки механизма сборки - перемещаемся в vim\emacs и там уже трудимся, ибо тут уже механизмы IDE не особо мне нужны.
все это работает на ноуте Sony Vaio C2ZR/B.
ждем ругани (:
p.s. шрифты на ноуте смотрятся хорошо

>>> Просмотр (1280x800, 215 Kb)



Проверено: Pi ()

Re: пишем на java (:

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

divenvrsk ()

Re: пишем на java (:

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

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

Ardolynk ()

Re: пишем на java (:

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

anonymous ()
Ответ на: Re: пишем на java (: от Ardolynk

Re: пишем на java (:

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

divenvrsk ()

Re: пишем на java (:

за Сусю +1

anonymous ()
Ответ на: Re: пишем на java (: от Bohtvaroh

Re: пишем на java (:

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

divenvrsk ()

Re: пишем на java (:

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

alx_me ★★☆ ()
Ответ на: Re: пишем на java (: от divenvrsk

Re: пишем на java (:

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

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

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

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

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

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

Bohtvaroh ★★★★ ()
Ответ на: Re: пишем на java (: от Bohtvaroh

Re: пишем на java (:

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

divenvrsk ()
Ответ на: Re: пишем на java (: от alx_me

Re: пишем на java (:

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

divenvrsk ()

Re: пишем на java (:

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

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

svu ★★★★★ ()
Ответ на: Re: пишем на java (: от svu

Re: пишем на java (:

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

svu ★★★★★ ()
Ответ на: Re: пишем на java (: от svu

Re: пишем на java (:

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

anonymous ()
Ответ на: Re: пишем на java (: от svu

Re: пишем на java (:

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

divenvrsk ()
Ответ на: Re: пишем на java (: от svu

Re: пишем на java (:

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

divenvrsk ()
Ответ на: Re: пишем на java (: от anonymous

Re: пишем на java (:

> Чем не устраивает обычный цикл с индексом или 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, пример специально взят бессмысленный.

svu ★★★★★ ()
Ответ на: Re: пишем на java (: от divenvrsk

Re: пишем на java (:

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

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

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

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

svu ★★★★★ ()
Ответ на: Re: пишем на java (: от divenvrsk

Re: пишем на java (:

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

!

svu ★★★★★ ()

Re: пишем на java (:

Потом еще говорят, что 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++] = }

gaux ★★ ()
Ответ на: Re: пишем на java (: от svu

Re: пишем на java (:

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

divenvrsk ()
Ответ на: Re: пишем на java (: от gaux

Re: пишем на java (:

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

svu ★★★★★ ()
Ответ на: Re: пишем на java (: от divenvrsk

Re: пишем на java (:

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

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

svu ★★★★★ ()
Ответ на: Re: пишем на java (: от svu

Re: пишем на java (:

> Объяснение довольно туманное. Я так понял, что кроме указателей, в Вашем случае еще не хватает препроцессора;)
это код после препроцессора, изначально эта конструкция выглядит примерно так:
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, искали долго...

divenvrsk ()
Ответ на: Re: пишем на java (: от divenvrsk

Re: пишем на java (:

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

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

svu ★★★★★ ()

Re: пишем на java (:

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

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

KOPEHb ★★★ ()
Ответ на: Re: пишем на java (: от svu

Re: пишем на java (:

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

divenvrsk ()
Ответ на: Re: пишем на java (: от KOPEHb

Re: пишем на java (:

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

divenvrsk ()
Ответ на: Re: пишем на java (: от divenvrsk

Re: пишем на java (:

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

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

svu ★★★★★ ()
Ответ на: Re: пишем на java (: от svu

Re: пишем на java (:

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

divenvrsk ()

Re: пишем на java (:

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

mono ★★★★★ ()

Re: пишем на java (:

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

defmacro ()
Ответ на: Re: пишем на java (: от divenvrsk

Re: пишем на java (:

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

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

Ardolynk ()
Ответ на: Re: пишем на java (: от Ardolynk

Re: пишем на java (:

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

divenvrsk ()
Ответ на: Re: пишем на java (: от defmacro

Re: пишем на java (:

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

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

divenvrsk ()

Re: пишем на java (:

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

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

Bioreactor ★★★★★ ()
Ответ на: Re: пишем на java (: от Bioreactor

Re: пишем на java (:

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

svu ★★★★★ ()
Ответ на: Re: пишем на java (: от Bioreactor

Re: пишем на java (:

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

divenvrsk ()

Re: пишем на java (:

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

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

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

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

anonymous ()
Ответ на: Re: пишем на java (: от anonymous

Re: пишем на java (:

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

divenvrsk ()
Ответ на: Re: пишем на java (: от divenvrsk

Re: пишем на java (:

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

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

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

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

anonymous ()
Ответ на: Re: пишем на java (: от divenvrsk

Re: пишем на java (:

Ключевые моменты:
- пересобрать 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 у меня не отображает цифры на курсиве и жирном. =( если у кого есть соображения.. :?

anonymous ()
Ответ на: Re: пишем на java (: от s1392781

Re: пишем на java (:

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

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

anonymous ()
Ответ на: Re: пишем на java (: от svu

Re: пишем на java (:

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

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

gaux ★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.