DDDEN!SSS, да почему он будет ощутим-то? Почему родной код, который выдаст твой компилятор, обязательно должен быть более производителен, чем тот, в который Java-машина сконвертирует байт-код? Да и вообще, насчет производительности нельзя рассуждать, пока не проверишь, это подтверждено на практике. Только пойми меня правильно, на C++ действительно больше шансов улучшить производительность за счет более тесного контроля над железом, но ничего конкретного заранее сказать нельзя. Может быть, проблема не в Java-машине, а в реализации видеосистемы прошивки? Мы же этого не знаем.
Первую фразу, кстати, вообще не понял. В выпущенных версиях не бывает незамеченных программистами ошибок, что ли?

Nicolos, seclub.org/forum/goto/8508522/ - такая организация кода - не лучший вариант, поскольку игровая логика зависит от того, что рисуется на экране, а нужно делать наоборот. Традиционно пользуются моделью MVC: Model-View-Controller. Применительно к игре будет модель игры, которая содержит положения объектов, игровую логику и так далее, будет вид, который через игроку показывают модель и будет контроллер, который принимает действия от пользователя. Допустим, последние два компонента частично смешиваются в классе Canvas (хотя все равно лучше разнести их по отдельности, насколько это возможно), но модель уж точно должна быть отдельно. Иначе получится нехорошая для ООП ситуация, когда все в кучу, как при структурированном программировании. Конечно, при небольших программах это сработает, но в больших уже придется туговато.

Malcolm, где можно об этом MVC: Model-View-Controller подробней прочитать? можешь ли ты исходный код игры high seas переделать? или код какой-нибуть дать для примера?

Nicolos, мне тоже было бы интересно узнать об этом подробнее.

Код как-нибудь выложу, а почитать об этом можно на Википедии: en.wikipedia.org/wiki/Model–view–controller .

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

Malcolm, а можно ли через OutputStream записывать байты в конец файла а не в начало?

DDDEN!SSS, насчет первой фразы: если разработчики заметят и исправят все огрехи. А если нет?
А что касается рисования на дисплей, то это, может быть, и было бы быстрее с двумя "но": не обязательно тебя даже родным кодом пустят рисовать прямо на дисплее и не обязательно видеосистема так устроена, что можно рисовать сразу пикселями, нигде их не сохраняя. Скорее всего, данные будут точно так же записываться в массив, только в формате C. И не факт, что это сильно быстрее.
LPzhelud, можно открыть поток на нужном месте через FileConnection.openOutputStream(long byteOffset).

а кто может на яве сделать конструктор явы,как javaBuilder ток намного лучше,чтоб больше команд было?

А как запихнуть в вектор массив байт, а потом обратно прочитать?

Malcolm, seclub.org/forum/goto/8516007/ - опа на. спасибо большое

КТО МОЖЕТ СДЕЛАТЬ?ПЛЗ!АТО КАМП ПОЕХАЛ?