Java + navtive C++ rendering

JNI + абстракция для рендеринга с помощью разных api.

у OpenGL и DirectX же можно рисовать в область окна.

мне нужно понять, как взять кусок гуя на Java, и преобразовать к виду «окна», в которое DirectX и OpenGL смогут рисовать напрямую

я не знаю, что это за «различные api», поэтому спрашиваю вас

API для отрисовки в рамках своего свинга - не нужно. Нужна именно прямая отрисовка через OpenGL и DirectX

мне нужно понять, как взять кусок гуя на Java, и преобразовать к виду «окна», в которое DirectX и OpenGL смогут рисовать напрямую

Есть контекст окна, он нужен и dx, и gl.

я не знаю, что это за «различные api», поэтому спрашиваю вас

У OpenGL и Direct3D разные API. Для унификации нужно сделать абстракцию.

у OpenGL и DirectX же можно рисовать в область окна.

тебя кто-то дезинформировал. любое окно это буфер. законченый сферический буфер в вакууме. ты не можешь взять часть от него и рисовать туда. т.е. в opengl ты создаешь окно либо offscreen buffer и рисуешь только туда. окно ты можешь вложить в другое окно а offscreen buffer забрать в обычную память и нарисовать процессором.

В венде вытащить HWND рефлекшном из кишков свинга. В линуксе видимо как-то так же.

в качестве данной абстракции я бы хотел Unity либо Unreal Engine конечно же, ради этого и весь вопрос

Неужели это примитивное действие в жабах такое горбатое? Мрак.

Что мешает связать две части программы через IPC? Разве много данных гонять между?

JOGL, LWJGL?

Гляди, в Unity есть параметр ParentHWND (https://docs.unity3d.com/Manual/CommandLineArguments.html)

А что является его аналогом в Linux? Как бы это сделать на Linux?

Хотелось бы, чтобы на линуксе тоже работало

Для начала читаем вот это http://www.oracle.com/technetwork/articles/java/mixing-components-433992.html

После чего понимаем что с LW эта хотелка слабо совместима

Потом смотрим сюда https://github.com/sgothel/jogl/blob/master/src/jogl/classes/com/jogamp/openg...

Здесь адская рисовалка через http://grepcode.com/file/repo1.maven.org/maven2/org.jogamp.jogl/jogl-all/2.1....

Который в кишках JDK IMPL

https://github.com/frohoff/jdk8u-jdk/blob/master/src/share/classes/sun/java2d...

(но он к OGL гвоздями прибит, DX не сработает)

И остается SWT, с ним проще т.к. он сразу heawyveight, и из него можно достать handle окна GTK https://github.com/sgothel/jogl/blob/master/src/jogl/classes/com/jogamp/openg...

Так нахрена тебе тогда JAVA, бери C# из Unity - и всё

потому что это нужно для legacy гуя с 20 летней историей, написанного на Java

Я на си не писал, но у меня сложилось впечатление что на cpp14 можно писать как на java, в полях класса ссылки на объекты держать через unique_ptr, шарить объекты через shared_ptr, главно придумать конвенцию как и что шарить, чтоб циклических зависимостей не было... и все, если придерживаться принципа kiss то вроде жить будет можно.

в качестве данной абстракции я бы хотел Unity либо Unreal Engine конечно же, ради этого и весь вопрос

Unity не дает такой возможности. Он экспортирует готовое приложение, которое вряд ли можно встраивать в другие приложения, на чем бы то ни было (за вычетом webgl в браузере).

про Unreal не знаю.

если тебе нужно просто рисовать в окно — в принципе все ответили уже. получаешь window handle, передаешь в JNI-код, и делаешь все точно так же, как делал бы в голой нативной программе.

Ты меня игнорируешь? Спрашиваю же, почему не IPC? Возьми Zeroc ICE или ченить подобное, ZeroMQ, не важно что - этот вариант не подходит? Опиши задачу, насколько интенсивный обмен данными?

Потому что ты хочешь жуткую нетривиальщину, что будет со стабильностью и переносимость?

в Unity есть задокументированная опция parentHWND

но она windows-only :(

непонятно, что такое window handle в контексте линукса, и как это подпихнуть какому-нибудь популярному движку (типа Unity)

задача простая. Мы несколько лет хотели сделать RPG, и вот даже нашли на это художника

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

а вот гуй - гуй будет сделать на основе IntelliJ IDEA platform. В крайнем случае, я готов смириться с Eclipse, но для этого его придется а) изучать б) имхо эклипс - шлак, и кастомайзить его под игровой UI будет тяжело

Гляди, в Unity есть параметр ParentHWND (https://docs.unity3d.com/Manual/CommandLineArguments.html)

по ссылке речь о запуске windows standalone в чужом окне, через редактор. т.е. на юзерский комп придется ставить unity editor.

идея использовать Idea лежит на поверхности. Есть куча очень хороших игрушек, пользоваться которыми невозможно из-за неудобного UI. Даже в хваленом Ведьмаке UI так себе, а в Skyrim хочется плакать реками слёз. В Morrowind уже получше, но работать и работать. Если же сразу взять Idea или Eclipse, UI сразу получается супер навороченный, и всё это забесплатно

непонятно, что такое window handle в контексте линукса, и как это подпихнуть какому-нибудь популярному движку (типа Unity)

скорее всего никак не подпихнуть стандартными/документированными средствами.

но вообще наверное никто не мешает найти окно Unity по имени, и за-reparent'ить его в свое приложение.

вероятно XReparentWindow сработает, но я не проверял, работает ли это между процессами.

по ссылке речь о запуске windows standalone в чужом окне, через редактор. т.е. на юзерский комп придется ставить unity editor.

а его можно будет запаковать себе в ресурсы (в формате «всё своё несу с собой»), так чтобы пользователь даже не догадывался, что там установлен какой-то редактор? Или лицензия не позволит?

в принципе, размеры дистрибутива игры сейчас начинаются с десятков гигабайт, плюс-минус немножко на редактор юнити - это вообще ни о чем

Вот теперь я переживаю за переносимость, а ведь еще Mac OS X - педики тоже хотят играть. Конечно, взять Java для GUI тем более игры это странное решение. Не будет ли просадки производительности при наложении GUI-окошек на картинку игры?

хочется, чтобы красивый графоний был сделан на нормальных графических движках
а вот гуй - гуй будет сделать на основе IntelliJ IDEA platform

и все это в одном окне? по-моему, тарабарщина какая-то получится.

во всех движках есть UI-фреймворки, специально для игр.

и как будет композитинг в случае если ТС-у удастся? мне кажется тут и будет FPS сажаться в два раза

а его можно будет запаковать себе в ресурсы (в формате «всё своё несу с собой»), так чтобы пользователь даже не догадывался, что там установлен какой-то редактор? Или лицензия не позволит?

есть предположение, что пока юзер не зарегистрируется и не активирует его — ничего у него не запустится..

насчет лицензии не знаю, почитай EULA.

а вот гуй - гуй будет сделать на основе IntelliJ IDEA platform. В крайнем случае, я готов смириться с Eclipse, но для этого его придется а) изучать б) имхо эклипс - шлак, и кастомайзить его под игровой UI будет тяжело

Игровой гуй или редактора ресурсов?

и как будет композитинг в случае если ТС-у удастся? мне кажется тут и будет FPS сажаться в два раза

может у него пошаговое RPG :)

а ведь еще Mac OS X - педики тоже хотят играть.

в задницу, яблочники должны страдать.

Не будет ли просадки производительности при наложении GUI-окошек на картинку игры?

окошки не будут накладываться на картинку игры. Это будет как тайловый оконный менеджер - посередине картинка рендерящаяся быстрым C++, по бокам - панельки (всякие инвентари и прочий шлак).

в самом печальном случае придется так и делать: два приложения, и точный расчет координат окон, чтобы получились тайлы

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

может у него пошаговое RPG :)

пошаговое. В стиле Baldur's Gate. Отдельные объекты на карте имеют свои собственные анимашки, плюс спарайты игроков и npc могут перемещаться по дорогам. Всё.

Примочка Java3D - стандартное решение для работы с аппаратным 2D/3D-ускорением в Java. С ней работает SweetHome3D.

http://www.sweethome3d.com/

Игровой гуй или редактора ресурсов?

и игровой, и редактор карт.

для игры например очень важен инвентарь, который будет с нормальным desktop-class драг-н-дропом, меню правого клика, табами и так далее, а не убого убожество, которое обычно происходит в RPG

или например, редактор кода (роботов можно будет программировать) - это нормальный редактор кода, с отладчиком итп. А не поделие типа как в Colobot

собственно, редактор карт - это просто еще одна «перспектива» (в терминах Eclipse), которая позволяет игроку делать некоторые дополнительные действия, и ничем не отличается от всего остального игрового UI

не понимаю, почему игростроители не используют это

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

не понимаю, почему игростроители не используют это

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

Потому что работа с циклом событий в игре и в оконном приложении - две большие разницы.

Чит для овервотча пишешь, да?

Забанют тебя, все это палится, не наследить невозможно.

// мимо рассматривал возможность написания радара для пубга

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

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

а завязавшись на то что есть в десктопах, это помешает консольной версии

// fixed

а offscreen buffer забрать в обычную память и нарисовать процессором.

В иксах можно делать XCopyArea, и это достаточно быстро, потому что происходит прямо в GPU, без пересылок в память CPU. Просадка по скорости будет, это ведь копирование как-никак. Ну будет 1901 fps вместо 2455 fps, это не так существенно. На фоне реального рендеринга это не заметно.

на наплевать на консоли и мобилки, на этих убогих платформах все равно игр нету, одни обмылки))

что происходит прямо в GPU, без пересылок в память CPU

ой не правда. если у вас внешнее окно рендерится в CPU(а это очень вероятно), ваша XCopyArea либо устроит синхронизацию, либо устроит глюки. кстати на астралинуксе + fglrx просто встраивание gl-окна в обычное приводило к развалу окна. т.е. появлялись «непрорисованные квадратики», иногда окно рисовалось только треугольником. в общем теория отличается от практики. на практике надо ставить объект glSync и по нему забирать картинку в память.

кстати на астралинуксе + fglrx

fglrx

Гы-гы. На fglrx у меня от запуска vainfo иксы падали. Так что не аргумент. С 2d там печально всё. И вряд ли стало лучше.

иксы падали изза бага в иксах. они зачем-то дергали уже убитый ими же объект. что-то destroyXxxx. собственно fglrx тут был ни при чем, он делал что мог.

а насчет композитинга: у вас уже есть 2 разных окна с точки зрения композитора и иксов. и ваша xcopyarea не синхронизирована на самом деле ни с одним из них, если там opengl. в gl вообще отдельный swapchain, и вы только у себя синхронизируетесь либо в glClientWaitSync либо по glFinish. swapbuffers не синхронизирует!

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

тут вы такой бдыщь хочу копировать пиксели. вообще, этот буфер увидит композитор в итоге. вы думаете он будет заморачиваться или пытаться понять вас? хер там. он берет первый surface как текстуру, берет второй surface как framebuffer, и рисует квадрат. а теперь какой-то из surface еще не отрисован. знаете в каком он состоянии в этот момент? у него даже адреса страниц undefined(отсюда и квадратики по 4 килобайта - я их мерял).

glFinish

Ну как бы есть glXWaitX и glXWaitGL, о них в доках упоминается. Правда, работают они так себе, и я делал XSync. И даже с XSync вполне себе норм. У меня не было особой нагрузки на рисовалку. По сути, там масштабирование, и всё. И всё равно норм.

Собрались теоретики футбола...

https://docs.oracle.com/javase/8/docs/technotes/guides/awt/AWT_Native_Interfa...

Ну и да, ещё Java3D, как справедливо советует iZEN.

я так глубоко не лез. может в Qt баг, может в композиторе. проще забрать в память по glClientWaitSync(его можно pollить) и не выпендриваться. к слову, в fglrx так и сделали в итоге через внутреннее api. Хы просирали синхронизацию.

может в Qt баг

Ты что-то перепутал, в этом разговоре об Qt не упоминали. Ты первый.

проще забрать в память

Проще, конечно. Но это совсем грустно, особенно, если кроме масштабирования ничего не делаешь. Тогда дешевле просто на CPU считать, быстрее получится.

в fglrx так и сделали в итоге через внутреннее api. Хы просирали синхронизацию.

Если в иксах действительно баг, может стоило с ними это пофиксить? Ну или хотя бы запротоколировать. Да, это муторно и сложно, но иначе никак.

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

As of 2015, JOGL provides full access to the OpenGL 4.5 specification as well as almost all vendor extensions

The 2.3.2 release added support for OpenGL versions up to 4.5, and OpenGL ES versions up to 3.2

Или надо готовы двиг?

https://stackoverflow.com/questions/386792/in-java-swing-how-do-you-get-a-win...

Разных графических движков для жабы - до жопы

Но они а) убогие б) сейчас стандарт - это Юнити и Анриал

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

желаю тебе зла

Почему не JavaFX? Сам его не использовал, но, насколько знаю, он через OpenGL может рисоваться.