Hi I have a box2d compound body which is intended to be a vehicle seen in profile. when it goes backwards i'd like it to face the other way ie flip/reflect on the x axis. is there an easy way to so this? I find nothing in google though much false hits due to other uses of word reflection.
I could recreate the body but I'd have to do the whole out-of-time delete/add thing? and it seems a bit cumbersome. i tried body.getFixtureList and setting the vertices but tyhe method is flagged don't change the list. does that mean don't add remove? or don't edit? Anyways nothing changes on screen. Off to double-check my code...
Am I missing something?
Changing the vertices won't work. Only possibility to do that is to recreate the body as you said. And don't think that it will be slow just because you will have to delete it and then create it again. Box2d could probably create 100 of your vehicles in one frame without having too much of a struggle.
And for the whole flipping process you would scale your vertices x component by -1. And if your vertices origin wasn't in center of shape you would have to adjust the x coordinate of the whole vehicle (or just have the origin properly placed in the first place).
Also when recreating the body you would probably want to save the linear and angular velocity of your original body. And then once you create the new one apply those velocities to the new body. If you don't do that you would make your vehicle freeze once you do the flip.
Related
I have a graph with vertices and edges (orthogonalEdgeStyle) and want to create new edges. After the creation the routing most times crosses existing vertices. Is there any possibility to route the new edges in a way that they not cross any vertex?
The best solution would be that other edges are also not crossed, but I think this is even more complex.
Any help is appreciated, if there is no build-in functionality (I found nothing), perhaps anybody has an idea where to start (overwrite function, algorithm)?
I'm also searching for a possibility to automatically create "bridges" if two edges are crossing.
I'm trying to get my box2d box to bounce when hitting another box2d box. The physical properties to both objects are set thus..
fixtureDef.density=1;
fixtureDef.friction=0;
fixtureDef.restitution=0.9;
And when I apply this line (which is meant to be the correct way of doing things) I get no bounce.
myElementsArray[0].myPhysics.myBody.ApplyImpulse(newVec, myElementsArray[0].myPhysics.myBody.GetWorldCenter());
But when I change the 2nd, part to some random vector, it bounces
myElementsArray[0].myPhysics.myBody.ApplyImpulse(newVec, new b2Vec2(20,20));
Which I don't get, what am I doing wrong?
The "bounce" you are seeing is probably a bit deceptive. I'm not a physics guru, I only know enough be dangerous as my main focus is game programming. Anyway here goes, the first statement uses the center of mass to apply the force to. When you are calculating a "bounce" using restitution, in most physics libraries it would very simply grab the largest restitution between the two collision objects:
restitution = Max( bodyA.restitution, bodyB.restitution )
Then disregarding torque, the new differential final velocities with respect to the restitution is:
–restitution * (bodyA.initialVelocity - bodyB.initialVelocity)
This is also more standardly written as:
–e(V1i - V2i)
Why is this important? Because this is probably the reason you are not seeing a bounce, the two initial velocities (without torque) are zeroing out. Now the second call to ApplyImpulse() uses a coordinate that is not the center of mass of the body. Because of this, Box2D is going to attempt to apply an angular velocity to the body. With that in mind a new series of equations will be used. I'm fairly confident that is where the problem resides, but someone else might correct me or know more about it.
When creating Box2D sidescroller game, is it performance friendly to scroll through every object and move it (for example by x axis) as it does in the following code snap:
for(Body b: bodies) {
b.setTransform(-1, b.getPosition().y, b.getAngle());
}
I was also wondering about the rendering, if I render every texture on every body, I would be rendering the whole level at once and it would cost a lot of my precious FPS.
In contrast to the comments saying that this is a good way to do it, I don't think so.
It is not intuitive to move every entity in your world. When you run around through a forest in real life, the trees also don't move around you, but only you move.
Use an OrthographicCamera and change its position. When rendering via a SpriteBatch, draw all bodies exactly on the position where they are (probably with some METER_TO_PIXEL scaling factor) and use spriteBatch.setProjectionMatrix(camera.combined) on your SpriteBatch. This way only the visible bodies will be drawn automatically, since the camera transformation will get rid of all non-visible bodies.
And another hint: Try to avoid Body.setTransform(). Instead try setting linear velocity or apply forces/torque on the bodies. Using setTransform causes non-physical behaviour since it's basically like teleporting and might lead to weird effects and in my case sometimes even bugs.
So created a Sprite to which I add other Sprites which are game tiles. Each tile is 60 x 60 px big. In result I've the Sprite with about 200 childs (those tiles).
When I try to startDrag() the container sprite the lag when moving it is very noticeable..
Is there a way like to join the tile Sprites so the container would have only 1 child Sprite instead of 200? Because it lags so much probably cause it needs to move (change the x and y) all those 200 tiles.. Am I correct?
In this case I can't use the cacheAsBitmap property, cause user can zoom in or zoom out the map..
Glycerine & Aurel do touch the crux of the real solutions. However I'd like to add.
You are correct by the way, when you said it has to manage so many sprite locations when you move the container around. CacheAsBitmap sure does does tackle this to great extent but the real solution is blitting. Try this link for that :
http://www.adobe.com/devnet/flash/articles/blitting_mc.html
It doesn't matter if a user zoom or something of that sort is required cause you can always switch between bitmap data & the original vector sprites. Your problem arises in moving.managing lotsa sprites, so just before doing that use optimizations, after that let them be back to their selves.
I've had the same issue before. Is it possible to 'join' them together - in a sense.
When you add your 200 sprites onto a screen - I assume you put them all into another parent sprite.
A this point - you will take a snapshot, or a screenshot - or a photographic replica (whatever you want to call it) of all the sprites and write the image (bitmapData) to a parent sprite. At this point. delete/remove/hide/nullify the original sprites and you'll be left with a sprite containing bitmap data.
One big image to move about and zooming and the like is no bother.
If you need code - ask. It's time consuming code so you tell me first then I'll write it :P
Hm, joining them would actually be quite hard... You would need to get the graphics, the code and all and put that into the parent...
I don't think that is the problem - you should do something else... In this case, I think that by "tiles" you mean that the parent would be a tile map, correct? So, you probably have a 2-dimensional array (array of arrays) with tile types - instead of parsing that array at initialization, creating A LOT of Sprites, try re-parsing it in each frame (it is faster), but add only the Sprites that are possible to see. That is - their X position (after adding the zoom and camera X) is greater than -sprite.width, where the height is also scaled by the zoom, and lesser than stage.width + sprite.width (again, width after zoom). Same goes for Y, only with the height attributes.
I'm creating a space game in actionscript/flex 3 (flash). The world is infinitely big, because there are no maps. For this to work I need to dynamically (programatically) render the background, which has to look like open space.
To make the world feel real and to make certain places look different than others, I must be able to add filters such as colour differences and maybe even a misty kind of transformation - these would then be randomly added and changed.
The player is able to "scroll" the "map" by flying to the sides of the screen, so that a certain part of the world is only visible at once but the player is able to go anywhere. The scrolling works by moving all objects except for the player in the opposite direction, making it look like it was the player that moved into that direction. The background also needs to be moved, but has to be different on the new discovered terrain (dynamically created).
Now my question is how I would do something like this, what kind of things do I need to use and how do I implement them? Performance also needs to be taken into account, as many more objects will be in the game.
You should only have views for objects that are within the visible area. You might want to use a quad tree for that.
The background should maybe be composed of a set of tiles, that you can repeat more or less randomly (do you really need a background, actually? wouldn't having some particles be enough?). Use the same technique here you use for the objects.
So in the end, you wind up having a model for objects and tiles or particles (that you would generate in the beginning). This way, you will only add a few floats (you can achieve additional performance, if you do not calculate positions of objects, that are FAR away. The quad tree should help you with that, but I think this shouldn't be necessary) If an object having a view leaves the stage, free the view, and use the quad tree to check, if new objects appear.
If you use a lot of objects/particles, consider using an object pool. If objects only move, and are not rotated/scaled, consider using DisplayObject::cacheAsBitmap.