I am working on making a demo with circle bodies and want to apply repulsive forces on them so that they get their positions randomly on world. It should somewhat resemble like the planets in the universe. The placement(coordinates) of the bodies should depend on the forces that places them randomly.
Related
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.
I'm currently trying to implement a "crouch" function in my game. I'm using WCK with Box2D.
I have something rather basic, I generate my main character as an extension of a shape. This means that collision is automatically generated from the getgo. This is wonderful for a lot of things, but not everything.
I have a crouch/roll function. The problem is that the hitbox for crouching and standing are the same, so if a box drops onto you while crouching it "levitates" ontop of you since the hitbox is still the standing hitbox.
How would I go about "refreshing" the shape collision? Is there a way to delete the collision and make Box2D recalculate?
It's possible to filter contacts and prevent them from happening (using a contact listener or iterating the world's contact list) but I think there are better ways to do what you want.
You could split the body in two parts, and connect them with a prismatic joint (limits and motor enabled, collideConnected disabled). Standing up you'd have the motor push the parts apart to the upper limit and when crouching you'd pull them together to the lower limit thus reducing the height.
If you need really different shapes (e.g. a rectangle when standing and a circle for rolling around metroid style) this might work: Add both shape's fixtures to the body and use mask filtering to prevent the one you don't need from colliding with anything.
I'm currently building an as3 isometric game, but I'm having a lot of problem with depth sorting. I've searched for a solution, but didn't found anything that match my problem (rectangle objects).
Here is a screenshot of my game:
As you can see, depth sorting works well when it's between 1x1 tiles objects. I simply use their x and y coordinates (relative to the isometric map) to sort them.
The problem comes when I have bigger objects, like 2x2 or 1x4 or 4x1.
Any idea how should I handle depth sorting then?
I don't think it is possible to sort a scene based on a single x,y value for each object if some of them can be long enough that one end should be at a different depth than the other. For instance, consider how you'd handle the rendering if the brown chair in your picture was moved one square down-left (to the square between the blue chair and the long couch). It would be deeper in the scene than the red table behind the couch, but would need to be rendered on top of the couch, which would need to be on top of the table.
I think there are two simple solutions:
Design your
levels using only one sort of overlap for large objects. For
instance, you could specify that an object's depth is based on its
nearest corner, which would require you to avoid putting things in
front of its most distant bits (since it will render on top of them).
Or you could stick with your current code (which seems to use the
most distant corner for depth) and avoid putting anything behind the
nearer parts. You may still have trouble with characters and other
objects that move around though. You might be able to make the
troublesome tiles inaccessible if you're careful with your design,
but in some cases this may be too restrictive.
Break up your large objects into smaller ones
which would have their own depths. You will probably want to go right
down to 1x1 pieces, each of which will have an unambiguous depth. You
might choose keep the larger objects in the code as invisible
containers for the smaller pieces, or they could be eliminated
entirely, whichever makes it easier for you to load up and enable
interaction with the various bits.
Splitting larger objects in to 1x1 sized pieces can also be nice since you can make them modular. That is, you can build differently sized objects by putting together 1x1 pieces in different combinations. If you cut your 2x1 tables in your image in half vertically, for instance, and created a 1x1 middle tile that fit in between them, you could stretch the design out to 3x1 or 10x1, depending on how many times you repeat the middle tile. There's a lot of other ways to make tiled graphics look good with only a modest amount of art required.
Ultima Online emulators (specifically, POL, though there may be others) achieve this through the implementation and usage of the concept of a 'multi' -- a single object comprised of sections of cut-up larger graphics. These cut-up graphics are such that their sprites are vertically-split at the left- and right-corner points of iso grid boundaries.
Other considerations:
- render 'multi' pieces sorted screen-Y axis from top-to-bottom.
- the southern (i.e. screen bottom-left) component of a 'multi' becomes the anchoring tile position (in the case of your couch, its left-most piece).
- consider that each map location can also hold its own vertical stack of objects; offsetting each object's render by screen-Y simulates height/altitude, and these must be sorted bottom-to-top (e.g. lowest-altitude to highest altitude).
Good luck!
I am starting to get a grasp of the HTML canvas and I wanted to know if it is encouraged to use optimization techniques. In games for example, is it encouraged to use bounding boxes and only redraw the portion of the screen that needs redrawing, or do people just blindly redraw everything. I ask this b/c I am creating a new engine for canvas and imposing bounding boxes complicates things greatly (ie. the user no longer has the freedom to quickly draw things to the stage).
Absolutely, it's almost always better to draw only what has changed on the screen at any one time. Attempting to draw everything causes unnecessary rasterisation of the images being drawn into one output image, when it's not even going to change on the screen.
In a small game I made a year ago, I was drawing a 2D array of tiles on the screen and getting around 15 frames per second. When I changed it to draw only the tiles visible on the screen, it was an amazing improvement. It will improve in this circumstance too.
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.