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 ()

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

divenvrsk
() автор топика

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

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

Ardolynk
()

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

anonymous
()
Ответ на: комментарий от Ardolynk

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

divenvrsk
() автор топика

за Сусю +1

anonymous
()
Ответ на: комментарий от Bohtvaroh

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

divenvrsk
() автор топика

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

alx_me ★★☆
()
Ответ на: комментарий от divenvrsk

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

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

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

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

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

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

Bohtvaroh ★★★★
()
Ответ на: комментарий от Bohtvaroh

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

divenvrsk
() автор топика
Ответ на: комментарий от alx_me

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

divenvrsk
() автор топика

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

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

svu ★★★★★
()
Ответ на: комментарий от svu

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

svu ★★★★★
()
Ответ на: комментарий от svu

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

anonymous
()
Ответ на: комментарий от svu

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

divenvrsk
() автор топика
Ответ на: комментарий от svu

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

divenvrsk
() автор топика
Ответ на: комментарий от anonymous

> Чем не устраивает обычный цикл с индексом или 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 ★★★★★
()
Ответ на: комментарий от divenvrsk

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

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

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

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

svu ★★★★★
()
Ответ на: комментарий от divenvrsk

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

!

svu ★★★★★
()

Потом еще говорят, что 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 ★★
()
Ответ на: комментарий от svu

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

divenvrsk
() автор топика
Ответ на: комментарий от gaux

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

svu ★★★★★
()
Ответ на: комментарий от divenvrsk

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

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

svu ★★★★★
()
Ответ на: комментарий от svu

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

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

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

svu ★★★★★
()

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

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

KOPEHb ★★★
()
Ответ на: комментарий от svu

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

divenvrsk
() автор топика
Ответ на: комментарий от KOPEHb

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

divenvrsk
() автор топика
Ответ на: комментарий от divenvrsk

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

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

svu ★★★★★
()
Ответ на: комментарий от svu

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

divenvrsk
() автор топика
Ответ на: комментарий от divenvrsk

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

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

Ardolynk
()
Ответ на: комментарий от Ardolynk

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

divenvrsk
() автор топика
Ответ на: комментарий от defmacro

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

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

divenvrsk
() автор топика
Ответ на: комментарий от mono

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

divenvrsk
() автор топика

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

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

Bioreactor ★★★★★
()
Ответ на: комментарий от Bioreactor

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

svu ★★★★★
()
Ответ на: комментарий от Bioreactor

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

divenvrsk
() автор топика

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

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

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

divenvrsk
() автор топика
Ответ на: комментарий от divenvrsk

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

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

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

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

anonymous
()
Ответ на: комментарий от divenvrsk

Ключевые моменты:
- пересобрать 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
()
Ответ на: комментарий от s1392781

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

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

anonymous
()
Ответ на: комментарий от svu

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

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

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