I know LWJGL is just a wrapper for OpenGL. It's a java library designed to use the lower level OpenGL functions in the java language.
As far as I understand now, GLFW is just a library which makes it possible to create better windows to display the graphics. So GLFW is just a library for creating windows in a better way than LWJGL did before.
Is it true that GLFW is not for creating graphics, but just for creating displays?
And GLFW is not for using alone, you still should just use the LWJGL library to have access to the OpenGL functions to create graphics?
Can someone explain why I would use GLFW?
And it seems there is a relation between LWJGL3 and GLFW, but what has it to do with each other?
Is it true that GLFW is not for creating graphics, but just for creating displays? And GLFW is not for using alone, you still should just use the LWJGL library to have access to the OpenGL functions to create graphics?
Yes.
Can someone explain why I would use GLFW? And it seems there is a relation between LWJGL3 and GLFW, but what has it to do with each other?
The main reason is that it's difficult* to get Java's Windowing API[-s] to behave interoperably with OpenGL. And even when you do get them to behave together, there's often substantial performance penalties for doing so.
GLFW, on the other hand, amounts to little more than a wrapper around the native Windowing API of your environment, whether it be Windows, MacOS, or Linux. Ostensibly this is what Java's AWT API is supposed to be, but again: AWT and Swing have performance problems, GLFW does not.
LWJGL is a wrapper for GLFW, but also a wrapper for the broader OpenGL API, including functions you'd normally have to manually load in C/C++ (typically through what's called GLEW, or the OpenGL Extension wrangler). They don't necessarily have a relationship to each other except for the fact that GLFW has to load some specific OpenGL functions to ensure that it can set up framebuffers correctly and take input from OpenGL (and also behave correctly when interfaced with various OpenGL extensions), but other than that, the two are essentially independent.
Related
I have an application that will be taking advantage of the NDK do to high graphics requirements and a terrain generation library that I wrote in c++. My question is if I already made my GUI with the SDK and I make a random opengl call in java such as GLES20.glEnable(GL_CULL_FACE); and then proceed to call glEnable(GL_DEPTH_TEST); in C++ via JNI would there be any known errors/build issues? In the case that someone wonders why I am asking this and/or thinks it is a stupid question it is because in desktop OpenGL there is an existing OpenGL context (though GLFW took care of most of this). I am concerned if OpenGL ES also has an existing context. If so, would making OpenGL ES calls from both java and C++ write to previously stated context?
In OpenGL you're always dealing with context, yes. The critical parts for you are
when and how is your OpenGL context bound in the Java parts?
is the OpenGL context kept current when calling into native code.
Practically all Java calls to OpenGL go into native code any way. So if you write parts of your program with the NDK and call into these parts in the same way as you'd call directly into OpenGL, then a OpenGL context will be current and be usable.
The direct answer is Yes, but you must be careful how you write your C++ and Java code
NDK offer some NativeActivity and native_app_glue codes, which helps you write pure C++ codes for game logic, rendering, etc., and minimize the requirement for writing Java code. You will find some entry point function like android_main() if you are using this way. In this case, you can't mix call OpenGL in Java and C++ codes in the same context, since your native code are run in different thread, and communicate through pipe with Java thread [Dalvik VM thread]
Call native function in Java through JNI, this will in the same thread, same context, call OpenGL API in Java or C++ should be no difference, just as the answer of #datenwolf
Hope this helps~
I've noticed that using the Java libraries that are default built in, rendering the simplest graphics absolutely kills the FPS, and furthermore, looks ugly.
Now I was wondering if I could use JOGL or LWJGL libraries to use in my pre-existing program. (I'm making a game which renders cubes as planets, and you have to build planets.) Do I need to completely rewrite my code? Or can I just install these and render freely? And which one of the above is easier to understand, because I have limited knowledge in these libraries.
Btw, right now, I am using JFrames, does that need to go as well?
Also, what is OpenGL, is that good to use as well without rewriting code?
OpenGL is a standardized graphics interface for use between programs and your graphics card. A proprietary version of this by Microsoft is known as DirectX. LWJGL and JOGL are two different Java bindings to OpenGL libraries, both of which have native code they load in.
LWJGL is much more aimed towards gaming with OpenGL, where as JOGL is more worried about complete and perfect bindings to OpenGL/OpenCL. I would recommend LWJGL if you're just getting started.
You're going to have to rewrite your rendering code, yes. But assuming you designed your project well, you shouldn't need to rewrite the game logic. JFrames will probably also have to go, but I'm not completely sure about that.
Please don't turn this question into another "JOGL vs LWJGL" thread. Moreover, JOGL is used in several games including Poxnora and Salem (MMO). You'll have to learn OpenGL if you want to use any Java binding of this API anyway.
Finally, you can use GLG2D in order to get a better hardware acceleration with plain Swing, it would allow you to benefit of better performance only with a very few changes in your program. GLG2D relies on JOGL 2, you can find more information about it here: http://brandonborkholder.github.io/glg2d/
I'm trying to design a side scroller for android and a level editor for windows. A lot of the code between the two programs will be the same. The bit I'm currently working on is drawing textures.
What I currently have is a library that includes code related to loading and drawing the texture information. The bit that I'm stuck on is how would I incorporate OpenGL (for windows) and OpenGL ES (for android) into the library?
I thought about having an interface that includes all the drawing functions and then implementing that interface separately within each program (since one will use OpenGL and one OpenGL ES) but that still produces a lot of duplicated code (and kinda defeats the purpose of trying to create this shared library).
Is there a better way to approach this problem? Am I just over complicating this by trying to make it too flexible? I have been thinking about this for a few sdays now, so any input would be greatly appreciated!
Please ask if anything doesn't make sense!
OpenGL and OpenGL-ES are similar enough, that you can share large amounts of the codebase. Since you're probably going to target OpenGL-ES-2, you will then probably use OpenGL-3 on the desktop. OpenGL-3 has a lot of what OpenGL-ES-2 has. So I suggest you develop your code primarily for OpenGL-ES-2 and then only for the small differences toward OpenGL-3 you add alternative codepaths.
I'm writing an online multiplayer game, and I'm thinking about implementing the network code in Java, using JBoss Netty. But I'm considering C++ for the 3D rendering (they're simple graphics, nothing extensive). Would it be worth implementing such behavior in C++?
Would it be worth implementing such behavior in C++?
No, I would recommend doing everything in java or in c++. That way you won't have any problems with c++ to java interoperability. In case you already have the network code in java I would go for that.
If you choose java you can use a 3D rendering library like for example jogl or lwjgl. These libraries are really light weight and you will probably not have any problems with the actual rendering performance since it is done by the graphics chip.
We would like to use some of our existing Java AWT graphics code on the Android platform. As far as I can tell, Android does not include any of the AWT classes -- no Graphics2D, Path2D, FontMetrics, etc.
What is the best approach to port our drawing code to Android? Ideally, we would like to modify our code base to target both Android and generic Java.
The android platform supports a small subset of awt. By small, I mean it supports awt fonts. Going from java swing (are you really just using awt as a standalone UI?) to Android is going to be a shock to the system. One defines Android's UI in XML resource files, and those resources are loaded into Activity classes which represents a logical unit of the application. Canvas' replace Graphics2D objects, and they have somewhat different functionality.The Android UI system seeks to avoid absolute positioning, which is common in java UI's. And there is so much more to consider for Android, like varying screen sizes and differences in resolution. Neither of which were much of a issue for Java SE. To answer your question: you have your work cut out for you and you will have to start much of your coding from scratch.
I'm not sure what 'drawing code' means, but in my case, I have a large amount of animation code that is displayed via awt shapes. This is reproducable on android as there are graphics.drawable.shapes objects, and one can display primitive shapes by doing something like canvas.drawCircle(x,y,z,h) (remind you of something?). But when I ported it, it was difficulty and felt like I was cortorting the android to do something it really didn't want to, and wasn't intended to do. It's hard to answer your question exactly given the vagueness of it.
I don't think you can port AWT to Android. I mean, it's Java SE vs a subset of it (or an updated Java ME with steroids, as you prefer).
There are though, some UI classes for Java ME that work perfectly on Android. Personally I like LWUIT but it's not the only one.
appengine-awt is a pure java implementation of the java.awt and javax.imageio packages for use in the Google AppEngine environment.
https://github.com/witwall/appengine-awt
SwingWT is a 100% pure Java library which aims to be a free implementation of Swing and AWT. Unlike Swing, it drives native peer widgets for your platform from SWT.
https://github.com/witwall/SwingWT