• Какие игровые движки существуют для Python?

    @WorldEn
    На данный момент для Python есть следующие движки на выбор:

    2D:
    - Cocos 2D (сам лично им не пользовался и ничего сказать не могу, но знаю, что русскоязычное сообщество использует этот движок для с++, вместо python)

    - Kivy (это потомок Pygame, о котором напишу ниже. В основном он предназначен для создания приложений под андроид, но 2D игры тоже на нём делают)

    - Собственно PyGame (Это библиотека Python для создания 2D игр. Очень проста в освоении и есть много уроков и книг на английском и русском. Можно создать практически любую 2D игру. Русское сообщество тоже есть. Хорошая книга на русском здесь)

    - Так же есть 2D + 3D движок с внутренним языком программирования, который очень похож на Python. Т.е если знаешь Python, то этот ЯП освоишь максимум за неделю или даже меньше. Godot Engine

    3D:
    - Из 3D движков единственные это Blender Game Engine. Движок прост в освоении и, в принципе, даже не надо знать языка программирования для создания хорошей игры. Однако если знаешь Python, то это большой плюс, так как скрипты для этого движка пишутся именно на этом языке. Хорошая книжка по движку здесь, а здесь перевод. Примеры игр: раз, два.

    - И , конечно же, Panda 3D. Это не конструктор игр, как Blender Game Engine, где ты создаешь игру, не написав строчки кода. Это конкретный игровой движок, где ты с нуля пишешь код на Python используя API этого движка и создаешь 3D игру. Я сейчас сам его осваиваю и у движка есть живое русскоязычное сообщество, где могут подсказать если что. Так же по движку много видео уроков и книг на английском. Вот одна из этих книг- она на английском, но написано всё понятно, что даже я, не зная инглиш, понимаю))))) Примеры игр: раз, два, три.
    Ответ написан
  • Стоит ли покупать коленный стул?

    @AlexeyCarpenter
    Коротко не получится.

    Я изготавливаю коленные стулья по индивидуальному заказу уже несколько лет и столько же сижу на нем(я и моя жена). Мы сделали это основной своей работой. Могу сказать многое как о самом кресле, так и о людях, которые на них сидят. Но мы противники распространяемой магазинами идеи, что этот стул лечит все болезни и в таком духе. Но скажем точно, что сами не пересядем на обычное классическое кресло. Стоит ли покупать? Вот мои рассуждения. Может кому-то пригодятся.

    Однозначно, что сам по себе стул - это лишь приспособление. Он не нужен всем. Допустим, вы испытываете легкий дискомфорт от 3-4 часов работы сидя - у вас немного болит поясница, но эта боль быстро проходит после перерыва. Вы - человек, которого раздражает даже такой "изи" дискомфорт. Не покупайте стул. Период привыкания к нему вызывает еще больший дискомфорт. По своему опыту скажу, что на коленном стуле сидеть невероятно удобно лишь с месяцами и годами. В классическом кресле же, наоборот. С годами от такого кресла могут развиться или усугубиться многие болезни. Тут все индивидуально. У кого-то сразу появляются межпозвоночные грыжи а с ними и защемления нервов. У кого-то с позвоночником все норм, но нарушается кровоток в мягких тканях таза и пошло-поехало. Никуда не денешься от нашей анатомии. Коленный стул за счет наклона сидения ближе к положению при котором мышцы спины не испытывают чрезмерную нагрузку, чтобы удерживать спину прямо. Поэтому тем, кто настолько устал от боли в пояснице, что их не пугает ни период привыкания, ни нестандартная новая посадка, добро пожаловать. Вы не пожалеете.

    Мы проводили испытания и наблюдения за людьми разного пола, возраста и комплекции. Вот что заметили. Женщины быстрее привыкают и меньше жалуются на дискомфорт в коленях. Высоким людям не удобно на коленном стуле, но высоким женщинам может подойти при условии, что коленный стул можно настроить. Для людей крупной комплекции необходимо выбирать модели с расширенным коленным упором для большей свободы ног. По этой же причине мы не советуем покупать стулья, в которых коленный упор раздвоен на две половинки (некоторые стулья типа "баланс", но не все). На сайте британского интернет магазина есть заметка от покупателя, которому не нравиться такой вариант именно из-за ограничения свободы колен.

    В течении дня сидящий активно меняет положение тела. Колени после привыкания вообще не жалуются. А мягкие ткани в бедрах и ягодицах испытывают меньшую нагрузку и в них улучшается кровоток(по сравнению с обычным креслом конечно).

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

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

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

    Мне в подростковом возрасте ставили диагноз остеохондропатия бугристости большеберцовой кости. Я не мог сидеть на полу опираясь на колени. Хоть с тех пор прошло около 10-ти лет и никакого лечения мне не прописывали я без проблем сижу на коленном стуле, хоть ходить на коленях, как здоровые люди, не могу вообще. Конечно, тут еще может играть качество материалов, из которых сделан коленный стул. В своих я использую 2 вида поролона с разной плотности, чтобы исключить продавливание подушки.

    Покупайте у тех, кто готов принять возврат в течении 14 дней.

    Лично мне удобно на стуле именно работать. Играть, смотреть кино на нем нет смысла. Мне он помогает сосредоточено и долго работать.
    Ответ написан
  • Верстка в Linux?

    @timonbandit
    Front End Developer
    Почему-то на этот вопрос есть ОГРОМНАЯ КУЧА БРЕДА, от малоопытных ребят, которые готовы прям помочь. Я с 2012 года не пользуюсь виндой(для игр только и то не для всех (-:) и я фронтендер.
    Linux Mint(Xfce и Cinnamon)
    Photoshop CS2 - просто скачал и установил(wine) - просто он бесплатен(типа того), работает отлично. ВСЁ РАБОТАЕТ.
    Но пришлось поставить cs6, по иным причинам. Так вот! ОН РАБОТАЕТ! БЕЗ ПРОБЛЕМ, БЕЗ ТАНЦЕВ С БУБНОМ, БЕЗ ВИРТУАЛОК. просто берешь и устанавливаешь в PlayOnLinux(уже готовая сборка есть под эту версию)

    Так же в playOnLinux - IE8, IE9, IE10

    На хабре мало линуксоидов, но много виндоюзеров без опыта и поэтому некоторые вопросы превращаются в Ответы.Mail. Не слушай их! Linux идеален для веб-разработки, мак тоже хорош, но мне не нравится клавиатура родная и для настройки сервера тоже нужны костыли(но это мелочи по сравнению с костылями в винде)
    Ответ написан
  • Софт для веб-дизайнера в linux

    showcrack
    @showcrack

    Недавно, был на одном мероприятии посвященном Ubuntu Linux, так вот там данная тема была затронута.

    Ведущий сказал, что GIMP при правильной настройке заменит полностью Photoshop. В зале сразу пошел недовольный гул и смех.

    Не тратьте свое полезное время:)

    Ответ написан
  • OBS Studio и пользовательский сервер вещания? Или как передать видео по локальной сети?

    @KsinyS Автор вопроса
    Вот ответ на мой вопрос, тот который я и искал и тут нет необходимости устанавливать стороннее программное обеспечение и колупатся в дебрях.
    Все оказалось так банально и просто что я сам даже и не ожидал, не ожидал что "OBS Studio" сам такое умеет.

    https://helping-squad.com/obs-studio-send-an-udp-s...
    Ответ написан
  • Черным по белому или белым по черному?

    @65520
    Попробуйте это. Ещё можно увеличить шрифты хотя бы в браузере. Я себе поставил 120% и мне стало гораздо комфортней.
    Ответ написан
  • Android: Qt vs Java. Что лучше использовать?

    @dplsoft
    Посмею оспорить ход рассуждений lorus ( Android: Qt vs Java. Что лучше использовать? ).
    Итог у нас почти один, но как в математике - когда ход рассуждений ошибочен - даже если ответ верен - то задача не решена. Возможно во много субъективно, но выскажусь, на правах личного мнения человека, который любит и писал и на Qt, и на Android с его "родным" Java тоже.
    На Qt для Android не писал, потому что на момент начала последнего проекта технология была сырая.

    И так: Не агитка за Qt но несколько слов в защиту Qt.

    Забегая вперед скажу: топикстартеру - если есть небольшой опыт разработки под Андроид, вы не работали ранее с Qt, и вам не важна переносимость исходного кода между всем и вся - продолжайте осваивать Android SDK ( Java ) .
    По крайней мере, сейчас.
    Хорошее знание хотя бы одного инструмента, лучше чем посредственное знание двух. ;)
    C Qt под Андроид потом разберетесь. Да и "пообкатаннее" оно будет.


    1. Qt - это всё-таки C++. Разрабатывать на нём существенно сложнее, чем на Java. То есть дольше и с большим количеством ошибок.

    Надо отличать "просто С++" и С++\Qt. В первую очередь, Qt - это фактически диалект языка С++. Например в объявлении Qt-класса появляются дополнительные секции signal и slots, а в процессе сборки существует фаза мета-компиляции, которая делает C++ код под вашу платформу. Не удивлюсь, если для андроида генерируется сместь Java и C++ кода которая потом скармливается Android NDK.

    Во вторых, Qt - это _самодостаточный_ фреймворк. Никаких STL или "чего-что-ещё что представляют себе в комплекте с C++" типичные сторонние разработчики.
    Многих проблем, которые приводят к сложности разработки "на простом C++" в "С++\Qt" просто нет "by design".

    Например в Qt заложен замечательный механизм предотвращения от выхватывания "null-poiunter" - "сигнал-слоты". Это в разы упрощает и делает надежнее работу как с GUI, так и с например, объектами, работающими в разных потоках. В Qt это все сделать разы проще, чем городить аналогичные стандартные механизмы на Java. Я не говорю в итоге оно будет эффективнее - тут надо выяснять и можно поспорить - но вот то, что в Qt многие вопросы работы с потоками и межпоточным взаимодействием продуманы лучше а механизмы удобнее - на мой вгляд это факт.
    (Хотя вот такого классного механизма аки runnable, в Qt нет. Но ждем 11-го стандарта С++.)

    В третьих - "С++\Qt" - это хорошо продуманный фреймворк едва-ли не с лучшим дизайном классов, продуманными методлами, единым стилем решения проблем.

    Как человек писавший на Qt 4.0-4.6 и сейчас закончивший первывый коммерческий проект для Android - могу выставить в сторону Java много минусов (в сравнении с Qt4/Qt5.) Просто потому, что Java - как в первую очередь коммерческая технология, был вынужден набирать нелогичности ради совместимости с предыдущими версиями - едва-ли не из первых версий Java. Посомтрите вопросы к сертификации - много вопросов, которые когда начинаешь разбирать "почему так" - уходят корнями в далекое темное прошлое развития Java. И в итоге - современная Java - это часто нелогичное, лоскутное одеяло, где в разных классах для решения одной и той-же задачи применяется если не разный подход и стиль, то как минимум разные имена методов. Ну вот зачем это?)))

    Да Java детально описан, и в технически прогнозируем - но его надо зубрить, тупо зубрить все исключения и проблемы наследования логики первых версий, и зубрить где используется put(), а где add()....
    ... а Qt-можно _понять_ и не зубрить, понять и только изредка заглядывать в документацию. И в итоге писать на нем - легче.

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

    Ещё к слову про миф "на Java писать проще чем на C++"(если сравнивается Java под DalvikVM и C++\Qt5):
    Не забывайте - DalvikVM - это вам не JavaVM.
    В DalvikVM вы легко отхватите "null-pointer-exception" если вы вдруг наивно думаете, что коли у вас есть в локальной переменной ссылка на фрагмент, активити или вью - то машина не уничтожит объект "когда ей вздумается", а у вас ваша переменная не об-null-ится.

    На понимание того, какие привычки десктопного написания и дизайна приложений нельзя переносить во фреймворки Android SDK и на перестройку собственного мышления - у вас уйдет несколько месяцев. А вы _начнете_ это понимать и отхватывать такие проблемы - как только начнете писать что-то бОольшее, чем набор разрозненных активити да пары фрагментов из учебных курсов.
    И в итоге - первый ваш серьезный проект на Андроиде - может влететь вам в хорошие переработки.
    Например, в том числе и потому что нет в Android SDK v17 жизненного цикла для класса Application. Нет механизмов для созранения состояния singleton-окружения и тд.и тп.

    А когда вы пишете на Qt - у вас гарантирована поддержка единых механизмов для всех платформ.
    Вам не надо перекраивать мозг, выработанные решения и отлаженные и проверенные паттерны.
    В итоге - писать на Qt - может статься и будет быстрее. В ряде случаев.
    Но из Qt - может быть сложно поиметь доступ к сугубо-андроидным сервисам типа поставщика данных.

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

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

    Простите, но тоже малообоснованное утверждение. См пункт 1.

    Кроме того, отмечу:
    Qt-шный инструментарий позволяет вам получать одинаковое поведение на всех поддерживаемых платформах. Включая поведение GUI, Форм и одинаковую для всех систем архитектуру приложения. В идеале - с Qt - вы можете писать под Андроид так, как будто вы пишете под десктоп - не меняя архитектуру и структуру приложения.

    А когда вы пишете под Android на Java - вы всегда пишете кусок кода работающий в колнтексте DalvikVM и должны жить по предусмотренным данной машиной паттернам и сценариям, причем многие аспекты того "как это работает" - явно мало где прописаны. И если вдруг вы отсутпаете от стандартных шаблонов фреймворка Dalvik-машины - вы рискуете отгрести непонятные, трудно отловимые косяки, причем _вне_ вашего контроля, которые вы не можете корректно перехватить и обработать. Кто не знает - попробуйте уничтожить ViewGroup, id которого вы использовали как контейнер для размещения внутри него фрагмента. Как только вы делаете FragmentTransaction.commit() - вы ставите машине задачу, которую она будет выполнять "когда-то позже", вне вашего контроля, и не соизволит позволить вам корректно обработать исключение. Вплоть до возникновения ситуации, когда фрагмент пытается быть добавленным в Activity который уже отработал стандартные процедуры по Activity.finush(). Ладно бы оно выкинуло код ошибки куда, и тихо проигнорило - но это же Java - она выкинет исключение. А обернуть это дело в try...catch - вы не сможете - это не ваш кусок кода. Максимум что вы сможете - это "поймать перед смертью" Thread.UncaughtExceptionHandler. И все.
    (если я не прав - поправляйте меня, я же тоже не инженер гугля)

    3. Java - родная платформа для Android. Отсюда потенциальные проблемы с совместимостью у Qt.

    Вот зачем вы занимаетесь запугиванием?
    Android NDK (для разработки на С++) такой же родной как как и Android SDK (для разработки на Java).

    И с совместимостью у Qt с платформой Android проблем не больше, чем у любого другого приложения, которое использует вставки C++ кода и разработано с использованием стандартного Android NDK.

    --------------------------------------------
    Резюмируя: автору надо просто взвесить что зачем и как он собирается использовать.
    Если автору нужно одинаковое поведение на различных платформах - включая огрызочные поделия, Linux, разные Windows RT недопланшеты - то выбор ознозначен - курите Qt. Это возхитительнейший, ясный, хорошо продуманный и максимально логичный фреймворк, который не побоялись пересоздать с нуля ради устранения накопленных сложностей (вспоминайте переход с Qt3 на Qt4) Лично я приходил в восторг, когда работал с ним (2005-2009 гг)

    Но - в части Андроидного приклада : подозреваю, могут быть "технические риски" с использованием каких-либо особых "мобильных кусков" типа "работа со звонками, "работа с контактами", "работа с почтой" или "поставщиками контента", и пр.
    Я отошел от мира Qt когда Qt был 4.8 и я не искал там классы которые этим занимаются. Думаю что-то потомки троллей должны были создать в 5.2, но лучше проверить.
    В крайнем случае - может потребоваться стыковка с джава-объектами, и тут вам потребуется изучать Android NDK, и возможно даже писать немного оберточного кода на Java.

    Если же вам _нужна_ обязательная работа с описанными выше функциями, а на переносимость исполняемого кода - наплевать, или же у вас _уже_ есть опыт разработки с Android SDK - то конечно писать лучше на Java.

    Но в этом случае бутьте готовы к тому, что это не JavaVM, и сохранности ссылок _для_ряда_классов_ вам никто не обещает, а т.к. Java не предполагает наличия деструктора - вы _будете_ иметь определенные архитектурные сложности при построении сложных приложений.
    Например то, что в десктоп-приложении вы решили бы "простым" "синглтон-объектом" с простой функциональностью типа записал-прочитал из файла - тут вам _придется_ решать путем построения "поставщика контента" и т.п. - что значительно повышает "порог входа" для тех кто погруждается в разработку для Android.

    Но - надо отдать должное инженерам гугля - у них _были_ весомые основания поступать итак, и они максимально вас обезопасили от попадания в многие проблемы - если, конечно, вы используете фреймворк именно так, как это предполагается. И сделали многие механизмы достаточно элегантными, и приятными в использовании. Дизайн гуглековских классов мне в большей части нравится. В общем не забывайте понимать почему в примерах делается именно так как делается, а не иначе.
    Ответ написан
  • Git: объясните «на пальцах» разницу между rebase и cherry-pick?

    @Nkly777
    git chery-pick - ты забираешь комиты из одной ветки в другую, это бывает полезно когда изменения сделаные другим разработчиком в его ветке, прямо сейчас нужны тебе в твоей ветке, и что бы не писать этот код заново, ты забираешь его комит себе в ветку

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

    git merge - обычно используется когда у вас 2 и более master ветки (к примеру master и prototype) в этих ветках очень много комитов (и rebase здесь не подходит) и обчно через пару недель, maintainer репозитория наработки из prototype ветки "сливает" в master ветку по средствам этого самого git merge

    P.S. Что бы легче предствить разницу между git merge и git rebase. Представь что merge как собачка на молнии у одежды - "сшивает" комиты по дате их создания.
    В то время как git rebase как пожарная лестница - при применении твои коммиты крепится на конец родительской ветки

    git merge используйте для мержа фич и фиксов в master ветку (как и делает это Github)
    а git rebase используется для своей ветку в которой вы работаете над фичей что бы забрать последние изменения с master ветку (для этого есть очень удобная команда `git pull --rebase origin master`, аналог 3х команд (`git checkout master; git pull origin master; git checkout mybrach; git rebase master`)
    Ответ написан
  • Git: объясните «на пальцах» разницу между rebase и cherry-pick?

    Все красиво объяснил Nkly777, только в блоке PS merge с rebase перепутаны.
    Добавлю картинок.

    git rebase devel - собачка на молнии - "сшивает" коммиты по дате их создания
    (ветка devel "растворяется" в основной ветке)
    518b8dbce1cd4f96b30de9782ae38fcd.png
    git merge devel - пожарная лестница, все коммиты ветки devel крепятся в конец, образуется пересечение
    (devel остается отдельной веткой, к которой можно вернуться)
    1ba8186d879d46ff85ea7c1e192328e2.png
    git chery-pick idea - забрать коммиты из ветки idea
    2717e3091f644ef2954aa2de4514f446.png
    Ответ написан
  • JavaFX умер или нет?

    Konstantin18ko
    @Konstantin18ko
    Стоматолог
    Пока в нем нет очень большой необходимости, как следствие развитие его в час по чайной ложке. А, так исторически сложилось что он пришёл на замену остальных GUI frameworks.
    Не соглашусь с оратором выше что десктопные приложения на Java это моветон. Если десктопное приложение создаётся с целью удалённого управления, то вполне JavaFX в самый раз.
    Ответ написан
  • Какой графический редактор использовать для пиксель арт?

    acbor
    @acbor
    Hobbist
    Тоже не винде использовал Paint.net, а перейдя на Убу мне его аналог Pinta не понравился.
    Недавно нашел Aseprite - годный редактор, рисую, не могу. Для пиксельных спрайтов очень хорошо подходит.

    Что интересно, сам редактор внешне тоже пиксельный)

    9c7547d7e69b428fb02fff154ac9cea9.png
    Ответ написан