Converting from 1.4 to 1.1...

Performance Tuning
#1

After a week of people playing our games (see Your Games Here thread) we’ve decided that we have to recode the games in Java 1.1. We have a rate of games accessed/games player of 4/1. That’s 75% of visitors don’t bother to update Java or have some other problem & don’t play the game :frowning:

Most of the conversion is Ok, but we now find that the speed of the graphics is terrible. We’re down to 4/5 fps on our test machine using the default Microsoft VM.
Ive looked through the threads, and have a couple of clues, so here is my questions:

In Java 1.1, what is the best way to create/process images so they will render Ok. Its slow on a 32bit screen, but a 16bit screen is even worse. I suspect it is having to convert all the GFX when it draws them to the offscreen image buffer we’re now using. Would it help if we convert the images to the offscreen buffer format first? Is there any nice simple sample code to do this ???

In fact any help in getting the frame rate slightly more respectable would help.

On a side note, if we install the Sun Java 1.3 VM, the applet totally fails to load, but it works (really well) with 1.4.

Thanks for your time,

  • Dom
#2

Ok, stage 2:

On a 640x480 canvas, a single draw of a background image takes an average of 35ms (!!!)
Using my own buffer & draw functions, I can do the same in 4 ms.

However, at the end of rendering, I have to copy my buffer onto the main canvas again - and (you’ve guessed it) this takes around 35ms again!

No matter what I do to the colourmodel of the MemorySourceimage Im using, it takes 35ms to copty the screen over.

Does anyone know why this is so slow, & how I can speed it up?

Thanks,

  • Dom
#3

By the way… don’t assume all your failrues are 1.1 issues.

I just tried to run your traffic game with my JDK 1.4.1 OSX mac and it failed :frowning:

Have you considered going the Java Web Start route to deal with the JDK compatability issues instead?

#4

We don’t really want to use web start as we like having the embedded app, and don’t really want to have the jar downloadable yet. We are writing downloadable versions (in C++ & OpenGL) that won’t suffer from this problem. How would Web Start solve the compatability issues anyway? I thought it was just a way to package up the app.

The problem we have is that people don’t want to install anything. They want it to run straight in the browser, and it seems the only way to do this is use 1.1.

We do have some failures due to session cookies (Opera doesn’t pass the session info into the iframe, & the arcadepod link we have uses a frame that screws up our sessions) We can tell if this fails as they don’t try to access the jar if the session is invalid. Most users do access the jar, but then no requests come for the resources, so the jar hasn’t been run.

Besides, we have found that doing our own image routines is a lot faster, takes me back to the old days of sprite routines. Who ever guessed they would come in handy again…

  • Dom
#5

Hi CrystalsSquid,

I too failed to get either Bee Mania or Traffic Jam working.

That was using:
[]Mozilla 1.4.1browser[]IBM’s 1.3 JVM.[*]Windoze.

What are you using in 1.4.2 that’s stopping it working in the rest?

Obviously it would be very silly of me to say whether your games can be converted to 1.1 with any speed as I have been unable to run them so have no idea the number of sprites or weather the screen is moving etc. So here are some thoughts instead.

But I should not think you would have much problem getting them to work in 1.1 faster, but you will basically have to ignore all the AWT and write all your gfx routines which you’ve tried(?).

You also do not say what spec of machine you are using for 1.1, which makes quite a difference as the Athlon does not get slowed down anywhere nearly as much when it comes to redrawing that screen in IE compared to a PIII.

640 x480 is also pushing your luck under 1.1 in 32 bit colour, as the amount of bandwidth is massive and often causes the cache to be emptied.

So you could:
a) make the screen smaller.

b) break up the screen into smaller sections so that only the areas that need updating are. (for example the status panel could be a separate canvas entirely).

c) Stop using 32bit colour and use 8bit colour (for reasons unknown Sun decided not to include 16bit colour in 1.1, although it can be faked).

Use an ImageProducer instead of MemoryImageSource, although I shall admit I don’t think there is too much difference as a MIS is just another level of abstraction for an ImageProduce. I use a ImageProducer though.

Ultimately there is not much you can do about the time it takes to draw a 32 bit 640 x 480 MemoryImageSource to the screen, you just have to make everything else faster!

It may, however, be too much work to get running at the same speed as 1.4.2, as you have already finished. So perhaps it would be better to concentrate on getting them working under 1.3 and the Mac first.

Although I suppose you would be happy just to get 10fps instead of 5fps?:smiley:

Hope that helps a bit.

Woz.

#6

We’re using 1.4 BufferStrategy for double buffering, but when we replace this with drawing to an image, the speed on 1.1 is atrocious (4/5 fps on our 400MHz PII with a TNT 2, our desired min spec). It managed a fairly respectable 18-20 with 1.4.

The software rendering in 1.1 does appear to run faster when drawing transparencies, but slower when drawing non-transparencies. I’ve based the Image producer on the sample code from the other thread (Jef), and I think I have worked out what is going on.
It makes an image with the image producer as the source. This I believe sets the ImageConsumer pointer in the Image Producer.
After drawing all my sprites to a memory array, I then call the ImageProducer to render to the screen (doing my double buffering for me in a way).
I believe this then calls setPixels() on the image, then draws the image to the graphics object of the applet.
(If someone here knows what Im on about could they confirm that this is the case?)

Is there a way I can speed this part up at all? I could feasibly alter the RGB order of my memory buffer so the SetPixels would go faster, but i would prefer to write my pixels directly to the screen if possible instead of via an image, but I realise that may be asking too much.

Thanks for your feedback,

  • Dom
#7

[quote]We don’t really want to use web start as we like having the embedded app, and don’t really want to have the jar downloadable yet. We are writing downloadable versions (in C++ & OpenGL) that won’t suffer from this problem. How would Web Start solve the compatability issues anyway? I thought it was just a way to package up the app.
[/quote]
No, its much more. Its a complete configuration manager that includes the ability to specify necessary JDK versions and necessary extensions and download them if they are not present. It ALSO acts as a class cache and version control manager so you only dl any version of the game once but automatically downlaod any updates.

Its well worth looking at as long as you don’t need browser frame embedding. if you DO, well then your stuck with Plug-In or the browsers default VM. (Be aware the MSFT has threatened to remove MSVM entirely so you won’t be able to coutn on its availability too much longer…)

And yet they download Flash all the time. Unless you are talking a really really casual game whose game DL time is under a minute, I don’t but it, sorry. I think rather its a matter of the content being compelling enough to justify the DL.

Just IMO.

JK

#8

[quote]After a week of people playing our games (see Your Games Here thread) we’ve decided that we have to recode the games in Java 1.1. We have a rate of games accessed/games player of 4/1. That’s 75% of visitors don’t bother to update Java or have some other problem & don’t play the game :frowning:
[/quote]
Be very careful to solve the right problem. How do you know that 1.1 is the cause of the rejection? I’d suggest creating a new one outright that is 1.1 only from scratch (to the extent that the game-design works around your performance problems!) and monitor it for a few weeks.

Also, look very closely at how your audience over the past week differs from your expected ongoing audience.

E.g. if I go to look at a game from JGO, I’m much more likely to go to the page it’s on, discover it’s an applet, and immediately quit (too many applets crash Mozilla, or screw up X-Windows for my liking). If I’m just looking, as a developer, I may be happy just to glance at it, get a feel for how big the app(let) is, and then get back to work - without necessarily even bothering to play the game.

I’m not even remotely implying tht this is typicalbehaviour - just trying to show that marketing is a deep science which (like Physics ;)) is easy to gloss over and come to completely the wrong conclusions.

#9

Good points.
Reasons for suspecting 1.1:
Mainly, because 1500 have accessed the page, and only 400 have actually downloaded the jar files. We have a second jar on the same page that tracks the page open/close, and this was downloaded 950 times (it doesnt need 1.4). If you say no to the install, we get a load of the tracker, but not the main app. If you quit the page, we get neither. Of course there is a large amount of error, but the size of the problem (400 to 1500) surpasses the error margin (+/- 150). :frowning:

The audience was our main aidience - most links came from ArcadePod.

Our current plot is to write our own Image,Graphics,BufferStrategy and Applet classes that can detect the version of Java and create an appropriate 1.1 or 1.4 version dynamically. That way, if they have 1.4 it will be nice & fast, if not, it will be faster than the straight 1.1. :wink:

#10

This kind of backtracking’s not going to do you or your customers any good in the long term :confused: It’s like writing for OpenGL and then realising that 35% of your users don’t have OpenGL drivers and attempting to do a software renderer instead of addressing the real problem - getting users to have the machine specs you want them to have.

If you write for 1.1, where’s the incentive to ever upgrade? When will you ever be rid of the spectre of 1.1 if you continue to support it? The whole write-once-run-anywhere thing is a joke if you have to rewrite the whole damned thing just to make it work on what is basically a different bit of technology. You’re right back to square one! You should have written it in C++ and deployed it with ActiveX.

Cas :slight_smile:

#11

Dom,

The ImageProducer really only hands the image over to the ImageConsumer. SetPixels indicates which pixels have changed and should be draw. BUT the ImageConsumer.setHints() controls how they are received so its not as versatile as it could be as SINGLE_PASS is always used. A call to ImageConsumer.imageComplete() sends the image to the screen.

So the general process should be:


graphics.drawImage( image, 0, 0, width, height, null); 
consumer.setPixels( 0, 0, width, height, colourModel, pixels, 0, width );
consumer.imageComplete( ImageConsumer.SINGLEFRAMEDONE );

Be very careful you don’t end up with something that only works in Microsofts JVM, get hold of Netscape 4.7x if you can get it to run under both then chances are it will work under dreaded Mac OS 9, (there are a lot of iMacs out there still).

Take a glance at TinyPTC http://www.gaffer.org/tinyptc/ which has a correct ImageProducer/ImageConsumer model, although I have not used it plenty of people like it.

I will point out that the ImageConsumer model is much slower on Java 1.2 upwards and you should use BufferedImage instead, which should cover your 1.2 & 1.3 gap nicely.

Try using System.arrayCopy() to speed up your non-transparent images, as it is ints you are copying not bytes (so a 32 pixel linear transfer is actually 128 bytes which arraycopy does quicker than byte codes).

Changing the memory order of your pixel buffer is not really worth it UNLESS you know you are getting lots of cache misses (things like rotation, zoom, line drawing and texture mapping) this is because it takes longer for Java to decode your custom address structure than without. Both seem to cause address interlocks, because they are tight loops but loop unrolling is mainly a no no in Java.

All the best,

Woz.

#12

Thanks for the advice :slight_smile:

We don’t like the backtracking, but the commercial reality is we need to target > 50% of users. Our ‘hybrid’ system gives us the best of both worlds, and we will add big warnings if it detects 1.1 reccomending they should upgrade, so if they like the game then it should spur them on to actually upgrade. The problem now is people can’t evaluate the game and are unwilling to upgrade on the off chance the game will be what they are after.

Preliminary tests look very good, we have a frame rate of 12-17 fps on our 400MHz pII, which is a big improvement form the 4/5 we started with.

The TinyPTC is almost identical to the JEF one we have based our 1.1 code on, so thats another good sign we’ve got that bit right.

The memory order thing was just to see if we could speed up the image draw, as the color mode of the app seems to be (when looked at as an int) (b,g,r,a) wheras we are passing in (a,r,g,b). As all the rendering is done by my functions, it would be fairly easy to change, but I wonder if it will actually make much difference.

  • Dom
#13

[quote] The software rendering in 1.1 does appear to run faster when drawing transparencies, but slower when drawing non-transparencies. I’ve based the Image producer on the sample code from the other thread (Jef), and I think I have worked out what is going on.
[/quote]
can you post a link to the other thread you mention or give me a few more words to search on for the sample code you mention?

I assume from your post your testing on an older machine with the ms vm. This is the way to go because I’ve experienced erratic rendering using an mis in 1.4.2. I still don’t know if the sample I run would be more smooth on a msvm or not as I don’t have access to a ms vm with out totally screwing mozilla.

[quote] We don’t like the backtracking, but the commercial reality is we need to target > 50% of users.
[/quote]
This simple observation separates a hobbyist from a professional I would say.

#14

[quote]Thanks for the advice :slight_smile:

We don’t like the backtracking, but the commercial reality is we need to target > 50% of users.
[/quote]
The big issue here is whether or not you can get your users with crappy VMs to download good ones. If you can, then its a non-issue.

Being 1.4 based hasnt seemed to hurt AF much. OTOH its a “real” and complete game. People download many megs to get real game all the time.

If OTOH you are really targeting the embedded-web, casual gamer, then I’d agree you have an issue. Its really part of a much LARGER issue which is how long can you make a causal player wait after a click to play? The magic seems today to to be under a minute.

Now, this is all assuming dial-ups, which I think you need to assume today. Alot of gurus though are predicting the imminent fall of analog to univesal broadband. I don’t ncessarily agree, but some big players (noteably Microsoft) seem to be betting on it.

#15

BTW…

I think this combined strategy could actually be beneficial to the community if they have a big sign which reads “Game play slow? Try downloading the REAL VM!” :wink:

#16

nonnus29,

JEF stands for Java Emulation Frame Work and is a Source Forge project which can be located here:

https://sourceforge.net/projects/jef/

[quote]Many common emulator related problems are solved in JEF such as CPU emulation, graphics decoding and rendering etc.
[/quote]
It also handles sound, emulating various sound chips such as the AY8910 + others.

If you do a search in these forums you will find many-a-thread on it. :smiley:

Hey DOM any joy changing the a,r,g,b order?

Woz.

#17

Jeff’s dead right on two counts: compelling content will get people to upgrade, and telling people their computers are inferior is a great incentive to upgrade. Just showing them a short red bar with “your computer” and a long green bar with “java 1.4” above it will hugely increase the take up of a 1.4 VM.

I believe the compelling-content applet market is basically up a certain creek without a certain instrument, as a) the majority still don’t have BB and therefore any decent graphics and sounds you might want to compel them with are too expensive to include and b) rather like owning a CD people like to actually have a “thing” when they pay for something; in the case of games it’s a downloadable “thing” which they don’t have to be online to use. I don’t think I’ve ever heard of anyone paying for an applet. It might not be there when you surf back in a few days!

Cas :slight_smile:

#18

I have added a comment on the games page, pretty much as you suggested Jeff. Hopefully it will encourage some upgrades from the ArcadePod crowd. Its just we have a chicken & egg situation - they wont upgrade unless they know the content is good, and unless they upgrade they don’t know the content is good. :-/

Anyway, the new 1.1/1.4 hybrid version is going up on our website now. It doesnt appear to work with Java 1.3 (Bad Magic Number). We even tried without the JIT compiler in case it was moaning at the 1.4 specific stuff still in there (1.1 is OK as it never runs the code, so doesn’t try linking to the 1.4 classes).

I havent tried changing the RGB order, just trying to get this version on ASAP. In fact it runs faster using the 1.1 on my ATI Radeon 9800 than the 1.4 version, although on Simons GeForce4, the 1.4 is faster. Seems to be not hardware accelerated on mine. Anyway, Ill play with the RGB order and see if I can get any speedup from it, & Ill let you know,

Many thanks for all the support,

  • Dom

PS: If you like the games, can you vote on our forums, as they are looking very empty & unused :stuck_out_tongue:

PPS: The previous thread I mentioned was:
http://www.java-gaming.org/cgi-bin/JGNetForums/YaBB.cgi?board=Tuning;action=display;num=1046144303

#19

Update: Had to add p3p docs to the site to stop our session cookies being rejected (thanks again Mr Microsoft). Preliminary results are looking promising - 60-70% of attempts to run are succeeding. In the space of a few hours we have as many succesful runs of the game as we had all yesterday. Woohoo! ;D

-Dom

#20

Dom,

I think the reason why it is not working under 1.3 is that you are compiling the code using a 1.4 compiler.

Try using the -target switch on Javac.

The Javac doc is located here: http://java.sun.com/j2se/1.4.2/docs/tooldocs/windows/javac.html

I’m getting a java.lang.ClassFormatError in class am of Bee Mania.


Error unable to create jar cache in /tmp directory : java.util.zip.ZipException: error in opening zip file
Error unable to create jar cache in /tmp directory : java.util.zip.ZipException: error in opening zip file
java.lang.ClassFormatError: am (Bad magic number)
      at java.lang.ClassLoader.defineClass0(Native Method)
      at java.lang.ClassLoader.defineClass(ClassLoader.java:496)
      at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:117)
      at sun.applet.AppletClassLoader.findClass(AppletClassLoader.java:146)
      at sun.plugin.security.PluginClassLoader.findClass(Unknown Source)
      at java.lang.ClassLoader.loadClass(ClassLoader.java:325)
      at sun.applet.AppletClassLoader.loadClass(AppletClassLoader.java:112)
      at java.lang.ClassLoader.loadClass(ClassLoader.java:257)
      at sun.applet.AppletClassLoader.loadCode(AppletClassLoader.java:370)
      at sun.applet.AppletPanel.createApplet(AppletPanel.java:583)
      at sun.plugin.AppletViewer.createApplet(Unknown Source)
      at sun.applet.AppletPanel.runLoader(AppletPanel.java:519)
      at sun.applet.AppletPanel.run(AppletPanel.java:297)
      at java.lang.Thread.run(Thread.java:498)
Begin Stats

Using IBM’s 1.3 JVM.

Woz.

P.S.
There is also the possibility of your obfuscation process causing it.