Hi, I'm making a game kind of similar to World of Sand (http://www.onemorelevel.com/worldofsand.php) where all the objects will be particles the size of a pixel, so I plan on rendering it pixel by pixel. The problem I'm running into is right now without anything moving and in a 640x480 window I'm getting 50fps tops (with a pretty fast processor) and I know that things will slow down a lot once I start adding physics. Here's a snippet of my current rendering code which should give a reasonable idea about what I'm doing: http://pastebin.com/f21628542 At the moment I'm using Java, though if I could significantly speed things up by switching to C++ then that's possible, though I would prefer to stay with Java though. Anyways, I'm pretty sure I've narrowed down the slowness to setRGB, but I'm not sure what would be better to use. I can certainly get all the pixel data as an array first if there's a way to set all of the pixels at once from one (I think this is possible using getRaster). Also, is there any way I can offload some of this to the graphics card? I feel like there should be a really fast way to do this since I'm determining what all the pixels should be myself and the computer just has to display them. Anyways, any help would be appreciated, I really need to get this much faster since I think the physics I hope to implement are going to be rather CPU-intensive.

Yes, you should offload all of it to the gpu. You can use point rendering so that each vertex = 1 pixel, but you should draw them all (or as many as possible) as one batch.

I understand that I should be doing that, but can you give me any direction as to how? What's the best way to access the graphics card in Java? Will the built-in Java2D stuff work, do I need to use JOGL or some other OpenGL binding?

Don't know, have never done graphics stuff with Java, but if there are Direct3D or OpenGL bindings for Java, that sounds like a good direction to take

Not the fastest, but certainly quick and dead simple, GDI has the CreateDIBSection() function that you can use to work with individual pixels.

You get a pointer to the data, making changes is fast and simple. 640x480 will be a cakewalk.

i would try have a precreated array of pixels which is what you actually work on and you render with that instead of setting one pixel at a time

might want to look into this function

g.drawRGB(int[] rgbData, int offset, int scanlength, int x, int y, int width, int height, boolean processAlpha)

Another option if that doesn't work is creating a mutable image from an array of pixels ( just like before ) and drawing that image

http://java.sun.com/j2se/1.4.2/docs/api/java/awt/image/MemoryImageSource.html

Remaining cross-platform is a must so GDI is out.
drawRGB looks like that's only in java for micro devices like cellphones so that's out, MemoryImageSource doesn't look bad though, however it seemed simpler to set up a raster once I found a nice code sample at http://www.exampledepot.com/egs/java.awt.image/Mandelbrot2.html?l=rel . My new code is now:
http://pastebin.com/f31e1b4ff
Where generateColorModel generates a an IndexColorModel which has all 3 colors my game is currently using.
While this certainly works at 640x480 all the way up to 100fps on my computer, I'm wondering if there's not some hardware acceleration I can incorporate to get it even faster. If possible I'd like to be able to run this at 1280x960 while maintaining at least 50fps. I'll start tweaking my benchmarking code to see which part is taking the longest, but any suggestions as how to better incorporate my graphics card are certainly welcome.
Also, thanks to everyone who's contributed thus far.

Alright, benchmarking shows the only significant amount of is spent on making the pixel array. It's taking on average 7ms to create it on 640x480. Isn't that quite a bit?
I think most of it has to do with requesting data from the particles array. It drops down to 1ms or less if I just pretend that every pixel is black. I think the slowdown might be due to particles being shared between threads (my physics thread will act on it and my rendering thread just renders it). I'll try cloning the array before I start working on it.

Even copying the entire array of particles to a new local particles array still takes just as long to read from. Any ideas as to how to speed this up?

if that code is happening each frame, your doing far too much

first of all,
byte[] pixels = new byte[width * height];
should be created once and reused

can you avoid doing all that junk at the bottom of the code
and just use the MemoryImageSource technique?

as for the double for loop with the switch in it [ahhh!]
you can at least get rid of the switch be having the particle know what color it is ahead of time [ more memory but you can get rid of the switch ]

Also the probably best solution would be getting rid of the double for loop copy code entirely by making the particle update code directly edit the pixel array as they move around

at least that's what i'd try