I'm currently playing with the JME-Jbullet physics engine, and having issues with my terrain.
I have 2 flat boxes, one for the floor, and one to act as a ramp. The issue is as follows:
With the following code:
Box slope = new Box("Slope", new Vector3f(0, -1, 0), 10f, 0f, 15f);
PhysicsNode pSlope = new PhysicsNode(slope, CollisionShape.ShapeTypes.MESH);
pSlope.setMass(0);
pSlope.getLocalRotation().fromAngleNormalAxis( 0.5f, new Vector3f( 0, 0, -1 ) );
Before the rotation is applied, the box acts as normal, if another object is dropped on top, then they collide correctly. After the rotation however, the box is rotated, but its "Physics" doesn't change, so when an object is dropped ontop of what appears to be the ramp, it is acting as though the rotation never happened.
Is there some way to update the ramp so that when an object is dropped on to it, it slides down?
Thanks.
are you remembering to update the physics world in your update method?
public void update(float tpf) {
super.update(tpf);
pSpace.update(tpf);
}
where pSpace comes from PhysicsSpace pSpace=PhysicsSpace.getPhysicsSpace();
The problem is in the collision shape. A mesh is an extremely expensive shape to calculate collisions for, and as far as I am aware of not working properly (yet) in JME. Replacing it by a box collision shape will solve your problem.
As indicated in the javadocs:
getLocalTranslation().set() does not set the physics object location, use setLocalTranslation(), same applies for getLocalRotation()
I would guess from that that you will need to call pSlope.setLocalRotation(...) instead of getting the rotation and modifying it in place.
Related
I'm programming a Strategy RPG using LibGDX, and Tiled as a map editor. I am loading the Tiled map with the Asset Manager and right now I don't have a Texture Atlas (I'm not quite sure yes which will be my definitive textures).
If you are familiar with Strategy RPG games, you should know that when you want to move a character, the cells where you can move it change color. That's what I'm trying to do.
But before figuring that, I'm trying to click a cell and change it's color by changing the texture of the upper layer of that cell, with the following code:
TiledMapTileLayer.Cell selectedCell = new TiledMapTileLayer.Cell();
selectedCell.setTile(selectedTileSet.getTile(0));
StaticTiledMapTile selectedTile = new StaticTiledMapTile(selectedSpriteRegion);
selectedCell.setTile(selectedTile);
selectedTileLayer.setCell((int) Math.floor(screenX / 32), (int) Math.floor((viewport.getScreenHeight() - screenY / 32)), selectedCell);
That code is inside a TouchDown inside a Screen, to be called every time I touch a part of the Screen.
The layer I use is one I set specifically for the highlighted tiles and it is above the rest of the layers in my code, except for the one that has the characters.
Thanks in advance!
I found the error.
Here is the new code:
TiledMapTileLayer.Cell selectedCell = new TiledMapTileLayer.Cell();
selectedCell.setTile(selectedTileSet.getTile(1765));
StaticTiledMapTile selectedTile = new StaticTiledMapTile(selectedSpriteRegion);
selectedCell.setTile(selectedTile);
selectedTileLayer.setCell(screenX / 32, (viewport.getScreenHeight() - screenY) / 32, selectedCell);
So there were two errors. First that the id of the tile was wrong. I thought that because I had one tile, it would be zero, but no, it is 1765 (don't ask me why).
Also, I was setting the wrong cell since the formula I used was wrong. Math.floor wasn't necessary and I was dividing before subtracting in the Y position (can't believe I did that).
That's all! Hope this helps to someone with a similar error in the future!
im trying do develop a Zelda like game. So far i am using bitmaps and everything runs smooth. At this point the camera of the hero is fixed, meaning, that he can be anywhere on the screen.
The problem with that is scaling. Supporting every device and keeping every in perfect sized rects doesnt seem to be that easy :D
To prevent that i need a moving camera. Than i can scale everything to be equally sized on every device. The hero would than be in the middle of the screen for the first step.
The working solution for that is
xCam += hero.moveX;
yCam += hero.moveY;
canvas.translate(xCam,yCam);
drawRoom();
canvas.restore();
drawHero();
I do it like this, because i dont wand to rearrange every tile in the game. I guess that could be too much processing on some devices. As i said, this works just fine. the hero is in the middle of the screen, and the whole room is moving.
But the problem is collision detection.
Here a quick example:
wall.rect.intersects(hero.rect);
Assuming the wall was originally on (0/0) and the hero is on (screenWitdh/2 / screenHeight/2) they should collide on some point.
The problem is, that the x and y of the wall.rect never change. They are (0/0) at any point of the canvas translation, so they can never collide.
I know, that I can work with canvas.getClipBounds() and then use the coordinates of the returned rect to change every tile, but as I mentioned above, I am trying to avoid that plus, the returned rect only works with int values, and not float.
Do you guys know any solution for that problem, or has anyone ever fixed something like this?
Looking forward to your answers!
You can separate your model logic and view logic. Suppose your development dimension for the window is WxH. In this case if your sprite in the model is 100x100 and placed at 0,0, it will cover area from 0,0 to 100, 100. Let's add next sprite (same 100x100 dimension) at 105,0 (basically slightly to the right of the first one), which covers area from 105,0 to 205,100. It is obvious that in the model they are not colliding. Now, as for view if your target device happens to be WxH you just draw the model as it is. If your device has a screen with w = 2*W, h = 2*H, so twice as big in each direction. You just multiply the x and y by w / W and h / H respectively. Therefore we get 2x for x and y, which on screen becomes 1st object - from 0,0 to 200, 200, 2nd object - from 210,0 to 410, 200. As can be seen they are still not colliding. To sum up, separate your game logic from your drawing (rendering) logic.
I think you should have variables holding the player's position on the "map". So you can use this to determine the collision with the non changing wall. It should look something like (depensing on the rest of your code):
canvas.translate(-hero.rect.centerX(), -.rect.centerY());
drawRoom();
canvas.restore();
drawHero();
Generally you should do the calculations in map coordinates, not on screen. For rendering just use the (negative) player position for translation.
I am making a 3d game with LWJGL. In this game, whenever I press an arrow key, I want the screen to rotate in that direction, regardless of the current orientation. I am struggling to implement this in code. Using three glRotatef functions based off of a rotation vector3f, does not accomplish this. Rotating up and down work because glRotatef(rotation.x, 1, 0, 0) is called first, but left and right only work when your not looking up or down. If you are, you rotate around a universal y axis, and camera spins. I saw that another implementation could use gluLookAt(), but I imagine I would encounter the same problem.
EDIT
I thought I solved my issue by changing the order by which glRotatef()'s where called depending on the direction I want to rotate. I thought this would work because in my game, I will only be rotating one axis at a time. It worked somewhat but in some orientations it doesn't.
if(updown){
glRotatef(rotation.x, 1, 0, 0);
glRotatef(rotation.y, 0, 1, 0);
} else if(leftright){
glRotatef(rotation.y, 0, 1, 0);
glRotatef(rotation.x, 1, 0, 0);
}
glTranslatef(position.x, position.y, position.z);
gluLookAt would probably get you there much quicker, but you would need to manually rotate the eye coordinate about the origin coordinate. With gluLookAt you also need to calculate an up vector if you plan to rotate around all 3 axes.
I have a hunch you just need to add a glTranslate before you do your glRotate so that the camera has something to orbit around.
If you show some code you might be able to get more help.
I am over this issue and have moved on. Because I am only going to rotate one axis 90 degrees at a time, I went through all 64 possible orientations and applied the necesary transforations manualy.
Alright so this is going to be a doozy to explain. I'm making a very basic "pseudo-3d" racing game for Android using AndEngine (and in turn, openGL - I think). I don't believe using AndEngine really has anything to do with this problem though, because I'm directly accessing openGL functions to accomplish my drawing.
Anyways, I copy-pasta'd some code that allowed the normally 2d AndEngine to have a 3d perspective (tutorial for such can be found here. This works pretty well, and I also don't believe this has much to do with my problem, but I don't fully understand openGL so it's a little hard for me to say. Here's the code from the onLoadEngine (called when app starts) that sets up the camera with a 3d perspective:
this.mCamera = new Camera(0, 0, CAMERA_WIDTH, CAMERA_HEIGHT) {
//other methods...
private void setFrustum(GL10 pGL) {
// set field of view to 60 degrees
float fov_degrees = 60;
float fov_radians = fov_degrees / 180 * (float)Math.PI;
// set aspect ratio and distance of the screen
float aspect = this.getWidth() / (this.getHeight());
float camZ = this.getHeight()/2 / (float)Math.tan(fov_radians/2);
// set projection
GLHelper.setProjectionIdentityMatrix(pGL);
GLU.gluPerspective(pGL, fov_degrees, aspect, camZ/10, camZ*10);
// set view
GLU.gluLookAt(pGL, 0,120f, camZ, 0, 0, 0f, 0, 1, 0); // move camera back+up
pGL.glScalef(1,-1,1); // reverse y-axis
pGL.glTranslatef(-CAMERA_WIDTH/2,-CAMERA_HEIGHT/2,0); // origin at top left
}
};
Then later in the onLoadScene (where the drawing takes place), I draw a bunch of my images like so:
for (int n=0;n<=100;n++) {
final int k = n;
final Sprite line = new Sprite(0, 0,CAMERA_WIDTH,16f, [AndEngine texture holding road img]) {
#Override
protected void applyTranslation(GL10 pGL) {
pGL.glTranslatef(this.mX, 120f, 15f*k); //16*k causes a sliver of a space between each segment
pGL.glRotatef(90f, 1, 0, 0); //**MAY BE MY ISSUE**
}
};
scene.attachChild(line); //actually draws the image to the screen
}
Which works pretty darn well as well, except for one thing! It distorts the shit out of my images. The images are simple pngs, both matching the CAMERA_WIDTH, and both looking similar to this:
And when I draw it without the rotate line, I get this:
Which has a decently straight middle line (tbh I'd be happy with them this way), but then you can see the edges of the road are all facing basically the exact opposite way they should be facing. I figured why not just flip them? I thought I would have to rotate them 180 degrees around the x axis, but instead that just makes them disappear, and instead I found that 90 degrees works (???). Anyways, Here's what I get:
So yeah. Here's where my problem lies - the middle lane divider is distorted as crap!! The lines marking the edge of the road line up wonderfully, but for whatever reason its really messing with that middle line. I get most of the math behind the 3d, but I really don't know what to make of this...it's almost like the image is being compressed because its being viewed at such a sharp angle, but I don't really know how the hell I could solve that without simply making it a top-down view? :S
Anyways... any ideas or guidance is welcome. Sorry this is such a long and convoluted post - it makes it hard when I really have no idea where the problem lies.
Also - It might be worth noting I have little to no experience with openGL or 3d graphics, and have even less interest in learning much about them in depth. I need a band-aid to this problem!
Ok so I found the solution! Turns out there is this little issue called Perspective Correct Texturing, that is basically just a flag that needs to be turned on in OpenGL to make it not skew images when they are being drawn with perspective.
Inside my Camera initializing code, I added this line to the method setFrustum(GL10 pGL):
pGL.glHint(GL10.GL_PERSPECTIVE_CORRECTION_HINT, GL10.GL_NICEST);
That this essentially solved the problem. Lines are as straight as ever now :) I found this out on another stackoverflow post where this answer actually wasn't what the asker wanted, but it just so happened to work for me :D The thread that led me to the answer can be found here.
In the two attached pictures, the desktop screenshot of libgdx functions as expected. The screenshot from my Galaxy Nexus is unfortunately not as expected. I am attempting to create a simple motion blur or trail effect.
Rendering as I expected on my desktop.
Not rendering as I expected on my Galaxy nexus.
The circle textures are drawn in a for loop during rendering and the effect is achieved with a pixmap using the RGBA of 0, 0, 0, 0.1f that is drawn before the circles.
screenClearSprite creation
Pixmap screenClearPixmap = new Pixmap(256, 256, Format.RGBA8888);
screenClearPixmap.setColor(Color.rgba8888(0, 0, 0, 0.1f));
screenClearPixmap.fillRectangle(0, 0, 256, 256);
screenClearTexture = new Texture(screenClearPixmap);
screenClearSprite = new Sprite(screenClearTexture);
screenClearSprite.setSize(screenWidth, screenHeight);
screenClearPixmap.dispose();
Render
batch.begin();
font.draw(batch, "fps:" + Gdx.graphics.getFramesPerSecond(), 0, 20);
screenClearSprite.draw(batch);
for (int i = 0; i < circleBodies.size(); i++) {
tempPos = circleBodies.get(i).getPosition();
batch.draw(circleTexture, (tempPos.x * SCALE) + screenWidthHalf
- circleSizeHalf, (tempPos.y * SCALE) + screenHeightHalf
- circleSizeHalf);
}
batch.end();
So, what did I do wrong? Perhaps there is a better way to get the 'motion blur' effect of movement?
Here is a different approach, where you clear your screen each time with solid color and no alpha.
This means that you will have to modify your code some. The good thing about this, is that the way you are doing it has some flaws: It will blur everything in motion, not just the balls. And can quickly produce ugly results/artefacts unless you are careful.
Do the same as you are doing now, but instead of drawing the balls to the batch, draw them onto a texture/bitmap/whatever. Then each frame add an alpha-blended image over the balls-image, and then draw the balls in their current position on top of that. Then add that image to your screen. Very much like you are doing now, except you draw to something else and keep it. This way you don't have to rely on the viewport you are drawing onto, and can keep everything separated.
This method is similar to drawing to an accumulation buffer.
Instead of doing it the way you are doing, you can keep track of the n latest positions of each ball. And then draw all of them each frame, with different alpha. This is very easy to implement. Can result in many drawing calls if you have many balls or a large n, but if it's not too much it shouldn't limit your fps and gives nice control.
Perhaps there is a better way to get the 'motion blur' effect of
movement?
in order to make motion blur in my game i use another approch "The particle effect" it works realy fine with me and i didn't have Android/Desktop problems or with different android devices
all you have to do is to use "Particle Effect Editor" of Libgdx and make your effect then load it in your project finally draw it at the same position you draw your object (and alos draw your object)
Tips to make the right effect file with Paticle Editor :
set (use) the same image of the object that you want to blur it motion in the particle effect
try to limit the count : the max number of particle allowed
Disable the "velocity" and "Angle"
parameter
Particle effect help to do motion effect
Hope this will help someone !