LWJGL 0.93 has been released some weeks ago (http://www.lwjgl.org), but i haven't tested it until now. The current version of jPCT should work with it without changes. At least a quick test under Linux was successfull. The current distribution of jPCT still comes with 0.92 (for no particular reason...  ).

Nobody said that it's going to be easy... :twisted:

Sounds like quite a huge project. I wish you best of luck for it. I think that Runescape is the perfect prove that a browser/applet game can be successfull.

Works fine now. I never experienced any performance differences between 1.4 and 5...not for the good and not for the bad. What exactly seems to be slower with Java5?

I'm having some problems to get it to run with Java 1.5 in both, Firebird and IE. It loads fine, it initializes everything and after doing the combined-vs-splitbuffer-test, it's sitting there displaying the Java 1.5 applet logo and nothing happens. However, it seems to do something in the background, because it consumes 50% of CPU power on my hyperthreading machine (i.e. one virtual cpu). If i reload the page, the actual game screen appears and i can play, but i'm at 100% CPU then, which means that the former instance of the game is still running in the background.
It worked fine on a 1.4.2 machine last weekend.

Very nice...seems like you put a lot of affords into this game to come that far in such a short period of time. Maybe a version with english texts for the menus would help some people to start a new game and such. I had to derive it from the naming of the HTML-page called which menu does what, because my girlfriends russian is too rusty to be helpfull in this case... :wink:
Anyway, i finally started my own game and killed two bots. When firing at the third, i got this exception:

java.lang.NullPointerException
at java.util.Hashtable.get(Unknown Source)
at game.client.engine.Grid.toVector(Grid.java:113)
at game.client.engine.Grid.getAngle(Grid.java:204)
at game.client.handlers.RotationHandler.process(RotationHandler.java:46)
at game.client.commands.FireCommandHandler.commandExecuted(FireCommandHandler.java:106)
at game.common.commands.Command.execute(Command.java:98)
at game.common.commands.CommandQueue.execute(CommandQueue.java:61)
at game.client.Game.play(Game.java:201)
at game.client.Game.process(Game.java:166)
at game.client.engine.Engine.notify3DHandlers(Engine.java:347)
at game.client.engine.Engine.gameLoop(Engine.java:146)
at game.client.engine.Engine.start(Engine.java:89)
at GameApplet.start(GameApplet.java:123)
at sun.applet.AppletPanel.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)


However, this you've done a great job on this game and i think has lots of potential. Can't wait to see how it evolves in the future.

Quote from: "Mike Nelson"I just realized that would only really work in fullscreen mode.  otherwise if the user moved the Applet/Application the coordinates for the center would be off.. that could screw things up. . . .

That's no problem at all. You can easily determine where the frame is located on the desktop and adjust your coordinates accordingly. I did that in the latest Paradroid 3D alpha and it works fine (at least on Windows XP and Linux..haven't tried others yet).

Looks amazing. I assume that it's turn based? When i'm finished with Paradroid3D (which is still a long way to go...), i may start something similar based on the idea of robosport (anybody remembers that game?).

Edit: I've added a link to this thread on the projects page (http://www.jpct.net/projects.htm). If you've got a public demo up and running, i can change the link to that...

There is not much to share at all. All this stuff is more or less based on the fps-example that comes with the API. That's why the weapon is always the same in these shots. The models are either quake3 maps or some 3ds stuff from the internet, of which i don't know the licenses, so i won't distribute it here. The textures i'm using for testing purposes are from a halflife texture pack, but i really don't know where to download it anymore.

Maybe the old terrain example helps. It's not exactly what you want, but at least it should be easier to understand than the car example. Have a look here: http://www.jpct.net/download/TerrainGL.zip

I'm not really sure if it compiles with the latest version of jPCT, but if it doesn't, only minor changes should be required.

Yes, there are. Have a look at the Primitives class. To texture the objects  that this class creates (not needed for cube and plane and such as they should already have the correct texture coords assigned), you can use the calcTextureWrapXXX-methods in Object3D.

Hope this helps.

QuoteIF this is still an issue try using the java.awt.Robot class you can move the mouse pointer, and simulate user input.

Neat idea...i remember that i once wrote a small test that moved the mouse and clicked left and right randomly...my desktop looked really crazy after running it for some time.. :wink:

That line is a requirement caused by the actual implementation, it's not a conceptual one. In jPCT every object has at least one texture, even if you haven't assigned one. This can either be a default, plain white dummy texture that the texture manager provides or a colored texture that matches the color of your material. This is (as said) implementation specific and it could change without any consequences for the user of the API (even if it most likely won't...), so i think you are save to write that an object may have a texture...but doesn't have to.

I think it depends on what exactly you mean by "load VRML". You may either load just the objects from the file or you may also be interested in animations, events or whatever VRML allows. In the former case, you have to parse the VRML somehow, create the objects from it, load the textures and you are basically done (still a lot of work...). In the second case, you need to write somekind of VRML-layer on top of jPCT...which will be a lot more work IMHO.
However...is it possible: yes. Can jPCT do it "out of the box": no.  Does jPCT includes everything that is needed to write such thing: yes.

Hope this helps.

Quote from: "rolz"Isn't there a way to do the trick with signed applets ?

According to the LWJGL-guys: no. Personally, i never tried it. But anyway: Even if signing the applet would do the trick, LWJGL will still render into its own window and not into the applet. because it can't render into Java2d components directly. That given, there's no point anymore to use an applet in combination with LWJGL: Java 1.1 can't use LWJGL anyway and everything that can (1.3+), can do webstart too.