Fastest graphic processing ?
And by the way, what would be now the fastest way to create an animation with images made from an array of pixels ? I mean, if I build a 640*480 game, and wish to have a nice frame rate, I need to be able to update all the pixels 30 times per second, so at maximum, the full update + display must not take more than 33 millisecs.
So how do you guys solve this ?
[374 byte] By [
taipan] at [2007-9-27 19:14:40]

write code that takes on average less than 33ms to execute :Palso, buying a faster pc helps - what more do you wanna know :D
Abuse at 2007-7-6 21:44:57 >

sorry 'bout that answer - it was late, I was in a bad mood :)
are you asking what kind of rendering loop is used?
most ppl use something like this.
Graphics bg = buffer.getGraphics(); //graphics context of backbuffer
Graphics fg = this.getGraphics(); //graphics context of Component
while(running)
{
envUpdate();
paint(bg);
fg.drawImage(buffer,0,0,null);
try
{
Thread.sleep(period);
}catch(Exception e){}
}
I use something like this...
boolean paintNeeded = false;
while(running)
{
if(System.currentTimeMillis() - environmentTime > PERIOD)
{
environmentTime+=PERIOD;
paintNeeded=true;
envUpdate();
}
else if(paintNeeded)
{
paintNeeded=false;
paint(bg);
fg.drawImage(buffer,0,0,null);
}
}
the 2nd loop is more processor intensive - but if your application/applet will be running on its own, it is preferable, because it offers consistent, accurate looping.
there is a 3rd alternative (2 Threads, using a wait(period)/notify() mechanism to control their timing - but, the overhead of swapping a Thread in/out every game cycle makes this method not so good)
Abuse at 2007-7-6 21:44:57 >

Try using full screen exclusive mode and BufferStrategy. This should allow you to sync to the refresh rate for smooth animation, and automate your back buffer (get the graphics from the buffer strategy, draw to that graphics object, then use the show method of buffer strategy to do page flipping or blitting).
Also, use GraphicsConfiguration.createCompatibleImage() for your images. It creates a hardware accelerated buffered image.
Id agree, its normally best to use BufferStategy. It simplifys alot.In java you definitly don't want to draw individual pixels, its much, much faster to draw full lines, rects,etc. Or turn it into a image and just draw that.Harley.
OK, thanks for the answer. But I know all about back buffers, drawing lines or polys etc etc. But the question is, suppose I have all the optimisations with a back buffer, that I redraw only the part of the visible area that actually changed, but suppose that, from time to time I have to redraw the whole screen, then what can I do ? It still takes more than 33 millisecs for that frame so from time to time, I will drop beghind !
> GraphicsConfiguration.createCompatibleImage() for your
> images. It creates a hardware accelerated buffered
> image.
GraphicsConfiguration.createCompatibleVolatileImage()
createCompatibleImage only creates an image of the same transparency, data layout and color model as the GraphicsConfiguration.
"The returned VolatileImage may have data that is stored optimally for the underlying graphics device and may therefore benefit from platform-specific rendering acceleration. "
mlk at 2007-7-6 21:44:57 >

> GraphicsConfiguration.createCompatibleVolatileImage()
> createCompatibleImage only creates an image of the
> same transparency, data layout and color model as the
> GraphicsConfiguration.
Well, that's all that's documented at least. But the reality is that you also get the image cached in VRAM, i.e. all the benefits of a VolatileImage, but Java handles the nasty stuff for you. Go to www.javagaming.org and do a search on "automatic images" to see more about what I am talking about.