Xbox One and PS4 games with JMonkey

Wouldn’t it be possible to run a headless java on Xbox with direct X, just like running headless Java on Ps4 with Opengl?

@Pixelapp said: But how was the Jmonkey iOS support created? How is it different from what I'm trying to do? @normen didn't seem to run into any complications or the slightest difficulties.

Edit: Man, you know what? This project is definitely going to happen. I can always ask the JOGL and JLWGL about their techniques. :slight_smile:

iOS supports Java and OpenGL… (well… there were issues as of late with OpenGL… but they were either resolved or are getting resolved. OpenGL and DirectX are not very similar. Here is an example of something that wouldn’t just port over:

Material.getAdditionalRenderStates().setBlendMode()

calls OpenGL’s method:

gl_Blend(blendFundtion, sourceMode, destinationMode);

And there are million other GL specific methods referenced in JME. I’m just curious how you could account for this without a complete rewrite of JME.

EDIT: Don’t get me wrong… I would be thrilled with both OpenGL AND DirectX support!

There is no iOS renderer, thats the point… You need to either port JOGL to PS4 or make a native renderer… Forget about DirectX for now.

@normen said: There is no iOS *renderer*, thats the point.. You need to either port JOGL to PS4 or make a native renderer... Forget about DirectX for now.

Ugh… I saw iOS but read OSX…

Were you hinting at someone currently working on an iOS renderer? Or is this future plans?

@t0neg0d said: Ugh... I saw iOS but read OSX...

Were you hinting at someone currently working on an iOS renderer? Or is this future plans?

You can compile and run jME apps on iOS using the SDK plugin I did, now all we need is a renderer so you can see something, hence all these comments here. ^^

Ok, I’ll start doing these things. But as @normen suggests, I’ll start with PS4 first.

@Pixelapp said: Ok, I'll start doing these things. But as @normen suggests, I'll start with PS4 first.

I’m so glad normen took the time to explain this to you /boggle

@t0neg0d Yes, I know. Nobody has explained anything to me here besides your extremely helpful link. :frowning:

But I have to start coding anyways.

Edit: Yes I know they are trying to help. And I appreciate that. But two lines responses for the things I’m asking on this thread don’t help much. Again, I’m not complaining. I’m just pointing out what might be helpful to me.

@Pixelapp said: @t0neg0d Yes, I know. Nobody has explained anything to me here besides your extremely helpful link. :(

But I have to start coding anyways.

Edit: Yes I know they are trying to help. And I appreciate that. But two lines responses for the things I’m asking on this thread don’t help much. Again, I’m not complaining. I’m just pointing out what might be helpful to me.

I think some of us walk a thin line between dumping tons of information at you and sounding like we are discouraging your efforts. Because if we were honest about the level of effort and forthcoming with all of the information (which most of us don’t have a handle on all of anyway) then it would sound discouraging by its very nature.

It’s a pretty big task, really. Easier if the PS4 already has an OpenGL2 API, though. Drop dead simple if it has a JVM. :slight_smile:

Ok, as it seems the PS4 does not support plaint open gl. From what i have found online they ship 2 api’s with their devkit. GNM, is the lowest layer giving you full control over the hardware, while GNMX is a layer on top of GNM and as i have read it should allow directX like programming.

All in all that means for me that you eighter have to write a wrapper that translates opengl calls to gnm , or write a special renderer only for the ps4. I probably would go for the first one since lots of other projects could use that too. (Maybe you get some support from other openGL users)

A more crucial issue is that, while the PS4 toolchain is designed to be familiar to those working on PC, the new Sony hardware doesn't use the DirectX API, so Sony has supplied two of their own.

“The graphics APIs are brand new - they don’t have any legacy baggage, so they’re quite clean, well thought-out and match the hardware really well,” says Reflections’ expert programmer Simon O’Connor.

“At the lowest level there’s an API called GNM. That gives you nearly full control of the GPU. It gives you a lot of potential power and flexibility on how you program things. Driving the GPU at that level means more work.”

Sony has talked about its lower-level API at GDC, but wouldn’t disclose its name, so at least now we know what it’s called (the PS3 equivalent is GCM, for what it’s worth) but what about the “wrapper” code supplied by Sony that is supposed to make development simpler?

“Most people start with the GNMX API which wraps around GNM and manages the more esoteric GPU details in a way that’s a lot more familiar if you’re used to platforms like D3D11. We started with the high-level one but eventually we moved to the low-level API because it suits our uses a little better,” says O’Connor, explaining that while GNMX is a lot simpler to work with, it removes much of the custom access to the PS4 GPU, and also incurs a significant CPU hit.

A lot of work was put into the move to the lower-level GNM, and in the process the tech team found out just how much work DirectX does in the background in terms of memory allocation and resource management. Moving to GNM meant that the developers had to take on the burden there themselves, as O’Connor explains:

“The Crew uses a subset of the D3D11 feature-set, so that subset is for the most part easily portable to the PS4 API. But the PS4 is a console not a PC, so a lot of things that are done for you by D3D on PC - you have to do that yourself. It means there’s more DIY to do but it gives you a hell of a lot more control over what you can do with the system.”

Another key area of the game is its programmable pixel shaders. Reflections’ experience suggests that the PlayStation Shader Language (PSSL) is very similar indeed to the HLSL standard in DirectX 11, with just subtle differences that were eliminated for the most part through pre-process macros and what O’Connor calls a “regex search and replace” for more complicated differences.

@normen @pspeed how does jmonkey run on ios, since ios has no JVM?

@zzuegg Thanks for the research. So, I guess that’s it. I’m not supporting XBoxOne or PS4. This is just a monumental task.

Thanks for all the help anyways everyone.

What have you tought that this is going to be an super easy job?

Note, i did not want to sound discouraging, i just did some quick read to give you a starting point. I actually guess supporting the xbox is a simpler task, because
a) Every Xbox is a dev kit
b) The probably use some API very close to directX (you could have a headstart by looking at something like: https://gl2dx.codeplex.com/)

c) If one of the directx wrappers works all you have to is to get java running…

//Add:@normen , regarding the iOS handler, maybe it could be interesting switching to a WebGL based backend on mobile devices. AFAIK ios 5+ supports WebGL for applications. Just a random tought

@Pixelapp said: @normen @pspeed how does jmonkey run on ios, since ios has no JVM?
The java code is compiled to native code through Avian http://oss.readytalk.com/avian/ I guess that's the same idea as your "translator" so at least this is the part you don't have to handle. The remaining task (for iOS that is) is to make a native renderer using the opengl API and to have a jni bridge over it to allow calls from java.

For PS4, we’d need something similar, but PS4 has to support opengl.
For Xbox…well we’d need a wrapper over directx…

Ofc… if those systems can have a JVM that’s a better way to go…but I wouldn’t trust any VM, like Google did for android.
If we go the native renderer way for ios and we succeed, I’ll consider going the native way for android too and ditch out the dalvik vm as much as possible.

Don’t be discouraged. It can work, it’s just that it’s difficult, because you’ll need several fields of expertise. You seem to not lack motivation though and that’s good. But as zzueg said, try to start simple and run a headless java application on the PS4 (or XBOX for that matter). This will already be a big step forward.

OK. I’ll put all this project on hold until the XboxOne and PS4 indie dev units are available to the public. Otherwise everything we do is speculate and we don’t have the resources to sit around speculating.

@Pixelapp said: OK. I'll put all this project on hold until the XboxOne and PS4 indie dev units are available to the public. Otherwise everything we do is speculate and we don't have the resources to sit around speculating.
Fair enough.

In the meantime, here’s another one for the research pile:
https://code.google.com/p/angleproject/
“The goal of ANGLE is to allow Windows users to seamlessly run WebGL and other OpenGL ES 2.0 content by translating OpenGL ES 2.0 API calls to DirectX 9 or DirectX 11 API calls.”

Actuall at least directx to opengl kinda owrks in the wine project, not for every case, but for older stuff its quite acceptable.

@zzuegg said: //Add:@normen , regarding the iOS handler, maybe it could be interesting switching to a WebGL based backend on mobile devices. AFAIK ios 5+ supports WebGL for applications. Just a random tought

Not really, WebGL isn’t powerful enough yet.

@normen said: Not really, WebGL isn't powerful enough yet.

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

Regarding WebGL, the WebGL 2.0 spec was very recently published:

http://www.khronos.org/registry/webgl/specs/latest/2.0/