Вот из-за таких схем и возникает ощущение, что большинство современных игр — крючки, запущенные авторами в мой карман. У меня еще с детства выработано (или воспитано) неприятие любых азартных игр как таковых. Для меня единственным условием покупки игры является fixed price. Любая игра, которая предлагает мне «внутриигровой контент» сразу теряет для меня привлекательность, та же, которая по самой своей механике требует что-то покупать, выкидывается без сожаления. К счастью, обычно отличить добротные игры от «одноруких бандитов» удается через час-полтора игры. К еще большему счастью большинство игр такого рода выходят под мобильные платформы, а не под PC, где я предпочитаю играть.
Рассказываю я это не из большого ЧСВ, а просто как рецепт прививки от подобных вещей:
1. Плати за игру, если она тебе понравилась — это благодарность разработчикам (когда-то я сперва прошел всю Diablo 2, а только потом купил ее за 1600 рублей (немыслимо дорого по тем временам, особенно для школьника, но мне очень она понравилась)
2. Никогда не играй во всякие free-to-play, если ты не видишь, что это — реально бесплатный и развиваемый энтузиастами проект с честным Donate, например (типа Path Of Exile или, если похардкорнее, Dwarf Fortress)
3. Никогда и ни за что не плати в игре настоящими деньгами (включая какую-либо подписку или абонемент на саму игру). Я играл во все игры Blizzard Entertainment, за исключением WoW.
Разумеется, это означает отказаться от, например, 90% MMORPG. Но… туда им и дорога. Это — далеко не самые интересные игры, на мой взгляд.
Внимание! Статья поправлена и доработана. Многие комментарии стали неактуальны, так как изложенные в них мысли я внедрил. Так что чем неактуальнее комментарий, тем сильнее я благодарен за него автору ;)
Я где-то писал про «автоматическую»? Определенные усилия приложить несомненно придется — кто же спорит? Просто они должны быть невелики по сравнению с усилиями для написания приложения.
А предлагаемый метод годится в первую очередь для небольших приложений, в частности, возможно, игр. Так что насчет тетриса — это вариант…
К тому же в данном случае я лишь имел в виду лишь то, что портированное приложение должно быть «лёгким», а не тянуть за собой целый фреймворк. А то проще сразу поставить VirtualBox и не мучаться
С паскалем давно дела не имел, он сейчас очень далек от мейнстрима. Что же касается Qt, единственное его преимущество, на мой взгляд, заключается в его больших возможностях. Но после нескольких проектов писать верхний управляющий слой UI на C++ я бы никому не советовал. Слишком многие неочевидные вещи надо держать в голове, слишком много шансов создать трудновылавливаемую ошибку в коде. Я тратил по 4-5 часов на поиск ошибки в коде на C++, причем ошибка была такого сорта, какого в Java в принципе не может быть. Но это, конечно, уже дело вкуса. Я лишь хотел продемонстрировать способ.
Собрать, разумеется, придется под каждую ось свой. Но переделывать Java-код для пересборки не нужно. Все различия в системных API учтены внутри Java-библиотеки.
Что касается «вызревания», замечу, что наблюдаю за ним я уже более чем полгода, коммитят они почти что ежедневно, но номер версии за это время сменился только с 0.5 до 0.6. Ребята, повидимому, очень ответственные, код вылизывают до блеска. На мой маленький баг-тикет ответили в тот же день (бага оказалась в Windows, а не в Avian). Так что возможно версии 1 ждать придется долго.
Согласен. Хотя не очень хочется ставить декларацию функции под #define. Не люблю макроопределения, которые идут вразрез со структурой кода. Хотя в данном случае, думаю, поправить стоит.
Вы абсолютно уверены в том, что результат будет в точности тот же? (А то честно говоря, я эту штуку сочинял довольно давно, для одного своего проекта, и тогда основательно намучался с этими кодировками)
Всё так. Но во-первых, если бы я еще описывал тут, как собрать рабочий MinGW 64 с MSYS, статья, и без того длинноватая для описания простого метода, стала бы вообще огромной. А в 90 процентах случаев, по моему опыту, 64 битность приложения не нужна (разумеется, если вы не пишете злобную математику или какой-нибудь фотошоп).
Насчет сторонних библиотек: я взял те, что рекомендовали разработчики Avian. Просто на всякий случай. zlib собирается своими руками и очень просто или его действительно можно взять из MinGW, да. Но билд-процедура Avian требует, чтобы он лежал в ../win32/lib, насколько я помню.
Что же касается копирования архивов, то я это сделал для того, чтобы всё это закоммитить на GitHub. Теперь вы можете слить себе crossbase и, только правя Java-код, собрать готовое приложение.
double k = 1;
for (int i = 0; i < 100000; i++)
for (int j = 0; j < 100000; j++)
{
k = i * j;
System.out.println(k);
}
Пока она мучается, выводя циферки, смотрим потребление памяти
Физической — 9.1Мб, виртуальной — 67Мб (многовато, конечно, но терпимо).
По второму вопросу:
Сам avian может быть собран с OpenJDK, причем в этом случае под ним можно успешно запускать eclipse (отнюдь не простое приложение). JVM, как я понимаю, — весьма простая вещь, если обрубить с нее всевозможные расширения, дополнения и мегафичи. А сторонние jar (включая и содержащие нативные библиотеки) грузить можно вполне успешно.
Помимо этого, насколько мне известно, он очень слабо поддерживается и в последний раз, когда я его пробовал под MinGW, он вообще не мог собрать тривиальную программу из-за какой-то баги.
Каюсь, должен был уточнить. Python почти не знаю (хотя его синтаксис и подход меня, честно говоря, не ввоодушевляет, но это — дело вкуса), с Ruby пока дела не имел вовсе.
Рассказываю я это не из большого ЧСВ, а просто как рецепт прививки от подобных вещей:
1. Плати за игру, если она тебе понравилась — это благодарность разработчикам (когда-то я сперва прошел всю Diablo 2, а только потом купил ее за 1600 рублей (немыслимо дорого по тем временам, особенно для школьника, но мне очень она понравилась)
2. Никогда не играй во всякие free-to-play, если ты не видишь, что это — реально бесплатный и развиваемый энтузиастами проект с честным Donate, например (типа Path Of Exile или, если похардкорнее, Dwarf Fortress)
3. Никогда и ни за что не плати в игре настоящими деньгами (включая какую-либо подписку или абонемент на саму игру). Я играл во все игры Blizzard Entertainment, за исключением WoW.
Разумеется, это означает отказаться от, например, 90% MMORPG. Но… туда им и дорога. Это — далеко не самые интересные игры, на мой взгляд.
А предлагаемый метод годится в первую очередь для небольших приложений, в частности, возможно, игр. Так что насчет тетриса — это вариант…
К тому же в данном случае я лишь имел в виду лишь то, что портированное приложение должно быть «лёгким», а не тянуть за собой целый фреймворк.
А то проще сразу поставить VirtualBox и не мучаться#define. Не люблю макроопределения, которые идут вразрез со структурой кода. Хотя в данном случае, думаю, поправить стоит.Вы абсолютно уверены в том, что результат будет в точности тот же? (А то честно говоря, я эту штуку сочинял довольно давно, для одного своего проекта, и тогда основательно намучался с этими кодировками)
Насчет сторонних библиотек: я взял те, что рекомендовали разработчики Avian. Просто на всякий случай. zlib собирается своими руками и очень просто или его действительно можно взять из MinGW, да. Но билд-процедура Avian требует, чтобы он лежал в ../win32/lib, насколько я помню.
Что же касается копирования архивов, то я это сделал для того, чтобы всё это закоммитить на GitHub. Теперь вы можете слить себе crossbase и, только правя Java-код, собрать готовое приложение.
Берем мою программу, добавляем к ней цикл вида
Пока она мучается, выводя циферки, смотрим потребление памяти
Физической — 9.1Мб, виртуальной — 67Мб (многовато, конечно, но терпимо).
По второму вопросу:
Сам avian может быть собран с OpenJDK, причем в этом случае под ним можно успешно запускать eclipse (отнюдь не простое приложение). JVM, как я понимаю, — весьма простая вещь, если обрубить с нее всевозможные расширения, дополнения и мегафичи. А сторонние jar (включая и содержащие нативные библиотеки) грузить можно вполне успешно.