I noticed that GLUT is only available for C++. I am looking to reuse my OpenGL code on Java, then again port it to Android. Is there anything that is the 'standard' used instead of GLUT for these systems?
Edit:
I am in fact using JOGL and interested in reimplementing via Java and not reusing C++. I have a basic understanding of C++, Java, and OpenGL, but nothing fancy yet. I'm fine with trying to figure out everything about windows like resizing, coloring, etc. I'm wondering if there's anything to help me with some of the (more advanced?) functions like glutSwapBuffers(), glutDisplayFunc(), glutMainLoop(), etc.
What about JOGL or LWJGL .Their APIs are 1:1 to C++ glut.If you use the fixed pipeline you also have Glu lib with all you need inside.I didn't work with JOGL seriously because I didn't like the way it manages contexts and windows but I did do commercial projects with LWJGL and can tell this lib is fantastic.Also you can use it for mobile development.
I want to extend on this topic a little bit:
First , it seems like JOGL has got GLUT class which takes care mostly of primitives creation.Also I found this lib which is a partial port of C++ GLUT.But in fact , I don't understand your reason behind seeking GLUT C++ like lib.JOGL and LWJGL both supply you with input handling , context and window creation which are built in features.And in Java you will not probably be able to Unify context and windows creation under single roof because Android and Windows Java environments do it differently.Of course you can always roll your own class which will underneath take care of context/windows setup based on the platform but I think it is like re-inventing the wheel.
Regarding primitive geometry creation- I wouldn't bother to look into GLUT in such a case.Those are made using old ,deprecated (fixed) OpenGL pipeline.Today is 2013 and OpenGL is currently on 4.3 version and if you want to be synchronized with the current state of this technology and benefit from many new capabilities in OpenGL ,I would strongly recommend moving forward to OpenGL 3.3 onward.Doing this you need to code geometry manually.But there are many other benefits you gain like a total control over the way your rendering pipeline works.Also there are many online examples and tutorials on how create geometry for the programmable OpenGL.
Hope it helps.
There is jnigraphics and use NDK to develop the native C code for Android.
GLUT support is very limited in jogl, it definitely has no glutInitDisplayMode(). I suggest you to do the following:
Simple way.
Figure out what is minimal set of glut functions you need;
Create a small dynamic library calling them for you;
Bridj that library and call the methods you need from your java app.
More complex way.
Add needed functionality to jogl+gluegen, they have kind of code generator for that.
This way is imho more correct but:
(a) This is more work;
(b) jogl maintainers are not so friendly unfortunately, you will not be able to easily share work with community. First they will start blame you that your patch is piece of shit. Later they will almost command you to do in a way they need. In other words, it will take month for stupid emails... :)
Related
I am working on making a very simple 2D game engine, and I am in the process of redoing my entities to work somewhat like Unity's system. I have been doing research on how the Entity-Component-System design pattern (ECS) works, and I am beginning to understand it better.
As I understand, a component in ECS only holds data and is not capable of doing anything but retain that data. These components are then used by systems which are used to read and manipulate their data.
This led me to question is if the MonoBehaviour scripts that are attached to a GameObject in Unity are technically systems and not components as they are called in the Unity editor?
If I am mistaken, I think it would be helpful for me to analyze true implementations of ECS. I am coding in Java, so if anyone has any examples of an ECS system implemented in Java or C#, that would be great as most of the examples I have seen were in C++ which is a bit more difficult for me to understand.
Thanks!
Unity doesn't strictly work via an ECS, despite using the term "Component." A Unity component, in the form of a MonoBehaviour, can have both data and system logic. Unity will, in future versions, be rolling out an ECS model.
If you'd like to use current Unity versions (2018.1 and below) and strictly adhere to an ECS methodology, I'd suggest looking into Entitas and their Unity Plugin. You can also choose to structure your code, assets, and scenes to conform to ECS principles but Entitas is very efficient and solves a lot of problems for you.
the mono system in unity can be called EC(entity-component) which is base on Object-oriented design.
the ECS(entity-component-system) is base on Data-oriented design.
there is both data and logic in a mono component.
just joined this awesome site…
Ive recently been working in XNA on C#, making a library for that framework.
Ive gotten interested in java at was going to try making a similar library for java.
Thats when the problem arrived, there doesnt seem to be a standard 3d renderer on it.
Ive heard of JOGL, but it seemed to be discontinued (project inactive), and i prefet high level anyway,
Then I saw jMonkey and espresso 3D, but both seemed less efficient and less pretty then directx.
JavaFX discouraged me by saying that its for rich internet content.
My question is, which out of these are optimal. What is the technical difference between OpenGL and DirectX, are jMonkey and co. Actuallh effective? And if not is there a framework similar to XNA for java?
I only ask you name some and point me in the right direction, as this got me a bit confused after the 1 way .NET xD.
Also, as this is my first post here, feel free to correct any mistaked I may have made.
I think jmonkeyengine or jogl are probably the best choices, but it really depends on what your doing. Jogl looks like its still going but is now part of a fuller set of libraries, jogamp, which covers sound and gpgpu programming as well as graphics.
http://jogamp.org/
Jogl is essentially a java wrapper around OpenGL, so will be low level and require to write shader code in order to do anything modern. Jmonkeyengine is probably more the sort of thing you're after since it comes with a lot of prepackaged functionality (including its own IDE).
The real standard 3D API for Java -- in the sense that it's the one that Sun once considered "official" -- is Java3D, which is a scene graph API, something like Open Inventor. I never liked it much, and the level of support these days is pretty low. But it's worth considering, if only for completeness.
I'm searching for a rich 2d multimedia framework that's meant to be used with the JVM
There's SDL and SFML for C and C++.
I've used Pygame with Python. It's very productive.
XNA is great, too.
What about the JVM ? I know that there's a wrapper around SDL http://sdljava.sourceforge.net/ but since the last entry on the homepages newsfeed dates back to 2005 it doesn't feel particularly alive.
Basically what I'm looking for is a hardware accelerated 2d canvas for the JVM that is backed with a neat framework.
I know that C, C++ and even Python (to some extent) can be considered low-level languages. Java on the other hand abstracts over the hardware. Therefore what I'm searching for is not it's "natural territory". Nevertheless http://lwjgl.org/ is a great example of what is possible in Java.
Googling brought up this interesting project http://libgdx.badlogicgames.com/ . Have you used it ? Do you know alternatives ? Please note: I'd like to use Scala, not Java. Therefore the stress on JVM and not just Java.
Have you already looked at JavaFX 2.0?
Rendering engine is based on prism, which supports hardware and software rendering (this means it will use either DirectX or OpenGL or Java 2D depending on what's available). You can find more information about it's architecture here:
JavaFX Architecture and Framework
It uses Scene Graph in order to define things you want to render. Here you can find small introduction:
Working with the JavaFX Scene Graph
Scalafx project provides Scala bindings for JavaFX 2.0.
If you want something that works use http://lwjgl.org/ from scala.
Colleagues of mine are using Java3D for visualizing results of finite element simulations. The problem is that Java3D seems to be somehow dead, and it is a pain on OSX. This is one of the reasons we are looking for alternatives.
Quite a lot of work has gone into our current implementation based on Java3D, so the question is how much effort it would be to move away from Java3D.
JOGL is one option, but looks like a lot of work.
Has anyone suggestions for alternatives? Any experiences with such a migration?
JOGL provides a direct access to OpenGL functions. These functions are mostly low level draw functions, and you have to deal with the 'state machine' nature of OpenGL while you are programming.
Java3D abstracts this state machine. It allows you to define a tree of graphic objects, placed in a virtual scene, and rendered by a camera. The manipulation of these graphic objects is easier with such a tree structure. Then, it's up to Java3D to walk through this tree and call the OpenGL drawing functions.
This kind of library is called a scenegraph. There are many scenegraph libraries in java, some are implemented on top of JOGL. I don't have a list, but this keyword will help you in your research.
In our project, we tried 3 or 4 different libraries, but no one filled all our requirements. We ended writing our own scenegraph library (on top of JOGL).
jMonkeyEngine, Ardor3D, jPCT or Xith3D are much better options these days.
JOGL is indeed a good option. However, it's simply a wrapper library for OpenGL. That means you'll still have to do a lot of the legwork yourself. If you're comfortable with that and it suits your needs, it's not actually all that difficult. But it might be a bit time consuming and not knowing your current code-base I don't know how easy the transfer is.
You could however go for an engine which might use JOGL. Something like JMonkey Engine to purely name an example. If you look, you'll surely find some others. Have a look at those, their ease of use and their functionality to see what best suits you. They probably won't take all the work away from you, but they might make it a bit easier.
See also this Java 3D forum thread : Java3D viability questions... https://forums.oracle.com/forums/thread.jspa?threadID=2150209&tstart=15
August, InteractiveMesh
I use JOGL 2.0 (which is a low level Java binding for the OpenGL (and OpenGL-ES) API. I have recently helped someone to revive Java3D. Now, it relies only on JOGL 2.0 and it works better, especially on Mac OS X. You can find the source code here:
https://github.com/hharrison/java3d-core
Let's have fun. It is actively maintained anew ;)
P.S: I wrote a detailed article to explain how to use the very latest version of Java3D (1.6) here.
Are there inexpensive or free gateways from .NET to Java? I'm looking at some data acquisition hardware which has drivers for C/C++ and .NET -- I really don't want to do any programming in .NET.
Update: I haven't done what I originally wanted to do, but I've done something similar, using JNA to encapsulate some functions from a DLL, in order to control a USB hardware device from Java. (the DLL comes from the device manufacturer) It works really nicely. Thanks!
You could also try to use JNA for accessing the native library. JNA provides Java programs easy access to native shared libraries (DLLs on Windows) without writing anything but Java code—no JNI or native code is required. If their API is fairly straight foward, this might be the path of least resistance.
See their getting started guide where they call some native code (printf and GetSystemTime).
Well, there's JNBridge and EZ JCom, just from a Google search.
You could also use IKVM which is a slightly different approach.
(Any reason for not wanting to learn .NET, out of interest? It's a nice platform, and C# is a lovely language...)
If they have C++ versions of the drivers then you could write a wrapper around it using JNI and then load that in Java. JNI can be a bit of a pain, but it would let you use the C++ version of their drivers and not have to deal with .Net at all if you don't want.
I am partial to the recommendation to jump in the deep end with C# since it is so similar to Java. I did this and used IKVM to compile my favorite Java libs. to .NET assemblies and you get [nearly] all the core java runtime classes to boot, so if you tire of trying to find just the right C# collection type, you can always go back to java.util. (No generic collections though. Not sure why.)
Depending on what platform you're on, you have several choices for free IDEs too. For windows you can get Visual Studio Express for free but I also use SharpDevelop. You can also get the Mono IDE on Linux (and a few flavours of Unix, I think ?).
The C# learning curve is shallow if you already know Java. I only blew off 1.5 limbs on landmines that came out of nowhere for reasons I still don't understand, but workarounds were easy to come by. The worst thing about it was the darn developer docs which are AWFUL on account of being so slow. I really miss the snappiness of JavaDoc. Not only are the online docs incredibly slow, the problem is compounded by someones's iffy decision to put class summaries, constructors and methods/properties all on seperate pages so it just takes forever. Someone said to get the docs installer and install docs locally for a slightly improved experience. Not a bad idea I suppose.
I am author of jni4net, open source interprocess bridge between JVM and CLR. It's build on top of JNI and PInvoke. No C/C++ code needed. I hope it will help you.
If you have a Java application, the JNI mentioned by the others will be the way to go. You write some wrapper classes, and that's it.
If writing the wrappes is a too big task (depending on the number of methods you have to wrap), have a look at SWIG . I think it generates wrappers automatically, but I never actually used it.
If you want to code in the Java language, but you don't care if your program will run on the JRE/JVM, then you might as well use Microsoft J#. Basically, it's writing Java-Code wich is compiled to .NET-Bytecode and can use the .NET classes of the driver as well as your existing Java classes. With J# you will run into problems if your existing Java-code is newer than Java 1.4, look at this question on how to solve them.
From that point on, you could later add code in J#, C# or any other .NET language. However, you won't get back to the JRE/JVM easily.