Draw distance seems to shrink every time I draw an Overlay

Started by AGP, July 13, 2009, 08:59:45 PM

Previous topic - Next topic

AGP

And the Overlay itself doesn't show. The first lines are how I initialized the Overlay, the second are in my collision(CollisionEvent) method.


explosionPlane = new Overlay(theWorld, buffer, "explosion2.gif");
explosionPlane.setVisibility(false);



explosionPlane.setSourceCoordinates((int)point.x-explosion.getWidth()/2, (int)point.y-explosion.getHeight()/2, (int)(point.x+explosion.getWidth()/2), (int)(point.y+explosion.getHeight()/2));
explosionPlane.setVisibility(true);

EgonOlsen

There is no code related to viewing distance in Overlay. What an Overlay actually is, is a wrapped Object3D with some magic added to it in the update-method. However, i'm not sure if you are using setSourceCoordinates correctly. It's for giving the Overlay new texture coordinates, not screen coordinates. If you want to do that, you have to use setNewCoordinates instead. If you are creating an overlay in the way that you do, it'll cover the whole screen. Maybe that is what causes the impression that it has something to do with draw distance!?

AGP

Actually, I was calling setDepth, if that's what you mean. Sorry I copy it. Anyway, you were right but the result with setNewCoordinates is that I don't see anything.

EgonOlsen

I'm not sure if an Overlay is actually what you want to use to render an explosion's bitmap...maybe a simple, bill boarded quad would be the better choice.

AGP

I used a billboarded plane instead, and I wrote a quick GifTexture class that switches the Texture instance of the object when a next frame method is called. All the Texture instances are pre-initialized and added to the TextureManager, but the plane, most of the time, is rendered without any texture because I don't think jPCT updates the texture references on the fly. Is there an Object3D.update method I'm missing (I've even tried rebuild())? If not, how could I go about doing that (replacing the texture on the fly)?

EgonOlsen

Quote from: AGP on July 16, 2009, 12:25:59 AM
I don't think jPCT updates the texture references on the fly.
No, it actually does that. I don't know what's wrong here, but it shouldn't be the texture assignment. It's not the most efficient way though, but for drawing some explosions, it should be fine.

AGP

Yeah, I made it work after tinkering it. Now here's a question about transparency: what exactly does Object3D.setTransparency(100) do? I've been using it in a lot of different programs and objects to erase the black areas in a texture, but I just came across an example where it doesn't work (the area that's supposed to be displayed appears in black while the black areas to disappear). The odd thing about this perfectly conventional texture is that if I don't call setTransparency the entire object comes off as black. And it is being lit. So I guess that's two questions (what does setTransparency do and why is this perfectly conventional texture appear as black). :-)

EgonOlsen

There's a clear answer to this: It depends... ;D 100 is a pretty high value for transparency. If you are using a texture without an alpha channel of its own, jPCT will create one by setting all black (or almost black) areas to 100% transparent and all other parts to opaque. However, when setting the transparency value, it affects the whole texture so that even opaque parts become transparent while the black parts stay invisible. With a value of 100, the opaque parts are almost opaque even when using transparency and the black parts remain transparent.
If you load a texture with an alpha channel of it own, the theory is the same but you may have all kinds of transparency in the texture because the values are not just 0 and 255 but all values between 0 and 255 are possible.
I don't know about the other texture...maybe it has an alpha channel of its own. But that wouldn't explain the blackness, i think. Maybe you can send me that texture for a closer look?

AGP

I was hoping the answer would be that clear, hahah. Anyway, the texture was being exposed to light but no light was affecting it for some reason. I created a light just for the plane it solved it. Now I'm running into a very weird problem. I'm writing a starship fighting game and originally I tested it with a single enemy ship. I have since changed the single variable to an array of a class names Enemy which holds both the Object3D and handles the ship's behavior (processed in the game loop). It worked fine for a single ship. The odd thing is that now that I have an array of ships (initialized really early on in the constructor), some of the collision tests are still being called for index 0 only (as opposed to a loop testing all the ships) and I'm getting not a NullPointerException but an ArrayIndexOutOfBoundsException on collision(CollisionEvent) when I try to shoot at the ship (or when it's time for it to turn because it hit the sky).

On run():

      if (!enemies[0].turning)
enemies[0].tieGuide.checkForCollisionSpherical(enemies[0].translation, 800f);
      if (enemies[0].turning)
enemies[0].turnAround();
      else enemies[0].perform();

On collision(CollisionEvent):

if (!enemies[0].turning && e.getSource() == enemies[0].tieGuide && e.getTargets()[0]==worldSphere && System.currentTimeMillis() > enemies[0].lastTurn+1000)
      enemies[0].turnAround();

EgonOlsen

And you get this exception on the enemies-array or the one returned by getTargets()?

AGP

My lines are out of sync with the compiler's, but a println call on collision reveals my two-ship array to be of length 2 and getTargets() to be of length 1.

EgonOlsen

Quote from: AGP on July 17, 2009, 07:33:18 PM
My lines are out of sync with the compiler's, but a println call on collision reveals my two-ship array to be of length 2 and getTargets() to be of length 1.
It highly unlikely that the line in your code doesn't match the line were the exception happens. Or in other words: If the exception says that it happened in line xxx of your code, you can be pretty damn sure that it did. So either you are looking in the wrong place or the code you execute isn't the one that you compile.


EgonOlsen

Not really. I've never seen such thing in over 10 years of Java development except when the code i was running wasn't the code i was seeing in the editor. Please do me a favor and add a


new Exception().printStackTrace();


in line 246, run the code and report the output.

AGP

I've seen it many times myself. It is the actual code, and there are sometimes ascii characters that the text area doesn't interpret as a line which the compiler does. If I remember correctly, the area needs 10 and 26 (break and new line). The compiler probably just interprets 10.