I'm creating a 2d game using the Java version of Box2d.
I know that the engine is generally paired with a separate library to handle animation, but I'm looking for something simple, with a more rustic feel, so I'm considering handling the animation from scratch.
The animation I am trying to create is something for the collision of two objects.
I'm using openGl to handle the graphics, and I pretty much have everything set up with the fps and rendering, it's just a matter of tweaking the frames to make it look smooth.
I tried bliting images of some things that I drew myself and it looked atrocious. I think the main problem is that the animation frame images are not linked to the physics forces and so they don't blend well.
What I want to try next is a sort 'spark effect' using a small number of pixels that sort of resemble 'dust' exploding off of the colliding images. If you've ever played dxball, you may recall a similar effect when the ball collided with the paddle at high speed.
As you can see in the above image, the principles are fairly simple. I figure by creating a set of small bodies with fixtures, I can use the box2d engine to produce this effect. I already have code that grabs the point of collision for all bodies, and am familiar enough with parabolic functions that I pretty sure I can create the force direction.
I'm just not sure if there is a better way of doing this, or how to apply a polynomial function to a body like in the image.
Does anybody know how to achieve this functionality with box2d? Any built in methods or documentation that would be helpful?
As a point of reference, the following snippet of code demonstrates the drawing of a small, red box on all of the collision points.
for(Vec2 point : listener.worldmanifold.points){
glPushMatrix();
newpos = point.mul(30);
glTranslatef(newpos.x, newpos.y, 0);
glColor3f(1,0,0);
glRectf(-2, -2, 2, 2);
glPopMatrix();
}
Related
How do you draw elements with JBox2D? I'm fine using the DebugDraw, I just want to find a quick way to do this in Java since I haven't worked much with graphics.
Do I need to use a Canvas? Or a JFrame? And how does the world know when I call
world.drawDebugData()
where to draw it to?
How could I devise a class that just drew points where I want them, and integrate this with JBox2D?
...
while(true)
world.step(timeStep, velocityIterations, positionIterations);
Vec2 position = body.getPosition();
float angle = body.getAngle();
System.out.printf("%4.2f %4.2f %4.2f\n", position.x, position.y, angle);
}
I imagine I could put this code somewhere inside this while loop, but I'm not exactly sure where. Is there a function that's called every time a World steps? Can I put a draw function in there? I'm even ok using the DebugDraw if I could figure it out...
Could you please help me understand what kind of class would take all the objects in the World object and draw them continually? (and where to draw to?)
You can easily create new testbed tests, this is the best way to test out your new physics ideas and not worry about drawing and GUI stuff. It even supports adding extra real-time options. Check it out here:
https://code.google.com/p/jbox2d/wiki/Testbed
It's difficult to know where to organize everything if you're not used to programming games and physics engines.
Dyn4j is another great physics library that has great examples explaining where to put everything and even how the user can interact with the world. A lot about the dyn4j library is identical to box2d/jbox2d, so if you just try out their examples real quick, it will lend a hand to figuring out how to render graphics in box2d.
I'm trying to make it so when a sprite which is attached to a physics body overlaps another sprite on the level something happens. The second sprite is NOT attached to a physics body.
More specifically when the two sprites are overlapping I want the game to constantly check to see if the distance between the centers of the sprites is less than a certain amount or not. Then if the distance is small enough something will happen.
I'm trying to use collision checking as a way of optimizing the game so it doesn't have to constantly check distances between every single object of type A and B even if they're not even close. It will only check the distance when they're close enough to be overlapping.
Now what I am wondering is how can I do this? Is there a way to check collisions between sprites as part of AndEngine? Or would it be easier to attach a physics body to the second object also and then just use physics collision detection? But then if I do that can I make it so the collision will be detected but they won't actually physically "collide"?
Yes, see CollisionDetectionExample.java. I suggest you download the whole examples package, it is very useful in the absence of any documentation for AndEngine. Please note that collision detection is not pixel perfect, so it will still detect collisions of transparent parts of the Sprites. There is a library for that, but I am afraid it is outdated.
I'm kind of new to JOGL, and I am working on a game. I have a rocket, stars in the background, and planets. I want the rocket to remain stationary at the bottom of the screen, the GO button to be pressed, and then planets start coming down for the rocket to avoid.
I keep ending up with hitting go, the planets coming down (via translation), and the rocket also going down. I know Why this is happened with the camera moving, so the whole world is moving. I've been trying to use the pushMatrix and popMatrix, but haven't had any luck.
i.e.
if (goButtonPressed)
{
//gl.glTranslatef(0.0f,0.3f,0f); // this line just keeps the whole thing still
drawRocket(gl); // I was trying to 'undo' the translation
gl.glPushMatrix();
gl.glMatrixMode(GL.GL_PROJECTION);
gl.glTranslatef(0.0f, -0.3f, 0f);
gl.glPopMatrix();
}
Is what I am trying to do possible in opengl? Am I making it too difficult?
Instead of relying on the projection matrix to hold the state of your rockets' positions, how about storing this information in your own code and then passing absolute coordinates to JOGL? Then updating the position of an object can be done with a more obvious bit of code like rocket.y += dy;.
As a small aside, the projection matrix is not intended to be used for spatial transformations. Use GL_MODELVIEW instead to avoid subtle problems down the road.
Not exactly an answer to your question, but you should look at JMonkeyEngine if you want to make a game with opengl in Java.
http://jmonkeyengine.com/
The thing you are trying to do is certainly possible with opengl and fairly easy to do with JMonkeyEngine. They have plenty of tutorials and such on their site.
I'm new to OpenGL. I'm using JOGL.
I would like to create a sky for my world that I can texture with clouds or stars. I'm not sure what the best way to do this is. My first instinct is to make a really big sphere with quadric orientation GLU_INSIDE, and texture that. Is there a better way?
A skybox is a pretty good way to go. You'll want to use a cube map for this. Basically, you render a cube around the camera and map a texture onto the inside of each face of the cube. I believe OpenGL may include this in its fixed function pipeline, but in case you're taking the shader approach (fixed function is deprecated anyway), you'll want to use cube map samplers (samplerCUBE in Cg, not sure about GLSL). When drawing the cube map, you also want to remove translation from the modelview matrix but keep the rotation (this causes the skybox to "follow" the camera but allows you to look around at different parts of the sky).
The best thing to do is actually draw the cube map after drawing all opaque objects. This may seem strange because by default the sky will block other objects, but you use the following trick (if using shaders) to avoid this: when writing the final output position in the vertex shader, instead of writing out .xyzw, write .xyww. This will force the sky to the far plane which causes it to be behind everything. The advantage to this is that there is absolutely 0 overdraw!
Yes.
Making a really big sphere has two major problems. First, you may encounter problems with clipping. The sky may disappear if it is outside of your far clipping distance. Additionally, objects that enter your sky box from a distance will visually pass through a very solid wall. Second, you are wasting a lot of polygons(and a lot of pain) for a very simple effect.
Most people actually use a small cube(Hence the name "Sky box"). You need to render the cube in the pre-pass with depth testing turned off. Thus, all objects will render on top of the cube regardless of their actual distance to you. Just make sure that the length of a side is greater than twice your near clipping distance, and you should be fine.
Spheres are nice to handle as they easily avoid distortions, corners etc. , which may be visible in some situations. Another possibility is a cylinder.
For a really high quality sky you can make a sky lighting simulation, setting the sphere colors depending on the time (=> sun position!) and direction, and add some clouds as 3D objects between the sky sphere and the view position.
I need a suggestion/idea how to create a 3D Tag Cloud in Java (Swing)
(exactly like shown here: http://www.adesblog.com/2008/08/27/wp-cumulus-plugin/)
, could you help, please?
I'd go either with Swing and Java2D or OpenGL (JOGL).
I used OpenGL few times and drawing text is easy using JOGL's extenstions (TextRenderer).
If you choose Swing, than the hard part will be implementation of a 3D transformation. You'd have to write some sort of particle system. The particles would have to reside on a 3D sphere. You personally would be responsible of doing any 3D transformation, but using orthogonal projection that would be trivial. So it's a nice exercise - what You need is here: Wiki's spherical coord sys and here 3d to 2d projection.
After You made all of the transformation only drawing is left. And Java2D and Swing have very convenient API for this. It would boil down to pick font size and draw text at given coordinates. Custom JPanel with overriden paintComponent method would be enough to start and finish.
As for the second choice the hardest part is OpenGL API itself. It's procedural so if You're familiar mostly with Java You would have hard time using non-OO stuff. It can get used to and, to be honest, can be quite rewarding since You can do a lot with it. If you picked OpenGL than you would get all the 3D transformations for free, but still have to transform from spherical coordinate system to cartesian by yourself (first wiki article still helpful). After that it's just a matter of using some text drawing class, such as TextRenderer that comes with JOGL distribution.
So OpenGL helps You with view projection calculations and is hardware accelerated. The Java2D would require more math to use, but in my opinion, this approach seems a bit easier. Oh, and by the way - the Java2D tries to use any graphic acceleration there is (OpenGL or DirectDraw) internally. So You are shielded from certain low-level problems.
For both options You need also to bind mouse coordinates s to rotational speed of sphere. Whether it's Java2D or OpenGL the code will look very similar. Just map mouse coordinates related to the center of panel to some speed vector. At the drawing time You could use the vector to rotate the sphere accordingly.
And one more thing: if You would want to try OpenGL I'd recommend: Processing language created on MIT especially for rich graphic applets. Their 3D API, not so coincidentally, is almost the same as OpenGL, but without much of the cruft. So if You want the quickest prototype that's the best bet. Consult this discussion thread for actual example. Note: Processing is written in Java.
That's not really 3D. There are no perspective transformations or mapping the text on some 3D shape (such as, say, a sphere). What you have is a bunch of strings where each string has an associated depth (or Z order). Strings "closer" to you are painted with a stronger shade of gray and larger font size.
The motion of each string as you move the mouse is indeed a 3D shape which looks like a slanted circle around a fixed center - with the slant depending on where the mouse cursor is. That's simple math - if you figure it for one string, you figure it out for all. And then the last piece would be to scatter the strings so that they don't overlap too much, and give each one the initial weight based on their frequency.
That's what most of the code is doing. So you need to either do the math, or translate the ActionScript to Java2D blindly. And no, there is no need for JOGL.
Why don't you just download the source code, and have a look? Even if you can't write PHP, it should still be possible to read it and figure out how the algorithm works.