Search Results

Search found 1184 results on 48 pages for 'movement prediction'.

facebook twitter digg google delicious technorati stumbleupon myspace wordpress linkedin gmail igoogle windows live tumblr viadeo yahoo buzz yahoo mail yahoo bookmarks favorites email print

Page 15/48 | < Previous Page | 11 12 13 14 15 16 17 18 19 20 21 22  | Next Page >

  • Separating physics and game logic from UI code

    - by futlib
    I'm working on a simple block-based puzzle game. The game play consists pretty much of moving blocks around in the game area, so it's a trivial physics simulation. My implementation, however, is in my opinion far from ideal and I'm wondering if you can give me any pointers on how to do it better. I've split the code up into two areas: Game logic and UI, as I did with a lot of puzzle games: The game logic is responsible for the general rules of the game (e.g. the formal rule system in chess) The UI displays the game area and pieces (e.g. chess board and pieces) and is responsible for animations (e.g. animated movement of chess pieces) The game logic represents the game state as a logical grid, where each unit is one cell's width/height on the grid. So for a grid of width 6, you can move a block of width 2 four times until it collides with the boundary. The UI takes this grid, and draws it by converting logical sizes into pixel sizes (that is, multiplies it by a constant). However, since the game has hardly any game logic, my game logic layer [1] doesn't have much to do except collision detection. Here's how it works: Player starts to drag a piece UI asks game logic for the legal movement area of that piece and lets the player drag it within that area Player lets go of a piece UI snaps the piece to the grid (so that it is at a valid logical position) UI tells game logic the new logical position (via mutator methods, which I'd rather avoid) I'm not quite happy with that: I'm writing unit tests for my game logic layer, but not the UI, and it turned out all the tricky code is in the UI: Stopping the piece from colliding with others or the boundary and snapping it to the grid. I don't like the fact that the UI tells the game logic about the new state, I would rather have it call a movePieceLeft() method or something like that, as in my other games, but I didn't get far with that approach, because the game logic knows nothing about the dragging and snapping that's possible in the UI. I think the best thing to do would be to get rid of my game logic layer and implement a physics layer instead. I've got a few questions regarding that: Is such a physics layer common, or is it more typical to have the game logic layer do this? Would the snapping to grid and piece dragging code belong to the UI or the physics layer? Would such a physics layer typically work with pixel sizes or with some kind of logical unit, like my game logic layer? I've seen event-based collision detection in a game's code base once, that is, the player would just drag the piece, the UI would render that obediently and notify the physics system, and the physics system would call a onCollision() method on the piece once a collision is detected. What is more common? This approach or asking for the legal movement area first? [1] layer is probably not the right word for what I mean, but subsystem sounds overblown and class is misguiding, because each layer can consist of several classes.

    Read the article

  • How can I solve this SAT edge case?

    - by ssb
    I have an SAT implementation that basically works, and the fact that it works is what's giving me a few headaches. Basically there are some situations where using the SAT doesn't quite give me my intended result. One of these involves movement across multiple collision objects. Or to put it another way, if I have several collision boxes lined up next to each other such as to create something like a wall or a floor, movement along that surface while constantly applying force into that surface sometimes causes hangups, i.e. the player stops moving. This illustration shows what I mean: The 2 boxes on the bottom represent a floor, and the box on top/in the middle represents what my player is doing. There are several squares lined up as world obstacles to create some kind of wall, and if I move to the left across this surface while holding the down key then the issue arises. It only happens at the exact dividing point between two blocks. It only happens when moving to the left. At any rate I think I know why it happens, but I don't know how to solve it. Basically when I update my player movement I consider which directions are pressed, naturally, so if down is pressed I will add the speed to the Y component, and so on. But due to the way my SAT is implemented, when the penetration into the shape is the same from both sides it just goes with the smallest axis that it finds first, and it checks collisions against objects in the order that they were created because it goes through a foreach loop on the list of collidable objects. So this all adds up to the effect of if I'm moving to the left over a series of boxes while holding down, it will resolve me back to the right out of the first box and then up out of the box to the right of it, and this continues as long as the penetration is the same. The odd part is that this doesn't happen every time, which I am going to attribute to some oddity regarding multiplying velocity by the game time and causing some minor discrepancies between the lengths. Ultimately what this boils down to is that it will keep resolving me to the right and up, but this is technically expected behavior. All the solutions I can think of only address the symptoms of this problem and not the actual cause, such as not using many blocks to create walls or shapes, which is an option I'd like to keep open. I could also change which axis my algorithm defaults to, but that would just cause problems when going up/down along the walls. What can I do to fix this?

    Read the article

  • 5 Android Keyboard Replacements to Help You Type Faster

    - by Chris Hoffman
    Android allows developers to replace its keyboard with their own keyboard apps. This has led to experimentation and great new features, like the gesture-typing feature that’s made its way into Android’s official keyboard after proving itself in third-party keyboards. This sort of customization isn’t possible on Apple’s iOS or even Microsoft’s modern Windows environments. Installing a third-party keyboard is easy — install it from Google Play, launch it like another app, and it will explain how to enable it. Google Keyboard Google Keyboard is Android’s official keyboard, as seen on Google’s Nexus devices. However, there’s a good chance your Android smartphone or tablet comes with a keyboard designed by its manufacturer instead. You can install the Google Keyboard from Google Play, even if your device doesn’t come with it. This keyboard offers a wide variety of features, including a built-in gesture-typing feature, as popularized by Swype. It also offers prediction, including full next-word prediction based on your previous word, and includes voice recognition that works offline on modern versions of Android. Google’s keyboard may not offer the most accurate swiping feature or the best autocorrection, but it’s a great keyboard that feels like it belongs in Android. SwiftKey SwiftKey costs $4, although you can try it free for one month. In spite of its price, many people who rarely buy apps have been sold on SwiftKey. It offers amazing auto-correction and word-prediction features. Just mash away on your touch-screen keyboard, typing as fast as possible, and SwiftKey will notice your mistakes and type what you actually meant to type. SwiftKey also now has built-in support for gesture-typing via SwiftKey Flow, so you get a lot of flexibility. At $4, SwiftKey may seem a bit pricey, but give the month-long trial a try. A great keyboard makes all the typing you do everywhere on your phone better. SwiftKey is an amazing keyboard if you tap-to-type rather than swipe-to-type. Swype While other keyboards have copied Swype’s swipe-to-type feature, none have completely matched its accuracy. Swype has been designing a gesture-typing keyboard for longer than anyone else and its gesture feature still seems more accurate than its competitors’ gesture support. If you use gesture-typing all the time, you’ll probably want to use Swype. Swype can now be installed directly from Google Play without the old, tedious process of registering a beta account and sideloading the Swype app. Swype offers a month-long free trial and the full version is available for $1 afterwards. Minuum Minuum is a crowdfunded keyboard that is currently still in beta and only supports English. We include it here because it’s so interesting — it’s a great example of the kind of creativity and experimentation that happens when you allow developers to experiment with their own forms of keyboard. Minuum uses a tiny, minimum keyboard that frees up your screen space, so your touch-screen keyboard doesn’t hog your device’s screen. Rather than displaying a full keyboard on your screen, Minuum displays a single row of letters.  Each letter is small and may be difficult to hit, but that doesn’t matter — Minuum’s smart autocorrection algorithms interpret what you intended to type rather than typing the exact letters you press. Just swipe to the right to type a space and accept Minuum’s suggestion. At $4 for a beta version with no trial, Minuum may seem a bit pricy. But it’s a great example of the flexibility Android allows. If there’s a problem with this keyboard, it’s that it’s a bit late — in an age of 5″ smartphones with 1080p screens, full-size keyboards no longer feel as cramped. MessagEase MessagEase is another example of a new take on text input. Thankfully, this keyboard is available for free. MessagEase presents all letters in a nine-button grid. To type a common letter, you’d tap the button. To type an uncommon letter, you’d tap the button, hold down, and swipe in the appropriate direction. This gives you large buttons that can work well as touch targets, especially when typing with one hand. Like any other unique twist on a traditional keyboard, you’d have to give it a few minutes to get used to where the letters are and the new way it works. After giving it some practice, you may find this is a faster way to type on a touch-screen — especially with one hand, as the targets are so large. Google Play is full of replacement keyboards for Android phones and tablets. Keyboards are just another type of app that you can swap in. Leave a comment if you’ve found another great keyboard that you prefer using. Image Credit: Cheon Fong Liew on Flickr     

    Read the article

  • GUI device for throwing a ball

    - by Fredrik Johansson
    The hero has a ball, which shall be thrown with accuracy in a court on iPhone/iPad. The player is seen from above, in a 2D view. In game play, the player reach is between 1/15 and 1/6 of the height of the iPhone screen. The player will run, and try to outmaneuver his opponent, and then throw the ball at a specific location, which is guarded by the opponent (which is also shown on the screen). The player is controlled by a joystick, and that works ok, but how shall I control the stick? Maybe someone can propose a third control method? I've tried the following two approaches: Joystick: Hero has a reach of 1 meter, and this reach is marked with a semi-opaque circle around the player. The ball can be moved by a joystick. When the joystick is moved south, the ball is moved south within the reach circle. There is a direct coupling with the joystick and the position of the ball. I.e. when the joystick is moved max south, the ball is max south within the player reach. At each touch update the speed is calculated, and the Box2d ball position and ball speed are updated. NB, the ball will never be moved outside the reach as long as the player push the joystick. The ball is thrown by swiping the joystick to make the ball move, and then releasing the joystick. At release, the ball will get a smoothed speed of the joystick. Joystick Problem: The throwing accuracy gets bad, because the joystick can not be that big, and a small movement results in quite a large movement of the ball. If the user does not release before the end of the joystick maximum end point, the ball will stop, and when the user releases the joystick the speed of the ball will be zero. Bad... Touch pad A force is applied to the ball by a sweep on a touchpad. The ball is released when the sweep is ended, or when the ball is moved outside the player reach. As there is no one to one mapping between the swipe and the ball position, the precision can be improved. A large swipe can result in a small ball movement. Touch Pad Problem A touchpad is less intuitive. Users do not seem to know what to do with the touch pad. Some tap the touchpad, and then the ball just falls to the ground. As there is no one-to-one mapping, the ball can be moved outside the reach, and then it will just fall to the ground. It's a bit hard to control the ball, especially if the player also moves.

    Read the article

  • Particle and Physics problem.

    - by Quincy
    This was originally a forum post so I hope you guys don't mind it being 2 questions in one. I am making a game and I got some basic physics implemented. I have 2 problems, 1 with particles being drawn in the wrong place and one with going through walls while jumping in corners. Skip over to about 15 sec video showing the 2 problems : http://youtube.com/watch?v=Tm9nfWsWfiM So the problem with the particles seems to be coming from the removal, as soon as I remove that piece of code it instantly works, but there shouldn't be a problem since they shouldn't even draw when their energy gets to 0 (and then they get removed) So my first question is, how are these particles getting warped all over the screen ? Relevant code : Particle class : class Particle { //Physics public Vector2 position = new Vector2(0,0); public float direction = 180; public float speed = 100; public float energy = 1; protected float startEnergy = 1; //Visual public Sprite sprite; public float rotation = 0; public float scale = 1; public byte alpha = 255; public BlendMode blendMode { get { return sprite.BlendMode; } set { sprite.BlendMode = value; } } public Particle() { } public virtual void Think(float frameTime) { if (energy - frameTime < 0) energy = 0; else energy -= frameTime; position += new Vector2((float)Math.Cos(MathHelper.DegToRad(direction)), (float)Math.Sin(MathHelper.DegToRad(direction))) * speed * frameTime; alpha = (byte)(255 * energy / startEnergy); sprite.Rotation = rotation; sprite.Position = position; sprite.Color = new Color(sprite.Color.R, sprite.Color.G, sprite.Color.B, alpha); } public virtual void Draw(float frameTime) { if (energy > 0) { World.camera.DrawSprite(sprite); } } // Basic particle implementation class BasicSprite : Particle { public BasicSprite(Sprite _sprite) { sprite = _sprite; } } Emitter : class Emitter { protected static Random rand = new Random(); protected List<Particle> particles = new List<Particle>(); public BaseEntity target = null; public Vector2 position = new Vector2(0, 0); public bool Active = true; public float timeAlive = 0; public int particleCount = 0; public int ParticlesPerSeccond { get { return (int)(1 / particleSpawnTime); } set { particleSpawnTime = 1 / (float)value; } } public float dieTime = float.MaxValue; float particleSpawnTime = 0.05f; float spawnTime = 0; public Emitter() { } public virtual void Think(float frametime) { spawnTime += frametime; if (dieTime != float.MaxValue) { timeAlive += frametime; if (timeAlive >= dieTime) Active = false; } if (Active) { if (target != null) position = target.Position; while (spawnTime > particleSpawnTime) { spawnTime -= particleSpawnTime; AddParticle(); particleCount++; } } for (int i = 0; i < particles.Count; i++) { particles[i].Think(frametime); if (particles[i].energy <= 0) { particles.Remove(particles[i]); // As soon as this is removed, it works particleCount--; } } } public virtual void AddParticle() { } public virtual void Draw(float frametime) { foreach (Particle particle in particles) { particle.Draw(frametime); } } } class BloodEmitter : Emitter { Image image; public BloodEmitter() { image = new Image(@"Content/Particles/TinyCircle.png"); image.CreateMaskFromColor(new Color(255, 0, 255, 255)); this.dieTime = 0.5f; this.ParticlesPerSeccond = 100; } public override void AddParticle() { Sprite sprite = new Sprite(image); sprite.Color = new Color((byte)(rand.NextDouble() * 255), (byte)(rand.NextDouble() * 255), (byte)(rand.NextDouble() * 255)); BasicSprite particle = new BasicSprite(sprite); particle.direction = (float)rand.NextDouble() * 360; particle.position = position; particle.blendMode = BlendMode.Alpha; particles.Add(particle); } } The seccond problem is the physics problem, for some reason I can get through the right bottom corner while jumping. I think this is coming from me switching animations but I thought I made it compensate for that. Relevant code : PhysicsEntity : class PhysicsEntity : BaseEntity { // Horizontal movement constants protected const float maxHorizontalSpeed = 1000; protected const float horizontalAcceleration = 15; protected const float horizontalDragAir = 0.95f; protected const float horizontalDragGround = 0.95f; // Vertical movement constants protected const float maxVerticalSpeed = 1000; protected const float verticalAcceleration = 20; // Everything needed for movement and correct animations protected float movement = 0; protected bool onGround = false; protected Vector2 Velocity = new Vector2(0, 0); protected float maxSpeed = 0; float lastThink = 0; float thinkTime = 1f/60f; public PhysicsEntity(Vector2 position, Sprite sprite) : base(position, sprite) { } public override void Draw(float frameTime) { base.Draw(frameTime); } public override void Think(float frameTime) { CalculateMovement(frameTime); base.Think(frameTime); } protected void CalculateMovement(float frameTime) { lastThink += frameTime; while (lastThink > thinkTime) { onGround = false; Velocity.X = MathHelper.Clamp(Velocity.X + horizontalAcceleration * movement, -maxHorizontalSpeed, maxHorizontalSpeed); if (onGround) Velocity.X *= horizontalDragGround; else Velocity.X *= horizontalDragAir; if (maxSpeed < Velocity.X) maxSpeed = Velocity.X; Velocity.Y = MathHelper.Clamp(Velocity.Y + verticalAcceleration, -maxVerticalSpeed, maxVerticalSpeed); lastThink -= thinkTime; DoCollisions(thinkTime); DoAnimations(thinkTime); } } public virtual void DoAnimations(float frameTime) { } public void DoCollisions(float frameTime) { Position.Y += Velocity.Y * frameTime; Vector2 tileCollision = GetTileCollision(); if (tileCollision.X != -1 || tileCollision.Y != -1) { Vector2 collisionDepth = CollisionRectangle.DepthIntersection( new Rectangle( tileCollision.X * World.tileEngine.TileWidth, tileCollision.Y * World.tileEngine.TileHeight, World.tileEngine.TileWidth, World.tileEngine.TileHeight ) ); Position.Y += collisionDepth.Y; if (collisionDepth.Y < 0) onGround = true; Velocity.Y = 0; } Position.X += Velocity.X * frameTime; tileCollision = GetTileCollision(); if (tileCollision.X != -1 || tileCollision.Y != -1) { Vector2 collisionDepth = CollisionRectangle.DepthIntersection( new Rectangle( tileCollision.X * World.tileEngine.TileWidth, tileCollision.Y * World.tileEngine.TileHeight, World.tileEngine.TileWidth, World.tileEngine.TileHeight ) ); Position.X += collisionDepth.X; Velocity.X = 0; } } public void DoCollisions(Vector2 difference) { CollisionRectangle.Y = Position.Y - difference.Y; CollisionRectangle.Height += difference.Y; Vector2 tileCollision = GetTileCollision(); if (tileCollision.X != -1 || tileCollision.Y != -1) { Vector2 collisionDepth = CollisionRectangle.DepthIntersection( new Rectangle( tileCollision.X * World.tileEngine.TileWidth, tileCollision.Y * World.tileEngine.TileHeight, World.tileEngine.TileWidth, World.tileEngine.TileHeight ) ); Position.Y += collisionDepth.Y; if (collisionDepth.Y < 0) onGround = true; Velocity.Y = 0; } CollisionRectangle.X = Position.X - difference.X; CollisionRectangle.Width += difference.X; tileCollision = GetTileCollision(); if (tileCollision.X != -1 || tileCollision.Y != -1) { Vector2 collisionDepth = CollisionRectangle.DepthIntersection( new Rectangle( tileCollision.X * World.tileEngine.TileWidth, tileCollision.Y * World.tileEngine.TileHeight, World.tileEngine.TileWidth, World.tileEngine.TileHeight ) ); Position.X += collisionDepth.X; Velocity.X = 0; } } Vector2 GetTileCollision() { int topLeftTileX = (int)(CollisionRectangle.TopLeft.X / World.tileEngine.TileWidth); int topLeftTileY = (int)(CollisionRectangle.TopLeft.Y / World.tileEngine.TileHeight); int BottomRightTileX = (int)(CollisionRectangle.DownRight.X / World.tileEngine.TileWidth); int BottomRightTileY = (int)(CollisionRectangle.DownRight.Y / World.tileEngine.TileHeight); if (CollisionRectangle.DownRight.Y % World.tileEngine.TileHeight == 0) // If your exactly against the tile don't count that as being inside the tile BottomRightTileY -= 1; if (CollisionRectangle.DownRight.X % World.tileEngine.TileWidth == 0) // If your exactly against the tile don't count that as being inside the tile BottomRightTileX -= 1; for (int i = topLeftTileX; i <= BottomRightTileX; i++) { for (int j = topLeftTileY; j <= BottomRightTileY; j++) { if (World.tileEngine.TileIsSolid(i, j)) { return new Vector2(i, j); } } } return new Vector2(-1, -1); } } Player : enum State { Standing, Running, Jumping, Falling, Sliding, WallSlide } class Player : PhysicsEntity { private State state { get { return currentState; } set { if (currentState != value) { currentState = value; animationChanged = true; } } } private State currentState = State.Standing; private BasicEmitter basicEmitter = new BasicEmitter(); public bool flipped; public bool animationChanged = false; protected const float jumpPower = 600; AnimationManager animationManager; Rectangle DrawRectangle; public override Rectangle CollisionRectangle { get { return new Rectangle( Position.X - DrawRectangle.Width / 2f, Position.Y - DrawRectangle.Height / 2f, DrawRectangle.Width, DrawRectangle.Height ); } } public Player(Vector2 position, Sprite sprite) : base(position, sprite) { // Only posted the relevant bit DrawRectangle = animationManager.currentAnimation.drawingRectangle; } public override void Draw(float frameTime) { World.camera.DrawSprite( Sprite, Position + new Vector2(DrawRectangle.X, DrawRectangle.Y), animationManager.currentAnimation.drawingRectangle ); } public override void Think(float frameTime) { //I only posted the relevant stuff if (animationChanged) { // if the animation has changed make sure we compensate for the change in with and height animationChanged = false; DoCollisions(animationManager.getSizeDifference()); } DoCustomMovement(); base.Think(frameTime); if (!onGround && Velocity.Y > 0) { state = State.Falling; } } void DoCustomMovement() { if (onGround) { if (World.renderWindow.Input.IsKeyDown(KeyCode.W)) { Velocity.Y = -jumpPower; state = State.Jumping; } } } public override void DoAnimations(float frameTime) { string stateName = Enum.GetName(typeof(State), state); if (!animationManager.currentAnimationIs(stateName)) { animationManager.PlayAnimation(stateName); } animationManager.Think(frameTime); DrawRectangle = animationManager.currentAnimation.drawingRectangle; Sprite.Center = new Vector2( DrawRectangle.X + DrawRectangle.Width / 2, DrawRectangle.Y + DrawRectangle.Height / 2 ); Sprite.FlipX(flipped); } So why am I warping through walls ? I have given this some thought but I just can't seem to find out why this is happening. Full source if needed : source : http://www.mediafire.com/?rc7ddo09gnr68zd (download link)

    Read the article

  • How can I simulate objects floating on water without a physics engine?

    - by user1075940
    In my game the water movement is done in a shader using Gerstner equations. The water movement looks realistic enough for a school project but I encounter serious problem when I wanted to do sailing on waves (similar to this). I managed to do collision with land by calculating quad's vertices and normals beneath ship, however same method can not be applied to water because XZ are displaced and Y is calculated in a shader :( How to approach this problem ? Is it possible to retrieve transformed grid from shader? Unfortunately no external physics libraries can be used.

    Read the article

  • Moving AI in a multiplayer game

    - by Smallbro
    I've been programming a multiplayer game and its coming together very nicely. It uses both TCP and UDP (UDP for movement and TCP for just about everything else). What I was wondering was how I would go about sending multiple moving AI without much lag. At first I used TCP for everything and it was very slow when people moved. I'm currently using a butchered version of this http://corvstudios.com/tutorials/udpMultiplayer.php for my movement system and I'm wondering what the best method of sending AI movements is. By movements I mean the AI chooses left/right/up/down and the player can see this happening. Thanks.

    Read the article

  • Best way to handle realtime melee AI in authoritative network environment

    - by PrimeDerektive
    So i've been working on a multiplayer game for a bit; it's a co-op action RPG with real-time combat. If you've seen or played TERA, I'd say it's comparable to that, but not an MMO, heh. I'm currently handling the AI units authoritatively, the server calculates their pathing, movement, and pursue/attack logic, and syncs the movement to the clients 15x per second, and the state changes when they happen. When I emulate 200ms ping, though, the client can perceive being out of range to an AI's attack, but still take the hit, because on the server he hadn't moved that far yet. This also plays hell with my real-time blocking. I don't really want to allow the clients to be allowed to say "that was out of range" or "I blocked that", but I'm not really sure how else to handle it.

    Read the article

  • Tile-wide extent tracing on a grid.

    - by Larolaro
    I'm currently working on A* pathfinding on a grid and I'm looking to smooth the generated path, while also considering the extent of the character moving along it. I'm using a grid for the pathfinding, however character movement is free roaming, not strict tile to tile movement. To achieve a smoother, more efficient path, I'm doing line traces on a grid to determine if there is unwalkable tiles between tiles to shave off unecessary corners. However, because a line trace is zero extent, it doesn't consider the extent of the character and gives bad results (not returning unwalkable tiles just missed by the line, causing unwanted collisions). So what I'm looking for is rather than a line algorithm that determines the tiles under it, I'm looking for one that determines the tiles under a tile-wide extent line. Here is an image to help visualise my problem! Does anyone have any ideas? I've been working with Bresenham's line and other alternatives but I haven't yet figured out how to nail this specific problem.

    Read the article

  • OpenGL 2D Rasterization Sub-Pixel Translations

    - by Armin Ronacher
    I have a tile based 2D engine where the projection matrix is an orthographic view of the world without any scaling applied. Thus: one pixel texture is drawn on the screen in the same size. That all works well and looks nice but if the camera makes a sub-pixel movement small lines appear between the tiles. I can tell you in advance what does not fix the problem: GL_NEAREST texture interpolation GL_CLAMP_TO_EDGE What does “fix” the problem is anchoring the camera to the nearest pixel instead of doing a sub-pixel translation. I can live with that, but the camera movement becomes jerky. Any ideas how to fix that problem without resorting to the rounding trick I do currently?

    Read the article

  • Component based design, but components rely on eatchother

    - by MintyAnt
    I've begun stabbing at a "Component Based" game system. Basically, each entity holds a list of components to update (and render) I inherit the "Component" class and break each game system into it. Examples: RenderComponent - Draws the entity MovementComponent - Moves the entity, deals with velocity and speed checks DamageComponent - Deals with how/if the entity gets damaged... So. My system has this: MovementComponent InputComponent Now maybe my design is off, but the InputComponent should say things like if (w key is down) add y speed to movement if (x key is down) Trigger primary attack This means that the InputComponent sort of relies on these other components. I have to do something alone the lines of: if (w key is down) { MovementComponent* entityMovement = mEntity->GetMovement(); if (entityMovement != NULL) add y speed to movement } which seems kinda crappy every update. Other options? Better design? Is this the best way? Thanks!

    Read the article

  • Developing GLSL Shaders?

    - by skln
    I want to create shaders but I need a tool to create and see the visual result before I put them into my game. As to determine if there is something wrong with my game or if it's something with the shader I created. I've looked at some like Render Monkey and OpenGL Shader Designer from what I recall of Render Monkey it had a way to define your own attributes (now as "in" for vertex shaders = 330) easily though I can't remember to what extent. Shader Designer requires a plugin that I didn't even bother to look at creating cause it's an external process and plugin. Are there any tools out there that support a scripting language and I could easily provide specific input such as float movement = sin(elapsedTime()); and then define in float movement; in the vertex shader ? It'd be cool if anyone could share how they develop shaders, if they just code away and then plug it into their game hoping to get the result they wanted.

    Read the article

  • Calculating angle between 2 vectors

    - by Error 454
    I am working on some movement AI where there are no obstacles and movement is restricted to the XY plane. I am calculating 2 vectors: v - the direction of ship 1 w - the vector pointing from the position of ship 1 to ship 2 I am then calculating the angle between these two vectors using the standard formula: arccos( v . w / ( |v| |w| ) ) The problem I'm having is the nature of arccos only returning values between 0 and 180. This makes it impossible to determine whether I should turn left or right to face the other ship. Is there a better way to do this?

    Read the article

  • How to simulate objects floating on water without a physics engine?

    - by user1075940
    In my game the water movement is done in a shader using Gerstner equations. The water movement looks realistic enough for a school project but I encounter serious problem when I wanted to do sailing on waves (similar to this). I managed to do collision with land by calculating quad's vertices and normals beneath ship, however same method can not be applied to water because XZ are displaced and Y is calculated in a shader :( How to approach this problem ? Is it possible to retrieve transformed grid from shader? Unfortunately no external physics libraries can be used.

    Read the article

  • How can I calculate the angle between two 2D vectors?

    - by Error 454
    I am working on some movement AI where there are no obstacles and movement is restricted to the XY plane. I am calculating two vectors, v, the facing direction of ship 1, and w, the vector pointing from the position of ship 1 to ship 2. I am then calculating the angle between these two vectors using the formula arccos((v · w) / (|v| · |w|)) The problem I'm having is that arccos only returns values between 0° and 180°. This makes it impossible to determine whether I should turn left or right to face the other ship. Is there a better way to do this?

    Read the article

  • possible to constrain jQuery resize to x or y axis, like drag constrain?

    - by Tim
    This jQuery lets you constrain drag movement so it occurs only on the axis specified: $("#draggable2").draggable({ axis: 'x' }); See: http://jqueryui.com/demos/draggable/#constrain-movement This is not legal jQuery but I wish it were: $("#Container").resizable({ minHeight: 150, containment: {axis:'y' } }); Is it possible to prevent the user from making #Container wider while allowing her to make it taller? Thanks

    Read the article

  • Gradient boosting predictions in low-latency production environments?

    - by lockedoff
    Can anyone recommend a strategy for making predictions using a gradient boosting model in the <10-15ms range (the faster the better)? I have been using R's gbm package, but the first prediction takes ~50ms (subsequent vectorized predictions average to 1ms, so there appears to be overhead, perhaps in the call to the C++ library). As a guideline, there will be ~10-50 inputs and ~50-500 trees. The task is classification and I need access to predicted probabilities. I know there are a lot of libraries out there, but I've had little luck finding information even on rough prediction times for them. The training will happen offline, so only predictions need to be fast -- also, predictions may come from a piece of code / library that is completely separate from whatever does the training (as long as there is a common format for representing the trees).

    Read the article

  • A Visual Studio tool eliminating the need to rewrite for web and mobile

    - by Visual WebGui
    We have already covered the BYOD requirements that an application developer is faced with, in an earlier blog entry ( How to Bring Your Own Device (BYOD) to a .NET application ). In that entry we emphasized the fact that application developers will need to prepare their applications for serving multiple types of devices on multiple platforms, ranging from the smallest mobile devices up to and beyond the largest desktop devices. The experts prediction is that in the near future we will see that the...(read more)

    Read the article

  • Google I/O 2011: Smart App Design

    Google I/O 2011: Smart App Design Travis Green, Max Lin, Robert Kaplow, Jóhannes Kristinsson, Ryan McGee Learn how to recommend the unexpected, automate the repetitive, and distill the essential using machine learning. This session will show you how you can easily add smarts to your apps with the Prediction API, and how to create apps that rapidly adapt to new data. From: GoogleDevelopers Views: 10078 47 ratings Time: 01:01:04 More in Science & Technology

    Read the article

  • 3D Ball Physics Theory: collision response on ground and against walls?

    - by David
    I'm really struggling to get a strong grasp on how I should be handling collision response in a game engine I'm building around a 3D ball physics concept. Think Monkey Ball as an example of the type of gameplay. I am currently using sphere-to-sphere broad phase, then AABB to OBB testing (the final test I am using right now is one that checks if one of the 8 OBB points crosses the planes of the object it is testing against). This seems to work pretty well, and I am getting back: Plane that object is colliding against (with a point on the plane, the plane's normal, and the exact point of intersection. I've tried what feels like dozens of different high-level strategies for handling these collisions, without any real success. I think my biggest problem is understanding how to handle collisions against walls in the x-y axes (left/right, front/back), which I want to have elasticity, and the ground (z-axis) where I want an elastic reaction if the ball drops down, but then for it to eventually normalize and be kept "on the ground" (not go into the ground, but also not continue bouncing). Without kluging something together, I'm positive there is a good way to handle this, my theories just aren't getting me all the way there. For physics modeling and movement, I am trying to use a Euler based setup with each object maintaining a position (and destination position prior to collision detection), a velocity (which is added onto the position to determine the destination position), and an acceleration (which I use to store any player input being put on the ball, as well as gravity in the z coord). Starting from when I detect a collision, what is a good way to approach the response to get the expected behavior in all cases? Thanks in advance to anyone taking the time to assist... I am grateful for any pointers, and happy to post any additional info or code if it is useful. UPDATE Based on Steve H's and eBusiness' responses below, I have adapted my collision response to what makes a lot more sense now. It was close to right before, but I didn't have all the right pieces together at the right time! I have one problem left to solve, and that is what is causing the floor collision to hit every frame. Here's the collision response code I have now for the ball, then I'll describe the last bit I'm still struggling to understand. // if we are moving in the direction of the plane (against the normal)... if (m_velocity.dot(intersection.plane.normal) <= 0.0f) { float dampeningForce = 1.8f; // eventually create this value based on mass and acceleration // Calculate the projection velocity PVRTVec3 actingVelocity = m_velocity.project(intersection.plane.normal); m_velocity -= actingVelocity * dampeningForce; } // Clamp z-velocity to zero if we are within a certain threshold // -- NOTE: this was an experimental idea I had to solve the "jitter" bug I'll describe below float diff = 0.2f - abs(m_velocity.z); if (diff > 0.0f && diff <= 0.2f) { m_velocity.z = 0.0f; } // Take this object to its new destination position based on... // -- our pre-collision position + vector to the collision point + our new velocity after collision * time // -- remaining after the collision to finish the movement m_destPosition = m_position + intersection.diff + (m_velocity * intersection.tRemaining * GAMESTATE->dt); The above snippet is run after a collision is detected on the ball (collider) with a collidee (floor in this case). With a dampening force of 1.8f, the ball's reflected "upward" velocity will eventually be overcome by gravity, so the ball will essentially be stuck on the floor. THIS is the problem I have now... the collision code is running every frame (since the ball's z-velocity is constantly pushing it a collision with the floor below it). The ball is not technically stuck, I can move it around still, but the movement is really goofy because the velocity and position keep getting affected adversely by the above snippet. I was experimenting with an idea to clamp the z-velocity to zero if it was "close to zero", but this didn't do what I think... probably because the very next frame the ball gets a new gravity acceleration applied to its velocity regardless (which I think is good, right?). Collisions with walls are as they used to be and work very well. It's just this last bit of "stickiness" to deal with. The camera is constantly jittering up and down by extremely small fractions too when the ball is "at rest". I'll keep playing with it... I like puzzles like this, especially when I think I'm close. Any final ideas on what I could be doing wrong here? UPDATE 2 Good news - I discovered I should be subtracting the intersection.diff from the m_position (position prior to collision). The intersection.diff is my calculation of the difference in the vector of position to destPosition from the intersection point to the position. In this case, adding it was causing my ball to always go "up" just a little bit, causing the jitter. By subtracting it, and moving that clamper for the velocity.z when close to zero to being above the dot product (and changing the test from <= 0 to < 0), I now have the following: // Clamp z-velocity to zero if we are within a certain threshold float diff = 0.2f - abs(m_velocity.z); if (diff > 0.0f && diff <= 0.2f) { m_velocity.z = 0.0f; } // if we are moving in the direction of the plane (against the normal)... float dotprod = m_velocity.dot(intersection.plane.normal); if (dotprod < 0.0f) { float dampeningForce = 1.8f; // eventually create this value based on mass and acceleration? // Calculate the projection velocity PVRTVec3 actingVelocity = m_velocity.project(intersection.plane.normal); m_velocity -= actingVelocity * dampeningForce; } // Take this object to its new destination position based on... // -- our pre-collision position + vector to the collision point + our new velocity after collision * time // -- remaining after the collision to finish the movement m_destPosition = m_position - intersection.diff + (m_velocity * intersection.tRemaining * GAMESTATE->dt); UpdateWorldMatrix(m_destWorldMatrix, m_destOBB, m_destPosition, false); This is MUCH better. No jitter, and the ball now "rests" at the floor, while still bouncing off the floor and walls. The ONLY thing left is that the ball is now virtually "stuck". He can move but at a much slower rate, likely because the else of my dot product test is only letting the ball move at a rate multiplied against the tRemaining... I think this is a better solution than I had previously, but still somehow not the right idea. BTW, I'm trying to journal my progress through this problem for anyone else with a similar situation - hopefully it will serve as some help, as many similar posts have for me over the years.

    Read the article

facebook twitter digg google delicious technorati stumbleupon myspace wordpress linkedin gmail igoogle windows live tumblr viadeo yahoo buzz yahoo mail yahoo bookmarks favorites email print

< Previous Page | 11 12 13 14 15 16 17 18 19 20 21 22  | Next Page >