gamedev Tutorials Программирование игр

Классика: Sun Java SDK на платформе Linux

Конечно компания Sun выпускает комплекты разработчка Java для всех существующих платформ. Но именно под Linux процесс разработки выглядит наиболее классически - с компиляцией и запуском программ из терминала (тогда как под Windows будут определённые проблемы из-за того что окно консоли в ней - это окно DOS, которое, в частности, весьма плохо понимает длинные имена файлов; а что касается MacOS - так она в принципе не имеет консоли).

Если у Вас есть дистрибутив Linux, то в большинстве случае JDK уже есть в нём. Возможно он даже уже установлен "по умолчанию". Если же это не так - установите его, воспользовавшись утилитой обновления Вашей системы (в современных русских версиях - от "ASP" и "Alt" - это не сложнее, чем установка программ в Windows, и никакой дополнительной ручной настройки не потребуется). Правда самостоятельно догадаться поместить на рабочий стол или в другое удобное для Вас место иконку для быстрого доступа к документации (кстати, она хранится в формате HTML) программа установки не догадается. Это советую сделать вручную, а заодно взглянуть и на входящие в комплект JDK примеры - часто то, что непонятно в документации, становится понятно из исходного текста соответствующего примера.

Итак, JDK установлен, и теперь, если вы откроете окно терминала, перейдёте в директорию с уже откомпилированным java-приложением (предположим HelloWorld.class) и наберёте после приглашения системы следующую команду:

ПриглашениеСистемы>java HelloWorld

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

Но как создавать программу?

Можно было бы ограничиться замечанием "наберите исходный текст в любом текстовом редакторе" - но я хочу показать Вам сразу удобный путь.

Kate - текстовый редактор

В поставку всех известных мне дистрибутивов Linux входит текстовый редактор Kate. В общем, он - как и все простые текстовые редакторы в Linux - умеет делать такие само собой разумеющиеся для любого линуксоида вещи как: перекодировка текстов в любой мировой набор символов (одинх только кирилических кодировок штук 5), проверка правописания (при помощи встроенной системы Linux это могут делать все программы), выделение цветом синтаксических конструкций языков программирования и разметки (причём не только HTML).

Нам же от него обязательно потребуется следующее (и я советую Вам проверить так ли настроен Ваш Kate - для этого откройте диалог "Настройка: Настроить Kate"):

  1. В разделе "Общие" обязательно выбирите "Синхронизировать эмулятор консоли с активным документом". Если планируете редактировать исходный текст не только через Kate, здесь же выбирите "Предупреждать об изменении файла другой программой"
  2. В разделе "Редактирование" очень советую выставить "Показать символы табуляции", здесь же можно выставить и ширину табуляции. А вот "Статичный перенос строк", на мой взгляд, лучше всего вообще запретить
  3. В разделе "Отступ" разумеется надо разрешить "Автоматический отступ"
  4. В разделе "Открыть/Сохранить" можно указать желаемую кодировку файлов и разделитель строк (он разный, на разных системах). А ещё можно разрешить или запретить делать автоматическую копию файла перед перезаписью и указать суффикс для резервной копии файла
  5. В "Значениях по умолчанию" настоятельно рекомендую включить "Динамический перенос строк", в "Сворачивании блоков кода" разрешить "Показывать полосу сворачивания блоков", в группе "Левая граница" выбрать "Показывать номера строк" (так как именно на номера строк ссылается компилятор при ошибке)

Всё, удобство работы уже получено.

А теперь как этим удобством пользоваться.

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

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

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

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


[user@localhost CurrentDirectory]$ javac HelloWorld.java

! В Java имя файла всегда должно совпадать с именем класса. Не забывайте, что заглавные и прописные буквы в Java различаются - и это же верно для имён файлов классов.

Имя файла с исходным текстом обязательно должно сопровождаться указанием расширения .java - иначе javac не поймёт чего Вы от него хотите.

Если в ответ javac не вывел ничего и через некоторое время просто вновь появилось системное приглашение - всё в порядке. В противном случае будет выведено сообщение об ошибке с номером строки, где она обнаружена.

Из этого же встроенного терминала можно и запускать программы на исполнение, описанной выше командой. Правда, так нельзя запускать апплеты - для их просмотра в JDK включена специальная утилита appletviewer. Но лично мне кажется более правильным тестировать апплеты вместе с содержащей их страницей, загружая её в браузер. Ведь апплет должен органично "вписываться" в страницу, должен стать частью её дизайна - и в просмотре отдельно от окружения смысла просто нет.

Предупреждение о совместимости

Остаётся лишь предупредить об одной не совсем приятной особенности: время не стоит на месте, и за десятилетие компиляторы Sun несколько изменились. Они стали выдавать более эффективный код, но вот встроенная в Windows java-среда, как была лицензирована 10 лет назад, так и застыла на том же месте. Так что созданный последними компиляторами код может быть "не понят" старой средой исполнения.

В этом случае есть два пути:

  1. предложить пользователю загрузить бесплатную новую среду исполнения с сайта Sun (JRE бесплатна - но Вы не можете утверждать это в отношении траффика пользователя, а так же его личных затрат времени - подумайте об этом)
  2. если программа не использует последние нововведения (а большинство Java-программ на деле используют лишь возможности Java 1.1 - как раз той версии, которая и была лицензирована Microsoft) - откомпилировать программу компилятором более раннего выпуска (под новой java-средой он будет исполняться вполне корректно, к тому же Вы сможете гарантировать и его работоспособность под старой java-машиной).

Кстати, как раз дальше будет рассказано о таком компиляторе.

Удобство от противника: Microsoft Visual J++ 6.0

Я рекомендую именно старый Visual J++ 6.0, потому что в нём Microsoft'овского вреда меньше всего или же его можно обойти (я расскажу как). Если не ошибаюсь это первый компилятор Java, выпущенный Microsoft вскоре после лицензирования технологии Java у Sun. Поэтому в нём совсем немного лишних пакетов, привязывающих программу исключительно к Windows.

В конечном счёте если уж писать принципиально только для Windows - пишите уж на Visual C++ (я и сам на нём писал). Хотя это, конечно, (не побоюсь этого слова) заметно сложнее, чем максимально облегчённый труд java-программиста (речь не о средах разработки - которые в этом случае функционирую практически эдентично - а о требованиях к глубине познаний программиста и обилии возлаемых на него, в общем-то тривиальных и обыденных задач).

Предположим, что Visual J++ у Вас уже установлен (если это не так - не бойтесь, установка окажется не сложнее, чем для игры). Запустите его. Перед Вами раскроется диалоговое окно "New Project".

Visual J++: выбор нового проекта

Нас могут заинтересовать Windows Application и Console Application из группы Applications (она раскрыта по умолчанию), но главное - в группе Web Pages есть Applet on HTML.

И всё же начнём с консольного приложения. Итак, меняем (если желаем) имя проекта и его расположение, затем кликаем на Console Application. И видим:

Visual J++: консольное приложение в разработке

Ну, если быть точным, то чтобы увидеть именно такое, придётся сначала кликнуть в левом верхнем окошечке - оно называется Project Explorer - сначала на Project1, а в раскрывшемся списке на Class1.java.

Как видите, кроме комментариев, имеем только самую общую заготовку - объявление главного класса и всего один метод в нём - это обязательный для любого приложения метод main и пока он пуст.

Тем не менее, пример можно откомпилировать. Для начала проверьте установки проекта: зайдите в меню Project, а в нём выбирите пункт Project1 Properties. Появится диалоговое окно "Project1 Properties":

Visual J++: свойства проетка

Здесь и осуществляются все "трюки по обману компилятора".

Как видите вверху, в выпадающем списке, указано Debug - это конфигурация по умолчанию. А ниже идут ряды закладок - выбирайте вторую по счёту - Compile. В ней ОБЯЗАТЕЛЬНО поставьте галочку напротив Disable Microsoft Language Extensions. Так же, при желании, можете указать необходимость оптимизации компилируемого кода. Вы можете заметить, что по умолчанию включён режим добавления отладочной информации в исполняемый файл - для конфигурации Debug отключать его смысла нет, а в конфигурации Release он по умолчанию и так отключён.

Кстати, не забудьте запретить MicroSoft'овские языковые расширения и для конфигурации Release.

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

Ну как, кликнули? Успели заметить пустое окно консоли, которое тут же скрылось? Правильно - ведь приложение не делает ровным счётом ничего.

Всем нетерпеливым, кому уже сейчас хочется увидеть хоть какой-нибудь результат на экране - рекомендую мою статью "Java-бух: Как начать программировать на Java". Попробуйте то, что описано там, а затем загляните в папку, где был создан Ваш проект (помните что Вы выбирали в диалоговом окне "New Project"?).

Там находится несколько файлов, из которых нас интересуют:

Если Вы заглядывали в эту папку до первой компиляции, то точно знаете, что никакого exe'шника в ней не было. Кликните на него - и запуститься Ваша java-программа.

Всё что делает этот exe'шник - запускает java-машину, передавая ей в качестве параметра имя файла с главным классом Вашей java-программы. При этом он не содержит в себе даже малой части java-машины, так что пользователю она будет нужна в любом случае - собирается ли он запускать Вашу java-программу традиционным способом или через такой вот своеобразный интерфейс. Видимо, такое решение свидетельствует о том, что даже сама великая Microsoft не смогла справиться со странностями своей же операционной системы (вроде непонимания длинных имён файлов в консоли).

Смешно, но порою интерфейсный .exe (не выполняющий ровным счётом никакой собственно работы, а только вызывающий другую программу) превосходит объемом само java-приложение (кстати, в нашем случае это именно так).

Снова посмотрим на полученные в результате компиляции файлы. Названия у них какие-то уж слишком типовые, ничего не говорящие. Как переименовать?

Начнём с переименования исходного текста на Java - и сделаем это через среду разработки (поэтому вернитесь в неё). Очень легко заменить название класса в исходном тексте с Class1 на скажем MyExample (оно станет подчёркнутым, как ошибка - не обращайте внимания). Теперь нужно переименовать и сам файл. Не покидайте среду разработки, а лучше в окне Project Explorer'а кликните на название файла и исходным текстом, а когда оно выделится - ещё раз. Название можно редактировать - замените его на MyExample.java и нажмите клавишу Enter (обозначение ошибки должно пропасть). Аналогично заменяется и название проекта.

Но если Вы немедленно попытаетсь откомпилировать - то увидите сообщение об ошибке:

Specified main class 'Class1' not found

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

Здесь Вы с удивлением обнаружите, что правильный класс уже указан - но, видимо, требовалось Ваше высочайшее подтверждение, чтобы это изменение вступило в силу.

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

Апплет

Начинаем с самого начала: запускаем Visual J++ и видим окно New Project. В нём выбираем группу Web Pages, а в ней Applet on HTML. Кстати, если желаете, можете сменить даваемое по умолчанию проекту имя (а это всегда какой-нибудь Project?) на что-нибудь более наглядное. Например MyApplet - введите это в поле Name. Одновременно среда сама изменит название будущей папки проекта (удобство, однако).

На этом учтивая предусмотрительность заканчивается - когда в окне Project Explorer'а (то маленькое окошко справа вверху) Вы откроете свиток MyApplet - в нём обнаружаться совершенно типовые имена файлов Applet1.java и Page1.htm (да, именно так - даже не .html).

Трудно объяснить логику программистов Microsoft. Ведь в конечном счёте нам, а уж тем более пользователю наших программ, нужна не папка, в которой хранятся исходные тексты - зато её нам предлагают переименовать, а исполняемый файл - который всегда будет получать одно и то же имя!

Ну ладно, не будем ворчать - ведь мы уже знаем как это исправить. В том же окне Project Explorer'а кликаем на имя файла и заменяем на желаемое - для примера пусть это будет MyApplet.java. Теперь кликаем, чтобы открыть исходный текст файла... и с ужасом убеждаемся, что Visual J++ оставил имя класса стандартным - при этом ещё и с наглостью сообщая нам, что де ошибочка - ведь имя файла должно совпадать с именем заключённого в него класса.

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

По счастью это одна из немногих вещей, на которые хочется ругаться в этой среде разработки (хотя новичку могут изрядно нервы истрепать).

Зато при помощи Project Explorer'а очень удобно и быстро перемещаться между файлами проекта (включая, между прочим, даже файлы ресурсов), в нём же, в отдельном свитке, появляются и прочие, так сказать вспомогательные, файлы (те, которые не будут компилироваться в проект).

А вот большое окно слева - Class Outline. В нём можно просмотреть все классы проекта, их методы и поля. Как видите здесь уже есть Default package и Imports (они иногда представляют интерес), но обычно Вы будете пользоваться следующими за ними свитками - у нас такой один, и, если Вы ещё не исправили имя класса в исходном тексте, он будет называться Applet1.
Поэтому исправьте (вручную) имя класса в исходном тексте, так чтобы строка с его объявлением приобрела вид:
public class MyApplet extends Applet
Сообщение об ошибке изчезнет, а имя класса в окне Class Outline автоматически заменится на новое.

В упомянутом окне, кликом на "+" перед именем нашего класса, раскройте свиток: в нём будут ещё два свёрнутых свитка (говоря коротко - они содержат то, что написали не Вы и Вам если и будут когда-нибудь нужны, то только как справочный материал - да и то редко, так что можете их не раскрывать), а ниже перечислены все поля и методы нашего класса (клик на любом из названий сразу же перенесёт Вас в указанную точку исходного текста). Как видите Visual J++ уже заботливо "насовал" нам кажется всё что только было возможно впихнуть в маленький пример.

Прежде чем запустить этот пример на исполнение проверим установки проекта (Вы должны помнить, что это делается в меню Project, пункт MyApplet Properties). Запретите языковые расширения от Microsoft. Взгляните на вкладку Launch - как можно понять из сообщаемого ею, сейчас наш апплет будет запускаться для просмотра не через браузер, а через специальную программу (она выполняет роль java-машины для оконных приложений, а вот консольные приложения обслуживаются другой программой - если, конечно, Вы используете java-среду от Microsoft).

Но если Вы немедленно запустите проект на исполнение (как Вы должны помнить, это делается кликом на кнопку, изображающую нацеленный вправо треугольник-стрелку, на панели инструментов) - то результатом будет пустое окно, свёрнутое до строки заголовка.

Почему?

Потому что так не работает! (спросите у Microsoft зачем же так сделано)

А работает только при просмотре апплета через браузер. Так что давайте настроим проект на нормальную работу. Снова открываем окно его (проекта) свойств и на первой же вкладке (это будет Launch), в раскрывающемся списке "When project runs, load:" - укажите Page1.htm и вслед за тем нажмите кнопочку Apply внизу диалогового окна.

НО это ещё не всё >:-D .

И чтобы убедиться в этом, откройте страницу Page1.htm (кликнув на неё в Project Explorer'е). Немедленно она появится в окне редактирования. В её окне есть 3 вкладки - две из которых (Design и Quick View) определённо не нужны - а пригодится только, расположенная посередине между ними, Source (в которой, судя по названию, содержится исходный текст).

Клик - и можно лицезреть примитивный HTML с непонятным прямоугольным элементом. Так вот - этот пустой прямоугольник и есть наш апплет.

Сразу и не догадаешься (таких бы дизайнеров, кто это придумал...).

Чтобы с этим можно было работать, кликните на прямоугольнике правой кнопкой, а в появившемся контекстном меню отметьте пункт Always View As Text - и HTML примет нормальный рабочий вид:
<HTML>
<HEAD>
<META NAME="GENERATOR" Content="Microsoft Visual Studio 6.0">
</HEAD>
<BODY>

<P>&nbsp;</P>


<!-- Insert HTML here -->
	<applet
		code=Applet1.class
		name=Applet1
		width=320
		height=200  VIEWASTEXT>
		<param name=label value="This string was passed from the HTML host.">
		<param name=background value="008080">
		<param name=foreground value="FFFFFF">
	</applet>

</BODY>
</HTML>
И опять нам придётся менять вручную имена файла с исполняемым кодом и апплета .Впрочем, обычно я использую собственные страницы - а не сгенирированные автоматически - и Вам то же советую, проблем с "не теми" именами не будет. А подключить свою страницу к проекту весьма просто - поместите её в папку проекта, а в диалоговом окне свойств проекта укажите, что запускать надо именно эту Вашу страницу (она автоматически появится в списке, так что даже не придётся ничего писать вручную).

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

А более терпеливые могут сначала дочитать эту.

Оконное приложение

Даже если Вам лично Java нужен только для web-апплетов - и в этом случае может однажды возникнуть необходимость в создании оконного приложения. Ну а раз Вы уже знаете Java - то почему бы не написать это приложение на нём?

У меня, например, такая потребность возникла, когда мне потребовался редактор трёхмерных объектов для моего 3D-движка. Такая программа могла быть только приложением - поскольку апплет не имеет доступа к файловой системе и не смог бы сохранять результаты работы.

Предусмотренный в Visual J++ путь для создания оконного приложения таков: как нетрудно догадаться, нужно в диалоговом окне New Project, указать Windows Application в группе Applications и ввести подходящее имя для проекта - пусть будет WinAp. Затем, как мы уже знаем, создаётся проект с наполнением по умолчанию - посмотрим что же нам предлагает машина, кликнув в окне Project Explorer'а на "+" перед именем нашего проекта. Свиток раскрылся, в нём лишь один файл Form1.java.

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

Visual J++: создание оконного приложения

Ну как, кликнули?

Я тоже, когда увидел Это впервые, был поражён. Нет, конечно немало людей (вероятно) используют Java для создания всяких там форм - но ведь здесь даже не видно никакой закладки типа Source - которая, между тем, есть даже для HTML (в этом же самом Visual J++)!

Кстати, не помню, чтобы такая же навязчивость была характерна для Visual C++ из этого же пакета Visual Studio 6.0 - хотя на C++ пишется ничуть не меньше разнообразных форм.

Погодите, это ещё не всё. Кликнув снова на файле в окне Project Explorer'а - только теперь уже правой кнопкой мыши - увидим меню, самый первый пункт которого - View Code - откроет нам доступ к заветному исходному тексту.

Но что это?

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

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

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

Поэтому вот Вам мой способ написания оконных приложений под этим изделием Microsoft.

Работающий (нестандартный) способ написания оконного приложения под Visual J++ 6.0

Начните с того, что создайте новый проект типа Applet on HTML. Теперь откройте окно с исходным текстом апплета - просто перепишите его весь как будто это оконное приложение. Не забудьте соответствующим образом изменить название файла и главного класса Вашей программы (конечно, если есть желание).

Вот теперь главный секрет.

Прежде чем запускать на компиляцию и исполнение - идём в диалоговое окно свойств проекта. Как обычно запрещаем языковые расширения от Microsoft. Но главное - на вкладке Launch убеждаемся, что запускаться будет не .htm (лучше вообще удалите этот файл из проекта), а именно сам исполняемый код (он будет иметь имя главного класса Вашего приложения). А запускать его должна программа WJView.exe.

Если по каким-либо причинам это не так (быть может Вы начали проект как консольный - тогда он будет запускаться через JView.exe, неприспособленную для поддержки окон) - смело выбирайте (на той же вкладке Launch) вариант Custom и вводите там имя WJView.exe вручную.

И может запускать на исполнение и наслаждаться.

Лирическое отступление

Я помню те времена, когда настоящие программисты не признавали никаких оболочек (даже Norton Commander) и всегда вводили все команды вручную, через приглашение операционной системы.

Прошла уйма времени - но глядя на даже на лучшие из имеющихся сред Visual'ьной разработки, порою я загружаюсь в Linux и пишу там всё руками.

Честное слово - там меньше приходится ломать голову. Не бойтесь - попробуйте. У Вас тоже получиться.

Ни в коем случае: JBuilder 8

Чтобы объяснить причину придётся ненадолго окунуться в историю.

Во времена DOS я был фанатом Borland - была такая фирма, которая казалась столпом индустрии. Конечно многие помнят их замечательный TurboPascal. В нём был настолько удобный редактор, что многие даже простые тексты набирали именно в нём. Непосредственно в редактор был встроен компилятор, позволявший создавать исполняемый файл за 1 проход (вместо 2 для прочих языков), причём с очень эффективным кодом (как по размеру, так и по быстроджействию).

Версия 3.0 ещё позволяла создавать очень компактные по объёму исполняемые .com файлы, 4.0 уже создавала только .exe, зато улучшилась графическая библиотека - именно с неё пошёл знаменитый в то время стандарт .bgi, единый для всех продуктов, созданных на любом инструментарии Borland (хоть на C++). Версия 5.0 внешне была простым улучшением, а вот 5.5 включила поддержку объектов. Но по-настоящему объекты показали себя в 6.0 - вместе с выходом библиотеки TurboVision, на которой была написана и сама среда программирования. Правда, по-началу, библиотека не была должным образом оптимизирована (этот недостаток исправили в 7.0, где она заработала в несколько раз быстрее), зато многооконность (под DOS!) давала изумительное по тем временам удобство разработки, а возможность писать ассемблерные вставки непосредственно в исходном тексте на Pascal поднимала быстродействие создаваемых программ на мамксимальный уровень. C++ отдыхал (не спорьте - это проверено мною неоднократно), быстрее мог быть только чистый ассемблер, да и то не всегда (да, были такие моменты - например в 16-цветной графике, которая настоящее мучение для ассемблерного программиста).

А ещё был TurboBasic - необычайно быстрый, как и всё Borland'овское. Мало кто слышал о нём, потому что едва он вышел в свет, хитрый Билл Гейтс предложил фирме Borldand интересное соглашение о разделении сфер: от Borland требовался отказ от производства Basic, а взамен Microsoft добровольно отказывалась от производства Pascal (которое на самом деле и не входило в её планы). Одновременно обе фирмы признавали права друг друга на производство C-компиляторов (в котором обе проигрывали Watcom).

Трудно сказать, что подтолкнуло руководство Borland к заключению этого соглашения без выгод. Видимо это ещё один пример, что единоличный лидер (в данном случае хитрый Билл) всегда лучше, чем совет директоров (управляющих Borland).

Соглашение было заключено, быстродействие Basic'а так и осталось ничтожным, в десятки раз уступавшим образцу Borland, а Pascal - этот вообще говоря прекрасный "прямой" язык и наилучший язык для обучения - едва не был придан забвению. Сама Borland ныне не существует, а дело её продолжает фирма-правоприемница.

И это, как оказалось, имеет значение.

Однажды я решил довериться старой марке и поставил JBuilder 8. Этот пакет существует в версиях для Windows и Linux - я опробовал обе. И затем снёс их без сожаления.

Выше описывался процесс набора текста программы в среде Visual. В JBuilder'е вроде бы то же самое (так же выскакивает список классов и их членов) - только нажатий на клавиши для выбора нужного из этого объёмного списка требуется заметно больше. Вообще не так всё наглядно, как у конкурента.

Это ещё можно было бы терпеть, но (тут я опускаю все эпитеты, которые очень хочется выссказать в адрес неуважаемых разработчиков) в JBuilder 8 совершенно невозможно задействовать дублирующий буфер!

Не могу сказать точно, с чем это связано, но попробуйте сами и убедитесь: самая простая программа, использующая дублирующий буфер - просто не будет откомпилирована. Никаких синтаксических ошибок нет. Тот же самый текст отлично компилируется всеми другими компиляторами, и разумеется не вызывает никаких проблем у javac (а он, как Вы должны помнить - эталон). Но JBuilder без объяснений лишает нас самого важного инструмента для любой видеоигры.

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

А значит и нам с ним тоже.

© Rex
Игры и Java

PMG  14 ноября 2006 (c)  Rex