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 ... 784 785 [786] 787 788 ... 800
11776
Support / edges
« on: February 03, 2004, 01:06:58 am »
Quote from: "acorn98"
Thanks - if you get a chance to look into it, anything you can add to that effect would be really useful.
I've added a refresh()-method to FrameBuffer that can be called after modifying the pixels-array to make it represent your code's changes to it. It's not an "official" release, so i uploaded the jar-file only:

Edit: *Link removed*

Please let me know if it works for you.

11777
Support / edges
« on: January 30, 2004, 12:26:29 am »
Quote from: "acorn98"
Rather than pollute your engine with a one-off blur effect, is there another way to retrieve an array using MemoryImageSource that causes the engine to reflect changes made to that array? It would be handy for all kinds of image post-processing.
I'll have a look at it after the weekend. It's a bit dirty to manipulate the pixels-array behind the framebuffer's back IMO but i also think that it could usefull in cases. I'll add something that makes it possible in one way or another.

11778
Support / edges
« on: January 29, 2004, 12:52:39 am »
Ok, i understand the problem better now. I once had a similar bluring for a depth of field effect implemented and its performance was ok...but it looked horrible and i never went public with it. I also had a postfiltering implemented (like the Voodoo2 did it) but i decided to remove it in one of the latest versions. Performance for this filter was ok too. So it's definitly possible to do this in reasonable time.
The problem is, that working with the pixels-Array on the application side works only if Java2 (i.e. a BufferedImage) is used. In Java 1.1, a MemoryImageSource will be used and that's "blind" for changes you may apply to the pixels-arrays. That's why the docs for this method suggest to blit the pixels-array back into the framebuffer....but that's even slower.
If you don't care for Java 1.1 support, just optimize your bluring routine and you are done. If support for 1.1 is important, adding the bluring into the engine's core would be the better solution. In this case, just send me your bluring routine and i'll add it somehow.

11779
Support / Re: edges
« on: January 28, 2004, 05:06:38 pm »
Quote from: "acorn98"
I also tried SAMPLINGMODE_OGSS_FAST, but the result wasn't quite what I was after.
In which way? OGSS_FAST does a simple 1.5*1.5 oversampling and rescales the rendered image. That's basically like AA worked on the older GeForce2 cards. OGSS does the same using a 2*2 pattern. Because it's supersampling and not multisampling (like newer hardware does it) not only edges but also textures are anti-aliased. Blurring on the other hand can't be seen as anti-aliasing IMHO even if NVidia offered something similar with their Quincunx-AA (a combination of MSAA and an adaptive blur filter).
I'm not sure what exactly do you have in mind, i.e. which result do you want to get from AA-ing the scene.... :?:

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

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

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

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

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

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

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

11787
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

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

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

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

Pages: 1 ... 784 785 [786] 787 788 ... 800