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/
Related
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.
I want to do Java 3D Graphics without using external libraries to develop a game applet. Sorry I am not that experienced with Graphics and so I am not sure how hard it would be to do it by myself
The real answer to your question is that you're thinking about it a bit sideways: you shouldn't be using an applet (they're dead), and you shouldn't try to do it all by yourself without any libraries.
I'd personally recommend Processing for beginners or libGDX for more experienced users. They both allow you to do 3D, and they both allow you to deploy as JavaScript- which is better than applets.
If you really, really, really want to try to do this without any libraries, then you'll have to do all the 3D math and whatnot yourself, then do the drawing in Java2D. A very basic example of getting started is here, but like I said, you're on your own to do all the conversions from 3D world space to 2D drawing space.
Any sane person would use something like OpenGL instead, which you can find Java wrappers for- JOGL is a pretty basic wrapper (so if your goal is to get "close to the metal" then this might be your best bet), LWJGL provides a few extra features for game development, and the already-mentioned libGDX is built on top of LWJGL.
If you're afraid of using libraries because you think they're too complicated, let me tell you that doing 3D stuff without a library is even more complicated.
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.
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
I've written a series of classes to interperet data from a serial port. This data needs to be displayed on the screen. I am trying to go for straight up eye candy with a refined look.
Swing UI- Easy to program, yields mediocre results
Open GL- Hard to program, yields good results.
Are there any other options?
Give SWT a go, the API is a lot simpler than Swing. Here is a recent question outlining the differences between SWT and Swing.
I'm not aware of any alternatives, but in my opinion it is possible to write beautiful GUI with Swing. Just changing the ugly default look and feel goes a long way. Visual appeal just doesn't seem to be a top priority for most Java coders and therefore you have to make an effort to make anything pretty.
JavaFX maybe? Didn't tried it yet, it obviously offers some eye candy.
You can use NetBeans combined with JOGL (Java bindings for OpenGL) or simply with Java2D.
NetBeans has an easy GUI Builder for Swing applications -- you can make beautiful interfaces (if you get into it), easily change the Look&Feel, etc etc.., and you can use Java2D or JOGL for visualizing your data and embed it in the GUI to display it.
There's a plugin for JOGL for NetBeans so getting started is hassle free.
use html, css, javascript. Much easier to get wizz-bang UI than using Swing or related technologies.
For my projects at work, we have purchased a licence of JFormDesigner.
This is really a great tool that saved us a lot of time.
Writing Swing application by hand can be a real pain and is awful to maintain.
This tool choose the right approach : The model-view-controller.
The GUI builder creates XML files for you that represent the interface. These XML files are loaded at runtime and transformed into Swing objects. The builder also generates Java stubs that you can fill with event handlers.
It also handles Localization and nice layout goodies.
Give it a try.