Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - EgonOlsen

Pages: 1 ... 779 780 [781] 782 783 ... 795
11701
News / Tested jPCT with LWJGL0.8
« on: January 28, 2004, 01:50:27 am »
I've been a bit lazy with upgrading my LWJGL-installation from 0.7 to 0.8, but i finally did and jPCT works fine with it. Just to let you know in case you want to use 0.8 yourself.

11702
Support / Object boundaries
« on: January 24, 2004, 12:42:22 pm »
Split the method above into 4 seperate ones. Each one checking for one border only and adjust your movement according to the results.

11703
Support / Object boundaries
« on: January 23, 2004, 09:17:35 pm »
I'm not sure if i'm understanding you correctly in this case. If i do and the "center" of the ship is placed in the actual center of the object, then maybe something like this will help (not tested...):

Code: [Select]
public boolean shouldIStop(SimpleVector projCenter) {

int xPos=(int) projCenter.x;
int yPos=(int) projCenter.y;

int xr=xPos+10;
int yt=yPos-10;
int xl=xPos-10;
int yb=yPos+10;

if (xl>LEFT_BORDER && xr<RIGHT_BORDER && yt>TOP_BORDER && yb<BOTTOM_BORDER) {
return false;
}

return true;

}


Or were you talking about something different?

11704
Support / Object boundaries
« on: January 23, 2004, 03:34:21 pm »
To determine if the object has left the screen boundaries, you can use Interact2D.projectCenter3D2D(); This will give you screen coordinates of the object's center. While it doesn't take the object's dimension into account, it should be sufficient in your case, if you roughly know an object's dimension on screen.
Or use Object3D.wasVisible(), which returns false if the object wasn't on screen in the last frame. This will work too, but it requires the object to be rendered offscreen at least once before it can be discarded.

11705
Support / Randomly Generating Object3D's
« on: January 22, 2004, 01:06:40 am »
Not sure if this will help you much, because the bubbles are managed in a reeeeaaalll simple way, but anyway:
Code: [Select]

for (int i=0; i<NUMBER_OF_BOXES; i++) {
         Object3D box=Primitives.getSphere(4,1);
         box.calcTextureWrapSpherical();
         box.setTexture("wood");
         box.setTransparency(0);
         box.setEnvmapped(Object3D.ENVMAP_ENABLED);
         box.setCollisionMode(Object3D.COLLISION_CHECK_SELF);
         box.setOrigin(new SimpleVector(140,0,-117));
         setBox(box, i);
         box.translate((float)Math.random()*-140, 0, (float) Math.random()*117);
         theWorld.addObject(box);
         boxes[i]=box;
}


And the code for setBox():
Code: [Select]

private void setBox(Object3D box, int i) {
      float x=15f-30f*(float) Math.random();
      float y=20f-40f*(float) Math.random();
      float z=15f-30f*(float) Math.random();
      box.setTranslationMatrix(new Matrix());
      box.translate(new SimpleVector(x, y, z));
      float trXn=1.5f+2f*(float) Math.random();
      float trZn=1.1f+2f*(float) Math.random();
      trX[i]=trXn/2f;
      trZ[i]=trZn/2f;
      lifeTime[i]=0;
      box.rotateX(x);
      box.rotateY(y);
      box.rotateZ(z);
}


The bubbles are stored in the array named boxes (they were boxes in the first version... :wink: ) and their current translation in X and Z direction in trX and trZ. In addition, the lifetime of each bubble is stored in the lifeTime[]-array. But this is ugly code written to serve a single purpose. It would be better to wrap this information into an object (or maybe to extend Object3D, which sadly isn't possible in 0.97 but will be possible in 0.98 because i'll get rid of the useless final-stuff) and manage these objects by a simple Manager-class. If you don't want to write such a wrapper class and go with the array-approach, the Manager is still a good idea because it can hide this fact from the rest of the code.

Hope this helps.

11706
Projects / tokima
« on: January 20, 2004, 10:11:29 pm »
Quote from: "acorn98"
Also, I have a couple of very long fences with a tiny repeating texture which seems to warp into a diagonal line - I think it started happening when I stretched the object to its current length (which is pretty big). Is it a bug, do you think?


Are you talking about this? :



(i applied some "Gamma" to it...)

I'm not sure what that is exactly...could it be that the u/v-coordinates are very high here? Like (1000,1000) / (1000,1001) / (1001,1001) for such a triangle instead of (0,0) / (0,1) / (1,1)? That's the only idea i have ATM, because it can result in an overflow somehow. The renderer uses fixed point math for the coordinates but even 32bits are not enough sometimes. I think the highest value possible should be around (+-)256 or (+-)512...i not quite sure ATM. Could that be a problem here?

11707
Projects / tokima
« on: January 20, 2004, 07:11:13 pm »
Quote from: "acorn98"
There's some bad poly overlap in places, mainly due to my abilities with 3dsMAX - I'm still getting to grips with it. My next effort should be considerably cleaner.
.......by the way - that fps source was fantastic.
Yes...i noticed that there seems to be one (or some) large polygon below the street's actual polygons which "shines through" due to inaccuracies in the zBuffer (caused by the nature of it...nothing i can do about it). That's causing most of the z-fighting problems and it hurts fillrate and the octree. You should try to get rid of it IMHO.
The newer versions of the fps-code are even better... :wink: (No multi-threading issues anymore).
Keep up the good work. I really like the mood of this level.

11708
Projects / tokima
« on: January 20, 2004, 06:46:29 pm »
Looks great and proves that simple vertex-lighting can still produce very nice results. However, i noticed two issues while running around in the level: There's some Z-fighting when polygons overlap. But that's a "problem" with the model, not with the code. It's not that bad anyway.
I assume it's somehow based on the fps-demo? If so, on which version? Older versions did the actual movement in the timer-thread and with the upgrade to a P4 with Hyperthreading, i noticed that this isn't a good idea, because it leads to threading issues (like when the timer-thread is working on a rotation-matrix the main-thread uses for rendering). This results in parts of the geometry rendered wrong or distorted for a frame. And this is exactly what i noticed when running around in the level. Note that i never experienced this on none-HT CPUs like Athlons, so it's difficult to explain and debug. Have a look at the newer version of the fps-demo to see how i'm doing it now. As a rule of thumb: Never let any other thread than the main-thread (the thread that does the rendering) modify the camera or some object's matrices. Not the timer-thread and not an Event-Listener-thread (like a Key- or Mouse-Listener) because you may run into trouble. And it's a real pain to debug this stuff...believe me... :wink:
But now back to running around in this world... :D

11709
Projects / JPCT and Applets
« on: January 19, 2004, 03:45:17 pm »
No, it doesn't support lightmaps/multitexturing but vertex lighting. You can bake your static lighting into the textures if you want to, but you have to do this yourself. The reason for not supporting lightmaps/multitexturing is performance of the software renderer. It's the price you pay for the flexibility.
About the animation: You can do keyframed animations by either creating the animation in your code (by combining several meshes into an Animation) or by using the MD2-loader to load MD2-models. Using the animation out of a 3DS-file is not supported as it would require a completely different animation framework.

Hope this helps.

BTW: What kind of game are you planning to make?

11710
Projects / JPCT and Applets
« on: January 19, 2004, 12:12:43 am »
There are some examples in the API distribution. However, they is no applet example anymore since jPCT0.97, because i decided to remove it. It's code was rather outdated. If you want to, you can still grab 0.96, which contains an applet example, from here: http://www.jpct.net/download/jpctapi_096.zip
Anyway, using jPCT in an applet doesn't really differ from using it in an application...

11711
Support / Randomly Generating Object3D's
« on: January 16, 2004, 09:44:11 pm »
Testing the ships for collision with the player should be fine. The demo i mentioned above does the same between the bubbles and the alien. It displays approx. 100 bubbles.

11712
Support / Randomly Generating Object3D's
« on: January 16, 2004, 02:53:41 pm »
Creating them at runtime may not be a good idea as it is quite costly to call build() on an object. It may be an option if the objects are quite simple though. I think it's better to add them at the beginning/setup of the level, i.e. when you know that you'll never use more than 100 objects of type x and maybe 50 of type y. Just create the maximum amount of objects for each type (try to use cloneObject() for this as it will save you lots of memory if the object's meshes are all the same), build them and add them to the world (remove the formerly generated objects for the previous level) and maybe to a pool/manager that you have to write yourself to manage the state of the objects (the pool can as well do the creation of the objects...that's an even better way of doing it). If you need a new object of type x at position a/b, ask the manager for it. Similar to a connection pool for accessing a database. This demo http://www.jpct.net/demos does something similar in a very small scale with the moving bubbles.
However, i hope you don't want to do a collision detection between all these objects, because when using 100 objects at time, this will result in something like 100*99 collision detections per step, which is a bit heavy...

Hope this helps somehow.

11713
Support / Randomly Generating Object3D's
« on: January 15, 2004, 09:20:58 am »
The amount of objects that may belong to a world is unlimited (in theory...in practise, memory usage and performance will limit it of course). However, letting the engine determine which objects are visible among 1,000s of them is not a good idea performance wise. Maybe it's possible for you to use a pre-processing stage based on the logic of your game to determine what may be visible and what isn't (divide the space into sectors or whatever...). With this information, you can either set some objects to visible/invisible as needed or remove them from the collection of objects if not needed and add them again if needed. The second solution may not be a good idea if it happens a lot, because removing them is not that cheap.
Note that you have to call build() only once on an object. It's not required to be called everytime you add it.
How much is "infinitely" in your case?

11714
Projects / fps showcase
« on: January 11, 2004, 01:43:11 pm »
:shock:  Looks great. I'll add a link to this thread to the projects page within the next days.

Edit: I've edited your first post to replace the image, because it wasn't working. If you are having problems with hosting images in the future: I can host them here on jpct.net if you want. Just send them to me.

11715
Support / Parenting the camera to an object
« on: January 09, 2004, 04:33:17 pm »
Another possible solution is to place the camera behind the object by getting the object's transformed center and translate it somehow (i.e. as needed in your case) by evaluating the results from the get?Axis()-methods of the object. Somehow like:

Code: [Select]

SimpleVector tc=object.getTransformedCenter();
SimpleVector pos=new SimpleVector(tc);
SimpleVector zAxis=object.getZAxis();
SimpleVector yAxis=object.getYAxis();
zAxis.scalarMul(5f);
yAxis.scalarMul(2f);
pos.add(zAxis);
pos.add(yAxis);
theWorld.getCamera().setPosition(pos);
theWorld.getCamera().lookAt(tc);


Please note that i haven't tested this and typed it out of my head, so i could be totally wrong here...

Pages: 1 ... 779 780 [781] 782 783 ... 795