Java2D is the starting point of some people who want to get started with their first game. There is some discussion if this is the right way (because eventually everyone ends up with a more performant framework). But this thread is not to discuss this point.

Java2D was also the starting point for some of my projects (nothing final however ). During developing with Java2D you are bound to encounter some challenges which I resolved in some utility classes.

For people who want to get started with Java2D I want to share these utilities. It isn't by far a framework but I think it will get you started with Java2D. If you dare Included is a demo that shows most of the features in the utility classes. Switching display modes and full screen and manipulation of images.

The demo also has an API overhead feature so you can check the performance you can roughly expect from Java2D. And yes... other frameworks blow Java2D away in this area. I suspect this is mainly caused because Java2D doesn't have a sprite batch feature.

The API overhead feature has some limitations. If you have a fast CPU but a relative slow GPU the bottleneck will generally be the GPU. You can 'fix' this by using smaller sprites for the API overhead feature, but I think that you have to accept that API overhead is apparently not an issue in these cases. By the way, I only encountered this situation on a fast Broadwell NUC with integrated Intel HD graphics.

Last but not least. I tested the code only on Windows.

The executable jar-file with the demo can be found here.And here are the sources.

My original Java2D application that I want to convert to libGdx uses a different shear transformation for every drawed image. Using the SpriteBatch.setTransformMatrix is not an option because it will render the SpriteBatch useless (flushes each draw to the GPU).

I tought about extending the Sprite class or build a wrapper around it. Problem with this solution is that it can become implemetation dependent on the Sprite class real fast.

I noticed that the transformations of the Sprite class are a bit different from the Java2D implementation. For example: rotate in Java2D rotates default around the bottom left point of an image. Sprite rotates around the center of the image. Of course this can all be solved.

Making my own AffineTransform implementation has the benefit that the original code doesn't have to be rewritten much.

In the end it is a decision with both pro's and con's. Rewrite more parts of the original code or create an easy way to use libGdx for this application. In this case I choose not to rewrite big parts of the original code.

Fixed. I now use the standard Java AfineTransform to change the vertices. This makes converting my existing code (Java2D) much easier because AfineTransform is used there quite frequently. See the example code below.

Setting a shear transformation on the SpriteBatch is not an option for me. I have many sprites that are sheared different ways. This will (like you say) kill the SpriteBatch. I'am going to try manipulation the vertices. I will keep you posted.

To avoid flickering during the resize of my game window I'am using the sun.awt.noerasebackground property. This works oké for simple drawings. However when the drawing complexity increases so does the flickering! I have tried different things to get rid of the flickering but I'am running out of options.

By the way... I don't wan't to use Toolkit.getDefaultToolkit().setDynamicLayout(false). This eliminates flickering completely but makes it impossible to resize the drawing during a resize.

OS: Vista 64bit;JRE: build 1.6.0_26-b03

Because code says more than a thousand words see the example below. Use the static variable COMPLEXITY to increase the "complexity" of the drawing till the point the flickering starts.

Works on my system, but only when the bitdepth of the demo is the same as the bitdepth of my desktop! When I choose a different bitdepth than the bitdepth of my desktop the graphics are all "scrambled" (full screen mode).

Drawing an accelerated "gif" image into an Image with Transparency.BITMASK does not accelarate this Image.

The only ways that I have found to create an working accelerated image with 1-bit transparency is by creating an gif or png file with an 8-bit indexed palette in wich one color is specified as transparent.

I'am now using indexed png files as a workaround. What also could work is creating an BufferdImage of type TYPE_BYTE_INDEXED. I havend tried it yet but it seems to fit the patern.

I have been able to create 1-bit transparent accelerated images with gif's and 8-bit color indexed png files. Creating 1-bit transparent accelerated images with "Transparency.BITMASK" has failed however.

Anyway I want to be able to create images with at least a colordepth of 16-bit and with 1-bit transparency. Is it possible (and so yes. how?) to create 16-bit indexed images (png files) in wich one color represents transparency and are these images accelerated?

Second question: Has anyone a full working example of creating an 1-bit transparent accelerated image with "Transparency.BITMASK"?

It is true, that transparency doesn't work on VolatileImages. It is however possible to do hardware acceleration on images with 1bit transparency. This requires a "workaround" that I have read in another post. However I can't seem to get this working.

Quote

In answer to your first question, there is unfortunately no way to create a VolatileImage that is non-opaque (translucent or transparent). This is API that we should introduce in jdk1.5 (a ways off, but I just thought I'd mention it). The main idea behind the first VolatileImage API was to have the ability to force the back buffer to live in hardware. Back buffers are usually opaque, so this simple API did the trick. Now that that functionality is there, we can beef up the Volatile API to include other related operations/formats that people care about.

As to how you work around the issue, you should be able to use createCompatibleImage(w,h,transparent) for any background which will remain static. Say you have a scrolling starfield (or whatever); you can create this as a compatible image and simply copy from there into your Volatile back buffer. At some point (usually the second copy), we will recognize this as something that we can do better in hardware and we will create a VRAM version of that compatible image to use from then on. As long as you are not touching the pixels of the compatible image, we will continue to use the VRAM version of it and you will get native-hardware speeds.

Things to watch for: - DO NOT grab the Raster or DataBuffer for the compatible image. If you do this, we give up on accelerating that image because we cannot guarantee that our VRAM version matches the original image (because you can tweak the pixels directly without our knowing). We will probably introduce some sort of Lock/Unlock API for this in the future, but for now just avoid it if at all possible. - Accelerating compatible images only works for opaque and transparent images for now. We're working on translucency acceleration; this should be there in jdk1.5. - There can be problems with images larger than the screen size (we may not be able to create a VRAM image larger than that size), so if you need a background image larger than this, you'll have to tile it into several images.

For a game I have created an VolatileImage as a backbuffer. I have tried to blit transparent gif images to this backbuffer and this works ok. The sprite is accelerated. When I try to create my own transparent BufferedImage the sprite works, but is not accelerated. I know that it can be done. So what im I doing wrong.

Below is the part of the code that blits the sprite to the backbuffer. the gif image is accelerated, but my own Image is not accelerated.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org