Xbox One and PS4 games with JMonkey

@zzuegg said: As Unreal showed their Citadel Demo running on javascript and webgl i cannot belive that webgl lacks of performance.

They showed their citadel model with the features enabled that WebGL supports, yeah :slight_smile:

I have no evidence to support this opinion but it wouldn’t surprise me in the slightest if the PS4 is OpenGL and the XB1 is DirectX. Microsoft have never been shy of using their platform control to push their technologies onto the world.

Interestingly though more and more games developers seem to be moving over to OpenGL.

If that is the case though then the PS4 will be substantially easier to support.

@zzuegg said: As Unreal showed their Citadel Demo running on javascript and webgl i cannot belive that webgl lacks of performance.

Once it has been sent to the graphics card the graphics card does all the work so performance on that side is fine. The problem is javascript which currently is just not fast enough to run any serious game in.

WebGl is also a bit limited comapred to the full opengl spec.

Hi

Please go on making a great engine, concentrate on what you do the best instead of wanting to do everything by yourself. Last year, @sgothel asked me whether the JogAmp Foundation should have its own engine, I answered “no” because we (JogAmp) should focus on maintaining our windowing toolkit, our APIs, our bindings and maybe our VMs rather than trying to compete with JMonkeyEngine. Please stay focused on improving JMonkeyEngine and go on communicating with other teams about the bindings, the third party APIs and the VMs that you need. Project Ji Gong (JogAmp Runtime Environment) is intended to cover some of your needs to support other platforms but we need some more contributors.

@zzuegg said: As Unreal showed their Citadel Demo running on javascript and webgl i cannot belive that webgl lacks of performance.
As I met the main guy responsible for the implementation of WebGL support in Google Chrome last year at siggraph 2012, I can just confirm that WebGL has other constraints than JOGL, it always uses offscreen rendering which is inherently slower than onscreen rendering, Javascript isn't the only bottleneck. I wrote an article about WebGL, a demo is a bit weak to draw such conclusions. I remind other people that JOGL supports more or less ANGLE.

I don’t want to be pessimist but I think that Java on consoles (except Java-based ones) is a dead end.

@normen You can contact @sgothel if you still need some help on iOS.

@gouessej said: @normen You can contact @sgothel if you still need some help on iOS.

I end up with the same problem over and over again: The project setup is just too complicated for me to actually get to the point where I can compile things (code generated by the build system etc). Funnily this is probably also the general reason why people rather do stuff themselves again instead of leveraging existing stuff :wink: As in use another build system, use different frameworks, use different programming paradigms etc. Generally I concur with what you say but just doing our own native JNI wrapper for GLES looks so much easier from here. Note this is not a rigid statement like “we don’t want multiple renderers per platform”. I’d like to see a unified (JOGL) backend for jME at some point.

Another funny thing to note is that the guy who did that MikuMiku stuff apparently created a libgdx renderer for jME xD People will always just mess about their way, synergy in Open Source is astoundingly hard to achieve.

@normen It runs out of the box within Eclipse and in command line and I think that a very few developers are really able to maintain a set of OpenGL/OpenGL-ES/PSGL/OpenCL/OpenAL bindings on a daily basis. 13 years ago, there were at least 5 Java bindings for the OpenGL API. Synergy is necessary. Supporting OS X is already very time consuming.

@gouessej said: @normen It runs out of the box within Eclipse and in command line and I think that a very few developers are really able to maintain a set of OpenGL/OpenGL-ES/PSGL/OpenCL/OpenAL bindings on a daily basis. 13 years ago, there were at least 5 Java bindings for the OpenGL API. Synergy is necessary. Supporting OS X is already very time consuming.

Its not about being able to run the existing builds… I’d either have to weave in the iOS compile into your build system or get the (partly generated) files out of it and into my iOS build system to do anything.

Anyway as said I don’t disagree in this respect but the facts look different. LibGDX also does its own stuff, the code is closely tied to RoboVM in that case. Another special build setup, another self-maintained wrapper. You may find synergy is necessary but its hard to find. (unless you walk around and make everybody use the same stuff :wink: ;))

This is an interesting thread I missed!
Is iOS still something @normen is actively working on then? I thought this was abandoned after http://hub.jmonkeyengine.org/forum/topic/ios-renderer-2/#post-228159

Whilst I am not a fan of Apple, I think iOS would certainly help people actually make money out of JME-based games, and with money comes investment of time (and more money!), so would be really cool to have a GLES wrapper.

I wonder if this could be of help?
http://www.spanglefish.com/dmsconsulting/index.asp?pageid=438180

Stuff like this for example: http://pastebin.com/hw2iXUg8

@monkeychops said: This is an interesting thread I missed! Is iOS still something @normen is actively working on then? I thought this was abandoned after http://hub.jmonkeyengine.org/forum/topic/ios-renderer-2/#post-228159

Whilst I am not a fan of Apple, I think iOS would certainly help people actually make money out of JME-based games, and with money comes investment of time (and more money!), so would be really cool to have a GLES wrapper.

I wonder if this could be of help?

Stuff like this for example: /** GLES10JNI V0.04 * (C) D.M.Scales 2012 * * V0.01 Sep 12 Developed from - Pastebin.com

Money doesn’t cause contributions, not at all. Maybe it causes a bit of money for us but money doesn’t write code.

I got a maybe stupid question…

Orbis OS (ps4 OS) is based on FreeBSD.
why than it is so complicated?

https://www.freebsdfoundation.org/java/java16
isent a dvd install impossible?

sorry if the question is dumb i dont have a ps4, but iam interessted in this.

@SaschaS said: I got a maybe stupid question...

Orbis OS (ps4 OS) is based on FreeBSD.
why than it is so complicated?

https://www.freebsdfoundation.org/java/java16
isent a dvd install impossible?

sorry if the question is dumb i dont have a ps4, but iam interessted in this.

Apple MacOS X is a BSD, too. Maybe that gives a hint at the actual problems which, as you indicate, are not so much code incompatibilities. Its more having the hardware and development environment set up, understanding all parts of the build system and code to put it together and finally getting all legal issues straight.