Yes, but you saved 20MB because the ImageIcons were simply wrapping the BufferedImages, so naturally there was more stuff in memory with a list of ImageIcons. The actual RAM used by BufferedImages was the same. If you cannot cut down your image size or resolution, you'll probably have to find an Image implementation that is more space efficient than BufferedImage (which I believe typically is just uncompressed RGB data). See this StackOverflow post for a discussion about this very problem and possibly some ideas for minimizing your memory requirements.

IMO you should not attempt to stream a movie for an intro. Especially not in Java2D.

Instead I would create a "modular" animation, made up of shapes and images. You can use something like Flash or Inkscape to create the animation. You can probably find some Java2D SVG parsers on the web, or you can create your own framework if your animation is relatively simple. This might not be exactly the look you're going for, but it's a much more realistic option.

And of course, as everybody else is saying, if you want to do something like this you should be using OpenGL. Even just storing downsampled and compressed textures on the GPU might be enough to solve your problem.

The only optimisations so far have been cutting off parts of the image, and removing the overhead of an ArrayList.

There is no way to compress the images in memory. You have to find a way to cut down on the amount of images (or at least full images) required.

That is the only solution.

As for a different kind of list. Why a list? Use a BufferedImage[].

Well thanks for that.Now that I'm actually calculating how long each Image takes to load.Implementing 'BufferedImage[]' instead of the List resulted in lowering the elapsed time took to load all 123 Images by about 5 - 7 seconds.

@BoBear2681:Thanks, I realized that the ImageIcon had something to do with the BufferedImage when the 'Java Heap Space' error occured.Could see in the stack trace that the ImageIcon was polling BufferedImage methods.Creating DirectColorModel, DataBufferInt etc, thanks

How about making the images very small and up-scaling them with nearest-neighbour filtering. Choose an art style that works well with nearest neighbour filtering. And reduce the image size by avoiding repeating areas like a starry background (which should instead be static).

Did you look at the code behind that link? Nothing says your stream has to come from a website, it could come from a file. The point is that finding a way to have all your images loading on the fly from a single file (as JPEGs) should be fast enough and get rid of your memory issue.

How about making the images very small and up-scaling them with nearest-neighbour filtering. Choose an art style that works well with nearest neighbour filtering. And reduce the image size by avoiding repeating areas like a starry background (which should instead be static).

I like that Idea Thanks mate

I've only messed around with MagFilter's in JMonkeyEngine, so I'd have to look into 'Nearest-Neighbour Filtering' with Images in Java2D.I do remember that when switching to MagFilter.NEAREST, it would result in major pixelation D: (MineCraft status textures)

EDIT:About the Art Style..

All of the 123 frames (Images) were captured with a Screen-Recorder I programmed in Java.Don't think I could really modify the art style of a video that was 'pre-recorded' can I?

Why is this recorded video so important to your game? Why don't you just re-do the intro using programatically animated sprites and shapes? It will probably look better; more original, and less "this is ripped off a crappy quality YouTube video."

Why is this recorded video so important to your game? Why don't you just re-do the intro using programatically animated sprites and shapes? It will probably look better; more original, and less "this is ripped off a crappy quality YouTube video."

It all goes with the music for the game trust me.(Personally I think the Quality of them are fine, even while animated)

Main Menu: (In Controls Menu, yes the background's animated)

Projects have motives lol. I started messing around in my IDE one day, wanted to make a 'Screen Recorder'.Than I wanted to create a 'Movie Shuffler' to see how the playback was.From there it turned out nice enough for me to want to actually implement a little Game + Menu into it.Now here we are

IMHO it looks cheap and inconsistent with the GUI, and will undoubtedly look inconsistent with the game sprites... but whatever floats your boat.

(Too bad spoilers don't work here T_T)

That is why my game has a 'Theme'...Cheap and inconsistent?, this is a 2 day old project O.O, only 'Sprites' implemented so far are in the main menu (Just the Animated Background), everything else I.E the Menu / Buttons are Round Rectangles for now.

lolz mate, 100FPS steady, no lag spikes, 1,500+ projectiles.Only problem at the moment is the memory issue with these frames, I'll take Sprite/Menu criticism later when I decide to post this in WIP for some feedback.

Completely change your idea of the format, and use a system which contains whole images where neccessary, and when there are chunks of pixels that stay the same, have some code which only replaces the parts of the image that change (like using g.drawImage() on the original image). This will require a new file format, lots of designing, and some nasty coding work, but at least it will be reliable if you get it right, and it will cut down the size massively

At the risk of putting too fine a point on it, that's basically writing your own video codec. It might be reliable if you get it right, but unless you've got a lot of experience in signal processing, you're not going to get it right the first time, or even the several dozenth.

This is an area where flash just dumps all over java. Maybe try javafx instead?

Completely change your idea of the format, and use a system which contains whole images where neccessary, and when there are chunks of pixels that stay the same, have some code which only replaces the parts of the image that change (like using g.drawImage() on the original image). This will require a new file format, lots of designing, and some nasty coding work, but at least it will be reliable if you get it right, and it will cut down the size massively

At the risk of putting too fine a point on it, that's basically writing your own video codec. It might be reliable if you get it right, but unless you've got a lot of experience in signal processing, you're not going to get it right the first time, or even the several dozenth.

This is an area where flash just dumps all over java. Maybe try javafx instead?

Exactly. And because the OP doesn't want to do streaming, this is the only other way to reduce RAM usage without losing data.

For programming in general:

If something doesn't work no matter how you code it, cheat. 99.9999% of your users won't know what you did, so who cares? And if all else fails, cut it out of the project.

If you struggle with that, try finishing the next Ludum Dare. It's good practice.

@OP: You will need to change something about your original plan if this is going to work. You can't make a wheel from water (unless you use ice, but that will melt unless you live in a cold place)

You don't need a fragment shader for a textures. Use glTexture2D() and supply texture coordinates in some way. (Depends on your rendering method)(Make sure you call glEnable(GL_TEXTURE_2D) before or it won't work)

Have a look at these resources: (you will have to Google them)

Coke and Code tutorialsLwjgl wiki

And davedes has some good tutorials on 2D lwjgl rendering. I think the link is in his signature.

If it seems a bit hard, try just using immediate mode. You can always learn the better practices (like VBOs) later.

You only need to call glEnable(GL_TEXTURE_2D) at the start of the program or if you disable textures and want to enable them again.

Lwjgl (and opengl) are state-based, so whenever you call a function, the data you set will remain that way until you call another function which changes that data.

You only need to push/pop the matrix if you need to store the current matrix for later use. It's probably good practice to call glLoadIdentity() (which resets the matrix) at the start of each frame to make sure the matrix doesn't get corrupted. (If you translate the matrix every frame without resetting it you end up with a mess)

The best way to answer your question is to see what happens without pushing/popping the matrix.

You can set nearest neighbor in java2d using rendering hints...it is what I said before. Try reading about the stuff your are using. 1,500+ projectiles is nothing. Using basic glBegin glEnd will yield close to 10x performance depending on the computer.

Switching to opengl will not solve his memory problems unless java2d is bloating everything up a whole lot. Let me just reiterate your options.

1. Stream an actual video of the animation in which case opengl will help a lot. 2. Do some hacky way of loading and freeing but I really don't think it will work much.4. Reduce the size by 50% and using rendering hints to increase quality of scaling. 5. Drop the crazy method of doing this. If you look around I have posted a bajillion menus screen demos which don't look to bad and are very dynamic. They also do not use more then 1 gig of ram.

Libraries like LibGDX exist so that you don't need to deal with OpenGL boilerplate.

I've been writing my own series that covers various LWJGL and LibGDX topics.

Some articles you might find useful:Textures - Explains how textures work in detail. This is basically how LibGDX's Texture class works under the hood.Sprite Batch - Intro to sprite batchers.Shaders - a series on GLSL and shaders. More useful for LWJGL devs, or those looking to get extra power/performance out of LibGDX.

The truth is, you don't need to know any of the "low level" stuff (like glTexImage2D, or GLSL) if you are using LibGDX. It's a flexible API with a lot of high level utilities; see the following example to get an idea of how easy it is to manipulate textures, play sounds, and handle input:http://www.java-gaming.org/?action=pastebin&id=358

Keep in mind, even if you do use OpenGL and hardware acceleration (be it LibGDX or LWJGL), you will still have the issue of decoding hundreds of PNG files, and uploading them to the GPU at a steady frame rate. Like we have all been saying, you are going about this the wrong way...

P.S. Don't expect to find a media player in LWJGL that will be easy for a newbie to drag and drop into their project. If you really need media playback, and you are new to OpenGL, you'd have a much easier time using Unity3D or another platform.

Actually, both YUNPM and the GStreamer code bring the data into Java before pushing it to OpenGL, therefore there's nothing stopping you displaying that through Java2D - this is exactly how the software pipeline in Praxis works. This screencast happens to be using Java2D (with a webcam and file feed simultaneously).

I still say the OP should bother to Google for "ImageIO MJPEG" before trying with native libraries though - there's countless examples of image-only MJPEG playing. I used to use that approach with an IP camera (just an infinite MJPEG file!) about 6-7 years ago and it worked much better than what he's got now.

Praxis is Java2D ?Either I never knew and assumed it was OpenGL or suppressed my knowledge of that fact

It has a software renderer and an OpenGL renderer, though the software one is primarily custom (direct pixel manipulation) and uses Java2D as little as possible!

It just so happens that in that particular screencast, the rotation is being done by Java2D and all in software as it can't use any of Java2D's accelerated pipelines - it's pretty smooth - thought it was a good example of not assuming Java2D is that slow!

Incidentally, the reason that example is in software is that Praxis is currently limited to one renderer at a time, and the OpenGL one can only run one window at a time - two are needed for the blob tracking, which is software anyway. It's a limitation that I'll be getting rid of shortly.

Textures are stored in VRAM, and that loader expands textures to powers of two. That means your textures will be stored as 2048x1024 textures, most likely in RGBA format. Wrote your own loader and store them in just RGB. Just be sure to not save the images once you're done with them.

...really? No one said that they would magically make everything work. Also, you may not have been doing everything right so... Good luck with java2d.

I've messed with LWJGL before, know how to construct a basic setup / switch between 2D / 3D drawing on the fly.My setup's fine, the only thing I'd assume I'm not doing right is how I'm drawing, pretty sure there's a more 'intermediate' way

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