What is the best way to make sand particles animate in a view?
Essentially, I would like to half fill the iOS device's screen with small sand-like particles, then allow a user to rotate and shake the device to dictate the sand's position.
Assuming I have never done any physics programming before, can anyone recommend a tutorial or show me how it's done?
Thank you,
Query.
UPDATE:
I have now come across this (mine should be 2D though) - how can I bring something similar into my app?
Using spatial indexing for finding the nearest-particles to check for collision and using an integration technique for the transition between force(acceleration)-velocity-position and using only gravity force as an outer-fource would give you your sand-box.
You will need to select a good exclusion-force derived from a particle-potential if you use post-collision detection.
I advise you to use the Truncated Lennar-Jones potential and Verlet-Integrator. Easier than Runge-Kutta's and more precise than Euler's. Because it is used in molecular-dynamics. You dont need to use other forces . Just use exclusion force, gravity and wall forces.
If you have bullets in your simulator, you can use Euler-Integration for them. I think this is acceptable for free-falling but not colliding sand particles. After they close each-other, it would be good to use Verlet or Runge-Kutta.
All i mentioned above assumes your integration step is so big that energy is not conserved and even decreased. If your integration is good enough to conserve energy, you will need to give your particles friction force to make sands slow or you will get your particles exploding everwhere.
If you like to make it on iphone then you have to think of certain optimizations and tricks as iPhone can't really simulate water or sand.
Your trick is that most of your work is to draw scene.
Create scene in Box2D with balls at size 10-20 times bigger then sand particle.
iPhone would be able to simulate it.
Then you should draw 10-20 sand particle per ball.
Every frame you may check if ball collides with other balls or not.
If balls is not colliding then these sand particles are in the air and you should draw them on certain distance one from each other.
If ball collides with other balls then particles should be rendered together
You may also detect margin and render glider sand border on top.
Related
I am just a beginner in game developing. Right now I am developing a game using Apple's Sprite kit and found out that the best way to position nodes on the scene is to provide percentages of width and height of the window boundaries as it makes sure all the nodes maintain their positions almost regardless of change in device display size. Using pixels to position nodes is not a peculiar idea as with the change in device display size of iPhone, nodes are either cut off or the scene squeezes leaving empty space around the scene boundary. I have watched how Apple recommend using scene editor but my issue is, using scene editor it allows you to position nodes by choosing pixels and not relative to to scene width or height. Am I making a mistake in understanding the scene editor capability. If I position all my nodes using scene editor as its saves a lot of time, how can I avoid problem with different iPhone sizes. I appreciate your help.
This is an age old problem, from all media formats.
You must decide, personally, what your favourite and most desirable target device is, and then make choices best for both it, and your creative process.
After making that decision you'll have to make your own decisions on how compromised you become on other devices, or how much you compromise your creative and production processes to benefit other device sizes and aspect ratios.
It's a balancing act.
And I strongly suggest favouring your favourite device and putting off all consideration of adaptation to other devices until after you've made something great.
Others will disagree.
How to correctly implement the blocks in the drawing view, so that when they could cut the line in two parts. Using UIImageView or UIImage?
After the cut blocks should fall under the influence of physics.
First, how many cuts could happen in total? How many independent pieces of block could result? 10? 100? Before implementing any of these, test moving that number of objects around on an iPhone or iPod touch. Just because it works on the simulator does not mean it will be fast enough on the actual device.
Second, as already noted, there are libraries for game graphics and physics that may do a lot of the work for you. Cocos2D appears to be a popular option, combining OpenGL drawing with relatively easy access to physics libraries.
Anyway, to do your own drawing, here are the choices:
Move all the graphics into OpenGL. This should not be undertaken lightly - you lose a lot of the ease of working in Cocoa Touch. You also have maximum control over your graphics and animation, and can achieve the smoothest performance if you take the time to optimise it.
Have a single UIView, adding CALayer sublayers to its main layer for every independent block. CALayers are designed for rapid moving and compositing. However, if you're running a physics simulation, your first step will be to remove their animation behavior. This tutorial series may be useful.
Have a separate UIView for each block. This will have similar performance to using CALayers, as UIViews are actually drawn with CALayer. This option will use up more memory, (you have at least as many layers and more views than before), but you have all of the power of CALayers plus a few drawing options that are easier on views.
Have a single UIView, and draw every block during its drawRect method. This may look easy to implement, but it will almost certainly be too slow.
If at all possible, test each of these. Before you continue with the cutting and physics parts, how many blocks can you animate across the screen before it slows down too far? Can you make a game with that Remember that your physics system will slow the game down when it does work.
I'm using following ratio for pixel to meter conversion,
PTM_RATIO=32;
v3BodyDef.position.Set(2848/PTM_RATIO, 102/PTM_RATIO);
This this produce weird output many times on the screen, so does setting position(v3BodyDef.position.Set) take floating point variable or not I don't know, but I think this conversion making trouble.
Please help me with this.
Thank you.
There isn't a recommendable ratio for that (though some will try and convince you there is).
The scale of objects in your physics engine should depend on the average scale of your dynamic objects. What I mean is, that if your player interacts with a lot of objects "slightly larger" and "slightly smaller" than itself, it's probably best to make player an average size in the optimal range (for example, Box2D is optimized for objects between 0.1m and 10m in size, so make player 1m, or 1.5m).
As for your pixel size, that all depends on how large you want your world to be on the screen.
If you want your hero to be 1/10th of the screen in height, and 2 meters away from the camera, then do the math :-p Others may want their here to be 1/8th of screen height, or 1/12th.. that really depends on how the game will look in the end. If the camera zooms in, the pixel to physics ratio would change. If the screen resolution changes (like a retina display), your pixel to physics ratio will have to change accordingly.
So in practice: there is no set value. It really depends on the game, and depends on what feels best for the hardware you're on.
It's most likely an integer division problem, change PTM_RATIO to a float (or if you are defining it, use #define PTM_RATIO 16.0f )
I have a game that's moving fewer than 10 small animated UIImageViews at once, maximum. I'm driving their animation with a CADisplay timer running at 60fps. Here is an example of how I move the views in my update method:
// for each insect in insectArray
insectView.center = insect.hitCenter // I pull a position from my model object
The graphics are 32 x 32 pixels with up to 5 animation frames each, if that helps. They have an alpha channel for transparency. I've profiled and eliminated any in-game calculations as a bottleneck. I've also made the opacity property = YES, for a very small speedup. Having the animated frames playing or not makes no difference.
The frame rates are mostly great, except on older devices like the iPhone 1G and 3G. There I get intermittent stuttering.
Before switching to OpenGL, is there any way to get a bit more performance?
I experienced the same kind of bottleneck with CoreAnimation; it is very limited in terms of system complexity that you can display with decent performance. From what I have read and discussed with others, there is no silver bullet for you (or me) there, sorry!
My usage was actually quite close to yours (no animated frames, though), and using OpenGL ES made it go from painfully sluggish to perfectly snappy, so there's hope for you!
CoreAnimation isn't designed for frame-by-frame animation, you tell it a few keyframes and times, and it will do the rest for you. Why not switch to OpenGL? You can't support the old devices forever...
I agree with FX that there is no silver bullet, but if you provided a little more code, we could make some specific suggestions. Here are a few general ones:
Don't round corners using -setCornerRadius on the UIImageView's layer. You'd never believe how much this can degrade performance
If you're using drop shadows behind your view, make sure you specify a shadow path on the layer as well.
Try turning -shouldRasterize on on the UIImageView layer: [[insectView layer] setShouldRasterize:YES];
Hate to say it, but after this, as others have said, OpenGL is the only other choice.
For a university term project, I'm working on a graphical roguelike (I'm aware of the contradiction in terms :P) that uses an isometric display. What I'm trying to figure out is, since drawing all the tiles is stupidly expensive and unnecessary, I'm wanting to figure out a relatively fast algorithm to determine which tiles should be drawn to fit within an NxMpx window, given that the tile graphics are XxYpx.
I'm not doing smooth scrolling for this, so that's not an issue. I'm also not worried about being perfect - a little unnecessary draw is fine, I just don't want to draw a huge amount of unnecessary tiles that won't show up in-game.
You need to think about two concepts: Screen space and world space. These are very important in 3d engines, but they apply to all but the very simplest games. In the isometric engine your world-space is a 2d array of tiles.
So you are looking first of all at a way to covert between these two co-ordinate spaces. Once you've done that, it'll be obvious that screen space maps onto the world as a rectange that's turned at 45 degrees. You can determine a formula for that, but it's only important if you are trying to determine which part of the world space is visible so you only simulate monsters in that area (an efficiency necessary on 8 bit consoles, probably not on a modern PC!). When it comes to actual rendering you don't really need to determine this visible region of the world, because it's implicit in the way you render the tiles onto the screen:-
You work out which tile location is at the top-left of the screen, call this O (for origin) - that's going to be a fixed offset from your point of interest, usually the player, that you want to keep in the centre of the screen.
Once you have that you paint the tiles in the top row of the screen, stepping +1X and -1Y in world space for each tile (if you are looking north-east).
Then you paint the row below. That is offset minus one half a tile width in screen space and starts at O -1X in world space.
You repeat steps 2 and 3, modifying your starting position in world space by -1 in X and Y from what you used in the previous stage 2 until you reach the top of the screen.
Other tips:-
Obviously you don't draw any tiles that are outside the map. You might also, depending on game design, not draw any tiles outside a particular room the player is in.
There's not just floor tiles to draw, theres also players, monsters, scenary, etc. The rule is you draw everything in a paricular world location in the same pass. That way objects closest to the 'camera' will obscure stuff behind them (which is why you start drawing at the top of the screen).
Also, you don't just have floor tiles in most iso engines, you would also have furniture and wall segments. You might designate areas of the map as belonging to a particular room, when the focus is on that room (because the player is in it for example), you don't draw the wall segments for the side of the room closest to the camera.
Anyway, that's enough to be getting on with, hope it's helpful and your project goes well.