Немцы доказали...

OpenGL рулит

Квака снова становится популярной 8)

ну и что если теперь то что они написали на Java переписать
на С, будет в разы быстрее работать. Они всего оптимизировали алгоритмы.
На черта это было сделано не знаю.

А если OpenGL еще на Java переписать вот будет тормоз.

ЗЫ
засим прощаюсь, не понятно что и кому они хотели доказать.
дети какие-то, ей-богу.

А ей что нужен виндовый квак ??

> будет в разы быстрее работать

в разы - может быть, но только если будет работать...

(а если на ассемблере... у-у-у)

"это наверное немцы придумали... оно всегда так - немцы придумают, а русскому человеку потом мучайся..." (цэ) "Мы из джаза"

вот :)

яваиздаинг, редай асхолз

>(а если на ассемблере... у-у-у)

и много ты программ написал?

C и есть ассемлер, только универсальный.
см. ядро.

действительно, причем тут java? за них все openGL делает.
Может тогда mesaGL на java переписать?

Java тут притом, что скоро на телефоны портируют кваку =)

ну-ну. Только GL на яве перепишут. :)

и GL на телефоны портируют скоро

как-то ява отстает! причем сильно в полноэкранном режиме. А давно Си стал ассембрером? си уневерсален, а вот ассемблер нет, да еще вроде как си язык высокого уровня, а ассемблер низкого. просто си с адресами помяти работает здорово!

кстати в вот под линуксом квака шустрее, даже виндовс-версии!

Изменений по сравнению с 1.4.2 было шибко много, что так оно (1.5) рулит?

Незнаю как квака, а дум 3 шустрее под линуксом. В смысле тормозит чууууть-чуть поменьше ;)

Неправильно выразился Правильно наверное надо было сказать- Шустрее тормозит :)

Еще бы крестики-нолики сравнивали на производительность.

А под оффтопик есть такая игрушка, названия не помню, но суть в том, что в код размером в 70 с лишком КИЛОБАЙТ они умудрились запихать поддержку DX9(с соответствующей графикой), 3D звука(кажется) и с десяток уровней :-)

Тоже немцами сделана...

и на телефоны ее ;-)

Ага, ага... Читали.... Только вместо Java 1.5 был .Net1.1 :) Цифры теже. Собствено напрашиваеться вывод: что жаба, что дот нет, одни и теже яйца, просто одни под лозунгом сельсофта и только под винду (извеняйте, c# от vb.net отличить можно только на уровне синтаксиса: там есть ; тут нету...) а другие "типо" свободные, и запускать надо не просто кликом, а набирая java -jar... :)

Так ведь только под оффтопик она и есть и нужен ей DX9

А сколько jake2 памяти отжирает, и сколько quake2?

afaik, сейчас и X-ы на GLе переписывают
http://keithp.com/~keithp/talks/xarch_ols2004/

.. GLи, GLи, кругом одни GLи ..

> Немцы доказали... что на Java 1.5.0 можно писать даже 3D-игры.

Аффигеть.

А в это время весной задрипанного 2001-го года под оффтопиком вышла этакая небезызвестная игрушка "ИЛ-2 Штурмовик". И мало кто заметил, что она написана бОльшей частью на Java.

Как раз меньше, читай внимательно ...

The fps values are not an absolute performance comparision Java vs C. But they show that at least 60% of C performance are achievable with Java. In comparision with object oriented C++ Code Java would look even better.

Jake2 0.9.2 can achieve up to 85% of the framerate of the C version.

Да в сети валяеться гама kkreger. Один уровень (кстати ничего так, по размеру примерно как один уровень в Q1) Всё 3d. Звук есть, несколько типов оружия, враги. Босс даже :) Вобщем всё как надо. ~100kb. Тока системные требования у неё очень неплохие. Оперативы от 512, видюха на 128, ну и всё в таком духе. Камень хороший нужен

Заглянул тут на страницу. гы-ы. Посмеялся. Они бы ещё первый Doom на Athlon XP 2400 запустили. Его хоть на Васике переписывай - один хер, на таком камне изменений заметно не будет (почти). Вот они бы Doom3 на java переписали, тогда сразу бы и стало понятно, что java это для мобильников и 2d игрушек.

>>да еще вроде как си язык высокого уровня,

Вот именно, что *вроде как* ;) A на самом деле, Си - ни разу не язык высокого уровня, а самый что ни на есть _портабельный_ ассемблер со всеми отсюда вытекающими.

>А давно Си стал ассембрером?

си - это универсальный ассемблер,

напишите тысяч десять строк на асме,
а потом подумайте как это переделать в C код.

и окажется что для этого хватит небольшого скрипта.

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

ЗЫ
а еще C++ называют объектным ассемблером, не слышали?

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

также как в ранний период C++ компиляторы всего лишь переводили,
C++->в C а потом компилировали.

Если вам интересно как, то посмотрите на GTK+.

такое ощущение что GTK+ именно так и сделан.

c кстати и был разработан чтобы быть универсальным ассемблером.

дык никто с тобой не спорит :)

linux_guru (linux_guru?)

>также как в ранний период C++ компиляторы всего лишь переводили,
>C++->в C а потом компилировали.

тоже самое происходит и в "поздний преиод", то-бишь сейчас

в современных C++ компиляторах это не так.

докажи, как немцы ;-)

Что-то не так с моим ником?

>то-бишь сейчас

это не совсем так

http://www.bytonic.de/html/jake2_webstart.html

>Что-то не так с моим ником?

"я не узнаю Вас в гриме ... Linus Torvalds, Alan Cox?"

Вообще-то мое имя Пупкин,
Вася Пупкин.

> afaik, сейчас и X-ы на GLе переписывают

Неужели они наконец-то разгрузят CPU и нагрузят GPU ? А заодно и с памятью то же самое сделают :)

C в asm легко, обратно - херушки. На асме можно много всякого наколбасить.

>напишите тысяч десять строк на асме,
>а потом подумайте как это переделать в C код.

>и окажется что для этого хватит небольшого скрипта.

Вранье. Если ты про inline, то это не будет портируемо, как это предполагает C, а в общем случае - задача не решаема без создания виртуальной машины. А с ней получатся реальные тормоза.

> А в это время весной задрипанного 2001-го года под оффтопиком вышла этакая небезызвестная игрушка "ИЛ-2 Штурмовик". И мало кто заметил, что она написана бОльшей частью на Java.

движок Chrome тоже полностью написан на яве

блин, а на перле или питоне игр еще никто не писал?

>Вранье. Если ты про inline, то это не будет портируемо, как это предполагает C, а >в общем случае - задача не решаема без создания виртуальной машины. А с ней >получатся реальные тормоза.

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

по-моему задача вполне решаемая.

>блин, а на перле или питоне игр еще никто не писал?

писали, а что.

почти на каждом более или менее известном языке написана пара игр.

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

>для конкретного ассемблера и конкретной архитектуры

Напиши мне "скрипт", который переведет любую прикладную (что является критерием?) прогу (на x86 асме и PC архитектуре), которую я ему подсуну, в С, без инлайнов и других способов вставок ассемблерного или машинного кода. Если он правильно переведет прогу которую я ему подсуну - я дам тебе $1000. Если нет - ты мне $50. Идет?

Критерием правильности является идентичность скомпилированой проги с оригиналом.

> Если он правильно переведет прогу которую я ему подсуну - я дам тебе $1000.

Да за это корпорация вроде интела и $1000000 не пожалеет :)

народ, вы че с луны ?

1) жаба 3Д для мобильных существует уже давно, нивидиа уже графические чипы для мобильных устройств клепает

2) GL по идее должен обсчитываться на видеочипе поэтому интерпретируемость джавы не должна сильно повлиять на скорость основной массы вычислений, а именно - рендериг, который и считается карточкой, весь перец ОпенГЛ именно в этом, ну и в том еще, можно кодить на чем угодно а не в ассемблерных кодах:)) Кстати код на Си будет не сильно отличаться от кода на джаве

3) Интереснее всего программить ОпенГл на питоне:))

pyopengl.org

pygame.org

А я-то думаю, чего он это так тормозит? ;)

>Если кто-то подумал, что взята какая-то левая самодельная игрушка, пусть сходит по ссылке. Сравнивается C-compiled и Java-версия игры Quake 2

Ну правильно, если головой подумать, то все закономерно. Какие мы имеем плюсы/минусы производительности Java в данном случае?

1. GC? Насколько мне известно, исходный движок Quake активно использует пулинг. Соответственно, GC остается за горизонтом (практически, все-такие какое-то минимально число объектов в процессе наверняка создвется). Можно проверить каким-нибудь профайлером.

2. Дополнительные рантайм проверки? Ну, на пару процентов FPS скинет. Это немного, особенно с учетом JIT/Hotspot.

3. JIT. Думаю, от-JIT-тиный код по скорости от кода, откомпилированного сразу в нативный сильно не отличается. Хотя надо признать, что у MS (по субъективным ощущениям и паре тестов) JIT лучше Sun-овского.

4. Hotspot. Не знаю, насколько он помогает. В любом случае это чисто плюс к прооизводительности, для C (например) Hotspot-а не бывает.

5. Маршаллинг. Тут без понятия, но расходы должны быть достаточно велики. Но при грамотной реализации основной объекм данных при загрузке сцены.

6. Всякие хитрые битовые операции, и.т.д. Это копейки.

7. Больший потребляемый объем памяти. При большом количестве памяти это почти не влияет.

Соответственно, два самых сильных минуса (на мой взгляд :) ), 1 и 5 можно довольно легко нейтрализовать. 4 - это плюс. 3 - при грамотной реализации VM, это тоже плюс (тормоза при загрузке не уучитываем). 2 - это минус, но небольшой.

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

Правда, после "тюнинга" 1 и 4 результат лучше выбросить и переписать на чем-нибудь более подходящем (например, C++), потому как плюсов такого программирования на Java я не вижу...