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

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.

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

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?

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.

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.

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

Quote

The problem we have is that people don't want to install anything.

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

Got a question about Java and game programming? Just new to the Java Game Development Community? Try my FAQ. Its likely you'll learn something!

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

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.

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

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.

This kind of backtracking's not going to do you or your customers any good in the long term :/ 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.

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.

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.

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.

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.

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.

This simple observation separates a hobbyist from a professional I would say.

We don't like the backtracking, but the commercial reality is we need to target > 50% of users.

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.

Got a question about Java and game programming? Just new to the Java Game Development Community? Try my FAQ. Its likely you'll learn something!

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!

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

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!

We are using -target 1.1 on javac, we need that to get it to run under 1.1.It seems to be some issue with 1.3 where it cannot download the jar file properly, while 1.1 & 1.4 seem to work fine. We have tested with Sun 1.3 VM and had the same error with our unobfuscated one as well.In short, I have no idea why 1.3 wiould fail when 1.1 & 1.4 seem to work fine :/

I saw a few prints in the java console that showed it was running some code... but then nothing appeared where the applet was supposed to be. There may have been a message about a recursive repaint call.. I noticed it after so I'm not 100% sure it was your applet.

Macs : We've had PowerMac's succesfully run the games (at least thats what the agent said in the server logs) so it works on some Macs now. Unfortunately we dont have any Macs, & Ive never used one, so its kinda hard to debug

Opera: Again, no idea, but Opera really hates us using an iframe to put the applet in. Most other browsers work so its Operas fault for being non-standard, or as they put it 'more standard than others' :-/ thats my excuse & Im sticking to it

Both the error and the stacktrace indicate that Opera has nothing to do with the problem. Both the error and the stacktrace indicate that your obfuscator has everything to do with it. The error is being thrown by a standard JVM in a standard situation. No other applets throw this exception. Ergo, you're doing something nonstandard and it's broken it. Would you perhaps care to upload a non-obfuscated version?

We have found the problem - all we need now is the solution.The issue is due to a PHP script that is called 'tj.jar', and this is what the games page references.this checks the session cookie is valid, then sets up a session variable allowing access to the resources, then sends the real jar file to the client with a HTTP header of type 'octet-stream'. If we replace this with the real jar file, it works ok with Opera and JRE 1.3.We have tried setting the content type to be 'application/x-java-archive', but this doesn't seem to help Anyone know if we need to be sending anything else in the headers?

We have found the problem - all we need now is the solution.The issue is due to a PHP script that is called 'tj.jar', and this is what the games page references.this checks the session cookie is valid, then sets up a session variable allowing access to the resources, then sends the real jar file to the client with a HTTP header of type 'octet-stream'. If we replace this with the real jar file, it works ok with Opera and JRE 1.3.We have tried setting the content type to be 'application/x-java-archive', but this doesn't seem to help Anyone know if we need to be sending anything else in the headers?

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