We Keep Coding

JavaFX and antialias

I am in the process of porting some graphics rendering from java/Android to standard java.
The first thing that I am faced with is - which graphics api to use, Graphics2D or JavaFX.
It was proposed by assylias in my previous question "Porting graphics drawing from android to standard java", that I use JavaFX.
I have seen that this has the advantage of taking doubles and floats as parameters for drawing, as with Android.
However, I have not been able to find anything which confirms that the drawing is antialiased, or that antialiasing can be turned on.
My objective is to generate a high quality image which will be directly saved to disk and not displayed in the application. It will be displayed in another context and not printed.
I need to be drawing text, paths, beziers, lines, ellipses and rectangles.
Is it worth my while digging into JavaFX or do I have no choice but to go with Graphics2D ?

Many (if not all) of the objects that are drawn in JavaFX applications already have antialiasing effect. This is visible to the naked eye. Try to write two identical applications, one in JavaFX, and another in Swing (without antialiasing effect of Graphics and RenderingHints object). The difference is clear, especially when drawing geometric shapes and text. Here you can find some comparisons between Swing and JavaFX, and here you can get to know better the JavaFX 2.X (read the subject "Graphics System" and "Media and Images").
Personally, I would prefer to use JavaFX technology. I previously used a lot Swing. Each of my applications had to be made in Swing. However, after seeing the practicality of JavaFX, its maintainability, its elegance and productivity, I did not think twice. Even if you just want to draw simple things, JavaFX seems to have a much better performance. If I'm not mistaken, JavaFX was developed taking into account the use of video hardware on your platform, and was also inspired by the famous game engines available for Java users, which are made to work with high processing visual effect, screen updates, and among many other things.
For you marvel a bit with the technology and effort that was put, I beg you, visit this address. Look for the download of a JavaFX program named Ensemble. You will find where is written "JDK 7 and JavaFX Demos and Samples". click download and use the demo program Ensemble.
For information on drawing text, geometric shapes and stuff, see the following links:
http://java.dzone.com/articles/javafx-21-beta-improved-font
http://fxexperience.com/2012/01/lcd-text-support-in-javafx-2-1-developer-preview/ (An alternative from the previous link)
http://docs.oracle.com/javafx/2/text/jfxpub-text.htm (Look for "Setting LCD Text Support" and also, with the feature of applying effects to text and various things of JavaFX, you can still improve the visualization of what is shown to the user.)
http://docs.oracle.com/javafx/2/api/javafx/scene/shape/Shape.html#smoothProperty (The "shapes part")
Would you like an opinion of a colleague? Adopt JavaFX in its version 2.X or higher (do not use the JavaFX 1.X). Over time this type of technology will mature. Much still come ahead. The next update of JavaFX, we will have many nice features. And notice that JavaFX is still in its version 2.X. Probably in the near future Swing library will be left out, as happened with the AWT. You better start now studying JavaFX, rather than only in the future you go familiarizing yourself. The market is there.
If you still have some questions, please come back and ask. We'll be here. :)
Good luck.

How to detect low-spec mobile devices meaningfully?

Right now I only know about Scientiamobile's WURFL and a few others. Those libraries or databases tell you quite a lot of things about the device but none of them can clearly indicate that you shouldn't use CSS transitions or other sorts of animation because even if the device supports it, its a complete different story that those features will run smoothly and this is my major concern when building mobile web apps.
Is it technically possible to 'classify' devices in this direction, using the 'WURF' database ? And which device capabilities I should use to 'group' devices as 'fast' in terms of graphic power ?
Finally, I just need a rating of the device from 1-5 in order to decide which gfx operations I can use.
well, any thought is welcome. It turns out as real brainer and the researches on internet didn't bring up anything useful except lots of data about device caps.
Update-1 : I just got a response from ScientiaMobile : "we have been playing around with the idea of some form of Javascript performance index (possibly based on one of the existing benchmarks) that could give some indication of that, but we are still not there yet. The problem is complex."
Update-2 : The biggest bottlenecks we discovered in mobile web apps
animation power
PNG transparency
text and box shadows
image resizing
For us its really enough to figure out that we need to disable those features as they can bring any application to its knees. Possibly, there are also other approaches.
Thank you.

Unfortunately, I do not believe this is possible today for the general case.
If you are only interested in a limited number of devices, of course you could test each and target those specifically via user agent or JavaScript-based detection.
Within the context of a thick app (e.g., you "wrap" your web site with something like Apache Cordova), it would be possible to provide JavaScript access to some of the device internals (e.g., amount of total memory, amount of free memory, processor speed), but otherwise, this information is not available from the browser. As you've hinted at, having access to this type of device information may still be insufficient (e.g., seemingly "high spec" devices that perform poorly).
JavaScript feature detection libraries like Modernizr can answer whether something such as box-shadow and text-shadow is supported by the user's current browser, but does not provide information about how well or how quickly supported features will be rendered.
Likewise, the datasets from Browserscope and related project ringmark (somewhat of a JavaScript analog to WURFL) answer these browser support questions on a per-browser-version basis through crowdsourced benchmarking tests (e.g., does the iPhone support CSS3 transitions?), and for the general case, this is what would be necessary. You would need to run a benchmark test for the various features in question and assess real-time performance. However, even this has its limitations:
Because the necessary conditions for speed (available memory, processor, battery, network connection, etc.) are constantly in flux as mobile users move around, receive calls, change hardware settings, launch background applications, etc., the result of the benchmark is likely to be unreliable/unrepeatable.
Benchmarking takes time and will invariable add a (hopefully unnoticable) delay.
Depending on the feature, benchmarking may not be practical.
Features may behave differently in combination (e.g., animating transparent PNGs with shadows) or at scale (e.g., every image on the page is animating) than individually in the benchmarking test.
If you rely on benchmarking datasets instead of performing your own real-time benchmarking, the sample size, scope, and age of the dataset greatly limits its usefulness.
A final point is that I haven't even addressed is the fact that performance is rather subjective. Say it were somehow possible to assess/predict the speed of an animation. If the animation will run at 15 fps, should the user see that animation? What about 5 fps? Who gets to be the ultimate arbiter that decides the threshold for whether or not a given feature performs well enough?
The best advice I can offer today is to reduce (or eliminate) your reliance on the troublesome features for the time being. It may seem terrible to suggest going back to "the old way" of using images with precomposed shadows or making background gradients without CSS3, but at the end of the day the user experience should take precedence over using the shiney new technology. Many mobile devices are simply not there yet, and neither are the detection methods. If you must use these features, perhaps consider a simple but unobtrusive way for users to opt-in/opt-out like Gmail's "standard" vs. "basic HTML" view options, or consider automatically doing the opt-in for known good browsers.

I can't add much more than 'user113215' already said. Also its not an answer to the actual question but rather to the actual problem :
I did experiment with a few users and we were using a simple welcome popup menu, asking the user to turn off special effects such shadows and animations. The most of the test users did appreciate the choice and clearly understood the means of such menu. We do integrate this now more advanced and in conjunction with a hidden benchmark for auto pre-selection of GFX effects.
Thank you.
g

In short, no. How we define the smoothness of animations and graphics is solely depend on the FPS(frame-per-second). And in this question we are talking about "web-app"s, which are making use of HTML and JS on the client-side. Since none of the client side provide interface for the programs to get the FPS by HTML or JS, it is impossible to tell if the client is smooth or not.
However, if you really want a benchmark on the performance of web-app. You can make use of stats.js to monitor the change of stat and have a benchmark for you to suggest your client activating or disabling any sort of effects on runtime. This method even working with most FXs of Javascript libraries like jquery too. But this will take sometime for you to get enough data before applying changes and the stat may differ from the status of the device, such as memory usage, concurrent applications, etc.

Using the Google Maps API in a 3D Java scenario

I am writing my dissertation this year in software engineering. I have a cool project in mind but wanted to ask if this was even possible first before I mention it to my tutor. If it is possible then it would be good if someone could point me in the right direction in achieving my goals.
My ideas is this. I want to make a Zombie survival game, generic and boring I know, but I want players to be able to run around in their own hometowns as if a zombie outbreak actually happened, the easiest way to do this would be to use the Google Maps API (I think) so maps are automatically created depending on a users home location.
And added feature would be to implement transport systems using local train stations so users can actually move to their friends areas in realtime on a multi-player platform.
So from what information I know already I would need these tutorials/resources.
The ability to import real time google maps into a Java environment
The ability to see where roads occur and where areas that can be walked on occur, maybe using the colour green as a basis for fields etc.. This is to ensure users can only walk within defined areas
The ability to generate surroundings (such as houses and fences) next to roads and walkable areas rather than have the user running around on a flat 3D environment
I already have some knowledge on creating 3D environments as it is using the JWJGL library. Each of the points stated above are dependent on the previous bulleted point. Any feedback or constructive criticism is greatly appreciated. Even just a "What the hell are you even talking about" would be helpful also.
Glad to see your replies.

It might be possible using the Google Earth API: https://developers.google.com/earth/
You would have to get a web view of some kind, basically integrating a JavaScript application into your Java application. I would be cognizant of the terms of service though.

Best of both worlds: browser and desktop game?

When considering a platform for a game, I've decided on multi-platform (Win/Lin/Mac) but can't make up my mind as far as browser vs. desktop. As I'm not all too far in development, and now having second thoughts, I'd like your opinion!
Browser-based games using Java applets:
market penetration is reasonably high (for version 6, it's somewhere around 60% I believe?)
using JOGL, 3D performance/quality is decent; certainly good enough to render the crappy 3D graphics that I make
there's the (small?) possibility of porting something to Android
great for an audience of gamers who switch computers often; can sit down at any computer, load a webpage and play it
also great for casual gamers or less knowledgeable gamers who are quite happy with playing games in a browser but don't want to install more things to their computer
written in a high-level language which I am more familiar with than C++ - but at the same time, I would like to improve my skills with C++ as it is probably where I am headed in the game industry once I get out of school...
easier update process: reload the page.
Desktop games using good ol' C++ and OpenGL
100% market penetration, assuming complete cross-platform; however, that number reduces when you consider how many people will go through downloading and installing an executable compared to just browsing to a webpage and hitting "yes" to a security warning.
more trouble to maintain the cross-platform; but again, for learning purposes I would embrace the challenge and the knowledge I would gain
better performance all around
true full screen, whereas browser games often struggle with smooth full screen graphics (especially on Linux, in my experience)
can take advantage of distribution platforms such as Steam
more likely to be considered a "real" game, whereas browser and Java games are often dismissed as not being real games and therefore not played by "hardcore gamers"
installer can be large; don't have to worry so much about download times
Is there a way to have the best of both worlds? I love Java applets, but I also really like the reasons to write a desktop game. I don't want to constantly port everything between a Java applet project and a C++ project; that would be twice the work!
Unity chose to write their own web player plugin. I don't like this, because I am one of the people that will not install their web player for anything, and I don't see myself being able to convince my audience to install a browser plugin.
What are my options? Are there other examples out there besides Unity, of games that have browser and desktop versions? Did I leave out anything in the pro/con lists above?

I'd suggest writing a game first.
It's easy to get caught up in how to make the best game ever,which can run on anything from an abacus to SkyNet, but the reality is that you're going to have plenty of challenges ahead of you just finishing a game that runs on your own PC.
Write a game first, for one platform (whether that platform is "Windows native with DirectX", or "Java applet" or even "pure AJAX in a browser"). If you can do that, then you can start thinking about how to port it to other platforms. But trying to do everything is a sure way to end up achieving nothing.
Or to put it another way:
I've decided on multi-platform (Win/Lin/Mac)
so you've actually decided nothing. Decide on a platform to develop on. Then make the game. Then make it work on other platforms.
Don't worry so much about what your "audience" will find acceptable. If your game is fun, then yes, people will happily install Unity. Just like they'll install your game if it's not browser-based. But the important point is not "what do I have to install to play it", but rather "is it worth it". Your focus should be on making a game that is worth the installation.
And unless you're planning to sell 20 million copies of the game and live off it, your "audience" doesn't really matter that much, does it? What matters is putting the game out there so those who are interested can try it.
But a single-platform game is a lot better than an unfinished cross-platform nothing.
A game that requires me to install Unity is a lot better than something that takes you an additional 3 years to develop because you insisted on reinventing the wheel.

Yes you can have the best of both worlds.
It's perfectly possible to write a Java application that will run in both an applet (for your online users) while also running as a standalone application in downloaded form.
The key technologies are:
JNLP
JOGL for the graphics, which also has some good demos
I'm not so familiar with it but I think jMonkeyEngine looks very promising if you want more of a full-featured game engine
If it's any use, an old game I wrote called Tyrant supported running both as an applet and as a standalone downloaded .jar file, all the source is open if you want to look at it. This used simple AWT rather than 3D graphics.
And finally here's another example of converting an applet into an application with a pretty minimal amount of code.

If you really want that kind of penetration then I suggest HTML 5 + javascript depending on the performance you need.

First of all you start with the wrong question. Your decision for a technology should be driven by the concept behind the game. It seems that you are sure about the idea to write a game - so ask your self what the requirements for the game are. This will lead you to your technologie. If it doesn't get an idea of "what" you want to do.
To your Pro's and Con's:
Don't focus on things you will never need or be able to use. Thinking about the steam platform isn't interesting for a hobby developer. Also android isn't interesting if you are not really want to ship your application for android. This Pro's will actually never be a pro in reality.
To sum it up: Let this decision be driven by your idea, not the technology itself. If you have a clear idea of what you want to do you will get your answer.
(And btw.:
Think about what browsergames imply. Behind a Browsergame there is a huge service-area, only for keeping the game running. Companys working in such areas are basically service-providers.)

You might want to look into Google's Native Client, which allows you to write your application in C or C++ (or anything else that compiles to native code, really). A new feature coming to the SDK is LLVM support, which will (hopefully) allow NaCl software to target any platform that Google's Chrome browser runs on (or any browser that the NaCl plugin works with - currently x86 and ARM are supported, IIRC).

You mentioned Android in your question - have you thought about developing the game purely for Android?
In effect you get the best of both worlds, easy to maintain, easy to release new versions, easy to monetize and get some small income and you don't have write your own installer or update mechanisms either.

Yes. You can make something that will work in both. Basically, make your program work inside a JPanel. The applet can display the JPanel, and the desktop version is just a window with your JPanel in it.
You could also have a full Swing (or whatever) GUI, which the applet launches in a new window when they click the little "start" button you'd have on your applet.
There are a few other differences you'll have to take into account, like possibly loading resources, but I've done it before for simple games I've made.

I don't think you can really compare the two:
In my opinion:
Applet, flash and other browser based games are typically small "toy" games either written for free or supplemented with advertising. For examples, check out the Addicting Games website.
C++ games are more likely to be heavyweight studio-written games relying on dedicated physics engines, graphics engines, etc (particularly true of games distributed on Steam I would have thought). The learning curve is likely to be much steeper, as C++ is inherently a more difficult language than Java / Flash.
If you're unfamiliar with C++ my advice would be to steer towards Java with JOGL. That way you can scale the Open GL learning curve before having to tackle C++.
EDIT
To address the other section of your question regarding implementing a game in both browser and desktop form, you could consider implementing the game in Java and deploying an applet and standalone version, whereby the standalone version can take advantage of Java's full-screen exclusive mode API. You could base both applications on the same codebase. You could also consider shrinking the applet's footprint size by retaining data files (e.g. game levels) on the server-side and retrieving them dynamically when required.

While WebSense won't let me browse directly to the site, for obvious reasons, the first thing that came to mind when reading this question is a game like Wurm Online. It's written in Java with JOGL, implements content streaming and local caches, and seems to have touched on a lot of the points you're interested in. It's a desktop Java application rather than being truly "in-browser" but I think you could still learn quite a bit from its implementation.
The in-browser game is always in peril of having its window closed or refreshed, causing it to abruptly lose state unless everything is being kept server-side. This means you either have very simple games that can maintain synchronization using a call/answer model (such as the myriad of Facebook "Mob Wars" text-based games) or risk an inadvertent bump of F5 catapulting someone back to their last "saved game."

I'm not sure that refusing to use a plugin because you personally don't like it is a sensible choice. This option lets you write you app installable as a desktop app, or a browser plugin (with not much extra work) and you still get to write it in C++/GL. You said you don't think your users will install plugins... why not? If they will install an application then why not a plugin which basically boils down to the same thing?
You could look at Flash too, which is gathering some 3D functionality and can run in-browser or as an AIR dektop app. But then users would need a Flash plugin, which you presumably don't have either.

Best way to get started on simple 3D user interfaces using Java?

I'm writing a time management application and I have an idea for presenting timelines and todo items in 3D. Visually, I imagine this as looking down a corridor or highway in 3D, with upcoming deadlines and tasks represented as signposts - more important items are larger and upcoming deadlines are nearer.
I want to do this in Java, however I have no idea how to begin. For example, I would like to be able to render text and 2D graphics (dates, calendars etc) on the floor/walls of the corridoor, as well as on task items. The tasks themselves could be simple blocks. However examples of 3D code I have seen all look to operate on a very low level, and what I can't figure out are the appropriate co-ordinates to be using, or how the user would be able to interact with the view by selecting items with the mouse (for example clicking an expand or info button to get/edit task properties with the usual swing components).
Is there any higher level API I could be using, or example code that does this sort of thing? Any other ideas for how best to approach this problem?
edit: removed Java3D requirement - I just need to do this in Java.

To be perfectly honest, most "clever" user interfaces are ineffective for a number of reasons:
They favor complexity (for the sake of coolness) over simplicity and usability.
They are likely to be totally unfamiliar to the user.
You have to implement them yourself without some library having done the hard work for you.
I think the interface you describe runs the risk of falling into this trap. What's wrong with the current interface? Won't it be really hard to get an overview due to foreground stuff getting in the way? Now of course you could take it a step further and zoom out/rotate to get an overview but that complicates things.
Having said all that, if you can make it easy to use and really slick, then it can make an application. Users will have a lower tolerance for failure in "fancy" UIs, so perhaps this isn't the best first 3D project.
I do think there is a need for more examples geared towards visualisation rather than games.

To be honest, having tried both, if you use JOGL instead you'll find there's tonnes of OpenGL examples to copy that sort of thing from, and you won't have to code around the limits of the scene graph Java3D gives you. I tried Java3D a couple of years ago in a simple wireframe viewer, and it was such a pain to get the camera control right and the rendering anywhere near OK that I gave up on it.

I've found Pro Java 6 3D Game Development to contain very good code examples.
Here's a code example of 3D text, from NeHe Productions!, check the "DOWNLOAD Java Code" and "DOWNLOAD JoGL Code" at the end of the example.
On a side-note, I was very impressed with LWJGL which makes you write in a very similar way to straight-forward OpenGL.