Quote from: paulscode on March 04, 2010, 10:48:55 PM
One good thing about Collada support would be that models exported from the free version of Google Sketchup into the Google Earth 4 .kmz format (which is just a .zip file containing a Collada model and textures) could be used directly by jPCT without any conversions required.  The countless free models available for download on the Google 3D Warehouse would be ready to use in jPCT projects as well.

sweet. I didn't know that. That's awesome and would make life a bit more easier.

nice, I didn't imagine that Bone/skeletal animation could have facial animation. That's awesome. Great job to Raft who's doing the porting and the Ardor3d team.

hmm, well you can try adding a JPanel to the JApplet. The new JPanel will be your canvas that you will be drawing on. Then just make sure to update both the JApplet and JPanel each frame.

Raft knows best for getting guis overlapping and making sure the graphics are update accordingly.

The examples as I understand it are in the wiki itself. You will need to copy and paste into a file as needed.

http://www.jpct.net/wiki/index.php/Advanced_example
http://www.jpct.net/wiki/index.php/Shaders

I passed on deadreckoning myself , but it is a per project and game play style. I don't think Robombs would need it. Since blowing people up are done with stationary objects. Where as shooting people with bullets or missiles would be a different story. Since I don't know his game. I'm only suggesting to go with standard practices in regards to highly shooting orientated games.

I feel your pain. I HATE MOVING. It's always a bad experience. :\ good luck

Part of the problem might with the time syncing. I don't know how to suggest syncing up time and deadreckoning better. You need a solid form of deadreckoning going. I only suggested the basics, but here is some gamedev articles about it.

dead reckoning cubic splines
http://www.gamedev.net/reference/programming/features/cubicsplines/page2.asp

Here is an article on a variant.
http://www.gamedev.net/reference/articles/article1370.asp

Well I've done a lot of reading about terrain. Your better off using extra objects, but it also depends on the detail of the terrain.

In the Terrain demo. It's a single mesh model with limited depth. However there are samples out there that produce the same type of terrain as the demo, but then adds additional layers of height and density as you get closer. In these cases your better off splitting them up and swapping the hiegher details models for lesser ones in the distance. In the case where i'm working on a 512x512 height map with no further details. Well I suggest using the various in api methods to split into octree(if not already done) and go with that.

For example
http://www.youtube.com/watch?v=F-4OeWL1sCw&feature=related
is from Inifinity: The Quest for Earth

Terrain demo is nice, but there is no way a single mesh design without breaking it into zones could handle a the demo in the video.

So determine what you need and go with it. Small terrains don't need it, BIG ones will.

From what i'm seeing of your screen shots. It looks like the ground plane is near the same height as your water. Increase the elevation of the vertex points so the terrain is more terrain'y with hills, mounds and lake/river drops. Then see if there is the same graphical problems. As it is, it just looks like the ground is too close to the water which is causing the graphical problems.

sender

SimpleVector p = object.getTransformedCenter();
action.x = p.x;
action.y = p.y;
action.z = p.z;


reciever

SimpleVector p = new SimpleVector(action.x, action.y, action.z);
SimpleVector local = Object.getTransformedCenter();
SimpleVector tran = local.calcSub(p); //or p.calcSub(local)
// update tran for motion and time difference.
Object.translate(tran);


It would be cool to see jPCT go Android. Though I don't know if any of the current users would make a lot of use of it. Then again maybe it would bring in a new crew of people and interest?

Though honestly jME is the LAST Java 3d engine I would put on Android(Except for Java3D). It's bloated and a heavy weight game engine. Android would need a lean and mean version of a SceneGraph or something similar to jPCT. I also wouldn't consider Ardor3d, or Ogre from the CPP entries. These are full fledge apis, not something you can shoehorn into a small portable device just because it has OpenGL ES.

I dropped jME because of it's heavy weight for webstart and applets. If I ever do a full size PC like game. Then yeah I would probably go to Ardor3d or jME. But for smaller, leaner, meaner games. jPCT all the way.

Personally I don't like the answer given for development time. Though the idea has merit. However look at the state of game development companies of Blizzard compared to any other PC developer. It's clear Blizzard doesn't consider "average" future computer a valid enough of a target. If theres complaints about that, then theres more than enough evidence to show that Blizzard does better than most other PC game developers in regards to profit per product. I think it would better to assume current average now, then that becomes the minimal standard after development time. ( my sister in law STILL plays Diablo 2. And she doesn't like any other PC games or VG violence.)

he listed the source code, but I in short i'm using this

This is my only message that I send for gameplay action.

public class GearAction implements Serializable
{
  public String userName;

  public float pos_x;
  public float pos_y;
  public float pos_z;
  public float[] torsoRot;
  public float[] legRot;

  public int action;
}


Well true enough. Various settings, parameters will/can substantially alter the behavior of follow or floating cameras.

I didn't think your were downplaying rafts cameraman at all.

Well I've always appreciated you posting your source. I have used it here and there.

Quote from: paulscode on February 09, 2010, 11:28:46 PM
From my experience, camera control tends to be very specific to a particular project (which is why I have written several variations, as I mentioned).  I think it would be pretty difficult to make something standard that you could use in every case.  Raft's Camraman class looks like it would cover some of the common setups - something like that might be worth putting in the Wiki.

oh, i'm going to disagree. I'm sure we both played ALOT of games. From a games perspective I have found cameras are broken into 3 different groups.
Floating, Rigid, FPS. What I found more common was that some games change the camera type.

Though I agree that Raft has an excellent base camera

Well maybe part of the stretched triangles have to do with the procedural generation. I assume that if your creating the land in memory it's a an array

• [y]. Where as Egons sample is a file. So what could be wrong is the the associated hieght.
  
  list the code that shows the the creating or setting of your terrain. I user the vertex controller and set the height of pre created plane. It's slow though.