JavaFX For Pixel Games

I have done some searching, but I haven’t found a satisfactory answer. How would one go about creating pixelated games using JavaFX? I am using JavaFX for the first time (cause I’m developing a game I would like to have run on the Raspberry Pi, and JavaFX seems to be the way to go performance-wise).

Anyway, when using Java2D I’d simply draw the game images onto an image, then draw that image to a canvas that is larger than the image, resulting in pixelly goodness. However, I’m new to JavaFX and don’t quite know how to do that. I created a Canvas and tried drawing images using its GraphicsContext, then scaling the canvas up by a factor of 2. This results in a blurry image, due to interpolation.

My questions are:

  1. Is it possible to scale a canvas without using interpolation to smooth the pixels?
  2. Should I even be trying to do it the way I am, or is there a better way?
  3. If there is a better way, what would it be?

Thanks a lot for any advice.

I don’t think you can run JavaFX on Raspberry PI. For one, graphics are needed, meaning they have a pipeline to make it graphics accelerated.

So unless you have a graphics card that will run JavaFX for your Raspberry PI, I wouldn’t bother learning JavaFX for it.

https://docs.oracle.com/javafx/2/system_requirements_2-2/jfxpub-system_requirements_2-2.htm#sthref6

@Hydroque
I wrote a small program using JavaFX and tested on a raspberry pi, and it ran just fine. It runs from the command line without a GUI running, cause I heard that JavaFX takes over the whole screen and doesn’t require a windowing system (at least on the Pi, that is). The program extended Application, created a scene and a stage and drew an image and some text to the screen. The Raspberry Pi ran it better than it runs ordinary Java2D.

I believe javafx has support for determining how images are scaled. Maybe not. I have that ability in opengl and we use texture parameters. Id do a Google search for controlling scaled images.

Any chance of posting a screen shot of this effect? I don’t recall seeing “pixilated” images like you describe before, and am wondering what this looks like.

As for alternate methods, I suppose it would involve working the raw data, which I know how to do with a BufferedImage. I haven’t gotten into an image’s pixel data with JavaFX yet, though.

There is a smooth property in ImageView that might pertain to this.

I’m talking about pixelated game art like this (The game is “Cave Story”). Notice that each “pixel” is actually about 2x2 pixels in size.

I just now tried that ImageView setSmooth() function, but strangely it seems to have no effect. I’m beginning to wonder if maybe that’s a bug or something.

Are you thinking you can stretch an image like you can a vector image? Or am I wrong?

Not quite. I’m trying to create a retro video game look. Say, for example, that I have a sprite that is 32x32 pixels. Using Java2D, I would draw that sprite to a BufferedImage using the BufferedImage’s getGraphics().drawImage() method. I would draw all of my sprites to that primary BufferedImage. Let’s say that this BufferedImage is 300x200 pixels. I would then take that BufferedImage and draw it to a canvas that is 600x400 pixels. Now, the image will come out looking blocky and pixelated on the screen, because I am scaling the image up by a factor of two, thus making each original pixel into a 2x2 square of pixels on the user’s screen.

The problem is that, with JavaFX (which I would like to use because it is faster than Java2D), when I get to the part where I draw the main image to a canvas that is twice the size, JavaFX feels the need to interpolate my image when it scales it up. This results in blurriness of the main image. There doesn’t seem to be any way to disable interpolation of scaled images or anything like that.

Concerning the Plan B (reading the pixels) I found this tutorial, which makes use of PixelReader and PixelWriter:
http://docs.oracle.com/javafx/2/image_ops/jfxpub-image_ops.htm

It is not as easy as expanding the image and having it work automatically, but maybe will suffice. Going from a reader to a writer to make a 2X image or 3X image would only require going once through a pretty straightforward for loop to create the new version of the image.

It seems like there could be some other layers or levels where some type of smoothing is being applied, assuming you have set the smoothing to false. But maybe just making new images is cleaner anyway. IDK.

Neat that JavaFX works on Raspberry!

Looks like you are out of luck: https://bugs.openjdk.java.net/browse/JDK-8091877

It’s trivial stuff like that, that has turned me right off of JavaFX again :frowning:

Also… it’s not actually supported on the Pi any more.

Cas :slight_smile:

JavaFX is actually nice, but still young. :slight_smile: Ironically thing which causes it to be not yet commonly used and developed for more platforms is… Older GUI API, Swing. Other than that, in JavaFX you can basically do everything you could in Swing + much more.

@princec, was going to say similar (about no longer supported - why does insert quote no longer work on FireFox! :frowning: )

JavaFX is no longer supported by Oracle in their ARM Java downloads, which means the one that comes with the Pi is old and missing features / bug fixes. However, there are community builds of OpenJFX available for Pi that (AFAIK) will work with the Oracle JVM - http://chriswhocodes.com/ I would expect Pi to get, if it hasn’t already, a package for OpenJFX at some point … but

Except that you can’t, although for games you’re probably OK. Still, again I agree with @princec that there’s some trivial stuff that just makes it not interesting for me right now. Having just got back from NetBeans Day the topic of JavaFX came up a few times in conversation, and I don’t recall anyone being that positive about current situation, and I get the feeling development is not far off stalled. I kind of agree with this post - https://www.codenameone.com/blog/should-oracle-spring-clean-javafx.html

There’s so much stuff missing from JavaFX over Swing :frowning: And what’s worse, to try and make any headway against the deficiencies, you’re left with digging around in undocumented stuff like internal component hierarchies.

Also, for some reason I absolutely hate using doubles everywhere. You might think it’s not such a pain, but go and take a peek at some fxml and recoil in horror at coordinates that have somehow ended up being 1.09845903874590875934243523.

And yes, Oracle should seriously spin off JavaFX into a separate project, and throw a lot more engineers at it. Though I feel that some aspects of its design are now no longer possible to fix (doubles, gah).

Cas :slight_smile:

JavaFX (OpenJFX) always has been a separate project. In some ways it might have done better if it was part of OpenJDK / JavaSE. Still, I doubt you’ll see Oracle throwing engineers at it, if anything (check out Future of JavaFX thread on openjfx mailing list, etc.) it seems to be the opposite with Oracle focus on browser and cloud.

Internal dependencies may at least improve because they have to make it work with Jigsaw. :wink:

Double vs what? If some things should really be integers I agree with you - if we’re talking double vs float it’s double every time!

Agreed about ints/doubles/floats.

I have a feeling JavaFX is basically dead but no-one’s realised it yet.

Cas :slight_smile:

I gave up JavaFX when I ported prism to LWJGL3. With such a horrible backend design and implementation, it’s not surprising that progress is slow, performance suffers and simple features cannot be added easily.

I had to delve (quite deeply) into JavaFX’s back-end whilst trying to find a multithreading bug. Turns out that the multithreading bug can be worked around by using -Dquantum.multithreaded=false on the commandline, but the reason it is needed it because the whole multithreaded design is broken anyway. On top of the design essentially preventing any efficient interaction between other OpenGL code and itself, the pointless lack of OpenGL support on Windows (which does exist! - they just leave it out of the standard JDK…), and the extraordinary difficulty in customising or extending exsiting FX components… I think I’m just going to forget about it.

Cas :slight_smile:

Why do Java GUI libraries all die a slow and painful death, alone in the dark?

Well, Swing didn’t die… it’s still pretty bloody good, but you know, for ordinary desktop applications… not so much for fancy things.

Cas :slight_smile: