Likewise for Metal because it is Apple-specific.
OPENGL 4.3 JMONKEY WINDOWS
Engines or higher-level API's can be built on top of that, with the option to dive down to the lowest level when needed (which will probably be a rare occasion).ĭirectX will definitely not be this API because it is Windows specific. I tend to agree with Jonathan Blow's comments on Twitter, that the low-level graphics API should be just that: as low level as possible, small, focussed, and not actually intended (but still allowing!) to be used directly.
OPENGL 4.3 JMONKEY LICENSE
Whether companies are actually willing to invest in a Metal back-end remains to be seen, but considering many of them license their engine for commerical use, I would be surprised if the major players will simply ignore Metal. I think most of the work is not in adding an additional backend like Metal, but in tuning the back-end for some specific piece of hardware (NVidia vs.
OPENGL 4.3 JMONKEY PS4
Xbox One, PS4 and Switch all use completely different API's, for example. Many of them already work across a pretty wide range of back-ends anyway. I think it's hard to argue that any of the companies that develop these engines would not be able to also add a Metal back-end. The OP's point was that the companies that make these engines can afford to invest in supporting an additional back-end API though. Decima for Horizon:ZD, KillZone and Death Stranding, Naughty Dog has their own engine (don't know the name), etc. Many console exclusives also use custom engines by the way, e.g. These formats must be supported for textures.īut the OpenGL specification does not require it.That's a nice list, quite complete.
RGBA, RG, RED unsigned integral 8, 16, 32įormat RGB is not within the required format. Presented in each row is a required format.īase format Data type Bitdepth per component These formats are required for both texturesĪnd renderbuffers. Of color formats, so long as all of those colorįormats come from the required set of color formats. Implementations must allow any combination That implementations support certain formatĬombinations if you use these, implementationsĪre forbidden to return GL_FRAMEBUFFER_UNSUPPORTED. However, the OpenGL specification also requires You attempt to use an unsupported format combination. They do not support some combination of imageįormats for the attached images they do thisīy returning GL_FRAMEBUFFER_UNSUPPORTED when OpenGL allows implementations to state that Short answer: Your framebuffer configuration is not required to be supported by OpenGL spec. So did you test it by using RGBA8 instead of RGB and the problem still persisted Or do you just state the above without experimental evidence?
There is nothing wrong with my framebuffer configuration, it works on every machine when called directly from java. : Framebuffer has erronous attachment.Īt .LwjglRenderer.checkFrameBufferError(LwjglRenderer.java:1323)Īt .tFrameBuffer(LwjglRenderer.java:1602)Īt 3d.c.c.postQueue(Unknown Source)Īt 3d.l.a(Unknown Source)Īt 3d.l.render(Unknown Source)Īt .update(SimpleApplication.java:252)Īt .nLoop(LwjglAbstractDisplay.java:151)Īt .nLoop(LwjglDisplay.java:185)Īt .n(LwjglAbstractDisplay.java:228) SEVERE: Uncaught exception thrown in Thread Starting the scene with dungeons (my custom materials, rendering pipeline) crashes the game with the following error in the console: 7:03:40 PM .LwjglRenderer setFrameBufferįrameBufferħ:03:40 PM handleError Things starts normally, loading and menu screens works well. Running Skullstone with that launcher on Dell Precision causes problem I cannot solve. I have launcher written in c#, it uses DarkNotes library to run java through JNI, very nice solution, it works perfectly on my PC. Skullstone runs when started from eclipse, everything is OK, despite the fact, that I had to force use of NVidia graphics, but it is case for another topic. Now I have Dell Precision 5520 on my desktop. I’m testing Skullstone on various hardware configurations.
0 kommentar(er)
