Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (527)
Games in Android Showcase (127)
games submitted by our members
Games in WIP (594)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1] 2
  ignore  |  Print  
  Converting from 1.4 to 1.1...  (Read 3936 times)
0 Members and 1 Guest are viewing this topic.
Offline crystalsquid

Junior Devvie




... Boing ...


« Posted 2003-11-03 12:46:12 »

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 Sad

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 Huh

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
Offline crystalsquid

Junior Devvie




... Boing ...


« Reply #1 - Posted 2003-11-03 16:57:02 »

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
Offline Jeff

JGO Coder




Got any cats?


« Reply #2 - Posted 2003-11-03 19:52:32 »

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 Sad

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

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!

http://wiki.java.net/bin/view/Games/JeffFAQ
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline crystalsquid

Junior Devvie




... Boing ...


« Reply #3 - Posted 2003-11-04 08:43:48 »

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
Offline Woz

Senior Newbie




A Troll who lives in a hole


« Reply #4 - Posted 2003-11-04 10:35:14 »

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?Cheesy

Hope that helps a bit.
-------
Woz.
Offline crystalsquid

Junior Devvie




... Boing ...


« Reply #5 - Posted 2003-11-04 14:22:45 »

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
Offline Jeff

JGO Coder




Got any cats?


« Reply #6 - Posted 2003-11-04 15:39:24 »

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.


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!

http://wiki.java.net/bin/view/Games/JeffFAQ
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #7 - Posted 2003-11-04 16:57:15 »

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 Sad


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 Wink) is easy to gloss over and come to completely the wrong conclusions.

malloc will be first against the wall when the revolution comes...
Offline crystalsquid

Junior Devvie




... Boing ...


« Reply #8 - Posted 2003-11-04 18:39:21 »

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

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
Offline princec

« JGO Spiffy Duke »


Medals: 425
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #9 - Posted 2003-11-04 19:04:45 »

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.

Cas Smiley

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 #10 - Posted 2003-11-05 09:26:12 »

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:
1  
2  
3  
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.

Offline crystalsquid

Junior Devvie




... Boing ...


« Reply #11 - Posted 2003-11-05 11:08:01 »

Thanks for the advice  Smiley

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
Offline nonnus29

Senior Devvie




Giving Java a second chance after ludumdare fiasco


« Reply #12 - Posted 2003-11-06 00:05:00 »

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.


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

JGO Coder




Got any cats?


« Reply #13 - Posted 2003-11-06 02:51:14 »

Quote
Thanks for the advice  Smiley

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!

http://wiki.java.net/bin/view/Games/JeffFAQ
Offline Jeff

JGO Coder




Got any cats?


« Reply #14 - Posted 2003-11-06 02:53:49 »

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


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!

http://wiki.java.net/bin/view/Games/JeffFAQ
Offline Woz

Senior Newbie




A Troll who lives in a hole


« Reply #15 - Posted 2003-11-06 08:53:01 »

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.


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

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

------
Woz.
Offline princec

« JGO Spiffy Duke »


Medals: 425
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #16 - Posted 2003-11-06 09:01:34 »

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 Smiley

Offline crystalsquid

Junior Devvie




... Boing ...


« Reply #17 - Posted 2003-11-06 09:37:40 »

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  Tongue

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


Offline crystalsquid

Junior Devvie




... Boing ...


« Reply #18 - Posted 2003-11-06 12:49:11 »

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! Grin

-Dom
Offline Woz

Senior Newbie




A Troll who lives in a hole


« Reply #19 - Posted 2003-11-07 09:06:26 »

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.

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
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.
Offline crystalsquid

Junior Devvie




... Boing ...


« Reply #20 - Posted 2003-11-07 09:42:02 »

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 :/

- Dom
Offline princec

« JGO Spiffy Duke »


Medals: 425
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #21 - Posted 2003-11-07 11:49:58 »

Well, I still get invalid magic number on Opera using the 1.4.2_01 plug-in, and there's no excuse for that...

Cas Smiley

Offline swpalmer

JGO Coder


Exp: 12 years


Where's the Kaboom?


« Reply #22 - Posted 2003-11-07 12:26:06 »

Doesn't work on the Mac (never has)

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.

Offline crystalsquid

Junior Devvie




... Boing ...


« Reply #23 - Posted 2003-11-07 13:39:35 »

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  Huh

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  Tongue

- Dom
Offline princec

« JGO Spiffy Duke »


Medals: 425
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #24 - Posted 2003-11-07 14:40:22 »

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?

Cas Smiley

Offline Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #25 - Posted 2003-11-07 15:41:50 »

I'm still getting the 'invalid bytecode' error on Opera as well. Despite the fact that it works fine in IE6, this is the only applet i've ever had a problem with in Opera.

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Offline Abuse

JGO Knight


Medals: 14


falling into the abyss of reality


« Reply #26 - Posted 2003-11-08 11:03:42 »

Quote
Ergo


Using that word is wrong on soooo many levels Wink

Make Elite IV:Dangerous happen! Pledge your backing at KICKSTARTER here! https://dl.dropbox.com/u/54785909/EliteIVsmaller.png
Offline crystalsquid

Junior Devvie




... Boing ...


« Reply #27 - Posted 2003-11-10 11:52:50 »

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 Sad
Anyone know if we need to be sending anything else in the headers?

- Dom
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #28 - Posted 2003-11-10 12:26:55 »

Quote
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 Sad
Anyone know if we need to be sending anything else in the headers?

- Dom


Why don't you post the headers here that you're sending?

malloc will be first against the wall when the revolution comes...
Offline crystalsquid

Junior Devvie




... Boing ...


« Reply #29 - Posted 2003-11-10 12:46:44 »

Header is simply (in PHP):

...
header("Content-Type: application/octet-stream");

if ( !readfile("../wwwprivate/$appName") )
{
     exit;
}
...

& Thats it.
1.1 & 1.4 seem to work fine. Its just Macs, 1.3, & Opera that throw a wobbly over this  :-/

- Dom
Pages: [1] 2
  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.

PocketCrafter7 (14 views)
2014-11-28 16:25:35

PocketCrafter7 (9 views)
2014-11-28 16:25:09

PocketCrafter7 (10 views)
2014-11-28 16:24:29

toopeicgaming1999 (76 views)
2014-11-26 15:22:04

toopeicgaming1999 (67 views)
2014-11-26 15:20:36

toopeicgaming1999 (16 views)
2014-11-26 15:20:08

SHC (30 views)
2014-11-25 12:00:59

SHC (28 views)
2014-11-25 11:53:45

Norakomi (32 views)
2014-11-25 11:26:43

Gibbo3771 (28 views)
2014-11-24 19:59:16
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!