I want a shot to point towards a certain target but it points in some strange direction.
Do you see any obvious flaw in my code?


vTargetPos.sub(vPlayerPos);  //to get direction vector
vTargetPos.normalize(vTargetPos);
vUp.set(vTargetPos.calcCross(VECTOR_LEFT));   // I do not care about the up vector, so I calculate an abitrary one
shot.setOrientation(vTargetPos, vUp);


As said, this does not work at all. Don't ask how I managed to finish my space shooter without figuring basic stuff like this out   
btw: "Direction" in setorientation means positive z-axis - right?

Sorry for being so anal, but I somehow don't like to see vec.normalize(vec) in my code
Any specific reason why it's not a static method?

See subject

When I setvertexcontroller before build(), there is a warning about normals. When I set vertexcontroller after build, applyvertexcontroller seems to have no effect.
I have read and experienced some contradicting things about the topic.

Maybe it's important to mention that there is a rotateMesh call in there as well.

It would be really convenient to have a non-uniform scale function for Object3D, something like scale(x,y,z). (I know there are ways to achieve that, but not as comfortable.)
Do you have any plans to implement that someday?

When I call
setScale (distanceToCamera)
on an object, shouldn't it always appear at the same size regardless of distance?  It seems to not work that way, so maybe my thought is wrong?

A journey that has taken over two years is coming to an end.
Besides some sub-standard texts and most likely a few bugs, Armada - Mobile Space Combat - is finished (though there will probably be continuous updates after publishing).
Anyone willing to try out the beta version, please direct your mobile browser to this address:
http://www.ironman-project.com/armada.apk (Use the link in the last post!)

Or use this QR code:

Those two nice guys are already waiting for some new friends and enemies:

Have fun!

P.S. Feeback is the lifeblood of all indie devs, so thanks to everyone in advance!
cu, Irony

Hey Egon,
do you have any idea why I don't see the title image?

This in ondrawFrame()

      if (man.state==SM.STATE_TITLE) {
         if (!tm.containsTexture("title1")) {
            Log.d("draw", "load title");
            tm.addTexture("title1", new Texture(am.open("title1.png"), true));
            tm.preWarm(fb);
         }
         fb.blit(tm.getTexture("title1"), 0, 0, 100, 100, 512, 512, 200, 200, 100, false);
      }


Log:
05-17 20:52:56.903: D/draw(9336): load title
05-17 20:52:59.456: D/draw(9336): draw title
05-17 20:52:59.476: D/draw(9336): draw title
05-17 20:52:59.496: D/draw(9336): draw title
...

Hi guys
after resisting for a long time,  I did the unthinkable and built an Indiegogo page to help the game get finished and polish it up. Not asking for a crazy amount, just enough to get in-game music and some other assets. Yeah, it's e-begging, but at least it's for a somewhat reasonable sum. (Will Wheaton is making a web series showing him playing board games with a few friends, and is asking for a million dollars to film it, so hey
Even if you cannot imagine giving out any cash, there is still a lot of information about the game I haven't posted before, so take a look if you're interested:
https://www.indiegogo.com/projects/armada-mobile-space-combat/x/505316#home
Thanks guys.

Time for another update.
For those who didn't have the chance to play the alpha before, this video shows a typical mission and how the virtual stick works.
https://www.youtube.com/watch?v=ezPCrl2OmjA

Egon, do you think there is any chance that some day you add a function to rotate the skybox?
I've set up the different mission types of my space game with fixed coordinates, so you are always flying against the same background. It would be really nice if I could simulate that the mission paths are different each time, without having to adjust all coordinates for all 13 mission types. There are hundreds of them...
I'm sure there are other uses for this as well, like a rotating background.

1. When I call addTexture from onDrawFrame() , does it block or will onDrawFrame continue?
2. When TextureManager.containsTexture returns true, is the texture already fully loaded?

If 1 and 2 are No, how can I check if a texture has been completely loaded?

Egon, can you make a wild guess what could be wrong if an overlay is not visible? It should be rendered on world.renderscene, right?

Debug code:

if (arrow==null) arrow = new Overlay(man.world, fb, "arrow");
arrow.setNewCoordinates(50, 50, 200, 200);
arrow.setVisibility(true);


Still, no overlay

I did setMipmap(true) after loading a texture. Strangely, it turned out black then. I don't get this - isn't mipmapping turned on by default anyway?

A nine-patch is a bitmap that is very useful for GUI elements.
Usually, when you blit-scale your buttons for different resolutions, they may look like that:



Wouldn't it be much nicer if they looked like that:



You can do this with a 9Patch, where only the inner area gets scaled in two directions; the corners do not get scaled at all, while the borders only scale in one direction (horizontally or vertical).




There is no built-in support in JPCT-AE for it, so I adapted the blit function to write my own implementation. It's not a 1:1 adaptation (scaleable area is supported, but not fill area).

First, you will need a source bitmap like this:



Zoomed in to better show the black borders. They need to be on the first horizontal and vertical stripe of the image and show where the inner zone begins and ends. The borders themselves do not get blitted.
I made the button translucent inside, but that is not mandatory.




Here is the code:



class NinePatch {

private int[]X = new int[2];
private int[]Y = new int[2]; //These hold the scale zone coordinates
private int W, H;  // Input bitmap dimensions
private Texture tex;
private String name;

public Space9Patch(Bitmap b, String name) {  // Make sure b is not scaled! It is best to use a white picture so you can blit it in any color later on
this.name = name;

W = b.getWidth();
H = b.getHeight();
X[0] = X[1] = Y[0] = Y[1] = -1; //Start and end positions of inner scale zone

for (int x=0; x<W; x++) { // Analyze first horizontal stripe of bitmap
if (b.getPixel(x, 0) == Color.BLACK && X[0] == -1) { // Look for black pixel
X[0] = x;   //Save position of first black pixel
}
else if (b.getPixel(x, 0) == Color.TRANSPARENT && X[0]>=0) {  //Look for first transparent pixel after black stripe
X[1] = x-1;  //Save position of last black pixel
break;
}
}

for (int y=0; y<H; y++) { // Analyze first vertical stripe
if (b.getPixel(0, y) == Color.BLACK && Y[0] == -1) { //same as above but in vertical direction
Y[0] = y;
}
else if (b.getPixel(0, y) == Color.TRANSPARENT && Y[0]>=0) {
Y[1] = y-1;
break;
}
}

//Create texture from bitmap
TextureManager tm = TextureManager.getInstance();
if (!tm.containsTexture(name)) tm.addTexture(name, new Texture(b, true));
tex = tm.getTexture(name);
}

//Draw 9-patch in abitrary size and additional color
public void blit(FrameBuffer fb, int x, int y, int w, int h, int transp, RGBColor col) {
fb.blit(tex, 1, 1, x, y, X[0]-1, Y[0]-1, X[0], Y[0], transp, false, col);
            fb.blit(tex, X[0], 1, x+X[0], y, X[1] - X[0]+1, Y[0]-1, w- X[0]- (W-X[1])+1, Y[0], transp, false, col);
fb.blit(tex, X[1]+1, 1, x+w-(W-X[1])+1, y, W-X[1]-1, Y[0]-1, W-X[1]-1, Y[0], transp, false, col);

fb.blit(tex, 1, Y[0], x, y+Y[0], X[0]-1, Y[1] - Y[0]+1, X[0], h - Y[0] - (H-Y[1]) + 1, transp, false, col);
fb.blit(tex, X[0], Y[0], x+X[0], y+Y[0], X[1]-X[0]+1, Y[1]-Y[0]+1, w-X[0] - (W-X[1])+1, h - Y[0] - (H-Y[1])+1, transp, false, col);
fb.blit(tex, X[1]+1, Y[0], x+w-(W-X[1])+1, y+Y[0], W-X[1]-1, Y[1] - Y[0]+1, W-X[1]-1, h - Y[0] - (H-Y[1])+1, transp, false, col);

fb.blit(tex, 1, Y[1]+1, x, y+h-(H-Y[1])+1, X[0], H-Y[1]-1, X[0], H-Y[1]-1, transp, false, col);
fb.blit(tex, X[0], Y[1]+1, x+X[0], y+h-(H-Y[1])+1, X[1] - X[0]+1, H-Y[1]-2, w - X[0] - (W-X[1])+1, H-Y[1]-1, transp, false, col);
fb.blit(tex, X[1]+1, Y[1]+1, x+w-(W-X[1])+1, y+h-(H-Y[1])+1, W-X[1]-1, H-Y[1]-2, W-X[1]-1, H-Y[1]-1, transp, false, col);
}

//Blit using original color
public void blit(FrameBuffer fb, int x, int y, int w, int h, int transp) {
blit(fb, x, y, w, h, transp, RGBColor.WHITE);
}
}



From time to time, I will post a few code snippets that proved useful while working on Armada. Maybe someone can use something for their own projects.

One problem that I ran into was the limited viewing distance. I thought that just setting the farplane value high enough would solve it, but there is actually a hard limit given by the hardware and/or OpenGl (not sure about that).
I wanted to have a planet that is far away but still visible (and approachable). While it would be possible to fake something with billboards, I found a solution that uses real geometry and actually pretty simple.


public class Planet extends Object3D { //It's better to not use Object3D directly for your game objects, but I do it here for simplicity

  private SimpleVector realPosition, camPos = new SimpleVector();
  private SimpleVector v = new SimpleVector; // temporary vector
  private final static MAX_VIEWING_DISTANCE = 5000; //this should be a safe value for most devices; make sure your farplane value is higher than this

  public Planet(SimpleVector position) {
      ... // init Object3D here

     translate(position);
     realPosition = new SimpleVector(position); //Save "real" position of planet in another vector as the object's physical position will change
  }

  // this is called in every frame update
  public void update() {
   
    world.getCamera().getPosition(camPos); //position of used camera

    float dist = realPosition.distance(camPos);  //calculate distance camera<->Planet

    if (dist>MAX_VIEWING_DISTANCE) { //outside of the viewing distance -> do projection magic

setScale(MAX_VIEWING_DISTANCE / dist);    //shrink the object

     // Now that we made the object smaller, put it closer to the camera

v.set(realPosition); //Set helper vector to planet position
v.sub(camPos); //calculate direction vector from camera to planet
v.normalize(v); //and normalize it
v.scalarMul(MAX_VIEWING_DISTANCE); // Calculate new position within viewing distance
        v.add(camPos);  // add camera vector to get final object position

  //Move it!
        clearTranslation();
        translate(v);
   }

   else { //planet is within viewing distance; reset size and position to real values
setScale(1);
        clearTranslation();
translate(realPosition);
  }


The Space Combat Sim Armada has reached Alpha Status. Get the APK here:
http://www.ironman-project.com/armada.apk

The easiest way to get it is by opening the link above on your Android browser.
Alternatively, you can download the APK to the PC, transfer it to your mobile device and install it from here.

Alpha status means:

• Graphics (GUI stuff mainly) and some sounds are not final
• There will be a few tweaks to the missions etc.
• You will encounter some bugs.

Note that you need a pretty potent device, preferable with a 5" or bigger screen, for full play experience. 
In-game payments are not active, but you get 99 instant repairs and 1000 startup credits instead.

Have fun!

edit: you can also try to scan this QR code to get the game

That's strange.. when I fly my jet into a space station (about 5x the size), often fly right trough it. When I turn around and try it again one, two or three times, the ship crashes okay. Same thing happens when colliding with other objects (all bigger than the jet)

Code snippet that is called every frame:


if (model.checkForCollision(xAxis, (float) (speed*ticks)/100) != Object3D.NO_OBJECT) {
   kill();
}


(xAxis points forward)

Already checked:

• latest Engine version
• Collision_check_self is set on jet model
• Collision_check_others is set on space station model
• Objects are all built
• Tried to play around with the "step" parameter making it longer/shorter

Still, only collides 1 out of 3 times.

I used the mesh serializer plugin to convert my 3ds files.

.3ds looks like this:



.ser looks like this:


The red gun mounts are projected from child objects with identical relative positions in both cases.
Also, when playing the game and the camera is mounted at (0,0,0) looking forward, the guns are not firing symmetrical.

So it seems the ship model itself is slightly displaced or rather the center is calculated different, so relative positions change from 3ds.

btw, I'm calling world.buildAllObjects() in both cases.

After seeking the reason for frequent GCs in my code for half of last night I found it's the ships' engine glow (a semi-transparent plane with additive blending).
To be exact it's the billboarding on them. Removing setBillboarding(true) eliminates nearly all GCs.
I suppose I could do the billboarding calculation myself, but maybe it's possible for you to take a look. Thx!