Draw distance seems to shrink every time I draw an Overlay

[AGP]

Here it is:

[EgonOlsen]

Strange editor that is. It's pretty hard to debug that way. Have you considered using Eclipse instead?

[EgonOlsen]

Is it save to assume that the line number's delta is constant at least within a method? In that case, line 258 seems to cause the problem, but that line isn't visible in the screen shots. If that isn't save either, get an editor whose line numbers match the ones from the compiler.

[AGP]

In keeping with the Star Wars theme, you phrased it well, hahah. And no, I hate other people's editors. I wrote mine to be as unobtrusive as possible. Probably my old professors' faults for making us write code with simple editors (what was the name of that popular notepad-like one for Linux--nedit, maybe?).

How'd you get 258? And here it is (don't tell me it's a visibility thing): SimpleVector point = Interact2D.project3D2D(camera, buffer, tieCenter).

PS: I took it out (didn't need it anymore), recompiled, re-ran it, and got the same ArrayIndexOutOfBoundsException. Line 281 this time. So after your formula...?

[EgonOlsen]

I just subtracted 246 from 267, which is 21. I subtracted that from 279 and got 258. However, due to the added line 246, it should now be at 259...i forgot to add that one line too. However, maybe you don't have to use another editor for every day work, but at least for debugging things like this, its needed IMHO. Get Notepad++ for example. It's free. OR fix your own editor to count the lines correctly. You are making your life harder than it has to be.

[AGP]

I agree, but it's just that when I spend too much time working on my editor I start feeling like I should be using it instead. :-) And a month ago I tried setting up a project on Netbeans for an applet. 40 minutes into it I still couldn't get it working. And I could tell from all the tabs that I was going to get annoyed with it even if I could. Anyway, the entire laser-collision condition:

Code Select Expand


else if ((e.getSource() == laser1 || e.getSource() == laser2)) {
      for (int i = 0; i < enemies.length; i++) {//IS IT ANY OF THE ENEMY SHIPS?
if (e.getTargets()[i] == enemies[i].tieFighter && System.currentTimeMillis() > timeSinceDestruction+1500) {

      SimpleVector tieCenter = enemies[i].tieFighter.getTransformedCenter();
//       SimpleVector point = Interact2D.project3D2D(camera, buffer, tieCenter);
      iGotOne = true;

      explosionPlane.setVisibility(true);
      moveTo(explosionPlane, tieCenter);

      thePlayer.numberOfKills++;
      enemies[i].enabled = false;
      theWorld.removeObject(enemies[i].tieFighter);
      if (Math.random() > .75)
theForce.play();
      timeSinceDestruction = System.currentTimeMillis();


}
      }
}


[EgonOlsen]

Ok, then this part will most likely cause it:

Code Select Expand


e.getTargets()[i]


You are iterating over the enemies, but are assuming that the array of targets is at least as long as the one that stores the enemies, which is pretty unlikely.

If there's only one target, that should be something like

Code Select Expand


e.getTargets()[0]


instead. Or if its larger, you should iterate over it with a second variable, but not with i.

[AGP]

Jesus, I meant it to be 0. What an idiot I can be. Thanks a lot, pal.

[AGP]

I sometimes lack the ability (physically, really) to fine-comb my own code. Now here's a brand-new question (!): what's the more efficient way to draw an animation on a plane than the one I'm doing (replacing the Texture instances on the fly)?

[EgonOlsen]

Another solution is to stick all animation phases in one texture and use the PolygonManager and adjust the u/v coordinates. I'm doing this in Robombs for the explosions. It CAN be more efficient. But on compiled objects for example, it will be less efficient. Just stick with your approach. It should be doing fine.

[AGP]

Cool, thank you. Here's a question about compiled objects: why do they use lightMul at 1.0 when the default lightMul is 10? Is there a reason for this decision (was it a decision or a necessity)? Because every time we choose to compile the objects (and I just ran into a performance issue that compile() solves nicely) we'll have to reconfigure all of our lights.

[AGP]

And yet another question (you're a very patient man!): World.getSize() is returning 14, but a loop that calls getObject(index) is returning every single reference as null (and jPCT prints out "Can't retrieve object #" for each). How come?

[paulscode]

Not related to your current question, but about your editor's line-counting abilities.  I've had some experience writing editors before, so I thought I would add my two-cents' worth.

If I remember correctly, the area needs 10 and 26 (break and new line).

The ASCII values for newline are 13 (carriage return \r) and 10 (line feed \n).  Microsoft saves ASCII files with both a charrage return and a line feed \r\n everywhere you create a new line.  Macintosh uses only a carriage return \r, and Linux uses only a line feed \n.

So if the whole "carriage return, line feed" issue is the source of confusion, then to make your editor count the lines correctly, I would recommend splitting first on "\r\n", then on "\r", then on "\n".  If you handle all three cases in that order, your editor should count the same number of lines as the compiler does (unless the compiler is just stupid and interprets "\r\n" as two lines, in which case, you could just "dumb down" your editor to do the same).

The other problem I had with line-counting is word-wrap.  Just from the screenshots, I don't know if your editor does this or not.  If so, make sure your code is taking this into acount when counting the lines (since the compiler does not word-wrap, of course).

[AGP]

Yeah, I knew I didn't remember the Ascii perfectly. Thanks for your suggestion, I will do that.

Egon, the follow-up to my unanswered question: would it be possible to make a Object3D.compile(float lightMul)?

[EgonOlsen]

lightMul=1 for compiled objects can't be changed. It's how the OpenGL pipeline works. I'm setting it to 1 for all objects when using a compiled one to get consistent lighting between normal and compiled objects. The default pipeline does a multiplication for the light values which the compiled one can't do.
If you want to preserve another lightMul for uncompiled objects, you can reset the lightMul to any value after calling compile on all your objects. It's not possible to use this value on compiled ones though for the reasons mentioned above.

About that count-getObject()-thing: The count in World doesn't match the objects' ids. The id is an internal ID that each object carries. It has nothing do to with the world's size. In fact, i consider this method to be pretty pointless in most situations. If you need access to a World's objects, use getObjects() instead.