seeing as how box2D bodies cannot be resized, I have a problem with bodies and my animated sprites.
here's the situation which I have no doubt is not unique:
my sprite's dimensions slightly change during different motions like attacking, walking, jumping. seeing as how I was about to use box2D body for collision detection this can cause quite a problem.
so far I thought of 3 ways to solve this issue.
1- not use box2d bodies for collision detection , just use them for object's physical behavior
2- delete and recreate body before each render. or on animation change.
3- trying to recheck the collision on bodies to see if it actually collides with the sprite itself. then act.
and here's the problem I have with each of these solutions.
1- this way makes using box2d as a whole seem rather absurd, also I'll be using not one, but two world logic and trying to keep them in sync. seems like a big headache.
2- this doesn't look very optimized, also I doubt I can just make objects pop in and out of existence in a physics world without side effects.
3- I'm not sure how or even if this can be done, actually this option is the one I require more advice on. will this cause any difficulties in the long run, or cause conflicts in physics.
please let me know if there is a efficient way to solve this , or if any of the above solutions is worth working on.
my thanks
Edit:
It was more of a general question since I still don't have proper graphics for the game I'm writing, but here's my practice material:
walking waiting (standing)
attacking
A body can have multiple fixtures, so you can add all fixtures for each state to the body. If you make them zero density it should not affect the physics behavior of the body. Keep in mind though, that at least one fixture on the body should be non-zero density - you could make one fixture to act as the main fixture, which has density to give the body some mass.
If you just need to detect when these fixtures are touching something, you could make them sensor fixtures, and use your contact listener to keep track of what other things they are currently touching. The contact listener would give you callbacks about all of the fixtures regardless of which state your character is in, and for each state you would keep a list of which things the fixtures for that state are touching.
If you need the fixtures to have physical interaction but only when their state is active, you could do the above but also in BeginContact you would do contact->setEnabled(false) if the contact is for a fixture that is not currently in active state.
Related
My java application requires a 2d physics engine for a horizontal world, however, looking at jbox2d and dyn4j, it seems that they don't offer what I need out-of-the-box. Specifically, they don't support defining which object groups can collide with others. Consider this simplified model: Bullets can collide with boxes. Planes pass through boxes, but they can collide with bullets.
How do I exclude certain groups of objects from colliding in a physics engine?
Dyn4j has the CategoryFilter. You create CategoryFilters with two longs and set those in your Fixtures. It's a little funny how the filters work because the category and mask are used in their binary forms to determine who can collide with who. To see this in practice check out this #Test from the Dyn4j repo.
Dyn4j also mentions this in the docs:
There are three Filter implementations provided, the Filter.DEFAULT_FILTER, the CategoryFilter (just like Box2D’s collision filter, int category + mask), and the TypeFilter.
So I'm assuming Box2D has this too (and jBox2d by extension). I'd say just about any physics engine at Box2D's or Dyn4j's level will have this ability in some form.
There is a solution in box2d (and jbox2d respectively).
The "PreSolve" method allows to disable a contact before colliding. See this question on gamedev which has pretty much the same problem as described here.
From documentation:
Pre-Solve Event
This is called after collision detection, but before collision resolution. This gives you a chance to disable the contact based on the current configuration. For example, you can implement a one-sided platform using this callback and calling b2Contact::SetEnabled(false). The contact will be re-enabled each time through collision processing, so you will need to disable the contact every time-step. The pre-solve event may be fired multiple times per time step per contact due to continuous collision detection.
I'm trying to make rogue-like game. Now i'm using Box2D to detect collisions with enemies (so i can destroy them when i collide with them), but i don't have any idea how to handle player's attack. I need to attack outside of my box2D player's body, i tried to create sensor's bodies when i'm attacking, but it didnt work for me (
Any suggestions about it ?
p.s sorry for my Indiano english ;D
You can either add/remove Sensor fixtures every time you attack or use Ray-Casting. I use both, depending on the dynamics of the attack (a dagger stab for example could be as simple as one ray-cast ray). I did quite a lot of research on this since I thought it would be ti heavy to add/remove things every time an attack occurs but there is no other feasible way with Box2D.
I'm trying to decide between several ways of drawing images for objects in a game.
I want objects to have their own draw() method, but I'm afraid that I may cause unnecessary copies of the image or some other drop in efficiency, noticeable or not.
The first way loads the BufferedImages when the level starts.
public class levelone{
BufferedImage imageguy;
public void draw(Graphics2d g){
g.drawImage(imageguy, null, guy.getx(), guy.gety());
}
}
The second way loads the image in the guy.class and draws it from there with just a guy.draw(g); call in the levelone.class.
The third way loads the image in levelone.class and draws it from guy.class with just guy.draw(imageguy, g); in levelone.class.
Help me understand the best way to go about this please. If it's not clear what I'm asking, do tell and I'll try to make it more comprehensible.
This is more of a design question. For a start, this:
... some other drop in efficiency, noticeable or not.
... is not a very healthy or productive way of thinking. If it's not noticeable, it's not worth worrying about. Otherwise you might as well be writing your game in assembly code if you are going to obsess over every clock cycle.
But there might be broader scale design-level scalability concerns here of note.
It's worth noting that coupling rendering/drawing logic with a high-level class can become a maintenance burden. It depends on the scope of your project, but if it's a rather large project, you'll have a lot more breathing room if you separate the drawing/rendering logic from your game logic. Then you can focus your full attention on just what a "Monster" or an "Item" or something of that sort needs to do from a game design standpoint without worrying about how it'll be drawn. The drawing is done elsewhere.
But if we assume you want to have the drawing logic inside these objects anyway, then it seems like your question ultimately boils down to where you want to store some image buffers for graphics related to the objects in your game.
And the short answer is, "it depends". What assumptions do you feel confident making? For example, in your posted code:
public void draw(Graphics2d g){
g.drawImage(imageguy, null, guy.getx(), guy.gety());
}
... this seems kind of ridiculous if all you'll ever do is blit the object image to the graphic. If all you're ever going to do is blit the item's image to the graphic, then you might as well eliminate the draw method outright, expose a public accessor to the image, and let one central place handle the responsibility of blitting those images at the right time and place.
And at that point, if all you're doing is storing images and exposing accessors to them in your objects, then you might as well let the outside world concern itself with loading/storing those images and blitting them, leaving your objects clean and devoid of drawing logic outright. That'll also give you the most flexibility to optimize when and how things are drawn without intrusively touching all your objects.
But are you always going to just blit images from an object? Will there ever be a case where an object in your game might draw additional things, shapes, text, etc? If so, you might want to keep the draw method.
So the ultimate question to me is, do you really want to do drawing inside your objects or not?
If not, then you'll have the most flexibility to optimize to your heart's content, since you can leave the responsibility of most efficiently loading and storing and drawing graphics to a central render engine instead of spreading that responsibility over every object in your game (and potentially having to change all of them if you ever want to do things differently).
if you do want this, then you might as well fully encapsulate all the details involved with rendering an object inside an object, including keeping whatever assets it needs to do that so that the outside world doesn't have to bother with it and can just call 'draw' and pass in a drawing target (Graphics2D, e.g.).
So I would suggest that maybe none of your proposals may be ideal. But if there's one option that might be bad, I'd say it's your third. That is:
The third way loads the image in levelone.class and draws it from
guy.class with just guy.draw(imageguy, g); in levelone.class.
The problem here is that you're kind of getting the worst of both worlds. You're leaking the drawing details of this 'guy' to the outside world, but the outside world still has to depend on the 'guy' to do the drawing by passing those drawing details back in. If nothing else, you want to really give either the guy or the outside world the primary responsibility here, with the latter being more flexible, but the former being more encapsulated. When the outside world has to pass a guy's image back to the guy for the guy to draw, then you get neither of these benefits. If you really want a guy to "draw himself", then you generally want to be able to do it without too much help from the outside. Give one entity the firm responsibility instead of spreading it across multiple.
About unnecessary copies of the same image, that's easily solved no matter what you do with a central image cache. An easy way is just use a map. When loading an image, search the map for the path. If it already exists, return a reference to an already-loaded image. Otherwise load the image and insert that the path/image as a key/value pair to the map.
If I'm making a game and I want certain things to only update every so often, what's the best way to approach this?
My naive thinking is just keep a "frame" tracker that cycles via mod. math and update certain things at certain numbers.
Is there a better approach?
Much appreciated!
The easiest way to fit your game 'loop' into the libgdx system is to assume your ApplicationListener.render() method is invoked at some unknown (and perhaps variable) frequency. In this callback you'll need to figure out how much time has passed since the last call, update any time-dependent actors, and then draw the update.
This means you should make decisions about updating something "every so often" based on actual elapsed time, and not number of frames.
See the accepted answer on this question for some sample code that does this (note the 'getDeltaTime()' calls):
How to move a sprite with the keyboard keys using libGDX?
I have been looking into box2d (in java with libgdx) lately and have been trying to create my own custom bounce effect (I increase the Restitution after the first bounce)
To do this as a test I simply checked the location of the object and waited for the first bounce.
But now I wanted to actually implement this and came across a problem: How to detect the collision of 2 specific object in box2d?
I found this tutorial:
box2d collision detection - but I am very reluctant to use that code. There must be a simpler and cleaner way to detect a collision between 2 objects (without having to set user data and checking all collisions with giant if() conditions...)
Can anyone help me out? (assuming I am not just hopeful and there actually is a better way)
Subclass b2ContactListener class to handle the collision and reimplement collision callbacks. Then just:
MyContactListener *listener = new MyContactListener();
myB2World->SetContactListener(listener);
And take note, some solutions don't have shortcuts as always but you can find the right solution and there is possibly a hundred ways to detect a collision and you know it, don't you? This is like in the solution of box2d collision detection program for example.
http://blog.allanbishop.com/box2d-2-1a-tutorial-%E2%80%93-part-4-collision-detection/