I'm looking into technologies for a new embedded product that has a 1 ghz via processor, and a via s3 graphics chip. So far the target platform is Linux, but would like the option to move it over to a windows based platform.
The application would consist of widgets like buttons, graphs, and numeric/text displays. More importantly, the app would contain animating objects, such as fans constantly rotating.
Qt seemed like a good choice because it is cross-platform and has a nice API for a bunch of widgets and an animation framework.
However, this animation framework uses the CPU quite heavily. The target CPU usage for rendering the UI is 40%. Rotating 25 objects with an image uses about 90% CPU.
The thought is to use opengl to animate the objects and take that heavy load off the CPU.
My question is, if Qt the best choice for something like this? Should I be looking more heavily into something like Java 2D?
OpenGL could give you a performance boost:
Qt for Embedded Linux and OpenGL
Or maybe you need a better graphics driver (I don't know if your graphics chip is supported out of the box by Qt Embedded):
Adding an Accelerated Graphics Driver to Qt for Embedded Linux
As far as I recall, Qt's animation framework can be used for continuous animation, but probably isn't the best choice for such. I think it was more designed for transient animations, like sliding a widget around, or growing/shrinking things. I would look into either using OpenGL or possibly QGraphicsView, which allows you to do a more direct sort of drawing.
Additionally, if you look around, you should be able to find instructions for telling Qt to use OpenGL or OpenGL ES as the back-end for the rendering system, which shoud reduce some of the hit to your processor (assuming you haven't already done so).
You need to profile your application to really find out what is wrong there. For example, a fixed shape but continuously rotating graphics item can benefit a lot from item coordinate cache (see QGraphicsItem::setCacheMode). Likewise, fixed images should be cached and kept as long as possible as pixmaps. Color depth may also play an important role. Complex path-based graphics items should be simplified as much as possible.
In short, there are tons of reasons why graphics performance is bad. Without elaborating them and attack them one by one, moving into OpenGL will not really solve the problem. It might accelerate the frame-per-second (due to the obvious advantage of shifting some responsibilities to the graphics hardware), but this is a near-term advantage and quickly diminish in the long-term if the real problem is not uncovered.
Qt's primary selling point is that it's a cross-platform GUI toolkit, which is a nice feature but one that Java has already. You may prefer Qt's version, and many people do, but don't use it just because it's cross-platform. This article shows that the Qt animation framework is not yet integrated into Qt.
If you can program in GL then JOGL is an obvious start point, but if you can't be aware that GL programming is not easy. You might also consider Java3D. Possibly what you want can be done in JavaFX.
Related
If I am going to make a game like Tower Defence on iOS or Android, do I need to use OpenGL ES extensively? Or am I merely using textures without using other features like geometry transformation, lightning, drawing primitive shape and such?
Secondly, if I am only using the sprite-sheet to animate the game, could I stick to the native platform provided library without the use of OpenGL ES? For example on iOS, using the UIImageView class animation method to perform an animation.
This is such a complex question that you will hardly receive a conclusive answer.
In short: There is no need to touch OpenGL at all to do a game.
Every method that you describe would work, but with various advantages and disadvantages. A short excurse for inbuilt frameworks on Android:
Use standard views (like FrameLayouts): The Framework can do most of your work (animation, z-sorting, ...) but you will run frequently into weird layout errors and surprising performance hits. This is because you are essentially perusing a UI framework for a game. However, for a very simple game it might be just the right thing to do.
Use Canvas painting: Android contains a good and rather fast 2D graphics library in that. You can use it for games, it will deliver enough performance for many games. However, you have to do more yourself already (e.g., z-sorting, animation) and some high-end effects are still not possible
OpenGL ES: Best performance, most choices. Good luck, when starting from scratch, there is A LOT to do before you get even the simplest stuff on the screen. On the other hand, you can do things that are almost impossible with the other approaches. Also, it's possible to reuse parts of the code for multiple platforms.
Renderscript: In my experience even worse than working directly with OpenGL in that the learning curve is even steeper.
In short, design the game first, then decide on which framework provides enough functionality for that without being too complex.
And finally: Think about not doing all the plumbing yourself but take a look at the existing game engines (Unity for example). Almost anything you ever need will be in there; furthermore, some of these engines work even cross-plattform: Write your game once, publish it on iOS AND Android!
I'm going to be working on a decent-sized game in clojure and for now it will have 2d graphics. Is Processing (or rather, Quil, which is just a clojure wrapper for Processing) an appropriate tool to use for this.
Processing presents itself as a way to quickly experiment with different ways of generating and manipulating graphics rather than a scalable 2d graphics library, but I don't see any obvious reasons why it couldn't be used as such, so long as you take care to properly separate logic code from rendering code.
If there are better options, let me know.
Processing is certainly cool, but is somewhat specialised towards visualisation / interactive animations. It also has it's own mini-language designed for visualization applications. While it is possible you could make a decent game using it, you might start running into performance issues as this is going outside its usual usage.
For a decent-sized game I expect you will ultimately want to use OpenGL directly, in which case LWJGL might be a better option.
Ultimately, you probably need to prototype using both and figure out what works best. As a rough benchmark, you will want to render a full screen of tiles plus 1,000 sprites at 100+ FPS with less than 20% CPU. If you can demonstrate that processing can handle that then you may be fine.
Other options that you can consider:
Swing - good for simple 2D games. Has the advantage that it is built-in to the standard Java distribution and has lots of good tutorials. Wasn't really designed for games but works fine providing you aren't too demanding.
JavaFX 2.0 - roughly intended to plat in the same space as Flash (rich internet applications). Looks pretty cool, but is still fairly new. Again, probably fine for simple Flash-style games.
I would be careful of using processing for this. I'm not sure about PC, but on the Mac Processing can have pretty hi CPU usage, depending what you are doing. So if your game is cross platform there might be a better option. If it's an online game why not use Flash? The scripting languages are not too far apart and in the book 'Processing: A programming handbook for visual Designers and Artists' (Casey Reas & Ben Fry) there's a handy little section at the back (pages 686 - 691) showing the comparative syntax of Processing, Java, Actionscript & Lingo that would be a useful way of getting you started.
I am gonna be writing java code to plot 3D point clouds. Someone suggested me to go for java 3D libraries however it is apparently dead (this reference) and not apparently good idea go to with JMonkey either (same reference).
That link was posted in 2009 and we are in 2012.
All I want to do is to plot a dense 3D point cloud, say 5 million points, and to be able to rotate it / or zoom in real-time. I know the algorithms for rendering and stuff however I need a set of 3D java library with active community and support ( if any).
Please consider Desktop and also Web applications while suggesting me the solution.
Thanks a lot
and not apparently good idea go to with JMonkey either (same reference)
What you reference there is more than three years old, ancient in terms of technology.
jME has come back in a big way since then. jME3 is it an extraordinarily stable beta with Android support, improved physics support (both JBullet as well as a native wrapper), an SDK with scene editor, lots of user-contributed plugins, and an extremely active community.
There are a number of successful games making use of it as well, most notably Mythruna and 3079.
What you're looking to do is easily accomplished in jME and we'd invite you to come on over and try it out. http://jmonkeyengine.org
Not a scenegraph, but LWJGL offers an easy wrapper around OpenGL, so you could quite easily construct a list of quads to represent your points and setup/modify a view to display and rotate them depending on user input.
This should work in applets also to cover your web targets.
jzy3d
is what you are looking for.
Jzy3d is an open source (BSD) java library that allows a rapid display
of 3d scientific data, either surfaces, scatter plots, bar charts, and
lot of other 3d primitives. The API provides support for rich
interactive charts, with colorbars, tooltips and overlays. Axis and
chart layout can be fully customized and enhanced.
I would use JavaFX for this. It is already included in JDK 8 and the project is well alive.
Contrary to LWJGL, there is more and better documentation. Also LWJGL being a thin wrapper, will force you to learn OpenGL as soon as you need to do any transformation, and that will take you some time.
Jzy3d is a higher level API but the tutorial is not free.
JME3 is overkill and, as long as my limited experience with it taught me, you'll need to use Blender to create the model (I might be wrong).
There is a lot of documentation for JavaFX online. If you don't mind buying a book, "JavaFX for Dummies" is quite good, although basic.
I realize JavaFx 2.0 has only been out for a short time but was hoping someone is aware of an FX 2.0 game engine ( or even such a project in open source development )? I've been unable to find one- so if you do please point me in the right direction.
I'm also wondering how JavaFX2.0 will change java game programming. From what I've read and the small experiments I've made I can definitely say it is much more pleasant to code in. And I believe it runs on a faster hardware accelerated graphics engine than regular Java swing or awt based stuff. But is it complete enough to support an entire game framework of any complexity?
JavaFX is great for simple browser based / 2D games - the kind of areas where Flash is currently most common. Reasons:
Great performance for 2D apps (good use of hardware acceleration under the hood)
Very easy to skin with CSS - web designers will love this
The new JavaFX 2.0 API is very usable from pure Java (or other JVM languages like Scala, Clojure)
Cross platform, so can reach the largest possible audience
It's unlikely to be suitable for complex / high performance 3D games where you will need a proper OpenGL game engine like jMonkeyEngine.
I think the jury is still out with respect to the games in the middle ground (shoot-em-ups, 3rd person view RPGs, RTS games etc.). These games don't necessarily need a full 3D engine but do need good, smooth graphics performance. I suspect JavaFX would be fine for these on modern hardware, but I'd strongly suggest doing a quick prototype just to check the performance meets your requirements.
javaFx is not much more than a GUI toolkit like Swing, but with some extras. It is already possible to render a proper game engine into a javafx node. Here is a dome showing this.
http://www.java-gaming.org/topics/lwjgl-javafx-integration/27801/view.html.
But this does not solve the problem to lock the mouse for first person like games.
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.