• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.

Archived

This topic is now archived and is closed to further replies.

snowmoon

[java] Direct rendering speed results ( awt vs java2d )

17 posts in this topic

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.
0

Share this post


Link to post
Share on other sites
Interesting numbers. It would be greatly appreciated if you could post the code for your tests somewhere and drop a link to it here. What exactely do you mean by BufferedImage + copyarray, do you just copy your tiles using arracopy into the databuffer and then draw the image with drawimage?

Henry
0

Share this post


Link to post
Share on other sites
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();
}
0

Share this post


Link to post
Share on other sites
Ok, thanks, that was what I meant too. You copy the data of the tiles using arracopy into the array that you get from the DataBuffer of the BufferedImage, but you still use drawImage in your paint method to draw the BufferedImage to screen.

Btw, read in the Java2D FAQ that jdk1.4 will feature a new hardware accelerated rendering technique:

http://www.javasoft.com/products/java-media/2D/forDevelopers/java2dfaq.html#accel

Henry
0

Share this post


Link to post
Share on other sites
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.

0

Share this post


Link to post
Share on other sites
Well, since the VolatileImage interface will be available in all implementations of the JDK, I am assuming that they will use it to enhance the rendering speed on Linux and other platforms too. IBM might do it for Linux if Sun ignores that platform.

I am not entirely satisfied with the speeds that you present though. First off, you ran the tests on a very fast computer (wonder what kind of rates I''ll get on my ol'' PII 450). Second, since you can not change the screen resolution from Java you will either require some native code that changes the resolution to 640*480 or your image will be tiny (most people use 800*600 or 1024*768). If you do not want to have native code to change the resolution of the screen and choose to draw a larger image instead, your framerates will probably be divided by approx 2-4 (you will just be able to draw 1 or 2 layers instead of 4).

The combination of a slower processor and being forced to draw a 1024*768 image can lower your numbers a lot. Then the fact that one wants to do AI calculations, play music, handle input etc., all while drawing makes me realize how much I really want that accelerated image interface

Henry
0

Share this post


Link to post
Share on other sites
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.
0

Share this post


Link to post
Share on other sites
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
0

Share this post


Link to post
Share on other sites
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.
0

Share this post


Link to post
Share on other sites
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.
0

Share this post


Link to post
Share on other sites
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
0

Share this post


Link to post
Share on other sites
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.
0

Share this post


Link to post
Share on other sites
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.
0

Share this post


Link to post
Share on other sites
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
0

Share this post


Link to post
Share on other sites
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.
0

Share this post


Link to post
Share on other sites
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.
0

Share this post


Link to post
Share on other sites
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
0

Share this post


Link to post
Share on other sites
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.
0

Share this post


Link to post
Share on other sites