Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (513)
Games in Android Showcase (121)
games submitted by our members
Games in WIP (577)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  1.1 performance renderer  (Read 2947 times)
0 Members and 1 Guest are viewing this topic.
Offline Lavahead

Junior Newbie




Java games keep me employed!


« Posted 2003-02-25 00:38:23 »

Hey guys,
 I'm trying to write a high-performance Java 1.1 renderer for a 2d game and am having some frustrations.  Things run okay, but I'm convinced there are more efficient ways to push image data around within Java.
Here's what the renderer does:

DirectColorModel cm = new DirectColorModel(24,0x00ff0000,0x0000ff00,0x000000ff);
mis = new MemoryImageSource(m_width, m_height, cm, m_pixels, 0, m_width);
mis.setAnimated(true);
m_image = GetAppInstance().createImage(mis);

Then, for every frame, the renderer writes to the m_pixels int array, calls mis.newPixels() and repaint()s.  When Applet.paint() is called, it does a g.drawImage(mis, 0, 0, null).

The problem is that, in 550x400 at 25 fps, the newPixels() call takes 1/3 of a frame, and the drawImage() takes about 1/2.  This only leaves a 1/6 of a frame for the game to do its real work.  Does anyone know if this is normal?  Is it possible to combine these two calls?  This is a painful overhead.
 Thanks for your help.
Offline Lavahead

Junior Newbie




Java games keep me employed!


« Reply #1 - Posted 2003-02-25 00:53:12 »

Argh...
 Maybe it would help if I was more specific, eh?
-no important code is taking place in synchronized() or try/catch blocks
-most of this code is running in a separate thread from the browser
-full window updates (all 550x400 pixels) are, unfortunately, necessary

Here's a speed breakdown.  In a 40 ms frame:
14 ms - newPixels()
17 ms - drawImage()
8 ms - renderer fooling around with the int[] m_pixels

This leaves a sad 1 ms/frame for other game code.  Is it possible I'm hitting a bus bandwidth limitation?  I'm at a loss for further ideas.  Any expert advice is most welcome.
Offline alexz

Senior Newbie




Java games rock!


« Reply #2 - Posted 2003-02-25 06:24:07 »

On my machine (PIII 600 MHz, 256 RAM) simple filling the pixels array then displaying the 550x400 image (MemoryImageSource, etc.) in applet (within MS IE 6) take:
~28 FPS for MS Java
~11 FPS for Sun Java 1.4.1

I think that this is the AWT 1.1 limitation... not the bandwidth one...  Sad
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Woz

Senior Newbie




A Troll who lives in a hole


« Reply #3 - Posted 2003-02-25 10:09:54 »

This is perfectly normal I'm afraid.

You should try using a 32 bit colour model though with:
1  
dcmModel = new DirectColorModel(32, 0xff0000, 0xff00, 0xff);


Using a desktop colour depth of 16bits will also speed this up considerably.

Although at the end of the day the PIII just falls over - best solution for this is to get an Athlon!

You should also try using a BufferedImage, this will speed it up to the point of a redraw being a non-issue, especially in Java 1.4.1 as MemoryImageSource has been sidelined (since 1.2.1 I believe) and has steadily been getting slower and more buggie (I wont use 1.4.1 until it's fixed).

So slow in fact that MS 1.1.4 JVM can usually beat it (but there in lies a riddle, with an interesting answer).

Interestingly it is still quicker to use a 32bit colour BufferedImage when using a 16bit colour desktop, especially for IBM's 1.3 JVM.

-----
Woz.
Offline erikd

JGO Ninja


Medals: 16
Projects: 4
Exp: 14 years


Maximumisness


« Reply #4 - Posted 2003-02-26 07:32:17 »

You can also get better results by not using MemoryImageSource, but by writing your own ImageProducer class (MIS is an ImageProducer implementing class).
The mis.newPixels() slows things down.
For an example, go to jef.sourceforge.net, dl the source and look at jef.video.GfxProducer. It's fairly easy.

But.... rendering in pre-1.4 will never be really fast.

Offline alexz

Senior Newbie




Java games rock!


« Reply #5 - Posted 2003-02-26 08:29:40 »

I've just looked in my code (the old one) and found that actually my timing above was made with my class implementing ImageProducer interface... not MemoryImageSource...  Tongue
Offline NielsJ

Senior Newbie




Java games rock!


« Reply #6 - Posted 2003-02-27 09:13:05 »

Thank you, thank you, thank you...  Cheesy

I've been using MemoryImageSource since forever - never bothered implementing my own ImageProducer since I figured the default implementation was so simple that there could hardly be any perfomance gains in messing with it.

How wrong I was.

And what's MUCH more important: it made me realize that I could blit my circular buffers in a single blit by wrapping data in the imageproducer rather than when blitting -> much faster and no shearing artifacts.

Thank you... In 30 minutes work I doubled my potential framerate. Why the f*ck is stuff like this not in the official documentation from Sun? Or in a tutorial? No wonder people think Java is slow........

Same thing with the color model issue - hardly documented, yet choosing the wrong model can chop your framerate in half with no warnings or indications of problems what-so-ever.

The Java gaming community needs a list of do's and dont's with respect to the performance of std. core java libraries (eg. JavaSound)...
Offline Woz

Senior Newbie




A Troll who lives in a hole


« Reply #7 - Posted 2003-02-27 13:53:41 »

Thats because Sun is crap! Lips Sealed Tongue Lips Sealed

That even the idea of providing decent documentation is beyond them.

A MemoryImageSource is a ImageProducer anyway, so there is (usually) little if no difference between performance.

The big kill is the 32 bit colour model over the crappy 24 bit colour model - this makes a massive difference.

But I do hope you are implementing a BufferedImage for Java 2 folk as this much faster than an ImageProducer.

The best thing most Java developers can do is ignore those near useless JavaDocs and go straight for the source code, you will learn more about how java works. Although there are plenty of unreference static attributes - what they are for can sometimes be a mistery!

Don't even get me started on Java Sound, it does work - just! - if you stay with certain parameters. Always use 44.1Khz Stereo 16bit sound as it may not work right if you don't. (Problems with different sound card et al.)

I was under the impression that they had got someone in to fix it, but that was ages ago and still it has the worst latency I have ever seen.

------
Woz.

P.S.
Does this class as trolling? Pitty on the old board they would have thrown me in the troll bin!
Offline NielsJ

Senior Newbie




Java games rock!


« Reply #8 - Posted 2003-02-27 18:24:40 »

A little harsh maybe - Sun did create a wonderful (free) language and software platform in Java and its VM Wink. I do agree though, that their core APIs are mysteriously inefficient compared to the platform itself.

I think it's odd how MemoryImageSource can be so much less efficient than my own implementation - try calling newPixels twice on a MemoryImageSource. BAD idea, yet, in my own class I update several smaller chunks and it doesn't seem to have any impact at all.

I guess the conclusion is that there's no point in EVER using MemoryImageSource.

As for buffered Images - I doubt if I will have much to gain as I rely heavily on pixel-operations and have multiple gfx layers added/blended and multiplied together (extensive framebuffer access both read and write) - I assume the speed improvement with buffered images comes from storing data in vmem, no?
Offline Lavahead

Junior Newbie




Java games keep me employed!


« Reply #9 - Posted 2003-03-10 17:43:24 »

Hey guys,
 Thanks for the help.  The ImageProducer wasn't that hard to implement (thanks NielsJ and erikd), and is buying me about a 20% speed increase.  That could be because it's allowing me to draw 20% fewer unnecessary pixels.  Regardless, it's good to see these gains.
 Lavahead
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline oNyx

JGO Coder


Medals: 2


pixels! :x


« Reply #10 - Posted 2003-03-10 21:31:53 »

http://sourceforge.net/projects/jef/

the other url is somewhat empty right now :>

弾幕 ☆ @mahonnaiseblog
Offline erikd

JGO Ninja


Medals: 16
Projects: 4
Exp: 14 years


Maximumisness


« Reply #11 - Posted 2003-03-11 06:08:57 »

Quote
the other url is somewhat empty right now :>


Oops   Tongue

Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

theagentd (20 views)
2014-10-25 15:46:29

Longarmx (53 views)
2014-10-17 03:59:02

Norakomi (47 views)
2014-10-16 15:22:06

Norakomi (35 views)
2014-10-16 15:20:20

lcass (39 views)
2014-10-15 16:18:58

TehJavaDev (70 views)
2014-10-14 00:39:48

TehJavaDev (69 views)
2014-10-14 00:35:47

TehJavaDev (61 views)
2014-10-14 00:32:37

BurntPizza (74 views)
2014-10-11 23:24:42

BurntPizza (47 views)
2014-10-11 23:10:45
Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06
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
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!