17 replies to this topic

[snowmoon]

I have finished doning some rough testing of various drawing routings in respect to java direct screen rendering. These were on a pIII700, but I believe most of the routines are memory/bus limited more than anything else, and %80 of execution time was in native methods of either awt or java2d. Ok here are the results all results were from drawing 1200 32x32 tiles ( 4 layers ) on the 640x480 screen. This represents a total of 1,228,800 pixels per frame. Not too shabby. Old style offscreen image + opaque images 20fps@16bit 15fps@32bit MemoryImage 1 + copyarray 11fps@16bit 10fps@32bit MemoryImage 2 + copyarray 2.29fps@16bit 13fps@32bit BufferedImage + drawImage 55fps@16bit 30fps@32bit BufferedImage + copyarray 58fps@16bit 33fps@32bit Buffered + copyarray 16bit 300 tiles( 1 layer ) 142fps So as you can clearly see if you do any direct rendering of images your choice is clear, use BufferedImage. It looks to be 2.5-25x faster than the equivialint awt functions. There are drawbacks. It only runs under the java2d ( java1.1 with j2d or 1.2+ ). To get the best speed you have to write a handler for each DataBuffer type byte, short, unsigned short, and int. Well I''m going to get back to work, just though all you out there might be interested.

[snowmoon]

Not quite. When I say arraycopy I use ayyapcopy to blit raw short ot int data into the surface array. With the memory image source you then have to update the imageproducer to key the data update. Under buffered image you get an array into the buffer and you just update it.

If others would like to see the code just shout, if I get enough people I''ll write an article for gamedev. I''m also finishing the helper chlasses so I can do...

main() {
ForcedTimingLoop test = new ForcedTimingLoop( new Component );
test.drawResultsOverImage();
test.run();
}

[snowmoon]

Wow, interesting stuff. Naysayers will be caught off guard when jvm starts exceeding compiled languages in time to market and overall performace. I''m a little upset that they are only planning these enhancements for the win32 platform kinda negates the platform independance thing. I checked the early access area and 1.4 is still not availible yet.

The performace of BufferedImage is more than enough for what I''m trying to do, and with a nice wrapper interface I should be able to run transparently on java1.1 and java1.2+ platforms assuming they are fast enough. I did the math my drawing routines are pushing almost 200 MB/s not that bad for a language most people consider slow.

Now if they could only incude functional mulit-track audio mixing I would be set. Java Media 1.0 looks good I just need to sit down and play with it.

[snowmoon]

I''m not agains using native code to do things that java is incapable of doing like changin resolution. The program will run fine at 640x480 without native code to switch, but I would love to get scaling for free. I''m going to test these results on my wife''s Cele 450 to see if I''m correct in assuming it''s more memory bound than CPU bound.

Something that some other programs have used that may give almost free scaling is using the buffered image as the texture on a polygon that fills the screen. A little overkill, but it it gets me scaling for free on 3d accelerated platforms I''ll take it.

I''ve only been working on this for a few days now and have anready been able to signifigantly increase my speed, so just give me some more time.

[Smoo]

Ok since I''ve got .. well no experience with Java2d at all, I''m guessing that when you say oldstyle offscreen vs bufferedImage I''ll take it you mean awt and java2d?

And as anon said, if you could post a link to get the source (when you''re done of course ) that would be cool.

Smoo

[snowmoon]

Yes oldstyle = awt ( Image + MemoryImageSource )
BufferedImage = java2d ( getRaster().getData() )

I''ll clean up the 6 or so test cases I''ve developed as well as the component fps tester. If I get a chance I''ll also throw in at no additional my handy Debugging class that redirects stdout and stderr to a window at the bottom of the screen.

[JasonB]

Regarding ''oldstyle''/AWT methods, I''ve found that implementing ImageProducer is faster than using MemoryImageSource. I think by about 20%, but it''s been ages since I''ve actually done a direct comparison.

Don''t think it comes close to the fps rates you''re quoting for Java2d though. I''m impressed.

I came across some code (with source) to change the screen resolution (JNI link to a DLL). I can''t remember where I found it, but I''ll email it to anyone who wants it.

J.

PS. I''d be interested in seeing your code as well.

[GKW]

I believe I read that in JDK1.4 you will be able to change screen resolution in fullscreen mode.

I wanrned you! Didn''t I warn you?! That colored chalk was forged by Lucifer himself!

Opere Citato

[snowmoon]

I tried running the fastest test on my wife''s celeron 450 I was getting 35fps insted of 55fps @16bit. It does appear to be CPU bound, but still not shabby. Anyone know of a way to break this CPU bound drawing routines?

Anyone who would like a zip file of the sources e-mail me eric at snowmoon dot com ( figure it out ) the whole thing is 6.6k.

I''m going to give that ImageProducer trick a try to see if that can spped things up some. I have also found a much more accurate timer, it''s part of the JMF 2.1 the Time class has nanosecond accuracy so that should do just fine. It also have audio/video playback and audio mixing... hopfully this will be included in 1.4 along with some of the other things mentioned here.

Java''s really starting to kick ass.

[JasonB]

Check out http://www.gaffer.org and look for TinyPTC. He''s got the source there for about the fastest direct blit to screen that I''ve seen (AWT that is).

I''ve managed to tweak a few frames more per second out of it, but not by much.

[Smoo]

Hey JasonB, I downloaded TinyPTC to see what it was and I was just going through the code and something caught my attention. Perhaps you (or anyone else) might be able to illuminate me on this since I''ve never used ImageProducer before.

The only time in the actual code where values are being assigned to the _image var is when it''s created:

_image = Toolkit.getDefaultToolkit().createImage(this);

what I don''t understand is when it where is _image updated since nowhere in the code is it linked to the ImageConsumer so could you (or anyone else who''s seen the code or knows what I''m talking about) explain to me how it gets updated?

My only explanation of this is in the createImage(this) where the this is a pointer to the ImageProducer in which case when the ImageConsumer var is updated, the image is also.

I''m not sure if I made sense there or not... I''m hoping you have a better explanation than the one I came up with.

Thanks,
Smoo

[snowmoon]

createImage(this)

creates the image with the timePTC class as it''s image producer. If you then look through the update(Object pixels) function. Update calls the necessary ImageConsumer functions to update the image and then calls paint() to put it on the screen.

It''s horrible code, because it changes update''s signature ( normally used by awt ). It attempts to pile so much into this one class you loose sight of what happening. I could be wrong, but run() calls Main(_with,_height), but the example file has it''s function declared main this will not work.

hmm.. still interesting tho.

[Aldacron]

Java Game Programming for Dummies has an excellent little class that implements ImageProducer (I believe they called it DirectImage). By doing it that way you have all sorts of options for creating images. Use one as your back buffer, load in bmps, tgas,pcxs, whatever. And it is fast. I haven''t toyed with it for a while, but I think I''ll pull out my old code and dust it off.

[Smoo]

Thanks for your post snowmoon, it helped

as for the Main(_height, _width) line, true it doesn''t work. Main should have been lowercase.

Smoo

[JasonB]

Hi Guys

Thanks for your code, snowmoon. I''ve done some tests and here''s what I''ve found. Note the figures are average frames per second running in a 640x480 window.
The test programs blitTest1-6 are code provided by snowmoon. tinyptc is the code taken (and fixed) from gaffer.org. blitTest7 is snowmoon''s fastest code, modified to display the same test pattern as tinyptc.

On my work computer (which is a dual-processor P800 with 350Mb RAM):

blitTest1 20fps
blitTest2 18
blitTest3 11 (color model appears not to work)
blitTest5 32
blitTest6 55

tinyptc 40
blitTest7 (RGB cm) 55

On my laptop at home, which is a gungy P266 with 64Mb of RAM:

blitTest1 6fps
blitTest2 0.5
blitTest3 2
blitTest5 (won''t run - 32bit color not supported)
blitTest6 12

tinyptc 8
blitTest7 8


It''s interesting to note the difference between tinyptc and blitTest7 on the faster machine.

The difference between tinyptc and blitTest7 is that tinyptc implements ImageProducer to deliver the content, whereas blitTest7 uses a BufferedImage. The loop to generate a static test pattern (ala tinyptc) is exactly the same.

J.