I want to write a very simple game in Java to demonstrate a wireless controller I've built. I thought of something like Breakout or Pong. Currently, I have a prototype Pong implementation that does all animation directly using the AWT functionality. However, this is somewhat awkward to program and also a major CPU hog.
My question:
Can someone recommend a library for Java to display simple 2D animations? What have you used for similar projects?
The library should be easy and straight-forward to use -- I'm not looking for something like Java3D.
Integrated collision detection would be a pro.
This question relates to comparisons of Java 2D frameworks and may be of use.
I'm interested as to why your original implementation is a CPU hog. Is that just whilst it's drawing, or is it consuming CPU resource all the time ? If the latter, it may point to a problem wrt. how you're querying/polling your controllers.
Related
I am making an RPG game in libGDX and have been reading about how to implement quest systems and a lot of people are telling me to use a scripting language such as LUA or Javascript.
I have never used a scripting language before and am curious about how exactly I would program my game to read them. I've looked for tutorials online but there doesn't seem to be any good ones that explain how to get started.
Could someone point me in the right direction on how to get started? Thanks.
There isn't any special task that would require using anything other than java. LibGDX and its friends covers everything you will need when working on an RPG game.
Using scene2D its fast and easy to set up your scenes stages and actors. With TMX support you can load your map in minutes.
There is Box2D for an easily manageable physics world.
Provides easy to use file handling system:
https://github.com/libgdx/libgdx/wiki/File-handling
And there is gdxAI: https://github.com/libgdx/gdx-ai
With features like: Movement AI,
Steering Behaviors,
Formation Motion,
Pathfinding,
A*,
Hierarchical Pathfinding,
Path Smoothing,
Interruptible Pathfinding,
Decision Making,
State Machine,
Behavior Trees,
Infrastructure,
Message Handling,
Scheduling,
And still a lot more. LibGdx is huge and provides everything you need.
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.
As we know that we can use NetBeans for creating Swing programs (with drag and drop the code for each part of Swing will be written automatically)
Is there any software that help us write Java 3d code without writing code manually?
I don't think there's anything out there like that for almost any languages. The problem is... what exactly are you creating? With swing you know you are making a GUI for a certain set of applications but with 3D, the applications are endless. The only thing out there are APIs to help with your job. If you are an animator or game maker there are plenty of game engines to help you out.
Widening your question slightly if what you're looking for is a more productive 3D java environment (rather than Java 3D itself) then Demicron's WireFusion is worth a look. It's Java based and the higher-end versions allow pretty comprehensive access to the underlying engine so you can effectively extend it to do nearly anything.
I've used it for a project or two and I highly recommend it, the only issue is it's ridiculously expensive - in fact jaw-drop'ingly so.
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.